[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Default Windows locale for localename.c

From: lrn1986
Subject: Default Windows locale for localename.c
Date: Fri, 9 Mar 2018 01:51:44 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Thunderbird/59.0

Currently localename.c (which is used by gettext, so it's really everywhere) calls GetThreadLocale() to get current locale identifier (if LC_* or LANG are not set).

One problem with that is that GetThreadLocale() is unaffected by setlocale()
(already discussed in "Fix libunistring in MS-Windows locales" back in 2014).

Another problem is that GetThreadLocale() defaults like this (according to 
"When a new thread is created in a process, it inherits the locale of the creating thread. This locale can be either the default Standards and Formats locale or a different locale set for the creating thread in a call to SetThreadLocale"

It was pointed out to me recently that the locale obtained from "Standards and Formats" (also known as "intl.cpl") is *not* the "UI locale". That is, the settings from intl.cpl influence the way timestamps, dates, currency and numbers are displayed. But they do not decide the UI language.

Because of this gettext-using programs tend to pick the wrong default locale when running on Windows.

I'm currently thinking what to do about this. Maybe GetThreadUILanguage() instead? OTOH, date, time, number, currency formats and days-of-the-week names should probably continue to be obtained from intl.cpl (directly or indirectly; i'm not sure whether C runtime functions do that, but there are W32 APIs for that, such as GetLocaleInfo(), and i remember seeing them being used in a plibc nl_langinfo() implementation back in the day; gnulib uses strftime() for this, and it seems to be working, so that could be expanded too, i guess).

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]