There are some general tips in this topic to help simplify the translation of your textual material.
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.
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% |
Over 70 | 30% |
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.
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.
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.
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.
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.
Rules for abbreviations vary from language to language. Abbreviations of words can lead to misunderstandings by the translator and by the user.
Slang, jargon, and humor are specific for a particular language and cannot be easily translated into another language.
Negative questions are often misunderstood by the user. When asking questions, ask them in a positive way.