Designing International IIS Applications

  • Article

One of the advantages of distributing information over the Internet or an intranet is that you can create international Web sites that users can access from different countries/regions. Users can request pages that have been localized into their own language, which they read in localized browser versions.

When you create a Web site that contains pages in different languages, you may need to convert strings that are passed between the browser and the Web server, or between an ASP script and a COM component. If all pages on the Web site are written in the default character set used by the Web server, ASP does the conversion automatically. If you author pages in different character sets for browsers of different languages, however, you need to use ASP commands that specify how the strings should be converted. For example, if your site contains some pages in one of the Japanese character sets and others in one of the Chinese character sets, you need to specify which character set ASP should use while processing strings for a particular page.

ASP also provides commands that support the cultural conventions for different locales, such as the format used for currency, time, date, and numbers. As with the string conversion commands, you need to use the locale commands only if your scripts do not use the default locale for the Web server and the browser.

There are many design scenarios for the structure of an international Web site. After finances and time are taken into consideration, the best structure might be a mix of scenarios. Three possible scenarios follow:

Scenario One - Translate each Web page

If you pay localizers to translate your pages, translating each Web page may not be the most economical solution. However, your server processes requests faster than in the other scenarios, especially if you maximize static content.

  • For each language you support, create a sub folder to store translated Web pages.

  • Use an ASP file in your root folder to determine the accepted languages of the browser, and redirect the translated Web pages to the corresponding sub folder. If you do not support the languages of the browser, provide links to the start pages of each sub folder to let the viewer choose a language. Use Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") to determine what languages the browser accepts.

  • Set the locale dynamically because some languages contain multiple locales. For example, the code page for English is 1252, but the locale can be 2057 for the United Kingdom, 1033 for the United States, or 4105 for Canada.

Scenario Two - Translate text segments stored in a database

If you have a small Web site, or one with content that changes frequently, you can store all of your text segments in a database that is indexed by the code page of the segment. SQL handles strings in different code pages. Access handles Unicode strings that you can write out with Response.BinaryWrite. When you translate text segments that are stored in a database, a localizer is given one file to work with. Because the database calls are simple queries, the speed of serving pages suffers only slightly.

  • In each ASP file, determine the accepted languages of the browser, and insert a text segment from the database that is translated in the right language. Use Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") to determine what languages the browser accepts.

  • Set the locale dynamically because some languages contain multiple locales. For an example, see Step 3 in Scenario One.

Scenario Three - Rely on a translation tool

Because individual locales may not be handled by the translation tool and there may be subtle errors in the translation, have someone proof read all your translated pages.

  • Subscribe to a Web service that provides instant translation of each of your Web pages, while maintaining the graphics and formatting of your page. Alta Vista has a downloadable document translation tool which you can purchase, as well as an online tool to translate posted Web pages.

Functionality has been extended in IIS 6.0 to improve development of international Web sites. UTF-8 support is extended to all multi-byte characters including surrogate characters like those for Japanese. The IIS intrinsic objects are able to store and retrieve strings using different code pages. For example, form data and server variables can contain strings that are encoded using a different code page than the default of the Web server. The IIS installable components like Ad Rotator and Content Rotator also support localized characters. Lastly, there are two new Response properties called CodePage and LCID, and a new metabase property called AspLCID, which change the hierarchy of how code pages and locales are set on a page. For more information, see the following topics.