Peter Eisentraut <peter_e@gmx.net> writes:
> On ons, 2011-05-11 at 16:47 -0400, Tom Lane wrote:
>> Hm, do you know how to enumerate the available locales on Windows?
> EnumSystemLocalesEx()
> Reference:
> http://msdn.microsoft.com/en-us/library/dd317829(v=vs.85).aspx
> Example: http://msdn.microsoft.com/en-us/library/dd319091(v=vs.85).aspx
> As you can see in the example, this returns names like "en-US" and
> "es-ES". I would imagine we normalize this to the usual "en_US",
> "es_ES" (but we could also install the not normalized names, just like
> we install "en_US.utf8").
I poked around in Microsoft's documentation a bit. It's not entirely
clear to me that the locale names enumerated by this API match up
with the names accepted by setlocale() --- in particular,
http://msdn.microsoft.com/en-us/library/hzz3tw78(v=VS.90).aspx
does not show any two-letter abbreviations for most of the languages.
That would need some testing, but it seems likely that what we'd have to
do is construct the longer-form locale name using info obtained from
GetLocaleInfoEx. Also, the locale names from EnumSystemLocalesEx
definitely don't include any code page identifier. We could probably
just enter the alias under UTF8, and again under the ANSI code page
number from GetLocaleInfoEx, if the locale has one.
> There is an older interface EnumSystemLocales() which returns locale
> IDs, which you then have to look up and convert into a name manually.
> There is code for that in the old installer CVS on pgfoundry. But it's
> very ugly, so I'd rather skip that and just concentrate on supporting
> the newer interface.
Another thing I found out from the docs is that locale IDs aren't unique
in Vista and later: they have "supplemental" locales that have distinct
names but share the same ID as the primary. It's entirely unclear how
that maps to setlocale names, but it does seem like we probably don't
want to use EnumSystemLocales.
regards, tom lane
