4dots Software

Localization Guidelines

Avoid jargon and country specific language

By using jargon or country specific language many problems can occur.Have in mind the international users.

Avoid using Text in graphics

Adding text to graphics (icons or images) will increase the localization costs since the graphics will have to be edited for each language.

Use consistent phrases and terminology

Using inconsistent phrases or terminology will only increase the localization costs and produce incoherence because each phrase or term has to be translated sepparately.On the contrary, same phrases or term are translated automatically in Localtransformer.

Use the active voice.

Avoid reference to or images of animals , religious symbols , sacred objects , hand gestures, body language, holiday symbols.

In many countries animals are sacred therefore including images of them in your product should be avoided. Also hand gestures and body language might be inappropriate in some countries.

Avoid using acronyms and abbreviations

Acronyms and abbreviations cannot be reproduced in foreign languages and moreover the translator might not understand for what they stand for.

Leave sufficient space for text expansion in controls of the user interface (labels, buttons, textboxes etc.)

This issue is very important since translated text is usually 30% longer than the English original (sentences) and can increase as much as 100% for single words. If no sufficient space is provided the user interface will not display correctly. Keep in mind that you can adjust the user interface layout of each language separately for .NET applications by using Localtransformer.

Put text labels above user interface controls such as edit boxes.

This would allow extending them more because of expansion reasons.

Write dates out fully

For example write "15 October 2008" instead of "10/15/2008" since this date format would be false in countries like Germany where the month comes second ("15/10/2008").

Use Unicode character encoding.

Unicode is the best encoding method to use when dealing with world-ready applications.

Avoid hardcoding keyboard commands.

Remove unused text or strings from the resource files

This will reduce translation costs since the unused strings will not have to be translated.

Use function keys instead of letters in shortcut key combinations

Avoid Run-Time Composite Strings

Avoid run-Time composite strings i.e. the use of text strings with variables that get composed at the application's run time. The translator cannot determine what definite article (masculine, feminine, neuter) should be used for the run-time composite string and an error will occur.Each sentence has to be written out completely.

When using variables, show variable order

The problem is that in some languages the object comes before the verb while in other languages the object comes after the verb. Therefore, it would be better if there was a way to show variable order. For example, in .NET use the string "Not enough memory to {0} the file {1}." instead of using simple placeholders with the string "Not enough memory to %s the file %s".

Keep Sentences in a Single String

Sentences should be in one single string. If the sentence is broken up into several strings the translator will have a problem to determine the correct syntax and the meaning of the sentence could also be ambiguous.

Pseudo-translate at the earliest stage point

Localtransformer is able to pseudo translate the project for localizability testing i.e. make a translation simulation by filling the translations with random characters of the target language .In this way, it is possible to verify, that the user interface of the application being tested can be easily translated to any target language without re-engineering or making code modifications. It is necessary, to run pseudo translation at the earliest stage point, since localizability bugs have to be fixed in the code of the application.

Read here more for Pseudo Translation