Ive got translations for most menus etc and they are handled dynamically.
Trouble is, they aren’t great.
I regularly have native French or German speakers tell me that the translations are poor, and offering new ones, which I use.
Ironically, no two seem to agree and they often are complaining about a countryman’s work!
Anyway, I get requests for the app to run in English, even though the computer is set to French or German.
I have discovered that I can delete the .lproj folders from resources in code on the Mac, then a restart makes it come up in English.
I assume the same technique will work on Windows.
And it seems to work.
My questions are - has anyone else done that before, and if so, did you encounter any issues with code signing or other odd side effects?
and
if I changed xxx.lproj to yyy.lproj , wouldn’t that have the effect of forcing the new language to appear?
I did that on 2013R3.3 Windows to avoid the bad French translation. No side effect with signing or the antivirus. From what I understand, since it is only data, it has no bearing on code signing.
As for why people complain about translation, I believe it is about culture. Translating from English requires a good enough comprehension not to fall into the traps of litteral translation, and rather perform an adaptation of the original. A re-interpretation that is more natural. Then synonyms can be used that usually never quite match the English sentence. That is where the controversy usually starts.
Finally, there are the purely inept translations, where the original meaning gets entirely lost. For instance, the French Xojo offered to create an “Application Graphique” in lieu of “Desktop”. Whoever committed that blunder does not even have a basic grasp of his own language !
Jeff, I seem to remember a forum conversation in which what was proposed for this situation was having only one dynamic constant that would be used to determine the local language (it can be called LocalLanguage and its localized values would be “EN”, “FR”, “SP”, …) and then all the translations would be stored in a database (or whatever file, xml, txt,…) and you would retrieve the adequate text for each label by default by using the local language but giving the user the possibility to override that.
You can even let them correct their own translations by allowing them to change the text wherever it is stored.
If I recall correctly Norman Palardy was involved in that conversation, in case you want to search for it.
Either add an initialiser method to every window, which updates every control,
or
add a line of code to every control
That’s certainly possible.
I’ll need to scope how long it will take… its not a small project…
I think the simple deletion of language files is a quick win if I want to ‘Force English’
This dynamic version is the better choice if I want to ‘Force language’
OS X does make it more difficult to have the OS run in one language & the app run in a different one - esp if you have localized it into whatever language the user is running. It will by default use that language and there’s no nice easy way to say “run this app in that language” at a global level in your app code.
Be aware that removing language files may break your app bundle signature if you have signed it.
What we did previously was have 2 builds - one English only and the other localized so people could chose which they wanted.
We found that very few people used the localized versions so we simply ship in English now.
[quote]What we did previously was have 2 builds - one English only and…[/quote].
Is there a simple way to say ‘build a non-localised’ and then ‘build a localised’ from the same project?
So far I seem to see that it always builds localised. Have I missed a setting?
I’ve done something similiar to what you said for a customer 2 years ago. Because NDA I can’t give you more information but i’ve made a small showcase video of my classes I used to switch languages “on the fly”. Basically I’ve put all Strings into a MySQL Database table and load them at start - or on demand when language is switched. So no need for swapping files.
I use a similar approach. It lets the user select his preferred language, irrespective of the OS language. I also find that it makes corespondence with business partners easier: I can issue business forms using the language specified in the customer master file without much additional effort. Form texts (and application texts) are loaded on request in the appropriate language. In clear, I can issue an invoice in French while using the program in English, or vice versa. Additional languages are fairly easy to add: translate appropriately all the app texts and all the form texts, add the language in the supported languages table, and go.
