International Features

Visual Studio has a variety of features that help international teams build and deploy globalized and localized applications. For instance, it offers support for different encodings and for font linking. It is also useful for creating localized Microsoft Windows Forms, localized Web applications, and deployment projects. In addition, Visual C++ handles a variety of character encodings, allows you to use locale-sensitive functions, and provides templates that have their own international features.

Support for Various Encodings and for Font Linking

The Visual Studio editor, which is fully Unicode-enabled, allows you to open and save files in any character encoding supported on the operating system. If you receive a source file that was saved in a particular encoding, you can use the Open With Encoding option, by clicking the drop-down arrow on the Open button, in the File Open dialog box. This dialog box allows you to select any character encoding installed on your system to open your file. You can also use the Advanced Save Options to save your file in a specific encoding.

The Visual Studio editor also supports font linking, which means that your source code can contain multiple scripts; the editor will select the correct font for a particular script. (For more information on font linking, see Chapter 5, "TextInput, Output, and Display.")

Support for Localized Windows Forms

The localization project model in Visual Basic and Visual C# allows you to create applications with multilingual resources and dynamic language switching. Localization projects have a main assembly that holds the actual code for your application, as well as satellite assemblies that contain only the localized resources. These resources can include strings, sizing information, font information, and other properties relevant to localization. (For more information, see Chapter 7, "Soft-ware Localizability Guidelines.")

You can create localized Windows Forms applications within a single project. All Windows Forms projects, whether in Visual Basic or Visual C#, can contain localizable resources. Each Windows Form has a Localizable property that, when set to Tru e, saves all form-based localizable properties in an Extensible Markup Language (XML) resource file with the extension .resx.

You can add new languages to your projects by clicking Language in the Properties window. By selecting a particular language from this window, you can edit and localize a form directly in the Windows Forms Designer. You also have the ability to add strings or other resources by using the Assembly Resource File template and editing the XML-based format in the XML Data View window.

The Assembly Resource File template, which is the XML-based resource file, contains a comment tag that can be used to enter comments for localizers. The comments will be stripped out when the XML resource file is compiled to the binary format. The comment tag is supported only in the Assembly Resource File template, and cannot be used with the Windows Forms Designer.

You can build your main and satellite assemblies from within the integrated development environment (IDE) by simply clicking Build Solution from the Build menu. Satellite assemblies are automatically compiled when the project contains the language-specific .resx files. Satellite assemblies are written to local directoriesunder a path using the culture names based on the Request for Comments (RFC) 3066 standard abbreviations for languages and regions. The format of the culture tags is <language code 2>-<country-region code2 >, where <language code 2> is a lowercase two-letter code derived from International Organization for Standardization (ISO) 639-1, and <country-region code2> is the uppercase two-letter code derived from ISO 3166. A language code is sometimes referred to as a "culture code," and a country-region code is also called a "subculture code." (For more information on culture names and subculture names, see Chapter 4, "Locale and Cultural Awareness." )

The .NET Resource Manager will load localized resources by detecting the UI language of the operating system, unless otherwise specified by the CurrentUICulture property. If resources matching the system UI language are not available, the project will revert to using the resources in the main assembly. (For more information on development within the .NET Framework, go to http://msdn.microsoft.com/net.)

Support for Localized Web Applications

The localization project model in Visual Basic and Visual C# can also be applied to Microsoft Active Server Pages for the .NET Framework (ASP.NET) Web projects, which means you can precompile your main assembly with your application code and use satellite assemblies for your localized resources. (For more information on the ASP.NET application model, go to http://msdn.microsoft.com/net/aspnet.)

You can add and edit localizable resources for your Web projects by using the same Assembly Resource File template that was used for the Windows Forms projects. Visual Studio will automatically generate satellite assemblies if your project contains resource files with a valid language identifier in the file name. To ensure that your resources will be loaded correctly, you must use a valid language identifier in the file name, such as WebApplication1.en-US.resx. (For a list of all valid language identifiers, see Appendix K, "CultureInfo Names and Identifiers in the Microsoft .NET Framework Library.")

You can configure your application through the settings within the XML-based configuration file-Web.config-or through the page directive values. Settings that are relevant to globalization include the following:

• Culture
• UICulture
• RequestEncoding
• ResponseEncoding
• FileEncoding

Culture and UICulture are equivalent to the CurrentCulture and Current-UICulture in the System.Globalization namespace. (For more information on CurrentCulture, see Chapter 4.) Culture defines the locale settings for your application, which include currency, date formats, list separators and others. UICulture defines the languages of the resources used in your Web application UI.

Even though all data is processed on the server as Unicode, there are three possible encoding settings for your ASP.NET application. These encodings can either be specified in your application code or in the globalization section contained within each Web.config file. RequestEncoding specifies the encoding the server uses to interpret data sent from the client, and ResponseEncoding determines the encoding of the data that is returned from the server to the client. FileEncoding indicates the encoding ASP.NET will use to interpret the file. If FileEncoding is not set and cannot be determined, ASP.NET will use the Windows code page of the server.

Deployment Projects

Glossary

• Setup project: Allows you to create installers in order to distribute an application in Visual Studio .NET.

In addition to support for Web projects, Visual Studio allows you to create deployment projects in nine languages, including English, German, French, Italian, Japanese, Korean, Spanish, Simplified Chinese, and Traditional Chinese. Each language version of Visual Studio contains all nine languages. Simply click Localization in the Properties window to create a Setup project with a localized UI. You can develop a single Setup project for each desired language version. Note that Setup projects do not support Unicode characters.

Visual C++ Support for Various Character Encodings

Visual C++ supports source-code files with a non-Unicode character encoding. Extended characters and ideographs can be used in #include file names, comments, character literals, and string literals. Source code can be made portable for compilation on a computer with a different system Windows code page by using #pragma setlocale("<locale string>").

For character-encoding support during run time, Visual C++ includes data types and application programming interfaces (APIs) for handling single-byte character set (SBCS), double-byte character set/multibyte character set (DBCS/MBCS), and Unicode (UTF-16) characters. Macros available in tchar.h allow you to write generic source code that can be compiled for any of these three run-time character encodings.

Locale Model

The Visual C++ run time also provides its own locale schema, which is modeled after the Portable Operating System Interface for UNIX (POSIX) locale model. This allows you to use locale-sensitive functions for string processing, number formatting, currency formatting, date and time formatting, and platform- independent sorting. Similarly, the Standard Template Library (STL) that ships with Visual C++ contains globalization support when C++ templates are used.

MFC and ATL Libraries

A final international feature of Visual Studio involves the libraries of both the Microsoft Foundation Class (MFC) and Active Template Library (ATL), which are available as versions for non-Unicode and Unicode character encoding. MFC and ATL applications that are linked with the Unicode libraries are usually restricted to Windows NT 4 or later. Unicode applications can, however, be statically linked to the Microsoft Layer for Unicode (MSLU) for execution on Microsoft Windows 95, Windows 98, or Windows Me systems. (For more information, go to http://www.microsoft.com/globaldev, or see the Microsoft Windows Platform SDK available at http://msdn.microsoft.com.) The display restrictions for platforms that are not Unicode-based are described in Chapter 3, "Unicode."

The MFC Application wizard contains translated templates for nine languages: English, French, German, Spanish, Italian, Simplified Chinese, Traditional Chinese, Japanese, and Korean. You can select any of these languages for the default UI language of an MFC Application project.

International features for ATL Server include both the possibility of configuring server processing with locale and code-page tags in server response files as well as support for creating Web pages that are encoded in UTF-8.