 |  |
Globalization Step-by-Step
Localizability Overview
On This Page
Overview and DescriptionIf you think that after a US product has been developed and trouble-shoot, it is easy to generate localized software by just translating a handful of UI-strings, think again!!!!! There are many many complications in most software projects that make it hard to localize:
On top of that there is always pressure of time, high volumes of changes, etc. This makes localization a complicated and error prone process. It is so hard to predict what strings can be localized and how they can be localized without introducing functional errors, that translating software strings can be compared with walking in a mine field. The basic problem is that there has never been a framework providing a way to separate strings used for functionality and strings that are displayed in the UI. Because of the lack of this framework, people have not been forced to think about impact on localization, and their software designs have not been fully international enabled. A resource table means different things for development as for localization. A resource table for development is a central storage of strings used in the code. If the string changes, the string can be changed in one location in the resource table, instead of in many places in the code. It is also a safer practice to do so, not changing code unnecessarily. Localization sees a resource table as a table of strings that need to get localized, however these strings are not necessarily UI strings. Some of the strings are used functionally, represent keys, identifiers, etc, and translating them has functional impact. In some cases information has been added to the source files, meant for localization, however this information is lost during compilation. As localization uses a non-compile process (localizing the compiled binaries instead of the source files), this information is not visible to the localizer. How to move forwardThe best way to move forward is to integrate "thinking about localization" in the development (and test) cycle. We need to setup a framework and guidelines to help development with this task. Support will need to be provided where needed. The proposed framework exists of two pieces, the first part is the clear separation of resources in "functionality related resources" and "UI related resources", together with solving some of the current limitations and dependencies in the software. This we call the "language neutral product" (for more information, see Isolating Localizable Resources). The second part of the proposed framework is pseudo localization. Pseudo localization is a simulated localized product. Every string gets replaced by a semi-random pseudo localized string. The product can then be tested for it's localizability. What else?There are a number of other factors that contribute to easy localizable software. Below you can see a list of these.
To learn more about these items continue with the rest of the sections under Localizability:
|
In This Article
|
