PROGRAMMING TRANSLATION

The programs should be prepared and designed to be translatable. That is, the programs MUST meet some conditions of design to make the translation possible and easy to do and for the end user easy to understand.

The conditions can be resumed in the following points:

1. Structure

• Panels and windows.
  The fields and field names must have enough room to hold some expansion of the source text when it is translated into a foreign language. The English is the shortest language, so the translated text usually larger than the original English. In the calculation for the English into Spanish a good rule is to consider an expansion of:
  
  English strings Spanish strings
  Up to 8 characters 100 % more
  Up to 16 characters 50-60 % more
  Up to 25 characters 40 % more
  More than 25 characters 25 % more
  
• Long messages. They should have enough room of 25 % more room of the longest message, or a scrollable room to hold it.
  
• The fields to hold economic figures must be designed for quantities resulting of the currency changes. Similar situation about decimal positions. In the case of English-Spanish they result fields 200 % bigger than source ones, and decimal positions changed from 2 to 0. Accordingly the currency symbol Must be translated.
  
• Is not tranlatable a program that generates text, connecting text from different messages or portions of strings. The structure of different languages are different among them and is impossible to convert it in a readable structure in target language. Developers must avoid this.
  

1. Linguistic considerations. Use always the same word for each concept, action, or command, so the use of synonyms must be avoided. Never use slang terms and the few possible built in sentences even the most common ones. An example of the BAD naming is precisely this page: the link sais "Translating programas" and the title of destination page reads "Programming translation".  The reader can think that are different things.
   Also jokes or funny text should be avoided  because in the target language may be is not useful, polite, or formal to use it.
   
2. Range
   It defines what should be translated and what MUST NOT.
   Specific instructions about what kind of text must not be translated i.e. System Commands, and how to identify it.
   Also what pieces of programming do not need to be translated i.e. remarks for programming documentation written inside of the program. Because those info never reach to the end user and they are beside of the objective of the program translation.
   
3. Define a quick way to resolve any kind of problems, such as:
   Specific meaning of technical words.
   Ambiguity of sentences without context.
   Further explanation about English synonyms that have the same target word and vice-versa.
   Others-
   
4. Supply to the translator:
   A glossary with definitions of the terms that have an special meaning in your program or you think they may have some ambiguity in others environments different of the scope of your program.
   
   Specific rules about the style you want the translation, based in previous translations or your special preferences if they are not against the syntactic or ortographic rules of the target language.
   
   If you don’t have the above documents ask to the translator to define them and agree with him its contents.

This is just a summary of some difficulties to translate programs that I had in my life of translator.