'''Definition''' SoftwareLocalization is the process to adapt a software so that it can be sold in markets outside of the country of origin. Localization or Internationalization basically consists of the translation of the software GUI and documentation. However, the translation of the software GUI requires massive extensions of the software architecture. FrankBergmann, CTO of a SoftwareLocalization company ---- '''The Fundamental Localization Issues''' * Software localization is expensive, because it requires a lot of manual translation work in order to produce good text quality * Localization is boring * Software developers and translators work in different spheres, making collaboration and review difficult. ** See BroadbandFeedback, which is the nice technique of putting screen-shots of your test-runner's output into a Wiki test framework * There are a number issues with localization that are difficult to imagine for monolingual software developers, such as different time/date/currency formats, strange character sets, "text swell" etc. See the primer below for more details. * Making a program's locale pluggable might risk BigDesignUpFront issues * Locales strongly resist TestDrivenDevelopment, because not all developers are polyglots. ---- '''Articles and Resources''' * Multilingual Architecture Primer (http://www.project-open.com/whitepapers/localization/) - Describes how to design software a software architecture so that it's easy to localize * Free Definition of Localization & Internationalization (http://www.free-definition.com/Internationalization-and-localization.html) * Java Internationalization Homepage (http://java.sun.com/j2se/corejava/intl/) ---- '''How It Works''' Let's imagine you have developed a software package that is successful in the US. Now you want to sell it in Germany, France, Japan and China for example. These countries are known to be very picky with language issues and would constantly call your hotline to complain about grammar mistakes, ugly menus etc. Your first straightforward option is to contract a large "multi language vendor" (MLV). They can provide you with a turnkey solution in exchange for a hefty share of your sales revenues in each country (up to 30%). They have in-house localization management teams that organize the entire localization process for unskilled software companies. Then they send the preprocessed files to "single language vendors" (SLV) in each of the target countries for translation. The SLVs in turn send the files to a number of freelance translators that do the real translation work. These poor freelancers receive only a fraction of the money. Your second option is to manage the translations yourself and save some 30%-50% of localization costs by contacting SLV vendors or freelancers directly. Also, this option allows you more control on who actually is translating you software (because MLVs frequently change providers). On a down side, you will need somebody familiar with the translation industry and capable of selecting and evaluating the single language vendors. Also, you will need certain IT infrastructure (translation workflow) to manage product releases, particularly with large software packages or when you need to release simultaneously in several languages. A third option seems to work for open-source software. The OpenACS project for example relies on voluntary work to translate their GUI by means of an integrated localization interface. I have heard about Wiki-based translation of other open-source projects. ---- ---- '''Discussion''' ---- CategoryInternationalization