Do's and Don'ts in Software Development Before Localization

By Micheline Freij,
Operations Director,
GlobalVision International, Inc.

Micheline[at]globalvis.com

Executives are under a constant competitive pressure to speed up product time-to-market, and in turn many developers must work in very tight deadlines to deliver functional software. Once the source language version is ready for release, this software is often sent for localization.

If developers know beforehand that this software will be localized, and if they are familiar with internationalization (I18N) and localization (L10N) issues, they can make sure while developing software, basic principles are maintained to facilitate localization efforts - and meet time-to-market requirements for all the required languages, not just the source.

The following is a list of 12 dos and don?ts that is recommended for all developers, for reading and applying in their work.

DO EXTERNALIZE MESSAGES IN MESSAGE CATALOGS, RESOURCE FILES, AND CONFIGURATION FILES

DO ALLOW FOR TEXT EXPANSION IN MESSAGES (ESPECIALLY FOR GUI ITEMS).

The following are some Microsoft translations into German:

bundle -> Einzelvorgangsbündel
Link -> Verknüpfung
Login -> Anmeldung
Update -> Aktualisierung
Undo -> Rückgängig (machen)
Geschäftsaktivitätsüberwachung replaces the acronym BAM (Business Activity Monitoring)

The following expansion rules should be applied when possible.

When the source text is:

0 -10 characters: The expansion required is from 101 - 200%.
11- 20 characters: 81 - 100%
21 - 30 characters: 61 - 80%
31 - 50 characters: 41 - 60%
50 - 70 characters: 31 - 40%
Over 70 characters: 30%

You should. However, make sure that the string length is well below your limit (usually 254 characters) to account for the extra characters needed.

DO PERFORM PSEUDO-TRANSLATION

Pseudo-translation is the process of replacing or adding characters to your software strings to detect character encoding issues and hard-coded text remaining in the source files.

DO USE UNICODE FUNCTIONS AND METHODS TO SUPPORT ALL SCRIPTS

Using Unicode encoding solves the problem of unsupported character sets and the display of junk characters.

DO MAKE SURE YOU CHOOSE YOUR THIRD-PARTY SOFTWARE PROVIDER CAREFULLY

You must make sure they support Unicode and comply with the above practices. With third-party software often problems are encountered, and since you don?t have control over their code to fix the problems makes the localization tasks particularly difficult.

Often third party tools are localized. If so, this will help save on your localization costs. Ask your software provider to give you access to the localized files and glossaries. If they are not localized, Pseudo translation is a good technique to apply to quickly test for obvious issues.

DO USE LONG DATES OR MONTH ABBREVIATIONS INSTEAD OF NUMBERS WHEN IDENTIFYING DATES

In different parts of the world, month vs. day orders vary (for example, dd/mm/yy in Europe; mm/dd/yy in the US).

In addition, the use of AM and PM can be problematic in Europe as they use a 24 hour format as opposed to two 12 hours.

DON'T INTERNATIONALIZE FIXED TEXTUAL OBJECTS

DON'T USE VARIABLES WHEN YOU CAN AVOID THEM

For some languages, the translator cannot be sure as to the gender of the term to substitute Variables, and this makes it difficult to correctly translate the sentences that incorporate it. If you have to use variables, you should offer a list of replacements. You must also allow for gender and plurals variations in the translation of the sentences that contain the variable.

For example:

<%if err = 400

               errtext = "server"

else

               errtext = "connection"

end if

<P> The <%=errtext%> is currently unavailable </P>

While this displays sentences that are grammatically correct in English, the translation in French, for example, will be problematic. In French, the word "server" is masculine, while the word "connection" is feminine. The translator cannot use the correct translation for the article "the" based on the translation of the differing genders of ?server? and ?connection?.

The code should be instead:

    <%if err = 400

    <P> The server is currently unavailable </P>

    else

    <P> The connection is currently unavailable </ P>

    end if

At the same time and for similar reasons, don?t use composite strings. A composite string is an error message or other text that is dynamically generated from partial sentence segments and presented to the user in full sentence form. Use complete sentences instead, even at the expense of repeating segments. This will ensure the accuracy of the translation, regardless of gender, plurality, conjugation, or sentence structure.

Also, avoid using the same placeholders when using multiple variables in the same string, since the sentence structure does change in different languages. For example,

<Total %s, %s of %s< (as in Total 5, 1 of 5) might read "5 of 1, Total 5" in the translated text. Instead, use numbered placeholders (e.g., "Total %1, %2 of %3").

DON'T USE "IF" CONDITIONS OR RELY ON A SORT ORDER IN YOUR CODE TO EVALUATE A STRING VALUE.

Always depend on enumeration or unique IDs.

DON'T INSERT HARD CARRIAGE RETURNS IN THE MIDDLE OF SENTENCES

Translation memory tools used by localization companies key off hard returns and assume that the sentence has ended. Inserting them in the middle of a sentence leads to incomplete sentences in the translation database and corrupts the sentence structure in the target language files. Instead, replace hard returns with soft returns (or better yet, use a break tag of some sort, such as <BR>).

Also be aware that sentence structures change in different languages, as well as the length of sentence parts. So, additional breaks may be needed in target languages.

DON'T USE TEXT IN ICONS AND BITMAPS

In general, it is recommended to create graphics in either a vector format like Adobe Illustrator, Macromedia Freehand, or Corel Draw, or if a bitmap format is required then save the text in a new layer, like with Adobe Photoshop.

Also, note that the translated text may be too long to fit. In addition, avoid using symbols with cultural connotations and locale-specific idioms.

DON'T ALPHABETICALLY SORT STRINGS IN STRING TABLES AND RESOURCE BUNDLES

Try to offer as much context as you can with the externalized strings. The translator can then better adapt the translation to that context.

For example: "Check" in a financial software could be the action (noun or verb), or the monetary equivalent. "Update" could be the action (to update) or the software itself. "Email" could be a verb or a noun.

CONCLUSION

Keep in mind that once you localize your product, the amount of work that will be needed for debugging and fixing any problems has the tendency to be multiplied by the number of languages that you support. Following these principles will not only expedite localization, but more importantly reduce testing, rework, and quality assurance time and costs - ultimately allowing your company to meet the strict time-to-market requirements expected by your executives.

Don't short-circuit your localization activities by side-stepping these issues. If you need help, consider involving experts.

*******

WSL can help you convert your product (software, documentation, online help, multimedia, etc.) into other languages.

WSL - Weizman Software Localization specializes in Hebrew and Arabic, as well as FIGS (French, Italian, German, Spanish) and CJK (Chinese, Japanese, Korean). We also handle Russian, Dutch, Portuguese, Swedish, Turkish, and other European and Asian languages.

For more information on our translation services, please download our profile HERE,

or contact:

Sagi Adiv
WSL - Weizman Software Localization Ltd.
www.WSL.co.il

Kibbutz Giv?at Ha-Shlosha, P.O.Box 379,

48800 ISRAEL

Tel: 972-3-9018890

Mobile: 972-54-3286565
Fax: 972-3-9018897
wsl-info@wsl.co.il

Primary links

Do's and Don'ts in Software Development Before Localization