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

[Jiang Xin <worldhello.net@gmail.com>]

2017-07-22 23:48 GMT+08:00 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.
>

I appreciate Junio's explanation. I totally agree.

-- 
Jiang Xin