- Unified Modeling Language
- Usage Scenarios
- Developing World-Ready Applications
- Practice Questions
- Need To Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Developing World-Ready Applications
CAUTION
Being able to develop applications that can be easily distributed globally with little or no specialized development for each locale is a major selling point for adopting the .NET architecture, so expect exam questions involving globalization, localization, and Unicode.
The .NET Framework provides extensive support for developing world-ready applications. There are several advantages to designing and developing world-ready applications using .NET:
Worldwide revenue—The more cultures the application can support, the larger your user or customer base will be.
Support for new cultures can be added quickly—After completing the initial application, no additional development should be necessary to produce localized versions. Creating a localized version is the process of adapting an application to a particular culture/locale.
Resources will be used more efficiently—Making the goal of world-readiness a key business requirement from the beginning of the project lessens the number of development and testing resources. Retrofitting an application designed to support a single culture, such as U.S. English, so that it can support additional cultures is expensive.
The .NET Framework fully supports Unicode—Unicode is a character-encoding scheme that uses two bytes to represent every character, regardless of whether it's an ASCII character. This scheme is capable of encoding all known characters and is used as a worldwide character-encoding standard. The Unicode-related classes, such as Encoder and Decoder, that can convert between Unicode characters and other types of target character code pages reside in the System.Text namespace.
System.Globalization functionality—Another feature included in .NET is the System.Globalization namespace, which contains classes that define culture-related information, including language; country/region; calendars in use; format patterns for dates, currency, and numbers; and sort order for strings. Although the options available in the System.Globalization namespace are probably more relevant in the design and implementation phases, being aware that this feature is available is still important during requirements gathering.
Systems.Resources namespace—The classes needed to read and write compiled resources are located in the Systems.Resources namespace. These classes aid in creating world-ready applications. The ResourceManager provides access to culture-correct resources at runtime. The ResourceWriter writes resources to an output stream or file. The ResourceReader readsresource name-value pairs from resource files and streams. Finally, the ResourceSet stores all resources localized for a particular culture.
When determining the requirements for a world-ready application, you should divide the process into two areas, globalization and localization.
Globalization
Globalization is the process of designing and developing a software product that functions in multiple cultures and locales. A globalized application can correctly accept, process, and display a worldwide assortment of scripts, data formats, and languages. A truly global application is culture-neutral and language-neutral. The trick, then, in the requirements-gathering phase is to determine which requirements will work equally well for users from all cultures and regions that the application must support. The most efficient way to globalize these functions is to use the concept of cultures/locales. A culture/locale is a set of rules and a set of data that are specific to a given language and geographic area. This process involves two tasks:
Identifying the cultures/locales that must be supported
Designing features that support those cultures/locales
If your company already has an international market or plans on pursuing international customers, there are several important factors to consider when gathering your international requirements. The ultimate goal should be to develop one common application that offers customers a choice of languages and currencies. In the Billington Pharmaceuticals case study, there are more than 1,000 stores in the United States and Canada. Because Canada (usually considered a foreign country) has a different currency from the United States and, in some areas, its inhabitants speak a different language, the application developed for Billington Pharmaceuticals should follow the concept of globalization.
Although this requirement seems obvious, most companies choose to ignore this option or create several versions of their applications for different language sets. This is an excellent way of keeping their IT developers fully engaged, but it is not the most efficient use of resources. The goal should be to make it easy for customers to change language or currency without being directed to another application. The specific areas that the requirements-gathering phase should focus on include:
Character classification
Date and time formatting
Numeric and currency conventions
Sorting rules
Keyboard setup
The "Localization" section, later in this chapter, provides more detail about these areas.
Being sensitive to cultural and political issues is also especially important when designing world-ready applications. What is acceptable in one culture might be offensive to another; this fact should not be minimized. These are common items to avoid:
Slang expressions—Just as people in the United States get confused when people from the United Kingdom refer to an elevator as a "lift," terms such as "bottom-line" or calling someone a "turkey" can be confusing to people in other countries.
Colloquialisms—Avoid using phrases that are local to a single region or have different meanings in different areas. This is true even within the United States. For example, in certain parts of the United States, asking for a "pop" might get you a punch in the face; in other parts of the country, you might get a can of Coke.
Obscure phrasing—Be cautious of using sports terms, such as "homerun," that have other meanings well known in the United States, but mean nothing (or have an unintended meaning) in most other countries.
Bitmap images that could be considered offensive in some cultures—For example, an icon of an outstretched hand indicates "Stop!" in some countries, but is considered offensive in Greece.
Maps that might include controversial regional/national boundaries or flags—For example, showing a French flag to indicate that the application can switch to French might be considered offensive to people in Algeria, Belgium, and Canada.
Localization
The final step in building a world-ready application is localization, which is the process of customizing and adapting your application for a given culture/locale. Localization consists primarily of translating the user interface, using rules developed for specific cultures/locales. Most organizations make the mistake of attempting localization after the initial application is developed. This approach is expensive and causes inconsistencies among versions. It also usually requires international users to wait weeks or months to have a localized version available.
These are the major advantages of following the localization model:
The application will reach the market more rapidly.
Resources are used more efficiently.
The application is easier and less expensive to maintain.
The application will be more stable.
There are several specific areas in which requirements pertaining to localization need particular attention:
Character display—Some languages need more space to display text than English does. Consider this factor when gathering requirements, especially for messages, menus, dialog boxes, icons, and bitmaps. Remember, too, that not all languages are displayed left to right. Some languages, such as Hebrew and Arabic, are bidirectional, going right to left for text and left to right for numbers.
Currency and number formatting issues—The currency symbol can be a predefined symbol, such as the European euro (), or a combination of letters, such as DM for Germany's deutsche mark. The negative sign can be displayed in many different positions, depending on local requirements. Many countries use different combinations of decimal and thousands separators than we do in the United States. For example, in Germany the decimal separator is a comma and the thousands separator is a period. Most currencies use the same decimal and thousands separator as the numbers in the culture/locale. However, in some places in Switzerland, for example, the period is a decimal separator for Swiss francs (Sir. 127.54), but the comma is the decimal separator everywhere else (127,54).
Date and time formatting—Although all culture/locales display a date with the day, month, and year, their presentation order and separators vary greatly. In fact, there might be many differences between regions within the same country.
For displaying time, the biggest issue is whether a 12-hour or a 24-hour clock is used. Most European and Asian cultures/locales use the 24-hour clock instead of the 12-hour a.m./p.m. model used in the United States.
Sorting—Alphabetical order and conventions for sequencing items vary from culture to culture. For example, sort order can be case-sensitive or case-insensitive. It can be phonetically based or based on the appearance of the character. A world-ready application must be able to compare and sort data on a per-culture basis to support culture-specific and language-specific sorting conventions.
Keyboards—The layout of keyboards differs in some cultures. Some characters might not exist on some keyboards, which could be an important factor when assigning shortcut-key combinations. Some cultures, such as Eastern Europe and most Arabic-speaking countries, use more than one type of keyboard (although probably not at the same time).