Message-ID: <3879e664-a29e-4b9b-9c83-1ffdc618d52a@gmail.com>
Date: Mon, 8 Dec 2025 13:41:45 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Let's add a test for NLS translation of PRI* macros
To: pgsql-hackers@lists.postgresql.org
References: <3098752.1765221796@sss.pgh.pa.us>
Content-Language: en-US
From: Bryan Green <dbryan.green@gmail.com>
In-Reply-To: <3098752.1765221796@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/3879e664-a29e-4b9b-9c83-1ffdc618d52a%40gmail.com>
Precedence: bulk

On 12/8/2025 1:23 PM, Tom Lane wrote:
> This was discussed a few weeks ago in [1], but I'm starting a
> new thread so as not to confuse things with the latest patches in
> that thread.  The issue is that it seems like it'd be a good idea to
> have specific regression testing of whether translation of the
> <inttypes.h> PRI* macros works properly, since that is an aspect
> of gettext() behavior that didn't use to work everywhere.
> 
> I don't know whether the attached will pass on Windows: we might
> not be able to assume that "es_ES" is the right LC_MESSAGES
> setting to use.  But it works for me on Linux.
> 
> 			regards, tom lane
> 
> [1] https://www.postgresql.org/message-id/flat/20250331.152829.1921392690375275165.horikyota.ntt%40gmail.com
> 
gettext() will be fine with that if you are using < 0.20.  After that
version it expects you to send it the windows locale, not the
IsoLocalName() converted one-- it will fail to find "es-ES" (by
enumerating through ~259 window locales) and use a fallback to translate
messages.  Since gettext() will not cache the "not found" locale, the
expensive enumeration call will happen everytime [1].  I am in the
middle of writing some patches to take care of that problem and a couple
of others involving that area of the code and gettext().

[1] https://savannah.gnu.org/bugs/?67781

-- 
Bryan Green
EDB: https://www.enterprisedb.com