Device Provider Globalization Guidelines
BizTalk RFID – Globalization Guidelines for Device Providers
Introduction
BizTalk RFID v1 is planned to be localized in five languages (in addition to English). The languages are Chinese (Traditional and Simplified), Japanese, German and Spanish. We will continue to add more languages as we see market demand.
Localization RTM
Microsoft is targeting early August for the RTM of the localized versions. For providers that are to be localized, we recommend that you RTM the localized providers two weeks after the Localization RTM of BizTalk RFID v1.
Globalization Guidelines
Resource Files
Place all the localizable resources (Provider Properties, Custom Groups, Property description etc) in a resource file. In general, all the strings that are displayable to the user are localizable. In .NET, the resources are placed in one or more .resx file(s). The resource file is compiled to a separate dll and the main provider dll refers to this resource dll. The main provider dll is marked as ‘Language Neutral’ while the resource dlls are culture specific.
Use a ResourceManager object to retrieve text from the assembly resource files based on the CurrentUICulture. For details on resource files, please consult the following references.
Generic .net globalization guidelines:http://msdn2.microsoft.com/en-us/library/aa719955(VS.71).aspx
Resources in applicationshttp://msdn2.microsoft.com/en-us/library/aa719838(VS.71).aspx
http://blogs.msdn.com/michkap/archive/2005/01/10/349988.aspx
Encoding Classes
The System.Text namespace provides classes that allow you to encode and decode characters. Always useUnicodeEncoding class and avoid the usage of ASCIIEncoding.
For example, to get a byte array from a string for sending over the network, the following snippet may be used.
UnicodeEncoding unicodeEncoding = new UnicodeEncoding ();
byte []bytes = unicodeEncoding.GetBytes(str);
Use of Cultures
1.Please follow the guidelines below for using the StringComparisonType
Use this value when comparing: case-sensitive identifiers, security-related settings, system constants or other non-linguistic identifiers where the bytes must match exactly.
For example, to compare the passwords, Ordinal should be used
If( String.Compare(password, "sample", StringComparsion.Ordinal))
{
//Do the operation when password matches
}
Use this value when comparing: case-insensitive identifiers and data stored in Windows(like file paths, WMI namespaces..)
CurrentCulture orCurrentCultureIgnoreCase
Use these values when comparing: data that is displayed to the user, most user input, and other data that requires linguistic interpretation.
InvariantCulture orInvariantCultureIgnoreCase
Use these values only when comparing persisting data or displaying linguistically-relevant data that requires a fixed sort order.
Please avoid using InvariantCulture unless otherwise you are intending to get linguistic behavior when comparing in culture agnostic manner
The following link talks in great detail about the string comparison guidelines
http://msdn2.microsoft.com/en-us/library/ms973919.aspx
2.The following operations on the strings should take care of culture specific information
·Sorting
·Sub-string operations ( Extracting characters from a string)
It means that the following APIs are culture dependent and hence explicitly passing the CultureSpecific Information is encouraged.
·String.Compare
·String.CompareTo
·String.ToUpper and String.ToLower
·Char.ToUppder and Char.ToLower
·CaseInsensitiveComparer
·CaseInsensitiveHashCodeProvider
·SortedList
·Array.Sort and ArrayList.Sort
·Array.BinarySearch and Array.BinarySearch
·Regex
·Encoding classes
·ToString methods wherever applicable
·Parse methods of wrapper classes of number types (Like Int32, Double, etc)
3.Please do not use abbreviations for any strings that are going to be displayed to the user.
Date Time Operations
Avoid using the members of DateTime structure such as the DateTime.Day property, the DateTime.Month property, the DateTime.Year property, and the DateTime.AddDays method. These methods always use Gregorian calendar.
Instead to perform culture-sensitive date and time operations based on the current calendar, use the DateTimeFormatInfo.Calendar property to call methods provided by the Calendar class such as Calendar.GetDayOfMonth , Calendar.GetMonth, Calendar-.GetYear, and Calendar.AddDays.
Handling of Numbers
Always specify culture information when handling the numbers
For example to parse the string toan integer, refer the following snippet.
int y = Int32.Parse(propertyRetryAttemptsValue,NumberStyles.Number,CultureInfo.CurrentCulture.NumberFormat);
//Here propertyRetryAttemptsValue is a string value like “123”, “100,000,000”
NumberFormatInfo class methods can be used for displaying the numbers in culture specific manner.
Support Different Time Zones (only if applicable)
Always store date time information in UTC.Display and allow input everywhere using the local (user) time zone (using user locale settings for formatting). Conversion to and from UTC should be done by the UI. Subsystems and back end API should manipulate date time in UTC.
Encoding for XML Files (Refer only if applicable)
Encode the Xmls either in UTF-8 or UTF-16. The use of the XML declaration in the xml is not mandatory, but the use of encoding declaration like the one below is encouraged.
<? xml version=’1.0’ encoding=’utf-16’?>
Reference Links
Microsoft Globalization Page-http://www.microsoft.com/globaldev/default.mspx
World Ready Guide -http://www.microsoft.com/globaldev/getwr/steps/wrguide.mspx
Building Applications With Globalization In Mindhttp://download.microsoft.com/download/e/2/1/e216b4ce-1417-41af-863d-ec15f2d31b59/DEV392.ppt
String Comparison Guidelines -http://msdn2.microsoft.com/en-us/library/ms973919.aspx
Globalization Blog -http://blogs.msdn.com/michkap/
Support
For any questions, regarding globalization and localization, please post your question in the BizTalk RFID forums athttp://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1474&SiteID=1
