I found it annoying that sql_help.c contains a literal parameter as a
translatable string.
The cause is that create_help.pl treats <literal>match</> as a
replaceable. The attached excludes literals from translatable strings.
By a quick look it seems to me that the "match" in "COPY.. HEADER
match" is the first and only instance of a literal parameter as of
PG15.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 81770afd9df6f073c50f875b2dd540273ecc15fa Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyota....@gmail.com>
Date: Tue, 17 May 2022 17:37:33 +0900
Subject: [PATCH] Do not treat <literal> words as translatable
create_help.pl extracts <literal> words as translatable but actually
they are untranslatable. Exclude such words from translatable words
so that translators don't mistakenly translate the words.
---
src/bin/psql/create_help.pl | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/bin/psql/create_help.pl b/src/bin/psql/create_help.pl
index 1a9836cbcc..9919aaf4e7 100644
--- a/src/bin/psql/create_help.pl
+++ b/src/bin/psql/create_help.pl
@@ -138,6 +138,11 @@ foreach my $file (sort readdir DIR)
while ($cmdsynopsis =~ m!<(\w+)[^>]*>(.+?)</\1[^>]*>!)
{
+ if ($1 eq "literal")
+ {
+ $cmdsynopsis =~ s!<(\w+)[^>]*>(.+?)</\1[^>]*>!\2!;
+ next;
+ }
my $match = $2;
$match =~ s/<[^>]+>//g;
$match =~ s/%%/%/g;
--
2.27.0
