Per-app language settings support on macOS

[sikmir]

I wonder if it's possible to support additional languages for Qt app on macOS:

[tumic0]

I think this feature will be somehow based on the standard "lproj" files used by native OS X apps. Qt uses its own mechanism so the answer is IMHO no. But I can not give you any authoritative answer as I do not even have access to a Mac where such setting would be possible.

[sikmir]

VirtualBox is just an example of such Qt app that supports language settings:

$ find /Applications/VirtualBox.app -name "*cs*"
/Applications/VirtualBox.app/Contents/MacOS/nls/VirtualBox_cs.qm
/Applications/VirtualBox.app/Contents/MacOS/nls/qt_cs.qm
/Applications/VirtualBox.app/Contents/Resources/cs.lproj

/Applications/VirtualBox.app/Contents/Resources/cs.lproj/ is empty, there is no *.strings files in it.

https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Frontends/VirtualBox/Makefile.kmk#L1931
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Frontends/VirtualBox/src/platform/darwin/VBoxUtils-darwin.cpp#L193

[sikmir]

Another example (more simple) is https://github.com/openorienteering/mapper, it also supports language settings:

$ find /Applications/Mapper.app -name "*cs.*"
/Applications/Mapper.app/Contents/Resources/cs.lproj
/Applications/Mapper.app/Contents/Resources/translations/map_symbols_cs.qm
/Applications/Mapper.app/Contents/Resources/translations/qt_help_cs.qm
/Applications/Mapper.app/Contents/Resources/translations/assistant_cs.qm
/Applications/Mapper.app/Contents/Resources/translations/OpenOrienteering_cs.qm
/Applications/Mapper.app/Contents/Resources/translations/qt_cs.qm
$ ls /Applications/Mapper.app/Contents/Resources/cs.lproj
locversion.plist
$ cat /Applications/Mapper.app/Contents/Resources/cs.lproj/locversion.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>LprojCompatibleVersion</key>
    <string>123</string>
    <key>LprojLocale</key>
    <string>cs</string>
    <key>LprojRevisionLevel</key>
    <string>1</string>
    <key>LprojVersion</key>
    <string>123</string>
</dict>
</plist>

[tumic0]

I have added the lproj stuff to the Resources directory in the latest OS X builds, does that help?

[sikmir]

I have added the lproj stuff to the Resources directory in the latest OS X builds, does that help?

Now it's possible to select a language:

But it doesn't applied yet, GPXSee still uses system language. Seems like one more trick is required somewhere, at least we have https://github.com/openorienteering/mapper as an example, where it works properly.

[tumic0]

I have extended the Info.plist which may have some impact. If that didn't help, please try to delete the "empty.lproj" file generated by qmake/macdeployqt from Resources and see if that has any effect.

[sikmir]

I have extended the Info.plist which may have some impact. If that didn't help, please try to delete the "empty.lproj" file generated by qmake/macdeployqt from Resources and see if that has any effect.

No, it doesn't work, the same with deleted "empty.lproj".

[tumic0]

Thanks for testing it. I have switched to CFBundleLocalizations in the Info.plist instead of separate lproj directories (2549204) as this is a better way how to "promote" the translations in cases where a non-native translation mechanism is used, but that will most probably also have no effect. The problem will be in the way how Qt gets the locale. I suppose there is a special API for that in newer OS X versions.

I have looked into the OpenOrienteering Mapper sources but there is IMHO no magic there. They seem to also use QLocale::system under the hood. But I have noticed, that they have their own application-specific language setting so maybe you have set it to the desired language and it may look like what is set in the OS X per-app settings works, but in reality it is just coincidence?

[sikmir]

But I have noticed, that they have their own application-specific language setting so maybe you have set it to the desired language and it may look like what is set in the OS X per-app settings works, but in reality it is just coincidence?

No, what I've tried:

$ defaults delete org.openorienteering.Mapper
$ open /Applications/Mapper.app

System default language (Finnish) is used.

$ defaults read org.openorienteering.Mapper
{
    AppleLanguages =     (
        fi
    );
    ...
}

Set Čeština for Mapper via macOS settings.

$ open /Applications/Mapper.app
$ defaults read org.openorienteering.Mapper
{
    AppleLanguages =     (
        cs
    );
    ...
}

Čeština is used.
Set Svenska via Mapper's application-specific language setting.

$ defaults read org.openorienteering.Mapper
{
    AppleLanguages =     (
        sv
    );
    ...
    language = sv;
    ...
}

macOS language settings is not used anymore after that.

[sikmir]

I have extended the Info.plist which may have some impact. If that didn't help, please try to delete the "empty.lproj" file generated by qmake/macdeployqt from Resources and see if that has any effect.

But macos dialogs (open file, etc) are properly translated now.

[tumic0]

I have investigated the problem a little bit more and it turns out, that the per-app language settings work by macOS putting a special configuration entry with the key "AppleLanguages" into the program preferences plist. So what looks like OpenOrienteeringMapper reading its own settings is in reality reading the entry set by the OS. There is QTBUG-51386 with the Qt-related info that is sadly closed as "Out of scope". So everyone who wants to enable per-app language settings has to "hack" the preferences plist and duplicate the selection from the languages list.

So it can be done, but it requires some ugly hack. Either by fiddling with the settings (there is AFAIK no official documentation from Apple - you shall access the locale by their API functions) or by using some Core Foundation platform specific code. The biggest problem for me is however that I have no access to a system where I could test my assumptions, implement the hack and test the result.

Given the low priority of the issue, my actual decision is to let the issue open until I get access to some recent mac machine.

[acrostich]

GPXSee 3.11 is not using the macOS (Sonoma 14.1.1) system default that is set to English for my system. The language it is using is set in macOS as my second preferred language (out of three).

I tried adding GPXSee in the Applications section at the bottom of Language & Region tab in System Settings, however I can't add it with the System Default - English (UK). I can only add it if I select another language, which is obviously not what I want.

[tumic0]

That's IMHO another Qt bug - QTBUG-86179. You can try the Qt6 Mac build from Github Actions and see if it works there, but be aware that the build may not work at all as I have no HW where I can test it. It's all the same story - unless GPXSee users start to support the project financially, the support for the Mac platform will only get worse through time and soon or later there will be no Mac builds at all.

[acrostich]

@tumic0 That Qt bug does indeed describe exactly what I'm experiencing. I've tried a Qt6 build from Github Actions and that is in English so solves that issue. Thank you.

As for the problem of financial support to the project and long term support of macOS, it may be useful to open a separate issue to raise the profile of these difficulties for everyone looking at the tracker and interested in macOS.

[tumic0]

As for the problem of financial support to the project and long term support of macOS, it may be useful to open a separate issue to raise the profile of these difficulties for everyone looking at the tracker and interested in macOS.

I doubt that this would have any effect. You have a "Sponsor this project" section on the GitHub project main page, a "GPXSee needs your financial help. Become a sponsor" section on the GPXSee web and yet the funding is practically nonexistent. Let's look at you as an example - you now know GPXSee macOS support is dying, you use GPXSee on Mac and you even ask the developers for help. But your name is still not on the list of the sponsors of the project...

[acrostich]

For what it's worth, I didn't know that the financial situation of this project was particularly dire nor that the macOS support is diying.

I didn't ask the developer for help, at least not directly. I noticed an issue. I went to check the tracker, found an issue that I understood to be related but the behaviour I encountered was slightly different. I posted about it in case this would help with this issue. I didn't know it was already fully understood as per QTBUG-86179. You suggested I try a QT6 version. I did and reported back to confirm it fixed the issue I encountered.

If you prefer that those who do not contibute financially do not report any issue, please be explicit about it. I very much appreciated your detailed and prompt response, but would also have accepted if this is not something you were willing to do. As you had written earlier that this bug is a low priority I didn't expect any response, I thought my comments could help the day you'd look again at this issue.

I keep the apps on my machine up-to-date (with a mix of Macupdate, Latest and subscribing to some releases rss feeds of some github projects). This is how I came to notice the view version and update GPXSee, but I have used it only a couple of times to help when transitioning iOS mapping apps to keep access to some locations that I could export but not import. I may still contribute to GPXSee as I hope it has a future, but it will only be modest as it's not an app I use much.

Apologies that my comment created extra demands on you.

[tumic0]

I didn't know that the financial situation of this project was particularly dire

The financial situation of every single (with exception of stuff run by multi-billion dollar companies like GoogleChrome) opensource desktop application project is "particularly dire"...

If you prefer that those who do not contibute financially do not report any issue, please be explicit about it.

What a nice straw man fallacy! No one says that. What I'm saying is, those who refuse to contribute financially should not give "smart" advice how to make people contribute financially. If your advice does not work for your self, what is the chance it will work for others?

People are simply not willing to pay for stuff if they are not absolutely required to do so. We both know this, no need to write tons of excuses...