Enable CFBundleAllowMixedLocalizations property list key inside Info.plist in macOS

[shyamnathp]

Feature or enhancement

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Proposal:

Feature Request

The QLocale module of Python packages like PySide6 and PyQt6, incorporates a notion of locale on macOS that extends beyond the POSIX locale (used by the locale Python module) and depends on the Info.plist of the application bundle. This is because both PySide6 and PyQt6 are python bindings to the C++ Qt framework, where every application is compiIed and will be mostly built as a framework, and have its own Info.plist file.

In the case of Python, the application bundle is Python macOS application framework and this module looks at the CFBundleDevelopmentRegion property key inside the Info.plist file of the Python framework (generally in /Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app/Contents/Info.plist), which is always English. Therefore, even when the system language is something different, QLocale always returns English as the system language. In order to support the retrieval of localized strings, CFBundleAllowMixedLocalizations property key must be turned on in Python's Info.plist.

In the case of non-framework builds of Python, the locale reverts back to the POSIX locale. However, the Python installed by default in macOS and available for install from https://www.python.org/downloads/ are all framework builds.

Corresponding bug in PYSIDE: https://bugreports.qt.io/browse/PYSIDE-2419

Solution

The solution is pretty simple and only includes adding the following line

<key>CFBundleAllowMixedLocalizations</key><true/>

to CPython's Info.plist file. Afaik, the additon of this does not cause any issues elsewhere as well.

I would be happy to make this change myself and contribute to CPython, if you all agree with the idea.

Linked PRs

• gh-108269: Add CFBundleAllowMixedLocalizations to Info.plist on macOS #113213
• [3.12] gh-108269: Add CFBundleAllowMixedLocalizations to Info.plist on macOS (GH-113213) #113294

[torarnv]

Note, both application bundles and non-application-bundle builds of the python executable can embed an Info.plist file. The latter is done by passing -sectcreate __TEXT __info_plist /path/to/Info.plist to the linker.

[ediosyncratic]

Just to clarify: in C++, on Darwin, QLocale calls CFLocaleGetValue() for keys kCFLocale{Language,Script,Country}Code to determine the language script and currency for the system locale, without consulting the environment variables POSIX defines for control of L10n, LANG, LC_* and LANGUAGE. When the Info.plist is suitably configured, this (and other calls QLocale uses to determine system settings) picks up the system L10n settings the user has configured via the system settings app. In particular, when the Info.plist is suitably configured, this lets QLocale::system() reflect user-configured departures from the standard CLDR L10n settings for their language, script and territory. If I understand correctly, python's locale module consults the environment variables instead, which will get it sensible enough results in many situations, but without any user customisation.

[ronaldoussoren]

How can reproduce the issue? That is, is there a script that I can use that gives the wrong result without the proposed change (installing PyQt or PySide for this is no problem)?

[ronaldoussoren]

I've set my system to dutch as the primary language with English as a fallback. After installing PySide6:

from PySide6.QtCore import QLocale
>>> QLocale()
<PySide6.QtCore.QLocale(English, Default, Netherlands) at 0x103278ec0>

Adding <key>CFBundleAllowMixedLocalizations</key><true/> to .../Resources/Python.app/Info.plist:

>>> from PySide6.QtCore import QLocale
>>> QLocale()
<PySide6.QtCore.QLocale(Dutch, Default, Netherlands) at 0x1005f0e40>

[ronaldoussoren]

The attached PR changes all 3 Info.plists we ship to be consistent, the change to the Info.plist in IDLE likely isn't necessary whereas the Python.app change definitely is and the framework change likely affects command-line tools linking to the framework.

[shyamnathp]

Thanks for fixing this @ronaldoussoren

[ned-deily]

I merged the PR to main for 3.13.0a3. I'll leave the issue open to decide about backporting.

[ronaldoussoren]

I've been conservative with back porting and only back ported to 3.12, primarily because I'm not sure in what circumstances this might break existing code on upgrade and because I expect that GUI code will often be distributed in app bundles using tools like pyinstaller and py2app where its easy enough to add the right flag to the app info.plist.