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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 19, 2017, 21:32 UTC
Message-ID: <xmqqd18wm7t6.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.21.1.1707191456010.4193@virtualbox>

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

Show 8 quoted lines

>> Gettext handles macros such as PRIuMAX in commit 8b45c5df1 ("Add
>> support for ISO C 99 <inttypes.h> format string directive macros.",
>> 2002-07-23 12:33:13 +0000).
>
> Wow. This is ugly.
>
> If I understand correctly, then this will not even work correctly for
> PRIuMAX on Windows: ...

I think it is the other way around. Without such a special-casing, and producing message identifier that has "%<PRIuMAX>" in it, they cannot get a .po source that is usable across platforms.

Imagine a hypothetical xgettext that does not have the special case, but just does what CPP does. Running it on a platform where uintmax_t is "unsigned long" would have "%lu" in resulting .po for a message that uses "%" + PRIuMAX. But the same source compiled on a platform where uintmax_t is larger would pass "%llu" in calls to _(...) it makes; such a string will not be found at runtime in the corresponding .mo file, because you started with "%lu" in the .po file. By leaving a special marker %<PRIuMAX> in the .po file by special casing, the toolchain can make sure that the actual parameter given to a _(...) can be found at runtime in .mo file that was produced by compiling the .po file for the target platform.

So our own PRItime was a good idea for maintainability's point of view of _our_ code, but it was not very friendly to i18n.

I can see two possibly usable approaches to make it i18n-friendly while retaining our ability to later change the underlying type of timestamp_t. But neither is very pretty.

 - One is what was in Jiang's earlier proposal.

 - Another is to replace PRItime with PRIuMAX _but_ leave a comment
   to tell us that it wanted to be PRItime, so that we can later
   "git grep" for such a comment if/when we want to update the type
   of timestamp_t.