Globalization and Localization are the two main aspects of developing an internationalized application. Globalization is the process of developing a program core for the input, display, and output of a defined set of Unicode-supported language scripts and data related to specific locales hose features and code design are not solely based on a single language or locale. Localization is the process of translating and customizing an application for a specific region/culture.
Microsoft .NET has introduced a number of features which can simplify the task of preparing ‘world ready’ applications. However, for the successful completion of this task, a number of factors are to be considered in each stage of SDLC. The purpose of this document is to list out all these points in the form of checklists.
There are three checklists in this document – Checklist for System Study Phase, Checklist for Design Phase and Checklist for Development Phase. As indicated by the name, each of these checklists stands for a distinct phase of SDLC. Since all these checklists can be used for testing purposes, there is no separate checklist for the same.
Check List Item
Is there any need for displaying predefined data and objects for different languages? (eg: labels, button text, images, title etc..)
Are the resource files being provided by the customer?
Does the calendar controls display the Gregorian calendar always, irrespective of the language in which it is shown? (e.g.: Some customers would want an Arabic calendar for Arabic culture)
.NET Framework DateTime structure(members such as the DateTime.Day property, the DateTime.Month property, the DateTime.Year property, and the DateTime.AddDays method) is based on the Gregorian calendar. This is not changed by any change in culture settings.
To handle native calendar types, the .NET Framework provides the Calendar class as well as the following Calendar implementations: GregorianCalendar, HebrewCalendar, HijriCalendar, JapaneseCalendar, JulianCalendar, KoreanCalendar, TaiwanCalendar, and ThaiBuddhistCalendar. Other things you can use include are the CultureInfo class, which has a CultureInfo.Calendar property that specifies a culture's default calendar. The CultureInfo.OptionalCalendars property specifies the optional calendars supported by a culture.
Has the time format been identified?
It can be either a 12 hour or 24 hour clock. The characters used to separate hours, minutes and seconds a\may be different for different cultures.
Are date/time values captured as local time zone values?
It may be a requirement to store the UTC equivalent of date-time values from entered from different cultures. Use the DateTime.ToUniversalTime method to convert a local DateTime to its UTC equivalent. To parse a date/time string and convert it to a UTC DateTime, use the DateTimeStyles enumeration AdjustToUniversal value with either the DateTime.Parse or DateTime.ParseExact method.
Is there any requirements for alternate sort orders?
Some cultures support more than one sort order. For example, the culture "zh-CN" (Chinese in China) supports a sort by pronunciation (default) and a sort by stroke count.
To specify the alternate sort order, create a CultureInfo object using the LCID for the alternate sort order. Then, obtain a CompareInfo object to use in string comparisons from CultureInfo.CompareInfo. As an alternative, you can create a CompareInfo object directly by using the CompareInfo.GetCompareInfo method (Int32), specifying the LCID for the alternate sort order.
Has the paper size been identified for each culture?
The paper sizes in the United States and Canada (such as letter, legal, and so on) do not satisfy the needs of all users in the world market. For example, most countries in Europe and Asia use a slightly larger standard known as "A4" (297 x 210 mm) that is slightly longer and narrower than the U.S. letter size (279 x 216 mm). Thus if your application needs to print, you should allow the default paper size to be configurable.
Has the Unit of measurement been identified for each culture?
There are different units of measurement for things like Length, Weight, Area, Volume, Temperature, Paper size, Angle notation, etc. There can be different requirements where conversion from one unit to another is required. For example, in one scenario, the end users may be allowed to view/enter data in their local unit of measurement; but it will be stored in a common UOM.
How is the data entered and stored into the system? Is it in local language?
For storing multi-lingual data, use uni-code data types.
Are the numbers and figures entered into the system always in English digits?
E.g.: Languages like Hindi have its own number system.
Do the users need localized thousand separators and decimal separators for the numbers and figures displayed on the system?
E.g.: In Polish, the thousand separator is a space and the decimal separator is a comma. The number “2,500.70” is written in Poland as “2 500,70”
For editable numeric fields, are the users allowed to enter thousand separators for the numbers and figures entered on the system?
E.g.: In Polish, the thousand separator is a space and the decimal separator is a comma. The number “2,500.70” is written in Poland as “2 500,70”. If the user is allowed to enter the thousand separators, appropriate validations needs to be considered.
Are the dates displayed and entered in the system in local format?
Are the reports to be printed in local language?
Are all the regional cultures/languages identified which are to be supported by the application?
Is there any special culture where the layout/orientation of the resource is different from other cultures? (E.g.: Arabic language).
Is the system testing of all cultures/languages (except the base language) being done by the customer ?
(Have to consider the availability of human resources for all the required languages and the effort.)
Is there any need for custom cultures? (e.g.: English for India)
Is there integration with other applications where multilingual could be a challenge?
Do all the database columns for storing multilingual data support Unicode? (e.g.: nvarchar, ntext)
Does the application design ensure that proper culture name is supplied to the application thread? (e.g.: For India, only Hindi language is supported by the .NET, say, “hi-IN”. You cannot set the language English for India like en-IN.)
Are all the multilingual resources identified and its resource files designed?
Should the Multilingual resource files be one for each culture? (It can be one for each culture or a single one for all cultures.
Does the design ensure that the culture-specific resource data is properly fitting into the available display area for all languages?
Size the UI to accommodate the largest localized version of the content.
Does the UI design take care of text alignment (eg:- RTL) as well as the alignment of controls on the page, where the screen layout/orientation is different from other cultures (eg: Arabic) ?
When the screen layout/orientation is different from other cultures, it could be useful to go for separate UI. When separate UI is used for a particular culture, additional code is required to switch the UI based on culture.
If there is any data transfer between layers using XML, is it ensured that the XML files support the Unicode to embed the multilingual data?
Do all the messages come from an external file (e.g.:- config file) ?
Has it been ensured that, in UI design, strings are not mingled with controls?
Do not mingle strings with controls, such as placing a text box in the middle of a sentence. Doing so would require the localization vendor to modify the UI to accommodate grammatical differences that cause sentence structures to change.
Has it been ensured that, in UI design, one control is not hidden behind another control?
Due to language expansion issues, hiding a control behind another may not work when you localize the application. For example, a button hidden behind another button in an English language application may extend beyond the covering button when you localize the application in German.
Has the UI design ensured that, the UI controls are not positioned/resized at run time?
Has flow layout been used wherever RTL is applied?
For greatest precision when laying out pages that will be displayed in right-to-left reading order, it is recommended that you use flow layout.
Have the multi lingual resource files got translated into various local languages?
The helper class for reading the resource files, formatting the data, etc. are developed?
Is all the resource text used, being read from the correct resource ID?
Are any labels overlapping with other controls while loading a different language with a longer translation?
Are the validations done appropriately for numeric inputs? (e.g.: the decimal separators and thousand separators may be different for different cultures)
Are the validations done appropriately for string inputs? (e.g.: English is a single byte character set, whereas Chinese is a double byte character set, so it will take double the memory space for the same number of characters as English)
Are the validations on dates done correctly? (Note: This will largely depend on how the user input the dates. If it is a manual entry, it would be very challenging to do the validations. Usage of calendar controls are recommended.)
If the data is being passed into the SP as XML, is the parameter in the SP for getting the XML declared as ntext?
Is proper format provider is used with .ToString() methods where the output of ToString() is used as a filter for DataTable object and Culture Info is set for the thread?
DataTable expects the numbers involved in filters, formatted in standard US format.
Is proper number format ensured in XML data passed to stored procedures?
When the thread culture is set and the output of ToString() method is used to create an XML file, this XML may contain numeric data with a format which is not acceptable in SQL Server.
Are proper Culture values set for the 'Culture' and 'UICulture' properties of the page?
The Culture value determines or influences results of culture-dependent functions, such as displaying the date. The UICulture value determines how the resources are loaded for the form and is used for culture-specific lookup of resource data.
Are there any text messages created dynamically at run time ?
Do not create a text message dynamically at run time, either by concatenating multiple strings or by removing characters from static text. Word order varies by language, so dynamic composition of text in this manner requires code changes to localize to some languages.
Has it been ensured that parametered string messages are not used?
The use of parametered string messages may create problems for localization as the order of inserting parameters may differ from language to language.
Is there any text used in bit maps?
Avoid text in bitmaps and icons, as these are difficult to localize.
Are all the localizable resources separated from the source code?
Do not hard code strings in the source code.
Has it been ensured that the client side is configured with proper UI language and cultural preferences?
Use window.navigator.browserLanguage to check the language of the browser (for the UI language) and use window.navigator.userLanguage to check the language of the user (for cultural preferences).
Unit of Measurement
Software Development Life Cycle
Right to Left
Extensible Markup Language
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)
General News Suggestion Question Bug Answer Joke Praise Rant Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.