From My Wiki

Lessons for Developers

• Be internalization aware from start
• Internalization first, localizations second, then translation
• Don't embed plural forms
• Avoid string concatenation
• Leave all strings in context
• Avoid embedded variables
• Document variable usage and every else that is tricky
• Expect and respond to feedback from translators
• Don't be afraid to ask translators if you need help

TERMINOLOGY

Using jargon makes tools only usable to professional users and not new users and harder for translators.

There is a lack of words for some terms in local languages. In english you have technical people making up words. English has a strong office culture so the translation is trickier and does not always translate.

Concepts of inbox, outbox are not concepts that translate in other languages. When you try and be descriptive of jargon the words do not always fit in the area allowed.

Users are good at learning software so they can learn what functions do even if it does not translate well.

Translators often have to make up new words that are adopted from english and become new words. The new word becomes a symbol to the user and needs a longer explanation and context to convey meaning of the word.

In some countries from a legal point of view you are not allowed to use english words at all but that is not always possible.

Consistency in the a translation community of IT terms to create new words are not always the same and some times english words are used instead of new word creation or software terms are not constant across applications.

If you enforce the use of native words there is a better chance that the new term will be adopted.

Relation between documentation and term constancy is a problem when using dialectics.

IT terminology has a small time window in a language to be adopted.

In Serbia they created a web based dictionary where suggestions can be added and voted upon to create new terms.

Once a term is used you should never change it.

Term creation is generally created form english words but sometimes are pulled from neighbor language IT terminology to create the new word.

There is a difference between hosted applications and installed applications in UI design fluidity. Game users and web site users are used to interface change and more artistic endeavors that have more flexibility.

Icons can help with conveying meaning without strings. Translations need to be grammatically correct but is not the easiest thing to write. It is not good to use jokes in documentation or interfaces

CHALLENGES

It is very hard to translate Firefox and Thunderbird. The import export process is buggy and broken. The fact that Mozilla and Open Office are not using standards and are multi platform mean they are not using linux tools for translation. They are using their own custom solutions for translations. There are campaigns to get them to switch to gettext.

People with windows background want to use ids for messages and changes cause problems.

English grammar structure causes a problem when messages containing an embedded variable. When these are done wrong they are considered bugs in gnome. Best practice for developers is to avoid string concatenation or using strings over and over for same context.

When a string context changes in a po file developers are asked to add a comment. When this happens it is a problem when applications have been translated and old translations have not been alerted to the change.

People are interested in the Worldwide Lexicon translation approach as opposed to just translating a file. The problem is that translation workflow processes are lost.

For --help command line help files like man files, a best practice is to split the large data into small strings.

One issue for developers is that they add pluralization in the code. They should abstract the pluralization outside the string so that the framework can deal with more complex pluralization in other languages.