Priority: P3: Somewhat important
Affects Version/s: 6.2
Fix Version/s: None
Component/s: Core: Locales (i18n)
As noted in
QTBUG-90971, a platform may have a notion of "system" locale that can be over-ridden locally by a parent process (e.g. via environment variables) when launching a child.
On platforms that provide dedicated APIs to access the system locale, these APIs may not take account of such an override.
At present, the default locale used until QLocale::setDefault() is called is QLocale::system().
Code that needs the system locale can access it as QLocale::system(); programs that want to use the system locale by default even if an override was used can do so by calling setDefault(system()), so having some other initial default locale, that takes account of any over-ride that may be in effect, would not prevent an application from having the Qt5 behaviour (system() as initial default).
Proposal, for QSystemLocale:
- replace fallbackUiLocale() with a fallbackLocale() that's used where fallbackUiLocale() currently is (not all of which is UI-related, e.g. the system locale global's initialization from it); it should be specified to reflect the system locale (as described by query()), in so far as it can be determined, but (as at present) must not be QLocale::system().
- add a defaultLocale() which may return the fallbackLocale() (provided this does not return the default-constructed QLocale()) or QLocale::system() and will be called at most once, to initialize the default locale as if by being passed to QLocale::setDefault() before any QLocale is instantiated. It, naturally, must not return a default-constructed QLocale().
This would let macOS (for example) return an environment-derived defaultLocale() that differs from a system-derived fallbackLocale(), without QLocale::system() being inconsistent (e.g. claiming to be en_US while using Finish number formatting), while allowing environment settings to control the default locale in use.