The design team uses locale information about Germany, Japan, and the United States to estimate the time and expense that globalizing and localizing the application for each locale will add to the design, coding, and testing phases of the application.
The following topics describe the areas the design team investigates for each locale, the development issues related to globalizing software, and the PT application's localization requirements:
The locales of the PT application do not share a common language origin. If an application is localized to different versions of the same language, this can simplify the localization process. For example, if the seven locales your application serves use regional versions of one language, you might decide not to localize messages and text strings for the user interface. Because many words have regional spellings, the messages and text strings might not be perfect but they would be acceptable. However, regional versions of a language do not necessarily format times, dates, and numbers the same way. For example, Panama and Chile are both Spanish-speaking countries but they format dates differently. In Panama the short date style is MM/DD/YYYY and in Chile it is DD-MM-YYYY. About the Formats Component and Converting a Recordset to XML further describe the localization of dates, times, numbers, and currency.
German and U.S. locales always use left-to-right horizontal text and Japan uses both left-to-right horizontal and right-to-left vertical text. Because it is common practice to support only horizontal text in dialog boxes and edit controls in Japanese software, the PT application does not support vertical text. The support of bidirectional text, which is used in Hebrew and Arabic writing, is a complex and pervasive development issue that the PT application does not need to address. Although the application is not required to support a bidirectional user interface, this subject is briefly covered in Summary of HTML AutoLayout Rules, which describes how you can code HTML to accommodate a locale that uses bidirectional text.
German and U.S. English share the Latin 1 (ISO-8859-1) character set, but Japanese scripts (hiragana, katakana, kanji, and romaji) require a multibyte character set (shift-jis). This means the PT application must support both character sets and their code pages, and convert localized text from its Unicode format. The following topics describe the use of Unicode in the PT application:
The address layout varies among the locales, and the application must be able to rearrange the sequence of the address fields and to suppress the fields that are not relevant to a particular region. Address Formats compares the address formats of the three locales. Some fields might not appear in the user interface for some locales, and the design team needs to keep this in mind when they design the database for the application.
The length of text strings can vary for each language without causing a problem for the localized PT application user interface because the design of the application will follow HTML AutoLayout rules. These rules provide a way to resize the elements on the user interface (labels, buttons, and menu options) and to accommodate translated text, regardless of its length. Summary of HTML AutoLayout Rules describes these rules.
The length of text data that is retrieved from the database also varies by locale. The layout of the user interface for the PT application needs to accommodate this data, regardless of length. Summary of HTML AutoLayout Rules describes the HTML AutoLayout rules that apply to sizing table cells, text boxes, and drop-down list boxes that contain data from the Eval database.
The PT application does not include currency data, but must support formatting of dates, times, and numbers by locale. The following topics provide details about dates, times, and numbers:
A number of calendars are used throughout the world. The calendar of a locale often marks significant events for that locale, and to be culturally correct your application must support all appropriate calendars.
Calendars include the following:
Germany and the United States use the Gregorian calendar, but Japan uses two different date formats: Western format (the Gregorian calendar) and Wareki format (the Imperial calendar). The PT application does not support the Wareki format, but you should be aware that the Wareki format is also commonly used in the Japanese business world.
It is a good idea to evaluate whether it makes sense to implement all application features in all of the targeted locales. The LitWare team decides that, except for minor layout changes that omit or add fields, the PT application will implement all features in German, Japanese, and U.S. English. Proposed Solution describes the feature set of the PT application.