An effective way to Localize my Revolution Projects for Multiple Languages
ambassador at fourthworld.com
Fri Feb 16 13:53:12 EST 2007
Derek Bump wrote:
> Now before I start down my typical path of re-inventing the wheel, I
> felt I should ask this question of the list, just to see if anyone has
> found an effective way of working with Localized (multiple-language)
> I have never done any work with creating localized projects. I know
> that I will end up mutilating the native languages via the Google
> Translator, but I figure that a 90% translated program is better than a
> program that isn't used because it's not in a person's main language.
> - Property profiles are nice, but it means that I have to store all of
> the language data for each object within a profile, making it harder to
> make changes to the text.
> - Placing all text in a file, and then just translating the file to
> multiple languages when building the standalone would be preferred, but
> that would require some massive scripting to populate button and field
> labels, etc.
> - Also, I have to roll my own dialogs that don't return the name of what
> button was pushed, but instead a number, as the number doesn't need to
> be translated. (Ex: 0=Cancel,1=OK)
> Any ideas? ... Please!
My gandfather used to say, "When a designer is faced with two equally
compelling options, find a way to do both."
Custom properties are handy because they bind the data to the object,
keeping everything together in a world in which it's wise to assume
everything will change at some point or another as the product evolves.
But as you note, it would be cumbersome to edit the data there. So don't
do that. :)
Instead, you could make a tool which extracts the language elements
relevant for a translator to work on, presents them in a convenient
editing interface right inside the program so they can understand the
context, and stores those back again into the object properties.
One of the larger products I've worked on in recent years was a medical
database for both US and UK markets, and while they're both "English"
there are a great many differences between the dialects, esp. in the
We used the approach I described above, and we've been delighted with
how fast Rev can walk through all objects to insert the appropriate text
on preOpenCard. Never even notice the difference.
We found that it was helpful during development to keep all work in one
language (we used US English, since that was how the project started),
and did the translation work as the last step in the process.
Commands follow suit: all command names are in the base language (for
us it was US English), and only the label property of controls is
changed so the name remains intact.
The only tricky items are background fields. Because the same object
can contain different text across multiple cards, we found it helpful to
store the data in the card rather than the field object. We used custom
property sets named for the desired language, with the element key being
the field's short ID (e.g., "USEnglish").
And of course it pays to have a native speaker do the actual
translation, esp. one who is also expert in the domain the application
supports. On our project this for that was easy, since one of the
company owners is an Australian doctor. But the last thing you want to
do is come up with unclear or misleading quasi-translations, or even
embarrassing ones like when Chevrolet rolled out a car for
Spanish-speaking markets named "Nova". :)
Fourth World Media Corporation
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the Use-livecode