"Skjalg A. Skagen" <skjalg.skagen@pm.me> writes:
> If you mean what I see in the drop-down menu during installation, I see "Norwegian Bokmål, Norway" -- identical to
whatgetlocales.exe reported in my installation log file on line 222:
OK, thanks for confirming. So the committed patch does *not* add enough
flexibility to cover this case.
I wrote:
>> I wonder whether we need to relax the matching code to be entirely
>> agnostic about spaces and punctuation in the Windows locale name.
After googling a little bit, I could not find any indication that
Microsoft promises anything at all about the stability of these
long-form locale names. They document short names similar to the
Unix conventions, e.g. "en-US" and "nb-NO", as being the stable
forms that applications are encouraged to use. So somewhere there
is code that converts these long-form names to the standardized
representation, and it would be entirely reasonable for that code
to try to be forgiving. Thus, it's no surprise that we're getting
bit by small variations like these.
I'm inclined to think that we ought to ignore anything that isn't
an ASCII letter while trying to match these locale names. That's
a little bit problematic in terms of what win32setlocale.c does
today, because it tries to replace "just the matched string",
but it'd be unclear where the match ends if there are ignorable
characters. But probably we could change it so that it just takes
the translation and then tacks on ".NNNN" if the input ends with
a dot and digits.
Maybe case insensitivity would be a good idea too? The existing
code hasn't got that refinement, so maybe it's not important,
but the examples I'm seeing in places like
https://docs.microsoft.com/en-us/cpp/c-runtime-library/language-strings?view=vs-2019
are all-lower-case.
regards, tom lane