Thread

1. Re: splitting pg_resetwal output strings

   Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-05-23T15:31:57Z

   Hello!
   
   I've tested the patch, and I found that in the first patch, the nsl.mk
   file is changed to match the first argument of CONTROLDATA_LINE as the
   string to match:
   
   +GETTEXT_TRIGGERS = $(FRONTEND_COMMON_GETTEXT_TRIGGERS) \
   +				  CONTROLDATA_LINE:1
   
   but in the second patch the CONTROLDATA_LINE moves the strings to the
   second argument:
   
   -CONTROLDATA_LINE("pg_control version number",
   +CONTROLDATA_LINE(CD_CONTROL_VERSION, "pg_control version number",
    				"%u", ControlFile.pg_control_version)
   
   While keeping the argument as it is, I suggest to switch to
   CONTROLDATA_LINE:2 like this:
   
   +GETTEXT_TRIGGERS = $(FRONTEND_COMMON_GETTEXT_TRIGGERS) \
   +				  CONTROLDATA_LINE:2
   
   This will make `make update-po` take the strings from entries.h, which
   is what I was expecting.
   
   During testing, I found a couple of things that may be interesting, or
   at least worth keeping in mind for the future implementation already
   mentioned [1].
   
   Even if the spacing calculation is correct, I found that the font size
   is not the same for different languages, so if a strings or part of it,
   is translated into, for example, Hindi, and most of it it's in English,
   it will affect how it look in the terminal, meaning that it's probably
   that a the second column will be moved to the left generating a
   misalignment in the printed data
   
   Regards!
   
   [1]
   https://www.postgresql.org/message-id/202509300530.jnwbfyrdxaah%40alvherre.pgsql
   [2] https://sw.kovidgoyal.net/kitty/
   
   -- 
   Jonathan Gonzalez V. 
   EDB: https://www.enterprisedb.com
   

2. Re: splitting pg_resetwal output strings

   Álvaro Herrera <alvherre@kurilemu.de> — 2026-05-24T03:50:48Z

   On 2026-May-23, Jonathan Gonzalez V. wrote:
   
   > Hello!
   > 
   > I've tested the patch, and I found that in the first patch, the nsl.mk
   > file is changed to match the first argument of CONTROLDATA_LINE as the
   > string to match:
   [...]
   > While keeping the argument as it is, I suggest to switch to
   > CONTROLDATA_LINE:2 like this:
   
   Yeah, you're correct, this is a bug in 0002.  Thanks!
   
   > During testing, I found a couple of things that may be interesting, or
   > at least worth keeping in mind for the future implementation already
   > mentioned [1].
   > 
   > Even if the spacing calculation is correct, I found that the font size
   > is not the same for different languages, so if a strings or part of it,
   > is translated into, for example, Hindi, and most of it it's in English,
   > it will affect how it look in the terminal, meaning that it's probably
   > that a the second column will be moved to the left generating a
   > misalignment in the printed data
   
   I don't think varying font width is something we should care about.  The
   multibyte system has a mechanism to tell us how wide the characters are,
   in units of some monospace font.  This is what the pg_wcswidth calls are
   there for (or internal_wcslength in the patch).  If the terminal doesn't
   align the characters correctly according to the declared width because
   different fonts are used, that's not our bug.
   
   The idea behind the patch is to measure the length of all strings after
   translation.  If a number of the strings are not translated, then we
   still measure them in their final presentation form.  Then we align the
   two columns based on the maximum length of all strings.  I don't think
   this is any worse than what you get with the original code; if a
   translator has chosen a different alignment than what English has, and
   some strings are not translated, then the output will appear misaligned.
   In fact, with the code it will be better (assuming no font issues),
   because we will try to align correctly even the strings that aren't
   translated.  In fact, if fonts differ, there's nothing the translator
   can do, because there's no way to know what's the user going to do at
   runtime -- users are going to have different terminals and different
   fonts.
   
   > [2] https://sw.kovidgoyal.net/kitty/
   
   Hmm, I'm not sure what you wanted to show with this URL -- can you
   elaborate?
   
   -- 
   Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
   
   
   
   

3. Re: splitting pg_resetwal output strings

   Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-05-24T09:48:13Z

   [...]
   
   > I don't think varying font width is something we should care about. 
   > The
   > multibyte system has a mechanism to tell us how wide the characters
   > are,
   > in units of some monospace font.  This is what the pg_wcswidth calls
   > are
   > there for (or internal_wcslength in the patch).  If the terminal
   > doesn't
   > align the characters correctly according to the declared width
   > because
   > different fonts are used, that's not our bug.
   
   Exactly, I forgot to clarify that this is to keep in mind if someone
   else want to test and reach the same point and had the same questions.
   
   
   
   > > [2] https://sw.kovidgoyal.net/kitty/
   > 
   > Hmm, I'm not sure what you wanted to show with this URL -- can you
   > elaborate?
   
   Just an example of a terminal if someone wants to test something
   different, but yeah lack of context.
   
   -- 
   Jonathan Gonzalez V. 
   EDB: https://www.enterprisedb.com
   

4. Re: splitting pg_resetwal output strings

   Jonathan Gonzalez V. <jonathan.abdiel@gmail.com> — 2026-05-24T10:10:05Z

   Hello,
   
   On a second round a notice these two strings:
   
   +               char *str = "First log segment after reset";
   +               thislen = internal_wcswidth(_(str), strlen(_(str)),
   encoding);
   +               if (thislen > maxlen)
   
   and 
   
   +               char *str = "First log segment after reset";
   +               thislen = internal_wcswidth(_(str), strlen(_(str)),
   encoding);
   +               if (thislen > maxlen)
   
   Are never catch by the `make update-po` command, instead, the strings
   are there in the `.po.new` file commented.
   
   Should we put them between `_()`? or is expected that it's being catch
   by the second line with the `_()` ?
   
   -- 
   Jonathan Gonzalez V. 
   EDB: https://www.enterprisedb.com
   

5. Re: splitting pg_resetwal output strings

   Álvaro Herrera <alvherre@kurilemu.de> — 2026-05-24T11:35:59Z

   Hi,
   
   On 2026-May-24, Jonathan Gonzalez V. wrote:
   
   > On a second round a notice these two strings:
   > 
   > +               char *str = "First log segment after reset";
   > +               thislen = internal_wcswidth(_(str), strlen(_(str)),
   > encoding);
   > +               if (thislen > maxlen)
   > 
   > and [...]
   
   > Are never catch by the `make update-po` command, instead, the strings
   > are there in the `.po.new` file commented.
   > 
   > Should we put them between `_()`? or is expected that it's being catch
   > by the second line with the `_()` ?
   
   Hmm, yeah, they need to be wrapped in gettext_noop() so that they are
   not immediately translated (because that will be done by the _() call in
   the other lines) but are picked up by msgmerge.  (I think the second one
   you reference is "NextXID epoch" but it was victim of a copy-paste
   failure.)
   
   Thanks again for looking,
   
   -- 
   Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/