Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 22, 2017, 15:48 UTC
Message-ID: <xmqqeft8fp5j.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.21.1.1707221323420.4271@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 20 quoted lines

>> >> A very small hack on gettext.
>
> I am 100% opposed to this hack. It is already cumbersome enough to find
> out what is involved in i18n (it took *me* five minutes to find out that
> much of the information is in po/README, with a lot of information stored
> *on an external site*, and I still managed to miss the `make pot` target).
>
> If at all, we need to make things easier instead of harder.
>
> Requiring potential volunteers to waste their time to compile an
> unnecessary fork of gettext? Not so great an idea.
>
> Plus, each and every Git build would now have to compile their own
> gettext, too, as the vanilla one would not handle the .po files containing
> %<PRItime>!!!
>
> And that requirement would impact instantaneously people like me, and even
> worse: some other packagers might be unaware of the new requirement which
> would not be caught during the build, and neither by the test suite.
> Double bad idea.

If I understand correctly, the patch hacks the input processing of xgettext (which reads our source code and generates po/git.pot) so that when it sees PRItime, pretend that it saw PRIuMAX, causing it to output %<PRIuMAX> in its output.

In our workflow,

    * The po/git.pot file is updated only by the l10n coordinator,
      and then the result is committed to our tree.

    * Translators build on that commit by (1) running msgmerge which
      takes po/git.pot and wiggles its entries into their existing
      po/$lang.po file so that po/$lang.po file has new entries from
      po/git.pot and (2) editing po/$lang.po file.  The result is
      committed to our tree.

    * The build procedure builders use runs the resulting
      po/$lang.po files through msgfmt to produce po/$lang.mo files,
      which will be installed.

As long as the first step results in %<PRIuMAX> (not %<PRItime> or anything that plain vanilla msgmerge and msgfmt do not understand), the second step and third step do not require any hacked version of gettext tools.

Even though I tend to agree with your conclusion that pre-processing our source before passing it to xgettext is probably a better solution in the longer term, I think the most of the objections in your message come from your misunderstanding of what Jiang's patch does and are not based on facts. My understanding is that translators do not need to compile a custom msgmerge and builders do not need a custom msgfmt.