Data processing: speech signal processing – linguistics – language – Linguistics – Multilingual or national language support
Reexamination Certificate
2002-04-03
2003-01-14
Edouard, Patrick N. (Department: 2644)
Data processing: speech signal processing, linguistics, language
Linguistics
Multilingual or national language support
C717S137000
Reexamination Certificate
active
06507813
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
For software publishers, overseas markets comprise an ever-growing percentage of revenues for all major PC applications. Traditionally, however, software products have been designed with little or no thought toward portability, let alone translating software products for overseas markets. As non-English speaking countries are buying more and more software from U.S. publishers, there is keen interest in improving the process of enabling or “internationalization”, that is, designing and coding a software product so that it can be made to function for international use.
In the past, the process of providing National Language Support (i.e., accommodating a specific country's language, conventions, and culture) was done on a more or less ad hoc basis—essentially retrofitting software to accommodate a particular locale. Merely separating the text in a user interface from one's program is not an acceptable solution, however. Even after translating software prompts, help messages, and other textual information to the target languages, one still has to address basic issues of displaying and printing characters in the target language.
For instance, a target language will often include characters which are not defined by the default character set provided by the computer's operating system. IBM-compatible PCs running MS-DOS, for example, can display and print up to 256 different characters, the first 128 characters of which include the well-known 7-bit ASCII character set. This, of course, is not enough characters to support all languages. Some languages will obviously require a different character set; thus, sufficient means must be provided for switching character sets.
Other issues to consider when developing a system for foreign users include keyboard layout and various format conventions applicable for a particular country. Any use of currency, date, time, and the like within one's software must take into account these factors. For example, keyboards sold for European languages must include additional characters, such as letters with diacritics, and symbols, such as the British pound (£) sign.
Another potentially serious problem for localizing a program is the set of assumptions with which the underlying source code for the program was written. Assumptions made by English-speaking programmers, which were quite valid for the once-ubiquitous ASCII character set, often break down when dealing with a foreign language. For instance, the common programming technique of converting a character to uppercase by simply adding the number 32 to the character (numeric code) is often inappropriate for non-ASCII characters. Similarly, one cannot rely on standard C functions either. For instance, one cannot use simple string comparison functions like the C programming language's strcmp( ) function. Does an “ã” (i.e., an “a” with a diacritic) sort before or after a normal “a”?
One of the first serious attempts at providing National Language Support (NLS) for PCs was Microsoft's MS-DOS version 3.3. Since MS-DOS accommodates different sets of 256 characters for displaying and printing text, one may employ different characters by swapping in new character sets. Each such character set is referred to as a “code page”; the code page in use at any given time is called the “active code page.” When installing operating system software, typically, a user may select a code page appropriate for his or her national language.
MS-DOS also includes an API (Application Programming Interface) having a variety of functions related to internationalization. Included are functions for inspecting code pages for determining and controlling how the keyboard, display, and printer handle characters. The API include functions, for instance, for inspecting and changing the current country code and obtaining information about the conventions associated with a current country code (e.g., how to display dates, currency, and the like).
Newer versions of MS-DOS also include support for character comparisons, through use of language-independent tables for sorting strings. Still, this is by no means a complete solution to the problem. Arabic languages, for instance, remain problematic. For one, Arabic is read and written right-to-left, not left-to-right. Also, Arabic characters require contextual analysis in order to determine which of four different shapes the Arabic characters should have (depending upon location in a word or phrase). Thus, a language may have its own special set of problems which must be addressed before international use.
To date, efforts at localization have been largely limited to ensuring that a particular program, such as an operating system or application software, is itself enabled for a particular country. When installing Microsoft® Windows, for instance, a user is asked to select a country from a list of supported countries. Windows, in turn, installs various keyboard, display, and print drivers appropriate for the selected country. This “program centric” approach is only a partial solution, however.
Consider the scenario of a corporation based in the U.S. receiving sales information from several foreign subsidiaries. Typically, such information would be transmitted as data files, such as spreadsheet or database files. In this instance, the information management system in the U.S. may be required to process data files created from a variety of foreign data processing systems, ones having character sets and conventions peculiar to a particular country. converting such data files from one language to another inevitably results in the loss of language-specific information. Once converted, the information cannot be processed (e.g., adding and deleting information records, generating reports, and the like) and then simply reconverted back to its original form. Moreover, should that information be inappropriately processed (e.g., sorting German information according to an English sort order), valuable data may be corrupted.
One approach to averting this problem is to agree, in advance, on a single data format (e.g., code page 437—the variant used in the United States and many European countries) to be used by all foreign offices of the corporation. However, this solution invites another problem: the foreign offices must forego their own National Language Support, thus compromising their own data processing needs all for the convenience of the U.S. office. And even with such an approach, the risk remains that an office may inadvertently mix data from its locale with the agreed-upon format, leading to corruption or loss of data. Needless to say, the approach is undesirable at best.
System and methods are needed which allow users of computer systems to create and freely exchange data files, irrespective of National Language Support requirements. In particular, such a system would permit a user to create an information file in his or her own locale without regard to the requirements of other systems which may need access to the very same data from that file. The present invention fulfills this and other needs.
SUMMARY OF THE INVENTION
The present invention comprises a National Language Support including a language configurator, for processing data objects in a manner which is appropriate for the language configuration of each object. The language configurator provides necessary support for a data object (which typically stores information in a particular language) so that the data object may be appropriately processed by the system.
The system of the present invention continually checks and maintains correct language configuration. A descriptor or Language Driver Identi
Schnepper David Brett
Veditz Daniel Paul
Boland Software Corporation
Edouard Patrick N.
LandOfFree
System and method for national language support does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for national language support, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for national language support will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3009861