![]() ![]() Note: The path through languages, countries and country region could be different. Data that is already the same on the more general level is not repeated. Branches lead to more specialized regions, usually through languages, countries and country regions. Data is structured in a tree like structure, with the most general region in the root (most commonly, the root region is the native language of the development team). Software is able to access the data through the API calls. ![]() The previous points all lead to a separate mechanism that stores data separately from the code. If the data is grouped correctly, the program can automatically find the most suitable data for the situation. For example, a Spanish speaking user in Mexico would probably be happier with Spanish than with English captions, even if some of the details for Mexico are not there. However, if the data is structured correctly, the user can be presented with similar data. Sometimes, the exact data for a region is still not available. A convenient way to do this is to use a tree like structure.Īnother way to reduce the data size is to allow linking of the resources that are same for the regions that are not in general-specific relation. This can be achieved by structuring resources in such a way so that an unsuccessful query into a more specific resource triggers the same query in a more general resource. It would be very beneficial if we can prevent the duplication of data. It is not unlikely that the data will be same for several regions - take for example Spanish speaking countries - names of the days and month will be the same in both Mexico and Spain. A convenient way for keeping binary data should also be provided - often icons for different cultures should be different. The data should contain all the elements to be localized, including, but no limited to, GUI messages, icons, formatting patterns, and collation rules. Resources are kept in human readable/editable format with optional tools for content editing. Application access data through API calls, which pick the appropriate entries from the resources. A separate resource managing mechanism is hence required. Instead, the translatable data should be kept separately, in a format that allows translators easy access. Obviously, one does not want to make translators wade through the source code and make changes there. There are several points to keep in mind when designing such a localizable software product. The process of localization will eventually involve translators and it would be very convenient if the process of localizing could be done only by translators and experts in the target culture. From the simplest point of view, that data is the information presented to the user (such as a translated message) as well as the region-specific ways of doing things (such as sorting). ![]() For an overview of the message localization process using ICU, see the related page Localizing with ICU.Ī software product that needs to be localized wins or loses depending on how easy is to change the data or “resources” which affect users. Note: This page describes the use of ICU4C Resource Management techniques and APIs. This site uses Just the Docs, a documentation theme for Jekyll.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |