2017-07-22 23:48 GMT+08:00 Junio C Hamano <gits...@pobox.com>: > Johannes Schindelin <johannes.schinde...@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
