Abstract: This article describes the best way to support multiple languages and currencies for international users to develop Web sites.
table of Contents
Introduction to use multiple currency configuration international area settings in multiple languages
Introduction
This article describes the best way to support multiple languages and currencies for international users to develop Web sites. Your goal should make your customers easily change the language or currency at any time, without losing the context (that is, no repositioning to another page containing different content). There are several ways to achieve a variety of languages and currencies. You can choose one of your preferences and engineering restrictions.
The sample site Sweet Forgiveness demonstrated the principles described in this article, which is located at http://www.microsoft.com/commerceserver/default.htm (English). The Sweet Forgiveness site is a multilingual site and it supports multiple currencies. It mixes a variety of methods described herein.
Use multiple languages
Most companies will benefit from language options that can provide customers with language interaction with sites. However, many companies don't ignore this problem, is to solve this problem by deploying multiple versions of their sites. For example, Amazon.com provides multiple versions of its site (including Amazon.DE and Amazon.nl).
If all of the versions of a site can be updated at the same time, then multiple versions of the compute will not be a problem. But in most cases, each version must be updated separately, which will cause a lot of difference between the version. For example, the Amazon.com English version of the function is much more rich than the German version and the Dutch language. Such a significant difference will cause the project group to be confused and the site is not easy to manage. This section will discuss the method of creating a single multilingual site.
Language related strings
Two languages related strings are used in e-commerce sites:
Product Information Site Information (including HTML content in advertising and discount)
product information
The Product Information string is a collection of language-related properties that belong to the product, such as names and descriptions. Product information should be stored in the catalog and should be displayed with all languages supported by the site because a multilingual product catalog is more easy to manage than the independent directory of various languages.
To manage language-related properties, simply adjust the code for each property to identify the language used when this property is displayed. For example, your product may contain a short_description property that needs to be displayed in English, French and Dutch. To achieve this goal, you can rename short_description_en as the English version, rename Short_Description_fr as a French version, and renamed Short_Description_nl as the Dutch version. When the page displays the product description, you can adjust the code to select the short_description attribute that contains the language code (EN represents English, Fr Represents French, NL means Dutch). The language code can be the parameters entered by the user, or an attribute of the user profile.
Site Information
Site information is a collection of strings that the site must display, such as "Product of the week", "Search", and "OK". You can store the entire set of displayed strings in a database or scalable tag language (XML) file in different languages. Selecting XML better than selecting HTML because it is easier to migrate. For example, if necessary, you can send an XML file to the translator via email. For examples of how to store a string using XML files in different languages, see the RC.xml file on the Sweet Forgiveness site, all site information of the file uses a string form.
When the application starts, the Global.asa file reads the XML file. The string is stored in the Microsoft® Commerce Server 2000 MessageManager object, which ensures that each server in the web domain has a list of its own strings for each language. When a string must be displayed on the site, the following method can be used to retrieve the string from the MessageManager object:
MscsMessageManager.getMessage (SSTRINGNAME, SLANGUAGE)
To speed up the implementation of the web page, you can display the string frequently displayed (such as a menu bar, which is a single string connection) is stored in the CacheManager object for future retrieval. When you do this, the MessageManager object only needs to find them once.
You can also use the same technique to other displayable strings, such as discounts that cannot be changed in Commerce Server Business Desk.
Cache
Commerce Server Solution Sites has widely used CacheManager objects. Essentially, the CacheManager object is an extension Dictionary object that stores a string in a name / value pair.
If you check the SOLUTION SITE code, you will see that the name / value pair is called a cache keyword. If you decide to implement a multilingual page, the build of cache keyword must be for a specific language. You can use the following code to complete this:
Scachekey = ScatalogName & ScategoryName & CSTR (Ipagenumber) & Slanguagecode
Use the language-specific cache keyword generation method to make the language code a part of the cache keyword, so that the CacheManager object can detect the language to display.
Choose a language
A basic site scheme that is often used in the European site is to provide language selection when the user has first access the site. Users must click a link or button to access the site in selected languages. This selection is then stored as an attribute in the user profile, or stored in the cookie of the user computer, and the user can display the correct language immediately when the user accesses the site.
Some sites use another program: They speculate users' native language by finding country / region extension from the Internet Protocol (IP) address. For example, if a user is online from Proxy.MyProvider.co.uk (Based on the UK provider), these sites assume that the user speaks English. This is usually a convenient strategy, but it is not necessarily the most accurate. For example, many tourists traveling abroad browsing the web from Cybercafé. Many other users are browsed from .com, .net or similar address, they do not have any obvious correspondence with specific languages.
In a third solution, for users using Microsoft® Internet Explorer, the site can check the default language settings. The disadvantage of this solution is that many users have installed the English version of Internet Explorer and have not changed language settings, even if English is not their mother tongue. Cybercafé problems will also occur in this scenario. If Cybercafé sets the local language parameters with Internet Explorer, the site that uses this scenario will assume that the tourist who is logged in from this location wants to use the local language instead of the native language to view the web page.
For most sites, the best solution may be the first solution: let the user select the language and save it in the user's configuration file. Next, no matter what location login, the site will automatically switch to the language selected by the user.
change language
Multi-language sites should make users can change from a language to another in each page. Sweet Forgiveness Sample Site Using a drop-down menu, you can select a new language from the drop-down menu on any page of this site. Some sites displays the national flag icon, the user can click the icon to select the corresponding language. Some multilingual sites are only allowed to change the language on the site home page, which means that the user must return from other locations from the site to select a new language. This approach is easy to implement, but is not friendly than the user to change the language in any page to keep the operation in which the operation is being executed.
There are four ways to encode the language context:
Use client cookies to store the current language code. The language code is encoded in the URL. Store the selected language in the user profile. Use the predefined page.
The method used depends on the restrictions of the project and the preferences of developers.
Use the client cookie for language code
If allowable, use the client cookie is the easiest way to encode the language context. To do this, you need to store language code (EN, FR, NL, etc.) in cookies and read this cookie in the page of each display language related string. You can also have a very long (for example, from January 1, 2100), so that the site can always know the user's language (assuming the user agrees to make the cookie).
It is best to use this technology only if you can control whether you accept cookies; for example, the concept or the company's internal project is verified. This technology cannot be used if a user's browser does not support cookies (such as micro browsers in a cellular phone).
Code language code in the URL
You can embed the language code into the URL, which is similar to the method of generating a session ID tag with the Solution Sites. This means that the GenerateURL function needs to be modified to add language code to each link you created, so that the site displays the correct language. For example, you must call your association for each link to turn http: //commercesitename.tld/mypage.asp to http: //commercesitename.tld/mypage.asp? Lang = nl. Then each page can simply read the language parameters.
Note: You cannot encode language code with a static HTML page because the HTML page cannot pass any input parameters to other pages.
Store selected languages in the user profile
Another way to encode the selected language is to retain the user language in the user profile. Do you need to add a language property in the user profile. In the future, if the user changes the language, you must update this property. This is an effective way to store the overhead of the selected language because the performance overhead involved is only retrieval and updating the configuration file.
Use the predefined page
If you are mostly a static HTML page, you can choose to encode site language using the pages of the predecessor. The pages of the predefined page do not need to pass the language identifier to other pages, because the context of the page (the directory where the page is located) provides this capability. The pages of the predefined page do not have to provide language information to link to other pages. In addition, the pages of the pre-gentleman do not need to read cookie, URL parameters, or user profiles to determine which language displayed.
To prepare all the languages that are supported, you can place all pages in the / source directory and will be brought to the Active Server Pages (ASP) code in the Active Server Pages (ASP) code. For example, you can specify the Search button as follows:
In this code, [[= Search]] is a spending of words to translate. You must write a page generator to read all the pages under the / source directory, find the separated help notes, translate the separated museum, and save the translated page in a specific language directory. Using a site supporting English, French, and Dutch as an example, you can read the page from the / source directory and generate a page in / en, / fr, / nl directories. You can automatically run once or twice a day, or run this process when you update your site.
Mr. Mr. is a page that saves time at time and does not depend on the CacheManager object. Also, if your site has a large number of static pages (these pages do not perform any other logical operations in addition to calling the MessageManager objects, using this method can significantly improve performance, because now those pages are real static HTML pages Not the ASP page. Place those static pages on a private server only for static content, can further improve performance.
Use multiple currencies
Issues that support multiple currencies are similar to those who support multiple languages, but more easily solved than it. You can support multiple currencies and allow users to switch back and forth, or they can also display prices at all monetary. For some e-commerce sites, it is useful to display prices in a variety of currency; but for most sites, especially companies to consumers (B2C) sites, the first method is simpler.
product price
If possible, you should store product price information only in a currency ("reference" currency). For example, you should store prices in dollars or euros, then recall the price in real time in other currencies when needed. To recalculate the price based on the reference currency, you need an exchange rate table to determine the exchange rate of other currencies and reference currencies. The exchange rate table should contain the following fields:
Currency Code Exchange Rate Display Format of Currency Symbol International Standardization (ISO)
The following example shows a form of the exchange rate table.
Currency symbol ISO currency code exchange rate display format $ usd (USD) 1.0 ####. ## £ UKP (£) 1.2 ####. ## fbef (Belgian franc) 0.023 ######, 00 € EUR (Euro) 0.9 ####. ##
When your site displays a price, it recalculates the price based on the exchange rate and displays the relevant currency symbols and display formats.
Important: If you store the search results and generate a detailed page with the CacheManager object, you must include currency in the cache keyword. Otherwise, when you try to display a price with other currency, you will retrieve the result of the error.
Use different prices for different regions
Some projects require different prices for different regions. For example, a car procures cost of 100,000 Germany in Germany, but only $ 40,000 in the United States. But this is the price of a particular area, not the price of a specific currency. German customers living in the United States are the same for the price of the car, which is the same as the price of the car.
Typically, different prices for different regions requires explicitly display prices in product properties, so you must keep multiple prices in your directory. To do this, you can use the Catalog Editor module in Business Desk to create a custom directory, or add the price properties of the specific area to the directory schema. The purpose is to create customer interest, attractive, market-oriented prices. For example, simply multiply the US offer of $ 9.95 with the conversion coefficient, the resulting Belgian franc price (for example, 457 francs) does not meet local habits, so this method is not available. A better way is to create a custom directory for Belgium, including prices suitable for the Belgian market (for example, 450 francs). Use different discounts for different regions
The concept of different discounts in different regions is similar to the concept of using different prices for different regions, but the discount of specific areas does not need to customize the directory or multiple price properties, and the Commerce Server Purchase pipe and the Content Selection pipeline can be configured according to different. The area performs different discounts. Although it seems to be a problem with currency, it is actually not related to the currency. For more information on the Commerce Server pipeline, see Commerce Server 2000 Help.
Change currency
The issue of changing the currency is similar to the problem related to changing the language. The Sweet Forgiveness sample site contains a drop-down menu, and the user can select a currency in the same way as in which the language is selected. Due to the needs of the demo, the currency is always passed through the URL as the needs.
You can provide current currency by any of the following methods:
Use client cookies to store current currency code: Like change language, using client cookies is the easiest way to encode monetary context. The sole disadvantage of this method is that some users have to use the cookies they don't like. Moreover, roaming users have to re-enter their data. Code currency code in the URL: Use the same generateURL function you use when you change your language, including the current currency. Store currency code in the user profile: Store the corresponding currency code in the user profile is a choice, but you need to call the user profile after each page of the currency information. If the user's configuration file data has been cached, this is a reliable and fast way to use user settings from any location.
Configure internationalized area settings
You can configure a site that makes it different from your development language. For example, you can develop sites in English, but you need to create a French site with this English site. To create a site by using different languages:
Set the system area in Microsoft® Windows® 2000. In the Control Panel, set the options under "Area Settings" for the new area. You must set the area separately for each computer and enable display and enter text at a given code page. You must also define the default settings of the area, such as currency, numerical format, date, and time format. Configure Microsoft® SQL ServerTM sort settings. SQL Server Sort Setup When setting SQL Server, it cannot be changed after the installation is complete. Sort settings determine the code page and sorting method used by the database to non-Unicode data. (The database architecture determines if the data is Unicode.) Change the following Commerce Server Site Properties in Commerce Server Manager by using App Default Config resources:
Site default locale Page encoding charset Unit of Measure for Weight Currency: Base currency locale Currency: Base currency code Currency: Base currency symbol If you plan to display more than one currency, you need to configure the following properties for each additional currency: Currency: Alternate currency Options Currency: Alternate Currency Locale Currency: Alternate Currency Code Currency: ALTERNATE CURRENCY CURRENCY: CURRENCY DISPLAY ORDER OPTIONS
For more information on configuring the App Default Config resource, see the "Configuring the App Default Config Resource Properties" topic in Commerce Server 2000 Help.
After configuring the Windows system area, SQL Server uses the corresponding sort mode by default. (Code page and sort mode match the area.) When you configure Commerce Server, the Commerce Server database will support the code page you configured. You can make changes to any settings in the App DEFAULT Config resource in Commerce Server Manager.
When you decompress Business Desk or use one of Solution Sites, the following site configuration properties are based on the system area, and you don't need to change them:
Site Default Locale (format of numbers and dates). Base currency locale. Note: The setting method of Base Currency Symbol and Base Currency Code properties is different. Page Encoding Charset (set to support the default character set for the system area related language). You can set the character set for each page in the Business Desk header file.
If you want to decompress the localization site with the Commerce Server Site Packager on the system configured for the same area, you don't have to change any settings unless you want to display multiple currencies. All other settings are included in the Site package. Before publishing the site, you must check all settings.
For example, if you install your English sites on your Korean system, you can enter Korean language characters in Business Desk without any other changes.
However, if you want to run a site on a system configured in a different language (for example, running French sites on English systems), you need to configure the following settings:
Set the Default Site Locale, Base Currency Locale and Page Encoding Charset attribute to French. In BDHeader.asp and BDXMLHEADER.ASP files, perform the following steps:
Delete <% @ language = VBScript%>. Cancel Notes <% '@ language = VBScript CodePage = 1252%> and set the code page to the correct value of French. Note: When creating a currency property, the Catalogs module uses Base Currency Symbol and Base Currency Code properties. The information contained in this document represents the latest perspective of Microsoft Corporation in the discussion date. Since Microsoft must adapt to the changing market situation, this information is not the commitment made by Microsoft, and Microsoft does not guarantee any information provided after the publishing date is completely correct.
This white paper is only used by information. Microsoft does not make any promise or implied warranties in this document.
Users have a responsibility to comply with all applicable copyright laws. Without copyright, no part of this document is copied, stored in or inputs or inputs or enters or inputs or inputs or enters or enters or enters or enters or enters or enables any form or mode (electronic, mechanical, photocopy, recording or) or Other ways to propagate or use as other purposes.
Microsoft holds patents, patent application rights, trademark rights, copyright or other related intellectual property rights. Microsoft only provides the right to clearly specify in any written license agreement, without granting the above patents, trademark rights, copyright or other intellectual property rights of this document.
In this paper, the company, organization, product, people, and events are fictitious, with any real companies, organization, products, individuals or events without any direct or indirect associations.
© 2001 Microsoft Corporation All rights reserved. all rights reserved.
Microsoft and Windows are registered trademarks or trademarks of Microsoft Corporation in the United States and / or other countries or regions.
The real companies and product names mentioned here are trademarks of their respective owners.
