Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Sat, 22 Jul 2017, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. > > Oh, I missed that. That's even worse, as it precludes what you were > wishing for: to replace timestamp_t by a signed data type eventually. Yup, Jiang's plan was to update the custom edition of xgettext when it happens and the Makefile patch has a provision to avoid mistakes. If Jiang's patch were extended so that xgettext would take a command line option "--custom-priformat=PRItime=PRIuMAX" and upstreamed and wildy deployed already, that would have been a good solution. That might be a preferred outcome that may benefit other projects, but it won't happen for at least 3 years if not more X-<.
