Dialogs

The .NET Framework includes many dialog components and a MessageBox class, all of which display dialog boxes. These dialog boxes are part of the user interface and, therefore, require some localization. The support offered to you is either a curse or a blessing, depending upon your requirements. All the dialog components in the .NET Framework have built-in support for localization. Table 4.2 shows the components and classes, and the source of their support.

Table 4.2. Classes and Components, and Their Localization Support

Class/Component	Localization Support Provided By
ColorDialog	Operating system
FolderBrowserDialog	Operating system
FontDialog	Operating system
MessageBox	Operating system
OpenFileDialog	Operating system
PageSetupDialog	Operating system
PrintDialog	Operating system
PrintPreviewDialog	.NET Framework Language Pack
SaveDialog	Operating system

Most of these components offer their localization support courtesy of the operating system, and this is because these components are wrappers around Win32 dialogs. So on the German version of Windows, the OpenDialog component is shown in German (see Figure 4.7).

Figure 4.7. OpenDialog on German-Language Windows

One component, PrintPreviewDialog, is specific to the .NET Framework and has no equivalent dialog in the operating system; it is supplied wholly by the .NET Framework. Figure 4.8 shows PrintPreviewDialog running on English Windows.

Figure 4.8. PrintPreviewDialog on English Windows

Because the localized version is dependent upon the .NET Framework Language Packs installedand, therefore, the current setting of CurrentUICultureif you open the dialog on German Windows without a German .NET Framework Language Pack installed, you get a mostly English dialog. In Figure 4.9, notice that the ToolTip is in German, whereas the rest of the dialog is in English.

Figure 4.9. PrintPreviewDialog on German Windows with No .NET Framework Language Pack

To get the fully localized German dialog (see Figure 4.10), you must install the German .NET Framework Language Pack.

Figure 4.10. PrintPreviewDialog on German Windows with the German .NET Framework Language Pack

This is where the curse or the blessing comes in. If you want the user interface in your application to be dictated by the operating system (i.e., on French Windows, your application always runs in French), this approach is a blessing because you do not need to do anything; the work has already been done for you. If you don't want the user interface in your application to be dictated by the operating system (i.e., the user should have the control to choose a user interface language that is different than the language of the operating system), this approach is a curse. In this scenario, your application will have a schizophrenic user interface; part will be in the language chosen by the user, and part will be in a different language provided by the operating system.

Unfortunately, the only solutions to this problem are not easy. The most straightforward solution is not to use the built-in components for these purposes and to write your own identical classes from scratch that mimic the behavior completely but that have a localizable user interface. A less straightforward solution is to let the dialogs load as normal but then iterate through all the controls on the dialog looking for known control names and changing appropriate properties to localized versions.

If you choose to abandon the .NET Framework dialog components, you might like to use the "Dialog culture dictated by operating system" and "Dialog culture dictated by .NET Framework" FxCop rules, in Chapter 13, "Testing Internationalization Using FxCop," to ensure that you do not accidentally use one of these dialogs.