In a project that contains localised strings for French, german, Italian, spanish…
The language setting in the app is set to English (UK) , although I have tried English, and French and Default
When I change the language in System Preferences to French or Spanish, the app does not change.
Customers report this too… always in English
But the same project does work localised when compiled for Windows.
I dont know what to change…?
Not sure if that helps but I had a similar problem on the iOS simulator. It would ignore the language setting in the macOS’s system preferences but what helped was changing the time zone on the Mac.
Does the final app contain the xx.lproj folders in contents/resources? If you’re using AppWrapper to sign and notarize, there is an option to automatically remove partial translations - maybe this happend with your app?
xx.lproj folders in contents/resources
yes
If you’re using AppWrapper to sign and notarize, there is an option to automatically remove partial translations
Excellent idea, but this happens with debug also.
Which settings did you change in the system preferences? Language, Region, Timezone ?
I go to language and region, and drag French over English to the top.
I’ve never had to change any others in the past.
But that’s just for my testing - users get the same.
Happy to try changing other things if we know it will fix the compiled build.
Oddly, if I remove the en.lproj and en-gb.lproj folders, the app runs in German, even though thats not on my list of languages in System preferences!
did you try using the acana app to test the languages of your app ?
https://www.pps4me.de/apps/acanapp.php
Arcana sees all the languages, but double clicking always starts in English
You “do” have “Localized” checked for every one of these strings, in the project, correct? (It’s possible to have all of the localized strings copies “existing” in the project, but if you don’t check “Localized”, you don’t get localization after you’ve built).
It’s working fine for me in a full set of applications, assorted versions of MacOS up through and including the latest Big Sur release.
They are all set to dynamic = true
Global scope constants
And the project works properly when compiled for Windows on a Windows machine.
I dont understand it.
Set the app language to Default.
Set the app language to Default.
Maybe thats how I got here… This is the Xojo page about localisation:
Building the Localized App
On the Shared Build Settings, there is a Language property in the Build section of the Inspector. This property determines the language that is used by any localized strings that have “Default” as the language.
It is important that you select a specific language in this build setting. If you also leave this setting at “Default”, you will run into confusion if the project file is shared with people that do not have the same system language as you.
For example, if you leave both the localized string language and build language as “Default” then “Default” becomes “English” for users that build with an English system and becomes “French” for users that build with a French system.
To prevent this confusion, always at least choose a specific language in the Build setting. Alternatively, don’t use “Default” for your localized strings and instead always choose the exact language for them.
Never ever use “default”. Use “english” instead and then everything will work fine.
I even have an IDE script so that I don’t screw this up:
'ensure english as basic language
theResult = DoShellCommand("/usr/bin/defaults read " + AppPath + "/Contents/Info ""CFBundleDevelopmentRegion""")
if instr(theResult, "en") = 0 then print "Language is not english anymore."While it is a good point to check because I can and sadly do make mistakes, the partial removal compares languages in nested components (such as the Xojo Framework) with languages in the enclosing bundle’s resources folder. If it finds a language that is not in the enclosing bundle’s resources folder, it considers this as a partial translation and when the option is enabled, removes it.
The partial removal should never remove a language from the main / enclosing bundle’s resources folder. Now I’ve got to go double check that section of code.
There seems to be some confusion about how this all works (including in our documentation, so I’ll try to get that cleared up).
First of all you need to take into account which languages you’ve localized in your app. Lets say for example that I have a localized (dynamic) constant in my app which has three values, each defined for one of three “languages”
(I’m using the english names for the languages because it’s easier on my old unilingual brain)
Now while many systems only allow you to choose a single language, macOS allows you to select several, in order of preference. That is, in my case since I understand more Spanish then French, mine are set up as English, then Spanish, then French.
Now we build the app, once as Default, once as English and once as French.
On my default system with English as my primary language here’s what I’d get:
| Build Language | Constant Language |
|---|---|
| Default | English |
| English | English |
| French | English |
Obviously, the reason for this is that my system prefers English and there’s an English constant, so that’s what’s used.
Now, if I change my language order to Spanish, French, English, here’s what I’d get:
| Build Language | Constant Language |
|---|---|
| Default | French |
| English | French |
| French | French |
Surprised? Don’t be. There are two things in play here:
The system is automagically showing the next preferred language, so the user gets French.
Now here’s where things get really tricky.
What happens if the user doesn’t have any languages on their system that you’ve defined in your app? If I remove English and French from my system, leaving only Spanish as my primary language:
| Build Language | Constant Language |
|---|---|
| Default | English |
| English | English |
| French | French |
In this case the constant that is displayed is dependent on the language that the app was built for and the system it was built on.
So yes, whether you choose Default or something else does matter in the grand scheme of things, but for most small development teams, leaving the language as Default works just fine because the only time it comes into play is when the user running your app doesn’t have any languages defined on their system that you have in your constants.
No, “default” is confusing. I remember running into the same problem that Jeff did. I use english translations for the default, english as language and everything works fine.
For what it’s worth, a few days ago one of my app suddenly stopped showing the proper localisation – I had defined localisations for German, US English, and British English. As it turned out this was because I had copied some stuff from another project where I had defined just two localisations, for German and for US English. After I had added the missing localisations for British English everything went back to normal.
Thanks for the explanation, @Greg_O_Lone.
Just tried localisation and it does not work on a M1 macOS 12.4, Xojo 2022R1.1
System is set to English as primary language.
I set the build language to ‘German’ but only get the English locale.
Also tried ‘EddiesElectronics’ sample app with ‘German’ language setting. This also gets me English labels only.
Worth checking App wrapper if you are using it.
If you ‘Show Package contents’, are the translations present?
Build → language is for default (if none other in the constant)
System is set to English as primary language.
You have them both so it uses the system requested language.
