wxUILocale Matching on OSX vs Unix

10 views
Skip to first unread message

Stefan Csomor

unread,
4:20 AM (12 hours ago) 4:20 AM
to wx-...@googlegroups.com
Hi,

as I’m streamlining base build under macOS I ran into a problem where the matching algorithms are not identical, exposed by searching for a language without a region in this test

    CheckSupported(wxUILocale::FromTag("en"), "English");

Where unix builds are using locale_t TryCreateMatchingLocale(wxLocaleIdent& locId) which is happy having anything in a language when no region is given, macOS uilocale.mm is more picky, as documented in

static wxUILocaleImplCF* wxUILocaleImplCF::Create(const wxLocaleIdent& locId)

// The following conditions have to be checked:
// - The language must always match.
// - The script must match, if it given,
-> // otherwise the region must match (even though it might be empty).

Is is ok to modify this in the unix sense ? using anything in the corresponding language if no region is given ?

Thanks for any insights,

Stefan

utelle

unread,
6:37 AM (9 hours ago) 6:37 AM
to wx-dev
Stefan Csomor schrieb am Mittwoch, 29. Oktober 2025 um 09:20:11 UTC+1:
as I’m streamlining base build under macOS I ran into a problem where the matching algorithms are not identical, exposed by searching for a language without a region in this test

    CheckSupported(wxUILocale::FromTag("en"), "English");

Where unix builds are using locale_t TryCreateMatchingLocale(wxLocaleIdent& locId) which is happy having anything in a language when no region is given, macOS uilocale.mm is more picky, as documented in

static wxUILocaleImplCF* wxUILocaleImplCF::Create(const wxLocaleIdent& locId)

// The following conditions have to be checked:
// - The language must always match.
// - The script must match, if it given,
-> // otherwise the region must match (even though it might be empty).

Actually, macOS is not more picky. The list of available locale identifiers [NSLocale availableLocaleIdentifiers]  contains an entry for "en" (without region). That is, if region is empty (as is the case for "en"), a perfect match is found, and the corresponding locale can be created.

For Unix it is different: we must have a region to be able to create a valid locale. Therefore, we have to find one, if it was not given. wxWidgets' list of locales contains for most locale identifiers without region part a reference locale id with region part. If such an entry exists, the reference id will be used; if such an entry does not exist, the first entry with the correct language and a non-empty region will be used - not ideal, but the best we can do.
 
Is is ok to modify this in the unix sense ? using anything in the corresponding language if no region is given ?

No. Windows and macOS support locales without region id, Unix does not. To overcome this deficiency of Unix, we have to select a region.

Ulrich

Stefan Csomor

unread,
2:24 PM (2 hours ago) 2:24 PM
to wx-...@googlegroups.com
Hi Ulrich

> Actually, macOS is not more picky. The list of available locale identifiers [NSLocale availableLocaleIdentifiers]  contains an entry for "en" (without region). That is, if
> region is empty (as is the case for "en"), a perfect match is found, and the corresponding locale can be created.

> No. Windows and macOS support locales without region id, Unix does not. To overcome this deficiency of Unix, we have to select a region.

Thanks for your explanations, ok, then I made an incorrect interpretation when debugging. I try to find out why the command line tests fail when using uilocale.mm instead oft he unix version, while executing the same test in the GUI app always works ...

Thanks,

Stefan

Reply all
Reply to author
Forward
0 new messages