An effective way to Localize my Revolution Projects for Multiple Languages

[Richard Gaskin]

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) 
> projects.
> 
> 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 
medical profession.

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[4433]").

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". :)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com