Microsoft Visual C# 2005 Unleashed
| The first step to globalizing your Windows Forms user interface is in knowing how the globalization functionality works within the .NET Framework itself. You may remember from Chapter 12, "Assemblies and AppDomains," how satellite assemblies are used to locate culture-specific resources such as alternate text and images. In short, resource files are keyed with a culture name and when they are built, directories are created beneath the output directory and resource-only assemblies called "satellite" assemblies are created. To see how all this works, start by creating an empty Windows Forms application. On the main form, find the Localizable property and change it to true. A panel and a label have been added to the main form just to have some controls to play with. In the Solution Explorer, double-click the Form1.resx file. You should see the resource editor in Figure 36.7. Each control stores its properties in a resource file. Figure 36.7. Editing form resource data.
Another property on the main form is the Language property, which starts off as (default), meaning the neutral culture. You can select from all of the available cultures. When you change from the current language to a language that you haven't yet done any work for, Visual Studio 2005 copies all of the default language settings to the new language. So, if your label text is "Hello" in the default language and you switch the form's language to Spanish, the form will appear to stay the same. The designer will visually indicate that you are working on the Spanish-language version of the form, however. Change the "Hello" text in your label to "Hola" and then switch the language back and forth between (default) and Spanish. You will see that the label switches from "Hello" to "Hola." It's really useful to be able to interactively set the properties of controls in different languages and switch back and forth between cultures, but that isn't the most beneficial aspect. The fact that you can switch between languages in the designer combined with the fact that all user-set properties are stored in a resource file gives you the ability to make layout changes given the language. For example, if a particular label in one language is three times as long as the same label in a different language, you can make changes to the layout of the form to take this into account. You don't have to write any code that dynamically moves controls around at runtime to accommodate font sizes and string lengths. In the sample included with this chapter, there is also a PictureBox on the form. While in the (default) culture, the American flag was loaded into the PictureBox. Then, the Spanish and Canadian flags were loaded in their respective cultures (Spanish/Spain and English/Canada). The code in Listing 36.3 shows how you can programmatically change the culture of the application to see what the culture-specific content looks like at runtime. Listing 36.3. Changing an Application's Culture
Figure 36.8 shows the application running in Spanish, including the Spanish version of the greeting and the Spanish flag. Figure 36.8. An application running in an alternative culture.
When you combine the power of strongly typed resource classes (explained in Chapter 12), the ability to have third parties supply both visual and textual translated content, and the powerful built-in support for Unicode language sets, you end up with what amounts to the most robust and powerful development environment for creating world-aware applications on the market today. |