软件本地化的准则
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
The Basics of Software Internationalization
Dan Moore
To do it right, start from the basics… And before doing anything else!
Software internationalization builds support for multiple locales in an application, where a locale is “[a] subset of a user’s environment that defines conventions for a specified culture,” (Cf. /doc_link/en_US/a_doc_lib/aixins/insgdrf/glossary.htm) typically including language. Supporting multiple locales lets the user choose the most appropriate one, allowing for easier use of the given application. It is best to complete the internationalization process as the application is being built, since adding in such support after the fact can be expensive and complicated.
In the following article, we will examine the major internationalized components of a web application, and extend some principles to all software internationalization efforts. This application was built in Java with an Oracle back end, primarily by Zia Consulting
(), and provides quotes for equipment to people in 27 countries. The software libraries referenced in this article will be Java standard libraries; other languages may or may not have the same level of support.
The three main phases involved in internationalizing an application are:
•finding the user’s preferred locale within the set of supported locales
•displaying information appropriate to the chosen locale
•operational concerns
Please note that internationalization is only half of the process—when the application can handle different locales, locale-specific data and information must be provided. That process is called localization, and this article will not cover the topic.
Finding the Appropriate Locale
First, a user must be associated with a locale. This is a configuration setting like any other. Allowing the user to explicitly choose the appropriate locale is crucial. There are some hints that the user’s computer can provide: in Microsoft Windows, for instance, there is a “Country” key in the registry1, and web browsers can provide preferences for a given locale and communicate this information to the server in a process called language negotiation (/International/questions/qa-when-lang-neg).
1For more information on this topic, please check the “How to read, add or modify Windows registry entries with REGEDIT” topic of Rob van der Woude’s website
(/index.html). It can be found by clicking the “Batch files” link under the “Scripting” section on the home page.
However, while these can serve as starting points for a piece of software, they certainly do
not represent the entire answer. The operating system may be configured incorrectly, or a user might be at an Internet cafe in a foreign country with settings adapted for that cafe’s
typical user, but not for him or her.
When the locale of an application is not set correctly, a typical user blames the application, not the operating system or browser. And unlike other configuration options, an incorrect choice of locale often renders an application useless. There also may be business requirements that require the user to choose their locale regardless of the machine setting.
For example, in the quoting system to which this article refers, users must be able to
receive a quote in US dollars. This often happens when multinational corporations have a procurement entity that deals with US dollar quotes only.
GFTPKlient Locale Install Dialog
In short, the best method for finding the proper locale for a given user is to ask. For
desktop applications, this usually occurs at installation time, as shown in the illustration above. For web applications, it is a bit more complex, but generally the application should
not ask for the preferred locale whenever it can recognize that a request has come from a user for whom the preferred locale is already known. By asking the user explicitly, the application also lets users know that it is prepared to handle a different locale, and allows them to choose whatever locale is appropriate, regardless of the existing settings.
Of course, there is a bootstrapping problem here: In what language should the initial locale query be posed? There are two choices: use a “lowest common denominator” language that is widely known by the target audience, or use a graphic that has simple instructions in several languages. The reason to use an image rather than text is that users may not have fonts for all supported languages installed. Besides, an image looks better than a series of question marks, which is how some operating systems render characters they do not recognize.