4709c938db
We currently don't have any machinery for qmake or CMake to map translations declared via TRANSLATIONS += or qt_add_translations to the Info.plist CFBundleLocalizations key. This results in macOS and iOS falling back to the development region, CFBundleDevelopmentRegion, as the only supported localization of the app, which is in most cases set to 'en'. Unfortunately this doesn't work well with the behavior of iOS 11+ and macOS 10.13+ where the OS will set the locale of the app to the best match between the app's supported localizations and the user's preferred language. https://developer.apple.com/library/archive/qa/qa1828/ Since we only support a single localization, the development region, the locale always ends up as 'en_<REGION>', which after QTBUG-104930 is also reflected in the QLocale's uiLanguages(), resulting in the QTranslator machinery always picking English translation for the app. As long as we don't explicitly declare CFBundleLocalizations we need to opt out of the system's behavior of finding the best match between the app's declared localizations and the user's preferences, which we can do via the CFBundleAllowMixedLocalizations key. Fixes: QTBUG-63324 Pick-to: 6.4 Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> |
||
---|---|---|
.. | ||
Info.plist.app | ||
Info.plist.lib | ||
qmake.conf | ||
qplatformdefs.h |