The present invention deals with data processing.
Localization is a process of modifying products or services to account for differences in distinct markets. A very common example of localization occurs when an application is authored in a source language and is introduced into a market that uses a target language different from the original one. For instance, if an application were authored in the English language and then introduced into China, it would be localized by translating the various English language strings and UI elements (menus, icons, etc.), software components and user assistance in the application into Chinese. The UI layout and style (including font type, size, control positions, etc.) will also likely be changed to suit the target language. Of course, the concept of localization is broader than simply modifying language. Markets that use the same language may be distinct for other reasons. For instance, a software application may be “localized” for different age groups. It may have one set of language and appearance for adults and another for children or teens. Thus, localization illustratively accommodates for a wide variety of differences in distinct markets.
Although, as described above, localization involves many more things that just translating strings; to facilitate the reading of the document we will concentrate the description on that scenario. In a similar way, most of the examples are taken from the software localization field but the invention is not limited to software localization. Similarly, while much of the present discussion focuses on localizing a product, the invention is not so limited and is just as applicable to services, and thus the term “product” includes “services” for the sake of this description. In the past, there has not been a system-level attempt to provide localization but instead, localization has been performed using individual components to solve individual problems. For instance, a localizer may be augmented with certain machine translation techniques to improve localization speed, accuracy and consistency. However, a different localizer may use just translation memories in order to increase the recycle rate by reusing previous translations, hence providing a more consistent result at a higher speed than she would without tools.
Also, this has all been done, conventionally, in an offline way. In other words, the author creates an entire application or a large portion of a component, and that component or application is provided to a localizer for localization. The usual process is such that the localizer's interaction with the original author is minimal or non-existent. This makes it hard to introduce changes in the original content that would ease its localization. In fact, in many cases, localization is not performed until well after the entire product has been developed and a strategic marketing decision has been made to expand that product into a different market that uses a different language or is distinct in another way. In all of these cases, there is typically very little up front work done in developing an application with localization in mind or even optimizing for localization. Similarly, there is very little support, in the development/authoring stage, for developing an application or other product/service which will be relatively easy to localize, even though authoring a product or service which is easily localizable is no more difficult than authoring one that is not easy to localize.
Therefore, products, services and applications have traditionally been translated into different languages or otherwise localized through a complex, manual and labor intensive process. The cost for this localization of software products, and the translation of product related content, represents a significant hurdle which must be overcome in order to enter new markets. This is especially true for small to mid-size independent software vendors or content authors.
The problem of localization also scales depending on the particular location in which the software is developed. For developers that are authoring software in locations that have large markets, localizing the software to different (and likely smaller) markets is less of a need. However, if a developer authors in a location (and using a language) which has a relatively small market, the entire viability of the product may depend on the ability to localize that product into languages used in larger markets. This requires the manufacturers to spend an inordinately high amount of resources on localization. This often detracts from the resources available for development.
Another problem associated with prior localization efforts is that there has not been a good way to draw on the work of a variety of other localization sources. For instance, a wide variety of vendors localize their products for various markets. Similar applications, developed by different vendors may likely be localizing the same, or very similar, strings or software for the same markets. However, there is currently no expedient way for the two to draw on, or share, the efforts of one another. Therefore, there is a great deal of duplicated effort in localizing products.
Furthermore, there are many different programming models (such as Win32, CLR and WEB scripting) with different types of resource managers, resource formats and data stores. They require different parsers and tool sets to handle localization, which results in complex and costly processes, and inconsistencies in localization quality.
USPTO Backgrounds
USPTO Backgrounds