Passage

If you are a developer about to write an application, stop and read 10 localization tips. It will save you time and money down the road. If your program is already all coded, take a look at the tips as well; maybe you can correct some mistakes before embarking into the actual localization process.

When you are ready, it is best to conquer foreign markets one language at a time. You can iron out the localization bugs with the first translation and proceed to other languages with a solid base.

What follows will seem like extra work, but in the end, it will save time and resources and keep you in control until you send your app’s strings to the translator. So before the actual act of translation takes place you will want to take some time to go through “pseudo-translation”.

What is pseudo-translation? It is the pre-translation of strings into a fake but legible idiom that mimics a variety of languages.

For example, if you are aiming for the European markets, you alter the text using accented version of the English letters like this: “Chéçk bõx ïf yôu ñeed èxtrå mêmørÿ“, which obviously stand for “Check box if you need extra memory”. If you want to conquer Asia, choose Arabic and Chinese signs that look like English letters. When you run the pseudo-localized version of your application, you will still understand the messages. Ok, so… what’s the point of all this, right?

Going through the trouble of pseudo-translation will uncover many problems before they show up in all versions of your software. Once you have dealt with the main localization bugs, the remaining problems will be a lot quicker to solve and will most likely be language specific.

What problems will pseudo-translation expose?

1. It will detect problems with encoding across all languages. Instead of seeing “Chéçk bõx ïf yôu ñeed èxtrå mêmørÿ”, you will see something like “Ch€€k b€x €f y€u €eed €xtr€ m€m€r€”, or a variation thereof. You will know right away that your encoding is wrong, and still be able to see where these strings are coming from.

2. It will detect problems with string length/height. If you followed tip #2a (previous blog entry), you will have allowed extra room on buttons, text fields, labels, etc. But to make sure they are big enough, your pseudo-translation should include begin and end tags that will easily show any real estate problems. Adding underscores to each end of the pseudo-translation string (_Chéçk bõx ïf yôu ñeed èxtrå mêmørÿ_) will immediately show clipped strings. If you know the actual maximum string length, it is always a good idea to mention it to your translators.

Moreover, depending on languages and captions, add extra characters (”%”, for example) within the pseudo string to account for expansion: “_%%Chéçk bõx ïf yôu ñeed èxtrå mêmørÿ%%_”. How much should you add? It depends on the language. Here is a very approximate guide for translating English into:

As a general rule, the shorter the word or sentence the higher the expansion coefficient. For example “low memory” will translate into “mémoire insuffisante” in French: a 100% expansion! For German, it can go up to 400% for single words.

Be careful with font size too. Roman font sizes do not necessarily correspond to Chinese, Arabic or Cyrillic font sizes. Choose replacement letters that have descenders or ascenders, include capital letters as well to see if there is sufficient room in the vertical.

3. It will detect hard coded strings. If you extracted all of your strings, pseudo-translated them and put them back into the resource files, you will see which strings were left behind, hidden in code, as they will appear in plain English.

One final advantage of pseudo-translation is that it can be done automatically with a script that does string replacement. And if no resource is available to carry this out in-house, some localizers will be able to do it, regardless of language.

Of course, taking that extra translating step will seem to create more work - and it does, for that first localized software version - but once it’s done, adding more languages will be less time-consuming, which will make up for that extra step.

Julie

You are about to write the best application ever with a fancy interface and sell it through your web site, and then you pause and ponder… How can I make it even more profitable right from the start? The answer is: localization!

Localization is adapting your software for a specific region or language by translating text elements and adding locale-specific formats. It is often abbreviated L10N (10 letters between “L” and “N”). Localization needs to be worked into the code right from the start. You can always translate an application later, but it will require more work.

10 ways to get a head start on localization:

1. Try to team up with a translator as soon as possible. He may have good tips for your particular application: game, text editor, back up software. If he is familiar with the language or the devkit you are using, he may even point to classes that will make things easier.

2. Identify all data that will require localization. Some of these are:

a) Buttons/labels/text fields/message boxes: Make them bigger (up to 50%) or leave room for resizing. English is compact; expect expansion with German and French. Also, the word “EXIT” on a round button may look spiffy, but the longer translated word may not. Design GUI accordingly.

b) Times/dates/numbers/currencies: Use only classes that are locale-sensitive. They will detect the regional settings of the user and write dates and numbers in the right order and with the right punctuation. Otherwise errors will creep in.

Original : January 5th, 2009
Right language. Wrong format : Janvier 5, 2009
Much better : 5 janvier 2009
An alternative (ISO 8601) : 2009-01-05 (YYYY-MM-DD)

c) Addresses/phone numbers: Do not hard code. Their formats are not only governed by languages, but also by countries.

Canada (French): 123, StreetName / France: StreetName, 123

d) Graphics/video clips: Make sure you have the uncompressed, layered files at hand so that added text can be translated with minimal manipulation. But it is easier to avoid graphic texts altogether.

e) Icons/colours/sounds: They can mean different things to different cultures, so be ready to make some changes there.

3. Punctuation/spacing: Punctuation and spacing rules differ according to language and region. For example, “34.8%” in English is localized to “34,8 %” in French. When this string is constructed at runtime, the translator cannot change the point to a comma. If a sentence needs a semi-colon, adding it at runtime may be a problem. In France, a space is required before the semi-colon or question mark; in Canada (French), there is no space before these two signs.

4. Compound messages/string concatenation: Avoid string concatenation such as this:

days_left = "3";
points_left = "15";
alert_message("You have " + days_left + " days to use the remaining " + points_left + " points from your account");

It will take a few more lines, but use something that includes stuff like:

GoodString = "new" String("You have %n days to use the remaining %m points from your account");
Etc;

However, it may just as well be better to avoid compound messages and use a less language dependant format such as “Days left: %n”, if possible.

Plurals can be formed by adding an “s” but also an “x” or replacing an “o” with an “i”, or using a completely different spelling such as in “mouse” and “mice”, so beware of hard coding an “s” as a plural form. Moreover, in some languages, the plural form for two objects can be different from the one used for three or more objects.

5. Use UTF-16. As a side note, when using XCode, make sure the IDE is set to UTF-16. I believe it defaults to UTF-8, but the string extractor uses UTF-16. It may not show in the emulator, but on a real device, some weird characters may show up.

6. Unicode collation: Make sure your string comparison methods use the right algorithm for sorting Unicode values. The sorting weight of characters is not determined by their position in the Unicode code charts. Moreover, the same accented character will sort differently from one language to the next.

7. Thinking of machine translation? Think again: How will the machine know, for example, which meaning of “Clear” to use? Clair, évident, limpide, transparent, degagé, tranquille… there are just too many! Actually, without context, even the translator may not know which one to choose. Put the description tag to good use. You’ll see why in this rather extreme example.

<Description> No comment provided by engineer. </Description>
<Position>%1 of %2 on %3, for %4.</Position>
<TranslationSet>
<base loc=”en”>%1 of %2 on %3, for %4.</base>
<tran loc=”fr_CA” origin=”"> ARRRRRGH </tran>
</TranslationSet>

To avoid mistranslations, have the help files ready for the translator, screenshots, technical notes or any other documents that will provide context.

8. Terminology: Make up your mind and stick to it. These error messages all mean the same thing, but will raise your localization cost needlessly.

Not enough disk space / There is not enough disk space left  / Insufficient disk space / No space left on the disk

9. New versions/updates: Once your application is up and running in many languages, keep track of changes you make to your next version, so that only those changes will be translated.

10. Web site: And of course, present your customers with a well translated web site. Some tips on that in a future entry of “Passage: A bridge between two worlds”.

Happy coding! 

Julie
PS: See also more localization tips!