Patent Application
20050137845
1. Field of the Invention
This invention generally relates to a method and to database structures that enable multi-language support for dynamic data, as part of an overall National Language Support (NLS) strategy. More specifically, the invention relates to a method that enables the persistent storage of textual data in multiple languages, concurrently, in a single database instance, and the retrieval for presentation of that data in a language appropriate for the specified NLS locale.
2. Background Art
When discussing systems applications, National Language Support refers to the ability to present information to users of an application with consideration for the particular linguistic and cultural preferences of a designated locale. In addition to the need to support multiple languages and dialects, these considerations include region-specific calendars, currency, date and time formatting, dictionary sorting, message formatting, number formatting, and text that flows in directions other than left-to-right.
Many NLS enablement functions (particularly those involving formatting) are the assigned responsibility of the presentation component of an application. This discussion, however, is focused on considerations for managing translatable, textual data and the persistent storage and retrieval of that data in multiple languages. Note that this refers specifically to storing the same piece of data in multiple languages and not simply to storing multiple pieces of data each in a different language.
Development of an NLS enabled application begins with a structuring of application components that effectively separates data from application logic, a technique known as “internationalization.” There is then a choice of design strategies, either “localization” or “globalization.” A localization approach involves adapting the application for a specific region and language, a process that must be repeated for each supported locale. Globalization refers to implementation of the application so that a single instance, simultaneously, accommodates any region and language.
The increasing use of web-based applications has enabled businesses to extend their area of operations beyond regional and national boundaries, and there is a corresponding need to develop and implement NLS enabled systems applications. In general, adoption of a globalization strategy delivers NLS enabled applications which are far less expensive to build and maintain. The key to globalization is the deployment of a single instance of each application for use around the world rather than duplicate parallel application instances each supporting a different locale.
The information presented to users of an application can be viewed as a combination of data that falls into three categories. There is, typically, “dynamic data” that has been captured and maintained through use of the application (either interactively by users or received from other system components), “static reference data” that is provided with the application and defines the valid context for the application's use (for example, the recognized set of status codes), and “other static information,” including titles, headings, and labels, that form the template on which data are presented to the user.
There is a considerable volume of literature available on NLS enablement techniques for static data, including both static reference data and user interface templates. In cases where products have implemented NLS enabled solutions, however, the multi-language capability is either limited to static data, or the implementation is based on a strategy of localization and requires the deployment of multiple database instances, each supporting a single locale.
Known solutions for NLS enablement do not implement a globalization strategy when addressing the need for the persistent storage of dynamic, textual data in multiple languages. Instead, the use of a localization strategy assumes either that access to the data in each application instance will be limited to the single, supported locale, or that the application will be supplemented with routines to replicate data in order to provide integration across application instances. The dependence on localization results in the increased cost of application deployment, operation, and maintenance, and the inherent risk of inconsistencies in data and processing logic.
An object of this invention is to enable the storage and retrieval of dynamic textual data in multiple languages, concurrently, in a single database instance.
Another object of the invention is to implement a globalization strategy when addressing the need for the persistent storage of dynamic, textual data in multiple languages.
These and other objectives are attained with a method and system for enabling multi-language support for data. The method comprises the steps of capturing a piece of data in a first language, and translating the piece of data into a plurality of additional languages. The original piece of data and all of the translations are stored in the same database instance, for retrieval and presentation in any of a group of supported languages. The preferred embodiment of the invention provides a design and implementation of generalized database tables to implement the features of NLS Locales and NLS Text Groups, in order to enable the storage and retrieval of dynamic, textual data in multiple languages, concurrently, in a single database instance.
Among other advantages, the present invention enables the scenario wherein a piece of data captured in one language is dynamically translated into all supported languages, and all translations are stored in the same database instance, for retrieval and presentation in any of the supported languages.
Further benefits and advantages of the invention will become apparent from a consideration of the following detailed description, given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention.
National Language Support (NLS) is based on the definition of recognized Locales, each representing an established set of linguistic and cultural preferences. These preferences are most commonly grouped by language and country or region, and each Locale is identified by the combination of a language code and a country code. In the preferred embodiment of this invention, the language and country codes used are those defined and maintained by the International Standards Organization (ISO). Specifically, ISO standards ISO 3166 and 639 provide country and language codes, respectively.
As illustrated in
The combination of codes representing each Locale is typically displayed with the language code followed by the country code, separated by an underscore. For example, “en_US” indicates the variant of the English language as used in the United States and the cultural conventions of the U.S.A.
With reference to
It may be noted that in enabling an application for NLS support, the application must have the ability to identify the preferred Locale of individual users. This is typically achieved through implementation of a User Profile which includes the preferences specified by each user. It may, alternatively, be done on a per session or even a per transaction basis. In the practice of this invention, any suitable structure may be used to support the concept of User Profile.
Data Capture and Translation
In one implementation of this invention, the data being captured or maintained (either interactively through a user interface or another component of the system) is submitted to the database component along with the NLS locale specified by the user. Some of the data elements may be defined as requiring translation before being presented to users who have specified the preference for a different NLS locale.
As illustrated in
As will be apparent to those of ordinary skill in the art, any suitable process may be used to interact with a translation service; and for example, this process may have specific dependencies on the technology used by the application system and the selected translation service. Also, this translation service may involve use of automated translation machines, or manually supported translation services, for example, the use of an IBM Translation Service Centre (TSC).
NLS Text Group and Text Tables
Data elements not requiring translation can be stored as attributes of a specific entity, implemented as a table in the database. Data elements designated as requiring translation are stored in tables designed to contain multiple translations of the data value.
Each translation of the data value is associated, not only with the entity to which the attribute belongs, but also with the NLS locale for which the translation was performed. The design and use of the desired database structures is greatly simplified by employing a generalized set of tables to hold the translated text values for all attributes of all entities.
The NLS Text Group is defined as the set of attributes of a specified entity that require translation in order to enable NLS. In the preferred embodiment of this invention, the NLS Text Group is implemented as a table in the database and associated with each entity that has attributes requiring translation. A row is generated and stored in the NLS Text Group table for each row in each table that implements an entity with translated data element values. The association with the specific entity is implemented as a foreign key relationship to the table that implements the entity.
With particular reference to
Also, the preferred embodiment of the invention implements the NLS Text Group at a row level, where each entry in the NLS Text Group table is associated with a row in a specific entity table. Alternatively, the NLS Text Group can be implemented at a column level, where each entry in the NLS Text Group table corresponds to a single column in an entity table. While this will avoid problems associated with the multiplicity of text fields in the NLS Text table, it adds considerable complexity to the design and use of the database, and may impact runtime performance.
It may be noted that, although the present discussion is focused on dynamic data, captured and maintained interactively, the above-described structures can also be used for static reference data that is pre-loaded in the database during application deployment.
Data Retrieval
The preferred embodiment of the invention also enables retrieval of data, for either presentation to the user or transmission to another component of the system, and this retrieval of data may be constrained to a specified NLS locale. As during data capture, the application must have the ability to identify the preferred locale of individual users.
Data elements not requiring translation can be selected from the database tables used to implement the entities. Access to data elements which have been translated for each locale must access the entity tables and the associated rows in the NLS Text table, making use of the “nls text group id” column on the entity table and the “language code” and “country code” values which identify the specified NLS locale.
It is possible that, at the time of data retrieval, the translation of a requested data value may not be available for a specified locale. This may occur due to a time lag between the initial capture of the data and the response from the translation service. Additional application features, discussed below, may be implemented to provide an appropriate response to the user.
Additional Features
1. Locale Substitution
During data retrieval, if a translation for the specified locale is not available in the database, it may be appropriate to substitute an existing translation that has been created for another locale. Implementation of a locale substitution strategy should be based on the standards and guidelines governing design of the application.
The substitute translation may be selected from a locale that uses the same language, for example, the substitution of a US English (“en_US”) translation when the Canadian English (“en_CA”) translation is not available. The application may also, as indicated in
2. NLS Text Group Documentation
Explicit documentation of the mapping between entity attributes and the generalized “text fields” (in the NLS Text table) used to store the corresponding data value translation can be used to facilitate application testing and maintenance.
Implementation of generalized data structures, such as the NLS Text Group and Text tables, simplifies application design and execution but complicates the application testing and maintenance process. As shown in
With reference to
These tables are populated and maintained during application development and maintenance activities and are not, typically, accessed during application execution. They are used during application testing to confirm the contents of the NLS Text Group and NLS Text tables.
The preferred embodiment of the present invention, as described above, provides a number of important advantages. For example, this embodiment of the invention enables concurrent, multiple language support for dynamic data, rather than simply static data; and leverages implementation of a globalization strategy employing a single database instance, rather than multiple instances each supporting a single locale. Also, the preferred embodiment of this invention achieves benefits associated with globalization including consistency, flexibility, and lower total cost of ownership. In addition, the present invention is extensible to support additional NLS locales without design modification, can be extended to incorporate additional data elements requiring translation, and can use row-level data access to optimize application performance.
While it is apparent that the invention herein disclosed is well calculated to fulfill the objects stated above, it will be appreciated that numerous modifications and embodiments may be devised by those skilled in the art, and it is intended that the appended claims cover all such modifications and embodiments as fall within the true spirit and scope of the present invention.
