I wrote my app in english.
So all default values are english.
A german translation I made by myself.
Is it possible to Export Localizable Values with the german values,
so that someone could translate from german to another language?
I hope I made myself clear…
If you are using Lingua, you can open the .xojo_locale files for each language and show them next to each other.
For instance, I already have English, German and French translations and now someone is creating an Italian translation as well. This person opens the German translation with Lingua and arranges it side by side with the English-Italian version, where she is translating. Like this:
Thanks Oliver.
Yes, this is a way, but I was hoping this could be done more simple.
I think it would be nice if the user could choose language.
Right now it is only possible to translate from the default value and that seems very limited to me.
Well, you can open the target .xojo_locale file( for example English->Italian), and then in a second step you can import an already translated file (like English->German).
You will be asked if the target is going to be Italian or German. Choose Italian.
Then you have the German values on the left, the English default on top and now you can translate from both languages to the target Italian:
All right! 
This is a good way to go!
Thank you very much!
[quote=75963:@Michael Thaler]I wrote my app in english.
So all default values are english.
A german translation I made by myself.
Is it possible to Export Localizable Values with the german values,
so that someone could translate from german to another language?
I hope I made myself clear…[/quote]
FYI - default values for dynamic constants are in “whatever language your OS is running”
While you wrote them assuming default = english IF you change the OS to run in Chinese then default means Chinese
Its why when you create dynamic constants you should ALWAYS set a specific value for the language you think your are localizing into and not rely on default meaning any specific language
[quote=76045:@Norman Palardy]
Its why when you create dynamic constants you should ALWAYS set a specific value for the language you think your are localizing into and not rely on default meaning any specific language[/quote]
I’m not clear about how to do this. I’m setting Language to English in Shared, Build Settings - is this what you mean? Or would I have to explicitly define an English value, like this:
I am not sure if I get this.
When I wrote the app I created constants for each language (english, german, spanish…)
At the default value I typed the same words as english.
Was this a mistake?
Should I leave the default values blank?
[quote=76050:@Oliver Osswald]I’m not clear about how to do this. I’m setting Language to English in Shared, Build Settings - is this what you mean? Or would I have to explicitly define an English value, like this:
[/quote]
I’d ALWAYS do what your have in the image as then even if build settings get changed you DO have an english localization
[quote=76051:@Michael Thaler]I am not sure if I get this.
When I wrote the app I created constants for each language (english, german, spanish…)
At the default value I typed the same words as english.
Was this a mistake?
Should I leave the default values blank?[/quote]
Do like Olivers picture shows so you have the “default” and a specific entry for “english”.
Then it won’t matter what you type in the “default value” field even if someone should compile your application using other settings for their OS.
… which becomes important from that moment on, where one starts to collaborate with a developer who sits somewhere else on this planet. It is always good to think ahead.
[quote=75963:@Michael Thaler]I wrote my app in english.
So all default values are english.
A german translation I made by myself.
Is it possible to Export Localizable Values with the german values,
so that someone could translate from german to another language?
I hope I made myself clear…[/quote]
I can send you a copy of the latest beta of my localization tool? You simply add 2 lines of code and wait 2-10 minutes for translations to complete, then your application can localize to 80+ languages. The application will create a file after running it for the first time (it takes care of all localization and controls/strings automatically using introspection methods), you then take that file and load it into the localization translator tool, select the languages to localize to, and push translate. Localization files will be created for each target language. You’ll just need to add the code to save a default localization or read it from the users system, or have available languages appear in a menu for the end user to choose from. If your interested in trying out the localization tool and localization automation class, PM me your email for a link or send me a message at xojodevspot.com. The localization application/editor uses the same localization class and is available in 80+ languages.
[quote=76060:@Norman Palardy]Do like Olivers picture shows so you have the “default” and a specific entry for “english”.
Then it won’t matter what you type in the “default value” field even if someone should compile your application using other settings for their OS.[/quote]
This is exactly how I did it.
The problem is, if I “Export Localizable Values” the one who is translating sees always the default values. (which is english in my case)
Now I have someone who wants translate into hungarian and he doesn’t speak english (but german)
Oliver showed me a way how this can be done, but this is still a workaround.
A better way would be if I could create a translation file e.g. from german to hungarian and the translator would see the german translation instead of the default values.
I am translating for IObit. They send me an Unicode textfile where I have to replace the english text with the Flemish translation. I save them in the same Unicode translation and send it again as a text file.
I find this system for an external translator the simplest and best one. It only dictates very good wordprocessor capabilities. I am using TopStyle 5 for it, but am working in my free time on a better solution by using Xojo.
Such a file is about 3200 lines long. I do not see all these lines replaced by dynamic constants. Also makes translating your application almost impossible for an external translator.
Keep things simple for an external translator because for them accuracy and speed is very important and a good error finding process. I don’t want whistles and bells, just plain wordprocessing.
Translating, or at least verifying, by a person is important and hence why most service organizations that do translation do it this way and not strictly by machine (since it can’t know the business area etc that may in fact be relevant) Subject matter experts are usually critical to make sure that whatever machine translation is done is accurate for the specific business sector.
On OS X there are many way to do translations - and they can be done AFTER the app has been built but before the app has been packaged & signed as you have to sign all resources.
However, for the way the IDE works it ships the “default value” and then translator uses that to create the new version in whatever language.
A long time ago I toyed with Lingua but found it to cumbersome and inflexible. Years ago I saw a RealBasic app which had an option (to the end user) to spit out a simple text file, containing all (maybe specific) translations. The user could add/edit translations and send it back to the developer.
Unfortunately I don’t remember the App’s name, and didn’t kept a copy of the translations file.
But I consider that concept a good one. As Chris said, it’s very simple for the translator to use.
Such a concept would be also flexible in the running app because it could act like common apps (use whatever language the system is set to), or let the end user decide which language he wants to use, regardless of the system language.
Is there anything that speaks against this approach?
On OS X compile & send the translator the localizedstrings file from the resources directory inside the bundle
Edit it with a text editor
Put it back
On OS X the convention is to run in the language the user is running their OS in
I did write a blog post about how to NOT do that if you want
[quote=76215:@Norman Palardy]
On OS X the convention is to run in the language the user is running their OS in
I did write a blog post about how to NOT do that if you want[/quote]
See also:
https://forum.xojo.com/6020-overriding-system-language/2
You can export a .xojo_locale file from Lingua, as a tab-delimited textfile, which then can be opened with Excel, for instance. There you have a nice tabular view which probably is what you are looking for. (Easy to add translations and one could even copy/paste already translated columns from other languages there…)
This textfile can then be sent to the developer who will be able to re-import it to Xojo via Lingua.
EDIT : Excel for Mac 2011 does not correctly import UTF-8 text files. For instance German ‘Umlaute’ will not display correctly. My workaround is to use TextWrangler in-between. I open the translation textfile first in TextWrangler and copy/paste everything over to Excel. That’s the only way I found to protect the characters as desired.