Thread: add more NLS to bin
Here is a series of patches to add NLS to the remaining bin programs, which were moved from contrib a while ago. (If you're missing pgbench, I'm skipping that for now because it's more complicated.) I'll add this to the commit fest. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Thu, Oct 27, 2016 at 10:02 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > Here is a series of patches to add NLS to the remaining bin programs, > which were moved from contrib a while ago. (If you're missing pgbench, > I'm skipping that for now because it's more complicated.) I'll add this > to the commit fest. +1. Side question just for curiosity: when is AVAIL_LANGUAGES filled? Once the translations are added to the tree? -- Michael
On 10/26/16 9:18 PM, Michael Paquier wrote: > Side question just for curiosity: when is AVAIL_LANGUAGES filled? Once > the translations are added to the tree? Yes, that happens when the translations are copied in before a release. See here for the script that is normally used: https://git.postgresql.org/gitweb/?p=pgtranslation/admin.git;a=blob;f=cp-po;h=5b569a43e39a7c1fd5e28ba00a6708995df1b445;hb=57f0390ed14ecb974d2bde6242ce7b268e8261d2#l216 -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Oct 27, 2016 at 10:27 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 10/26/16 9:18 PM, Michael Paquier wrote: >> Side question just for curiosity: when is AVAIL_LANGUAGES filled? Once >> the translations are added to the tree? > > Yes, that happens when the translations are copied in before a release. > > See here for the script that is normally used: > https://git.postgresql.org/gitweb/?p=pgtranslation/admin.git;a=blob;f=cp-po;h=5b569a43e39a7c1fd5e28ba00a6708995df1b445;hb=57f0390ed14ecb974d2bde6242ce7b268e8261d2#l216 Ah, thanks. That explains the whole thing! -- Michael
On Thu, Oct 27, 2016 at 10:02 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> Here is a series of patches to add NLS to the remaining bin programs,
> which were moved from contrib a while ago. (If you're missing pgbench,
> I'm skipping that for now because it's more complicated.) I'll add this
> to the commit fest.
I have been looking at this patch set, and that's definitely a good
idea to do this change.
1) 0001 for pg_archivecleanup is missing nothing.
2) For 0002 and pg_test_fsync, I am seeing a missing entry: printf(NA_FORMAT, "n/a*\n");
3) For pg_test_timing, the doc changes could be into a separate
change, but that's fine to group them as well. I am seeing no missing
strings for translations.
4) 0004 and pg_upgrade... In check.c, three places like that: if (!db_used) {
fprintf(script,"Database: %s\n", active_db->db_name); db_used = true; }
In exec.c:
#endif fprintf(log, "command: %s\n", cmd);
#ifdef WIN32
+GETTEXT_FLAGS = \
+ pg_fatal:1:c-format \
+ pg_log:2:c-format \
+ prep_status:1:c-format \
+ report_stats:2:c-forma
s/report_stats/report_status/
In info.c, missing some entries in report_unmatched_relation() when
reporting unmatching relations?
In parseCommandLine() of option.c, the "pg_upgrade run on" string
needs to be handled.
In util.c, doesn't pg_log_v() need to handle strings used in fprintf?
In version.c, this one: if (!db_used) { fprintf(script, "Database: %s\n",
active_db->db_name); db_used = true; }
5) 0005 and pg_xlogdump, I am not seeing a missing entry.
--
Michael
On 10/31/16 1:58 AM, Michael Paquier wrote:
> 2) For 0002 and pg_test_fsync, I am seeing a missing entry:
> printf(NA_FORMAT, "n/a*\n");
ok
> 4) 0004 and pg_upgrade... In check.c, three places like that:
> if (!db_used)
> {
> fprintf(script, "Database: %s\n", active_db->db_name);
> db_used = true;
> }
>
> In exec.c:
> #endif
> fprintf(log, "command: %s\n", cmd);
> #ifdef WIN32
These and several of the other places write into log or script files. I
have chosen not to do anything about those for now. That might be a
future change, or we just leave them.
> +GETTEXT_FLAGS = \
> + pg_fatal:1:c-format \
> + pg_log:2:c-format \
> + prep_status:1:c-format \
> + report_stats:2:c-forma
> s/report_stats/report_status/
ok
> In info.c, missing some entries in report_unmatched_relation() when
> reporting unmatching relations?
Yeah, that will need a bit of a rewrite, so FIXME later?
> In util.c, doesn't pg_log_v() need to handle strings used in fprintf?
Which specific lines do you have in mind?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Nov 4, 2016 at 1:44 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 10/31/16 1:58 AM, Michael Paquier wrote: >> In info.c, missing some entries in report_unmatched_relation() when >> reporting unmatching relations? > > Yeah, that will need a bit of a rewrite, so FIXME later? This patch not being complicated, so I would vote for those being addressed now so as they are not forgotten even if there is a FIXME flag added. Perhaps you don't think so, and as that's a minor issue I'll be fine with your judgement as well. >> In util.c, doesn't pg_log_v() need to handle strings used in fprintf? > > Which specific lines do you have in mind? The verbose logs at the top. In pg_rewind for example those logs are getting translated via the pg_log() calls used with PG_DEBUG. -- Michael
On 11/3/16 7:17 PM, Michael Paquier wrote: > This patch not being complicated, so I would vote for those being > addressed now so as they are not forgotten even if there is a FIXME > flag added. Perhaps you don't think so, and as that's a minor issue > I'll be fine with your judgement as well. OK, I just wrapped it in translation markers as is, which should work well enough. >>> In util.c, doesn't pg_log_v() need to handle strings used in fprintf? >> >> Which specific lines do you have in mind? > > The verbose logs at the top. In pg_rewind for example those logs are > getting translated via the pg_log() calls used with PG_DEBUG. Yeah that was wrong anyway. The previously existing translation markers were wrong. We want to translate the fmt, not the formatted message. New patch attached. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Sat, Nov 5, 2016 at 9:17 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 11/3/16 7:17 PM, Michael Paquier wrote: >> This patch not being complicated, so I would vote for those being >> addressed now so as they are not forgotten even if there is a FIXME >> flag added. Perhaps you don't think so, and as that's a minor issue >> I'll be fine with your judgement as well. > > OK, I just wrapped it in translation markers as is, which should work > well enough. Agreed. I don't see anything wrong with that. >>>> In util.c, doesn't pg_log_v() need to handle strings used in fprintf? >>> >>> Which specific lines do you have in mind? >> >> The verbose logs at the top. In pg_rewind for example those logs are >> getting translated via the pg_log() calls used with PG_DEBUG. > > Yeah that was wrong anyway. The previously existing translation markers > were wrong. We want to translate the fmt, not the formatted message. Does using one way or the other actually change something? Because pg_rewind/logging.c is not marking fmt but the message, the opposite of your v2 patch. One way or the other, having consistency for both would be nice. The patch looks good to me, the instructions for the script could be changed... But you are right let's not mess up with non-ASCII characters in it, like from some Asian language translation. -- Michael
On 11/5/16 8:03 AM, Michael Paquier wrote: >> > Yeah that was wrong anyway. The previously existing translation markers >> > were wrong. We want to translate the fmt, not the formatted message. > Does using one way or the other actually change something? Because > pg_rewind/logging.c is not marking fmt but the message, the opposite > of your v2 patch. One way or the other, having consistency for both > would be nice. Consider the following for example: pg_log(PG_DEBUG, "fetched file \"%s\", length %d\n", filename, len); If you pass fmt to gettext(), then it will look up the string that you see in the code. If you pass the formatted message to gettext(), then it will look up something like "fetched file \"foo\", length 12\n" which it will not find, unless you provide translations for all combinations of file names and lengths. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11/5/16 8:03 AM, Michael Paquier wrote: > On Sat, Nov 5, 2016 at 9:17 AM, Peter Eisentraut > <peter.eisentraut@2ndquadrant.com> wrote: >> > On 11/3/16 7:17 PM, Michael Paquier wrote: >>> >> This patch not being complicated, so I would vote for those being >>> >> addressed now so as they are not forgotten even if there is a FIXME >>> >> flag added. Perhaps you don't think so, and as that's a minor issue >>> >> I'll be fine with your judgement as well. >> > >> > OK, I just wrapped it in translation markers as is, which should work >> > well enough. > Agreed. I don't see anything wrong with that. committed and closed the patch -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Nov 8, 2016 at 12:13 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 11/5/16 8:03 AM, Michael Paquier wrote: >> On Sat, Nov 5, 2016 at 9:17 AM, Peter Eisentraut >> <peter.eisentraut@2ndquadrant.com> wrote: >>> > On 11/3/16 7:17 PM, Michael Paquier wrote: >>>> >> This patch not being complicated, so I would vote for those being >>>> >> addressed now so as they are not forgotten even if there is a FIXME >>>> >> flag added. Perhaps you don't think so, and as that's a minor issue >>>> >> I'll be fine with your judgement as well. >>> > >>> > OK, I just wrapped it in translation markers as is, which should work >>> > well enough. >> Agreed. I don't see anything wrong with that. > > committed and closed the patch Thanks for adjusting pg_rewind as well. -- Michael