d8158c6c93
The system locale of a macOS application is not affected by environment variables like LANG. Yet, we were reporting a name determined from environment variables as the fallbackUiLocale(), rather than one based on the language and country of the actual system locale. This lead, via the usual CLDR likely-subtag fallback, to claiming the system locale's name, language, script and country were those obtained from these environment variables, even when they were at odds with the actual locale being used by the system, which was being used for some queries. Worse yet, any data not supplied by these queries was being obtained from the same CLDR locale as the name, making for an inconsistent mix of locale data. While we cannot avoid the likely-subtag fallback step for fallback data, it is more consistent to use the actual system locale's name as start-point for that fallback. At the same time, add support for the language, script and country queries, so that the QLocale::system() describes itself faithfully, instead of claiming to be the locale that results from that fallback. If we want to support LANG or other environment variable overrides, they should be handled by the layer above the system locale, by changing the default locale of the Qt application, as if the user had called QLocale::setDefault(). [ChangeLog][QtCore][QLocale] QLocale::system() on macOS no longer pretends to support LANG or other environment variables as overrides, as this is not a feature that the system locale on macOS supports. To override the locale of an application, use QLocale::setDefault(), or pass -AppleLocale en_US. Fixes: QTBUG-90971 Change-Id: Ibdaf5ff9a2050f61233a88eabf3c29094f7757f1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> |
||
---|---|---|
.. | ||
auto | ||
baselineserver | ||
benchmarks | ||
global | ||
libfuzzer | ||
manual | ||
shared | ||
testserver | ||
CMakeLists.txt | ||
README |
This directory contains autotests and benchmarks based on Qt Test. In order to run the autotests reliably, you need to configure a desktop to match the test environment that these tests are written for. Linux X11: * The user must be logged in to an active desktop; you can't run the autotests without a valid DISPLAY that allows X11 connections. * The tests are run against a KDE3 or KDE4 desktop. * Window manager uses "click to focus", and not "focus follows mouse". Many tests move the mouse cursor around and expect this to not affect focus and activation. * Disable "click to activate", i.e., when a window is opened, the window manager should automatically activate it (give it input focus) and not wait for the user to click the window.