Planning For and Testing Global Software

Introduction
Globalize: to make global; especially to make worldwide in scope or application.
Localize: to make local; orient locally.

Merriam Webster’s Collegiate Dictionary, makes clear the difference between what we usually do, that is localize, and what we can do, that is globalize, the applications we develop.

We can globalize applications by taking languages of the world into account in our development efforts. In software development, these language groups use these code implementations.

• Extended ANSI for Latin-1 (Western, Eastern European, and Cyrillic languages).
• Double byte characters for Far Eastern languages.
• Bi-directional characters for Middle Eastern languages.

You can read through this document, or choose a topic of interest from this list:

What does language affect?
Extended Character Testing for Feature Sign-off and Release to Integration
DBCS Testing for Feature Sign-off and Release to Integration
Pan-European Testing for Feature Sign-off and Release to Integration
Multilingual
National Language Standard (NLS) API
For More Information about Developing Globalized Software

What does Language Affect?

• Address formats
• Alphabet
• Currency formats
• Date formats
• Keyboard layout(s)
• Measurement system
• Number formats
• Paper sizes
• Phone number formats for reference
• Phone number standards for dialing out
• Punctuation
• Sorting
• Time formats

Locale Settings (Control Panel and Regional Settings)
One key to developing a fully global product is to develop a system that is extremely dynamic, so it's able to conform to different cultural standards, such as sort orders, date and time formats, and number and currency formats. Microsoft Windows and NT have this dynamic capability when developers use the National Language Standards (NLS) APIs. If you find that your areas of the product do not dynamically update locale-specific values after changing a locale setting, such as short date, it is a bug you can avoid by using these APIs.

Locale Values
Here are some variables you'll want to pay attention to as you develop global software:
Sort order (Windows Explorer, list boxes, common dialog box entries).

Note if you change the locale from U.S. to German the sort order should change.

Time formats (Explorer detail, property sheet, tray).
Date formats (Explorer detail, property sheet, tray time and date).
Number formats (Explorer, Find File, Calculator accessory, third party applications).
Currency formats (third party applications).
Measurement system (centimeters or standard, printer page layouts).
Paper size (Word, WordPad, printer setup).

Note Papersize is determined by the locale selected. U.S. uses letter size and Europe uses A4 size.

Extended Character Testing for Feature Sign-off and Release to Integration

What are Extended Characters?
The Number One global issue that breaks functionality is the use of extended characters. Here are some examples of extended characters that are used in some of the countries.

German ä ö ü ß
Dutch à á ä â è é ë ê ì í ï î ò ó õ ù ú û ñ ç
French à â ç ë è é ê ï ô æ ü ù û

Note You can use charmap to create these characters or use ALT+<numeric keypad> ASCII or ANSI code.

Extended characters are in the character range from ASCII 128 to 255. Most code pages have the same character set for characters values 0 to 127. This is the standard ASCII character set and is the same one found on the ANSI U.S. platform. Therefore, characters specific to a given language are always identified by the values from 128 to 255. This range of values is often called the extended ASCII character set.

Test Cases for Extended Characters
• Here is a list of test cases you can review to test for extended characters.
• Verify that users can type extended characters in all areas of the system
• that allow for text input.
• Verify that sorting and case conversions are culturally accurate in Explorer.
• Verify printer settings are culturally correct for the correct paper and envelope
• size, and for the measurement system.
• Verify that a user can save files using filenames that contain accented characters.
• Verify that a user can successfully print documents that contain accented
• characters.
• Verify that a user can successfully cut and paste text that contains accented
• characters.
• Verify that the user can embed OLE objects with extended character names.
• Verify that the system or applications dynamically change when locale values
• are changed in Control Panel or Regional Settings, such as number formats, time
• formats, date formats, currency formats, measurement system, and list separators.
• Verify that the system can handle globalization issues pertaining to Modems/Tapi.
• Verify that documents created in one language edition can be opened successfully
• in other language editions, and vice versa.

Sample Test Cases for Software Containing Extended Characters
You can look through this list to find samples appropriate to your development effort. Categories include:

Networks
• For networks that use extended characters, check:
• User logon name in protected mode.
• User logon name in real mode.
• User logon name on different networks, such as Windows NT® or Novell™.
• Passwords in protected mode.
• Passwords in real mode.
• Passwords on different networks.
• Changing passwords in protected mode.
• Changing passwords in real mode.
• Changing passwords on different networks.
• Workgroup names.
• Workgroup names on different networks.
• Computer names.
• Computer names on different networks.
• Comment fields.
• Domain names on different networks.
• Share names.
• Share names on different networks.
• Share passwords.
• Share passwords on different networks.
• Accessing a share.
• Accessing a share on different networks.
• Printer shares.
• Printer shares on different networks.
• Printing to a share.
• Printing to a share on different networks.

OLE
• Verify that the user can insert an object that contains extended characters.
• Verify that a user can insert a filename containing extended characters.
• Verify that a Word document with extended characters in the filename that
• contains a Microsoft® Excel object is updated when the Excel file is modified.
• Verify that a user can insert a bitmap or a paint brush object with extended
• characters in their file name into Word.

Shells
• Verify sorting and case conversions are culturally accurate in Explorer,
• common dialog boxes, list boxes, and network neighborhood.
• Folder names.
• Filenames.
• Shortcut names to files.
• Shortcut names to folders.
• OLE object names.
• Volume labels (hard drive and floppy drives).
• Start menu options.
• Task bar buttons.
• Find File.
• Find File volume names.
• Find File share names.
• Folder names on different servers, such as Windows NT and Novell.
• Filenames on different servers, such as Windows NT and Novell.
• Find file on different servers, such as Windows NT and Novell.
• Drag-and-drop files.
• Drag-and-drop folders.
• Common dialog32 UNC file run paths.
• Common dialog32 filenames.
• Common dialog32 folder names.
• Common dialog32 Share names.
• Common dialog32 Volume labels.
• Server-based Setup (SBS) Windows NT or Novell folder names.
• SBS filenames.
• SBS shortcut names to files.
• SBS shortcut names to folders.
• SBS OLE object names.

Applets
For applet text editors, check:
• Save Filenames.
• Open Filenames.
• Find string.
• Text.
• Text Find.
• Text Replace.
• Paper size.
• Measurements.
• Date format.
• Time format.

NLS API Values from Regional Settings
For shells, check:
Tray clock format.
Tray date format.
Explorer details view date format.
Explorer details view time format.
File properties date format.
File properties time format.
Find File date.

For applet backup with international characters, check:
Date format.
Time format.
Folder names.
File names.
File name created.
Volume names.

For applet backup and restore with international characters, check:
Folder names.
Filenames.
Volume names.

For applets such as Calculator, check:
List separator.

For applet date and time, check:
Spelling of the months, based on locale.
Spelling and format of days of the week, based on locale.

Multimedia Components
Play files.
Create files.
OLE-embedded objects.

System Tools
For tools such as a scandisk tool, check:
Filenames in real mode.
Folder names in real mode.
Filenames in protected mode.
Folder names in protected mode.
For tools such as a defrag tool, check:
Filenames.
Folder names.
For tools such as a drivespsace tool, check:
Filenames.
Folder names.

Setup
For code pages check the Windows Registry setting and DOS Autoexec.bat & Config.sys settings
Verify that group names that contain extended characters are retained.
Verify that Setup will not allow the user to install to a directory that contains extended characters.
Verify that the correct locale is installed after Setup.
Verify that the locale is retained if this Setup is an upgrade over Windows98.
Verify if you select an international keyboard during Setup that the keyboard is installed in the Config.sys and in Windows.
Verify that non-domestic version upgrades over the domestic version properly. All desktop icons and group folders should be upgraded. Check the Start menu, Desktop, and the Program Folders directory.
Verify country settings, such as U.S. vs. German vs. French Win.ini and Config.sys settings.

Printing
Verify that the paper size, envelope size, and other defaults are culturally accurate.
Verify that the correct measurement system is used, either standard or Metric.
Verify that the user can create a share with extended characters in the share name.
Verify that the user can connect to a shared printer that contains extended characters in the share name.
Verify that the user can print to a printer that contains extended characters in the share name.

Application Compatibility
Verify that third-party applications function correctly with Non-U.S. locales, such as German. When a Non-U.S. locale is selected, the system uses a different code path.
Verify that applications respond to changes in the Control Panel Regional Settings applet, for example in Microsoft Excel, check the currency formats and list separators.
Verify documents created in this language edition can be opened successfully in other language editions and number, currency and date formats are retained or updated.

General Components
In general, you can check:
Case (Uppercase, Lowercase, Is Alpha) so that uppercase and lowercase rules include letter change and accents added or removed going from uppercase to lowercase or from lowercase to uppercase.
Sort including grouping rules, folding rules, character expansion, and character contraction, and case sensitivity.
Keyboard layouts and keyboard switching in all text fields.
Measurements and their meanings including length, inches versus centimeters; weight, kilograms versus pounds; temperature, Fahrenheit versus Celsius, and so forth. This also calls for appropriate conversion when the units of measure have different meanings. For example, a U.S. point is different from a European point.
Date formats were ever they appear, they should be dynamic, thus using the NLS APIs.
Time formats were ever they appear, they should be dynamic, thus using the NLS APIs.
Currency formats were ever they appear, they should be dynamic, thus using the NLS APIs.
Number formats including positive and negative formats for currency and other numbers. This includes separators for these numbers were ever they appear, they should be dynamic, thus using the NLS.
List separators including separators for pages, rows and columns, lists of numbers, and arguments of functions.
Page sizes.
Interface (toolbars, icons, cursors).
Included files and graphics.
Spell checker and Thesaurus.
Inter-operability with applications (includes OLE)
Converting files from one environment into another.
International communications dial-out options.
International communications phone number formats.

DBCS Testing for Feature Sign-off and Release to Integration

General
What follows covers basic testing that should be done before a product is certified as double-byte character set (DBCS)-enabled. Testing is covered in general terms. Specific test cases are provided where they have special merit, or provide unique tests that would otherwise be missed. The areas covered are User Interface, Strings and Buffers, Character-based tests, Named Object Tests, Document Tests, and Special Cases.

You can look through this list to find areas appropriate to your development effort. The section begins with a definition of terms used in the areas covered in the section. Categories include:

Definitions
DBCS: Double Byte Character Set. This a system of encoding characters that uses one or two bytes. (You can think of this as a mixed-byte character set.) The first byte of each character is evaluated to determine if it is in the DBCS range, which varies from locale to locale, and then the character is evaluated as a two-byte character.

Named Object: An object in the operating system that is given a name by the user. This includes user names, machine names, server names, share names, user groups, and so forth.

Prettification: The process of formatting a string so it looks correct to the user.

Romanji: Roman-style or English-style characters. Technically these can be single-byte or double-byte. For the purposes of this paper Ro-manji is used to refer to double byte Romanji.

SBCS: Single Byte Character Set.

User Interface
The following items do not require a localized build.
Check the product to verify that all strings are located in resources, and they are not hard-coded.
See prettification of Ro-manji under "Character-based Tests," below.

String and Buffer Tests
Wherever strings can be typed or edited, the following tests should be done:

Character splitting
Can DBCS characters be split, meaning can you make the program treat a double-byte character as two single-byte characters? Prime tests of this are:
Does BACKSPACE delete half a character?
Can you position an insertion point in the middle of a character?
When blocking text, do the edges of the block split characters?
Does word wrap split characters?
When strings are typed into any edit field that has a maximum length, are the characters refused or truncated at even-character boundaries. (See "Border Conditions," below.)

Static controls
This chiefly comes up where there is a user-defined static control, an area where the user enters information that is later displayed as a static text field. Where such a control exists, a string of double-byte characters should be used that is longer than the field will hold.
View the string in all possible settings and verify that the string is truncated properly.
Look under the edit text field and verify that there is not a line of excess trash pixels. (This indicates the box is sized to large.)

Buffer capacity
Since DBCS characters can fill up to twice the character buffer space that SBCS characters can fill, all string buffers must be checked.
In all edit fields use double-byte characters and type the maximum number of characters allowed. This should be the same as for single-byte characters.
Type the maximum number of characters into any field that will be used by the system. Include named objects (see "Named Objects," below). Run normal system and regression tests this way to verify that no buffer overflow situations occur, and the system has not been trashed.

Border Conditions
Where an edit field allows a maximum number of characters, type a single-byte character and then enter double-byte characters. This will put one byte of the character within the allowed range and one outside the range. The full character should be rejected.

Character-based Tests
All input, output, filename, document names, network operations, and named object tests should include tests using the following characters.

1xx, 9Fxx, E0xx, and FCxx are boundary cases and should be tested early in the project.
xx5B, xx5D and xx7C should be tried in all edit fields to see if they are rejected as illegal DOS characters. If they are rejected or the user is warned they are illegal, the test fails: they are valid characters.
xx5C should be tried in the lead, middle, and trail position of all appropriate strings. Each can be handled differently. There is no guarantee that because it works in one position it will work in the others.
E5xx should be tried in the lead position of all appropriate strings.
2xx many characters in this range are double-byte Ro-manji or English/Roman characters. In test they are treated like English characters and are cased. In filenames and object names they are not cased. That is: a double byte A!= a. Ro-manji is most likely to break when a lower-case character is used at the start of a name or an upper-case character is used anywhere but the first position.
Verify that the characters are not cased.
Verify that comparisons are case sensitive. This means that a double-byte aAa != Aaa.
Verify that comparisons work with Ro-manji. This means that double-byte aAa == aAa. Often this will fail because part of the process is casing the Ro-manji.
Verify that filenames, URLs and names or strings using Ro-manji are not formatted so as to look correct to the user. That is, they are not cased in the UI but are left alone.
xxAA, xxAE, xxBF should be used with operations over a Novell or Microsoft NetWare network. These cases are not valid when run locally or on a SMB (Microsoft Network).
The following test strings can be used to cut down the amount of testing required on a stable build. When there are many bugs, the characters should be used separately.
[82h 81h][82h 60h][82h 81h] (aAa)
[E5xx][xx5B][xx5D][xx7C]
[xx5C][35][43][xx5C]
or [8F5C][35][43][8F5C] ([Juu]5C[Juu]
[xxAA][xxAE][xxBF]

Named Object Tests
Named object testing centers around the characters defined above, which represents most of the test cases. There is one important case that is missed. General system tests in all areas should be run with the computer and user being given a name containing the problem characters 5C, and Ro-manji being the most important. Once this is done, normal test should be done. This is especially important when testing anything that touches on drag-and-drop or other OLE functionality.

Document Tests
Any application, applet, or area that loads or saves documents must be tested with problem characters as defined above. This area is often missed under the mistaken belief that the area is just using common dialog boxes. This must be tested.

Special Cases

Drive letters
Verify that all Setup and other operations can take place on a drive other than one named C. To do this, test on a system where no C drive exists. If there is a C drive, temporary files may be written there unbeknownst to you. This is important because on some systems, such as NEC®, there is a floating boot drive. An easy way of performing this test is to map a write-protected network drive over your C drive.

Pan European Testing for Feature Sign-off and Release to Integration

Introduction
This section is intended to describe specific testing that should be done to certify that a product is properly enabled for Pan-European use. It describes the areas that are prime targets for Pan-European issues, and presents a general guide for the kinds of testing that can be done in each of these areas.

Pan-European includes these countries:
The European countries of Greece, Russia, and Turkey. The Central European countries of the Czech Republic, Slovak, Poland, and Hungary. The Baltic Rim countries, including Latvia, Estonia, and so forth.
On each Pan-European platform, the following elements must be tested:
Code Pages
Fonts
Locales

Code Pages
A code page is a specific set of characters. Each character in a code page has a number to identify it, and the code page itself is also identified by number. A code page contains all the characters necessary to render text strings in a target language. Code pages are also called character sets or charsets.

Each Pan-European country has a code page specific to its local language. In all cases, Pan-European code pages consist of 256 characters identified by the numbers 0 to 255, inclusive. Consequently, each character value can be contained in a single byte. Also, each Pan-European code page has the same character set for characters values 0 to 127. This is the standard ASCII character set and is the same as found on the ANSI US platform. Therefore, characters specific to a given Pan-European language are always identified by the values from 128 to 255. This range of values is often called the extended ASCII character set.

To complicate things, there are two kinds of code pages, one that is specific to the MS-DOS character-based screen, and one that is specific to the Windows graphical user interface (GUI). MS-DOS code pages are usually called original equipment manufacturer (OEM) code pages, or OEMCPs, and Windows code pages are called ANSI code pages, or ACPs. For many languages, the OEMCP character set is slightly different from the ACP character set, so the code page ID values are different. Conversely, when the OEMCP and ACP characters sets for a language are identical, they both share the same code page ID value.

Testing issues for code pages include:
Detection of the correct code page to install during a clean Setup.
Retention of the correct code page settings on an upgrade from Windows 3.1 or Windows 98.
Use of the correct code page in DOS boxes and in the Windows GUI.

Fonts
Fonts and code pages are closely related. Fonts contain images of many different characters. These character images are used to actually draw the characters in the text strings. To show strings in a given language, there must be a code page that contains the character values used in the language, and there must also be a companion font containing images of all of the characters in the code page. When a font has all the character images for a given code page, that font is said to support the code page.

Note that it is common for a font to have character images for more than one language. These fonts support multiple code pages. The font must be told what the target language is in order to show the correct extended-ASCII character. This is done by setting the charset of the font. Charsets in this context are yet another set of numbers that indicate the characters of a specific code page. However, note that code page values and charset values are always different.
Users do not normally get the chance to select the charset of a font. This is handled automatically by the operating system and by applications. However, the ChooseFont common dialog in Windows does contain a control to select the charset. This control is called the script control, and it is used to specify the target language that the font should use. Internally, this sets the charset of the font.
As mentioned above, language-specific characters always occur in the extended ASCII range of 128 to 255. Therefore, testing should be focused on these character values. Operating system components, network interfaces, and programs must be able to work with these extended character values without trouble.

Testing issues for fonts include:
Check that extended-ASCII filenames work properly.
Check network operations using extended-ASCII names.
Check extended-ASCII strings in various dialog boxes, controls, and so forth.
Check that upper-case and lower-case conversions are done correctly.

Locales
Locale is a general term referring to those items that are adjusted to accommodate a specific language. Items include the layout of the keyboard, character evaluation when searching and sorting operations are performed, and the way items such as the currency symbol are displayed. Also included are the formatting of elements such as decimal points, date, day, and time formatting.

Testing Issues by Category
The following list shows some of the testing issues for Pan-European builds by category. This is only a sample of the kinds of issues to look for; it is not intended to be a complete list of all test issues.

Code pages
Detect the correct code page to install during a clean Setup.
Retain the correct code page settings on upgrade from Windows 3.1 or Windows 98.

Character sets and fonts
Handle extended-character filenames correctly.
Handle network operations correctly with extended character names.
Handle upper-case and lower-case conversions correctly.

Locales
Handle calendar formats (time, date, day, month, day-of-week) correctly.
Handle accelerator key mappings correctly.
Handle searching and sorting correctly.
Keyboard keys generate the expected characters.
Keyboard Caps Lock and other control functions work correctly.
Handle local formatting conventions for variables, such as date and time.

Applications
Important ISV applications work as expected.
External components, especially multi-platform components work as expected.
Common dialog boxes work as expected.

Multilingual
What is it ?
The ability to switch input languages on the fly using a shortcut keyboard combination in any application and thereby use multiple input language layouts.
APIs which support new Windows applications being aware of multilingual content in documents and changing input languages appropriately.

Notes
Applications that use fonts can display all languages which the fonts support.
Applications that do not use fonts, such as Notepad, will only support languages that fit in the base charset.

How does it work?
Steps:
User loads (using the Control Panel => keyboard => language sheet), the input languages to be available to switch between in applications.
An icon located on the tray (by the system clock) displays the two-letter code for the current input language.
The user runs applications and switches input languages by typing left ALT+left SHIFT or left ALT+right SHIFT, and the language indicator will change.

Multilingual Test Cases
Multilingual settings on your Windows system:
To change the keyboard language Click on the language icon located on the tray, this should give you available list of languages to from which to choose.
To change the list of available languages Locate the Keyboard Control Panel dialog box which enables you to alter or choose the list of available languages.
To change the font type, script Open the Fonts dialog box in the application, which allows the user options to change the script language of the character.

Note This will most likely take the form of additional language choices for a given font in the Choose Font dialog box.

While running your application, exercising the multilingual functionality should not cause the system to fail or stop responding or similarly affect your application. You may notice varying degrees of unaware support affecting your application; these will be explored in the next section. The following functions should be performed and then the application should be tested for stability and any odd behavior.

What to look for
At this point, you are mainly looking for the system to fail or stop responding or for any obvious display problems in your application. You might see some strange results in your application, which may be due to unaware application support. When copying text from aware applications, you loose the font information and possibly the language text. As a result, you may see garbage characters appear when pasting the text. This is acceptable functionality for this level of support. The next section will give general guidelines on how to determine if it is functioning properly.

Smoke Testing the Multilingual Functionality
When working with the default language for the system, here are some tests to perform and issues to watch out for:

Tests to perform
With only one, preferably the default language present you should not see a language indicator on the tray.
Startup in proper default language, change the default input language, and then reboot. Does the language change?

Watch out for
No keyboard functionality in either applications or dialog boxes or edit controls.
A layout other than the correct keyboard layout.

Working with the Keyboard Language Interface
When working with the keyboard language interface, here are some tests to perform and issues to watch out for:

Tests to perform
Add a language(s).
Reorder the languages.
Delete the language(s) both while they are in and are not in use by applications.
Add all the languages.

Watch out for
Improper error messages.
Not deleting language after reboot.

Working with ML in Applications
When working with ML in applications, here are some tests to perform and issues to watch out for:

Tests to perform
Open applications, and use them with two or more keyboards loaded.
Start all applications to verity they come up in the system default language.
Type in the default language then change to another language.
Open other applications, change to different input languages in each, switch applications, and verify keeping the proper language in each of the applications.
Cut and paste between applications in different languages.

Watch out for
No keyboard input.
Applications which do not save the language information and thus do not load the correct font, which may be an application problem.

Other Areas
Tests to perform
Cut and paste between applications.
DOS box should not be affect by keyboard switching. (Switching only supported in Windows applications.)
Dialog boxes and edit controls might have trouble with multiple languages.
Fonts, do they display the characters in that font properly?
Setup configurations and dual keyboard setups, such as Russian.
OEM or replacement drivers.

Watch out for
Any and all odd behavior with the multilingual system or keyboard behavior.

Supported languages

National Language Standard NLS API
This API would be better termed the Windows Locale API, in that it specifically deals with manipulating Windows Locales, but no means encompasses all of Windows National Language Support.
Windows provides generic support for linguistic and cultural conventions through the NLS API, which carries information on date, time, calendar, number, and currency formats. Also, NLS provides sorting and character-type information for all the locales supported by the operating system. Simply, the NLS is language rules and cultural conventions.
The NLS API can be divided into following categories:
Formatted Date and Time Strings
Calendar Formats
Currency and Number Formats
Locale IDs
Sort Keys and String Processing

Formatted Date and Time Strings
When a user installs Windows on a computer, the default setting of date and time is set. The default date and time strings can be changed using the Control Panel, Regional Setting, Time or Date dialog box. When the user opens the Control Panel, Regional Setting, Time or Date dialog box, the user can look at the default setting of date and time string or the user can modify the date and time strings.

Test example
Change long date to a different style
Select the Control Panel, Regional Setting, Date dialog box.
Change Long date style to MMMM dd,yyyy.
Position the cursor on the task bar at the right side of corner.
The date string should appear as, for example, July 9, 1996.

Test example
Change time format into different style.
Select the Control Panel, Regional Setting, Date dialog box.
Change Time style to HH mm ss.
The time string should appear at the task bar as, for example, 09:47, which means the time string format is in 24-hour clock mode, with leading zeros, minutes with leading zeros , and seconds with leading zeros.

Testing issue When a user changes the date and time picture string using the Control Panel, Regional Setting, make sure the change appears in Windows applications such as the Windows Explorer and the Windows Task Bar. Some Windows applications will not pick up the changes, because the application has its own date and time picture string handling functionality. For example, Word has its own date and time picture string format using the Date and Time command on the Insert menu. Some languages, such as Finish, German, Polish, and Russian, have several noun forms. Windows carries both the nominative and genitive forms of Polish and Russian month names, and the form changes depending on the month name's position in the string separated by the null value.

Calendar Formats
Most locales use the Gregorian calendar, but some editions of Windows also support Hijri (Middle Eastern), Japanese (Japanese Emperor year), Korean (Tangun Era), and Thai calendars. Windows assigns each locale a default calendar type.

Testing issue
Make sure that the alternate calendars work correctly. The user can change the calendar type using the Control Panel, Regional Settings, Date dialog box. Some counties have different days for the first of the week. For example, although calendars in the United States list Sunday as the first day of the week, calendars in the other countries, such as Germany, list Monday as the first day of the week. Similarly, not all cultures assume that the week containing January 1 is the first week of the year.

Currency and Number Formats
Currency and number formats vary from locale to locale. Reformatting a number based on different locales involves more than changing the currency symbol or the decimal separator. A currency symbol might come before or after the numeric quantity, it might be separated from the number by a space, and it might be composed of one character or more than one character. In addition, if a currency amount is negative, the system might format it in one of 16 different ways.

Test issue Through the Control Panel, the user can change the number and currency setting. So after you set the number or currency setting, you can go to an application, which uses different number or currency format, to verify the changes. Each country has its own unique number and currency format, so make sure the unique format appears throughout the application. Excel changes the currency symbol when the user changes the locale in the Windows Control Panel.

Locale IDs
Locale ID is a 32-bit value defined by Windows that consists of a language ID, a sort ID, and reserved bits. Windows-based applications can indicate the language of a test stream by tagging it with a locale ID. Saving locale IDs in documents gives application multilingual flexibility. For example, Word will automatically use the spelling checker, the Thesaurus, the hyphenation engine, and the grammar checker associated with the language of the test stream it is checking, if these tools are available.
Test issue When changing from one locale to other locale, the changed locale must be used throughout the Windows application.

Sort Keys and String Processing
The sort key, which is a numeric representation of a sort element based on locale-specific sorting rules, also consists of several weighted components that represent a character’s script, diacritics, case, and so on. String processing in NLS is a very important feature of NLS, because searching and sorting uses sort key in the searching and sorting engine. In most languages, words consist of characters separated by white space and punctuation. Instead of calling the system each time it analyzes a letter in the data stream, the search engine builds several tables at startup. To build these tables, the engine calls GetStringType and LCMAPString, which can return information for an entire string of characters. With this series of API calls, the search engine has constructed several tables that indicate which characters can be interpreted by the user’s system.

Test issue
The sort keys are unique to each country or each language, so the sort results are different. For example, in Swedish, some vowels with diacritics sort after Z. Languages that include characters outside the Latin script have special sorting rules. For example, some Icelandic characters sort between Latin script.

Copyright 2002 Chromosome22. All Rights Reserved.

download the WORD .DOC (136k)