Software localization

The educational technology and digital learning wiki
Jump to navigation Jump to search

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. (Le grand dictionnaire terminologique). McKethan and White (2005) define localization as “the process of adapting an internationalized product to a specific language, script, cultural, and coded character set environment. In localization, the same semantics are preserved while the syntax may be changed.” The authors further argue that “Localization goes beyond mere translation. The user must be able to not only select the desired language, but other local conventions as well. For instance, one can select German as a language, but also Switzerland as the specific locale of German. Locale allows for national or locale-specific variations on the usage of format, currency, spellchecker, punctuation, etc., all within the single German language area.”

Since we shall focus on translation of open source software, we shall stress the importance of "ergonomic aspects" as a priority. Ergonomic translation means both "surface usability" (users can understand the meaning of UI interface elements and system messages) and cognitive ergonomic (user can get meaningful tasks done with the system).

Abbreviations for internationalization, localization and globalization

Internationalization is known as I18N.

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

Software globalization (i.e. localization that also extens to local subcultures like German Swiss (de_ch) or French Suiss (fr_ch) is known as G11N 

G11N = I18N + L10N

Issues

Infrastructure and people

In a larger project, the list of types of participants can be quite long: E.g. Gregory M. Shreve identifies: Project managers, Translators (Generic), Localization Translators (Specialists), Terminologists, Internationalization/Localization Engineers (Software Background), Proofreaders, QA specialists, Testing engineers, Multilingual Desktop publishing specialists.

Now, what would the absolute minimal rules in a volonteer-based open source project ?

  • one person to coordinate software development and translation
  • one person to coach translators (can be the one above)
  • translators

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
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.e. they have know how of the tool which "normal affordable" translators do not have.

I (10:25, 21 January 2010 (UTC)) believe that there ought to be some strategies to improve volonteer translation efforts. The main issues:

(1) Motivating people to help and to continue translating

(2) Make sur that translation is usable (see next item)

Technical infrastructure

Translators should "see" what they translate. This implies concerns several items. 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")
  • A meanigful short description. This description may include a link to a glossary.
  • 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
  • Be able to edit and consult a short glossary that includes the most important terms (might be combined with the general user manual)
  • (dreaming) direct access to some online translation dictionary like the english/french grand dictionnaire terminologique

Links

Short howtos
Issues to look at
Classes
Softare
  • Trados® Freelance™, Atril Déjà Vu, STAR Transit, SDLX™, IBM TranslationManager,

Bibliography

  • McKethan, Kenneth A. (Sandy)Jr. and Graciela White (2005). Demystifying Software Globalization, Translation Journal 9 (2), April 2005. HTML, retrieved 10:25, 21 January 2010 (UTC).
Retrieved from "https://edutechwiki.unige.ch/mediawiki/index.php?title=Software_localization&oldid=24527"