Software localization

Draft

This article or section is currently under construction

In principle, someone is working on it and there should be a better version in a not so distant future.
If you want to modify this page, please discuss it with the person working on it (see the "history")

Introduction

Software localization can be defined simply as "translation of software" or as "adaption of a product following the needs of a particular population in a precise geographic region". The latter implies that translation includes linguistic, cultural and ergonomic aspects. ([http://www.granddictionnaire.com/BTML/FRA/r_Motclef/index800_1.asp Le grand dictionnaire terminologique).

Localization is also known as l10n, an funny acroynm that is composed of the l of localization, followed by 10 letters (ocalizatio) and the final n of localization.

Some ground rules

On the code side

Language files

All output messages to the user must be defined as a kind of constant that the programmers will use

Name of the constant should be meaningful to translators. E.g.

Languages files must be separate (if terms are not in a database)

Encoding

• Use Unicode

Space and Layout

• Space of text fields: Some languages are more verbose and one must plan for that, by using wider icons, menu items, user input fields and such or else use a "fluid" design.

Managing volonteers in an open source project

Opensource projects don't have the funding to pay professional translators. This situation has disadvantages but also some advantages.

Disadvantages: Quality of the translation, completion (untranslated strings for new versions, missing languages, etc.)

Advantages: Meaninfulness of the translation (often translators are users)

I (09:27, 21 January 2010 (UTC)) believe that there ought to be some strategies to improve volonteer translation efforts. I see X main issues:

(1) Motivating people to help and to continue translating

(2) Improving the technical infrastructure so that translators can "see" what they translate. This implies several things.

• When translating a string, the translator should be able to see:
  • The name of the constant (which must be meaningful, e.g. "modulename.mainmenu.edit" or "modulename.errormsg.upload.xxx")
  • All other translations (languages strings) the translator understands (e.g. if I translate to German, I'd like see both English and French)
  • (If possible) the constant displayed in the interface. That of course requires extra programming. Or even better: be able to edit strings directly on the interface

• Tools for consistency
  • When translating hundreds of strings (and the situation gets worse if it's done by several people) there should be a way to search through all terms in all modules in three ways:
• Find same expressions in the target language and display an other language next to it
• Find same expressions in another language and display the target strings next to it
• (that dreaming) direct access to some online dictionary like Le grand dictionnaire terminologique (english/french)

Links

• How to Localize Software (Developer-resource.com, retrieved 09:27, 21 January 2010 (UTC)).