Introducing Globalization

You need to perform a couple of steps to globalize an application (most of which you have not done up to this point):

• Ensure there is enough space in labels to hold the maximum size strings.

• Store all strings (and images) if they are to be localized, externally of the executable.

• Store all data in the database using Unicode encoding.

• Do not concatenate strings at runtime for display.

  Note

  There is a much longer list of best practices in the MSDN help documentation under "Globalization, Best Practices" and "Localization, Best Practices."

These are the only areas covered in this chapter because each requires some technical insight. Most of the other globalization issues revolve around the do's and don'ts of different political systems, cultures, and so on. You do have one advantage using the .NET Framework: All controls that display text are Unicode enabled, so character sets are no longer an issue.

Note

This chapter is about converting an application to a different language, Appendix A contains a small example of adding special characters (including foreign language characters) in an application designed to support only one language.

So, let's examine each of the four requirements listed previously.

Ensure there is enough space in labels to hold the maximum size string: When you create labels to hold text that describes information in a textbox or listbox, you generally size the label just large enough to hold the text so you can have a nice, neat form. However, look at the following word in English, then in French and Spanish:

• Birth Date (English)

• Date de naissance (French)

• La Fecha del nacimiento (Spanish)

As you can see, it will not do to size labels to their minimum size when writing an application that eventually needs to be localized.

Store all strings (and images) if they are to be localized, externally of the executable: When you place a label on a form, you should store the text of that label in a place other than the text property of that label. In this case, I am specifically talking about a satellite assembly that contains resources. A satellite assembly, by definition, is an assembly that contains only resources. There is no application code in a satellite assembly. You should insert all text that is displayed in labels (and images that have local significance, such as flags, leaders, maps, and so on) into these labels at runtime.

Store all data in the database using Unicode encoding: Ensure that all character fields are created using the Unicode version (noted in SQL Server as n plus the datatype; for example, varchar would be nvarchar). This also covers the fact that monetary values should be stored in money fields and not decimal or float fields because these will not automatically be converted and formatted according to the region. You should also store dates in date columns, not as text columns formatted as dates.

Do not concatenate strings at runtime for display: This is a big no-no when dealing with foreign languages. Take the following example: ^[1]

• English: Release the hold and start the second by one press on S1 at the appropriate time.

• French translation: Publiez l'influence et commencez la seconde par une presse sur S1 au temps de l'appropriate.

• English translation from French: Publish the influence and start the second by pressing S1 at the time of the appropriate.

So, if you were to create a string by inserting variables into the string at the same locations in English and French, the results would be incomprehensible to anyone in the foreign language.

You are going to create your own satellite assembly, read values from the assembly into your application dynamically, and resize labels where necessary. But before doing that, let's look at some of the tools available to you.

^[1]This was inspired by an example of "bad translation" at http://www.fortunecity.com/business/reception/19/mtex.htm.