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
___________________________________________________________
[EMAIL PROTECTED] http://www.FourthWorld.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
