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

[Junio C Hamano <gitster@pobox.com>]

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

>> >> 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.