Text translation design
These general tips help simplify the translation of your textual material.
Isolating textual data from running code
To allow easier translation and to avoid translating the running code, you should separate all textual data from the running code. Only one set of running code is needed, but many translations of the textual data can be done.
Providing expansion space
The space needed to translate text from one language to another varies by language. To ensure that the translated version preserves the concept and keeps usability, allow sufficient presentation space for the textual data expansion. The following table shows recommended expansion space for user interfaces designed using U.S. English.
|Number of characters in text
|Additional space required
|Up to 10
|100 to 200%
|11 to 20
|80 to 100%
|21 to 30
|60 to 80%
|31 to 50
|40 to 60%
|51 to 70
|31 to 40%
Variable placement of an object on the display
Because the position of one display element often is influenced by the position and size of others, some of the elements on the translated version of a display might need to be relocated. The program must continue to respond properly, despite this relocation.
Flexible order of variables
In order to contain dynamic information, messages typically employ substitution variables. However, each spoken language has its own syntax (order of arrangement of parts of speech). When a message is translated into another language, the position and order of substitution variables might need to change to meet the syntax requirements in the translated language.
Complete textual data entities
If the final form of the constant text relies on the composition of various parts, it might be untranslatable. This is because the translator might not know which form of the word to use or because there is no combination of parts that work for a different language.
For example, you should define column headings for display screens as complete entities. You should not combine words or parts of words to define column headings. Assume that you are writing an application for scheduling jobs between Monday and Friday. You are creating your application in French. You decide to create column headings for reports and screen displays by combining the first part of the name of the day with the constant DI. Throughout the application, the column and report headings are assembled like this:
First Part of the
Name of the Day: Combine With: Result:
LUN DI LUNDI
MAR DI MARDI
MERCRE DI MERCREDI
JEU DI JEUDI
VENDRE DI VENDREDI
When you translate your application from French to German, you cannot combine two parts to create the names of the days: MONTAG, DIENSTAG, MITTWOCH, DONNERSTAG, and FREITAG.
Treating commands, responses, and keywords like textual data
Commands, responses, and keywords should be translated into the language normally spoken by the user. For example, an English application has been translated into German. If the response is still in English as Yes and No, the German users might feel unfamiliar and uncomfortable in using the program because the responses they are familiar with are Ja and Nein.
Expressing all text as simply and clearly as possible
- Use simple phrases and sentences and avoid compound phrases. Simple words allow easy translation.
- Make terminology consistent throughout the product.
If consistent terminology is not being adopted throughout the product, translators will waste time trying to determine the appropriate word to be used in translation.
- Include notes to translators in your information for correct word use to prevent any misunderstandings.
- Avoid abbreviations.
Rules for abbreviations vary from language to language. Abbreviations of words can lead to misunderstandings by the translator and by the user.
- Avoid slang, jargon, and humor.
Slang, jargon, and humor are specific for a particular language and cannot be easily translated into another language.
- Avoid negative questions.
Negative questions are often misunderstood by the user. When asking questions, ask them in a positive way.