开发国际站点

Microsoft Corporation

2001 年 1 月

摘要：本文描述在为全球用户开发 Web 站点时支持多种语言和货币的最佳做法。

内容

介绍
使用多种语言
使用多种货币
配置国际区域设置

介绍

本文描述在为全球用户开发 Web 站点时支持多种语言和货币的最佳做法。您的目标就是使客户可以很轻松地随时更改语言或货币，并且不会丢失上下文，也就是不会被重定向到包含不同内容的另一页。实现多种语言和货币的方法有多种。选择哪一种方法取决于您的喜好和项目的限制。

使用多种语言

大多数公司都会得益于向客户提供多种语言与他们的站点进行交互的能力。但是，许多公司或者忽略了此问题，或者通过部署若干版本的站点来解决此问题。例如，Amazon.com 就为其站点提供了几个版本，包括 Amazon.de 和 Amazon.nl。

如果一个站点的所有版本可以同时更新，存在多个版本并不会有什么问题。但在大多数情况下，每个版本必须分别更新，这就会造成版本之间的重大差异。例如，Amazon.com 英语版的功能比德语版和荷兰语版丰富。对项目小组来说，这种重大差异会造成混乱，并使站点难于管理。本节探讨创建一个多语言站点的方法。

语言相关字符串

在电子商务站点中使用以下两种类型语言相关的字符串：

• 产品信息
• 站点信息（包括广告和折扣说明中的 HTML 内容）

产品信息

产品信息字符串是属于产品的语言相关属性的集合，如产品名称和产品说明。产品信息应存储在产品目录中，并用站点支持的所有语言来提供，因为多语言产品目录比使用各自语言的单独目录更容易管理。

若要管理语言相关属性，只需为每种属性调整代码，标识出显示属性所用的语言。例如，某个产品可能包含一个名为 short_description 的属性，而您希望用英语、法语和荷兰语来显示该属性。为此，对于英语版可以将 short_description 重命名为 short_description_en，对于法语版可以将其重命名为 short_description_fr，对于荷兰语版可以将其重命名为 short_description_nl。当页显示产品说明时，就可以改编代码，选择属性 short_description 以及语言代码（en 代表英语，fr 代表法语，nl 代表荷兰语）。语言代码可以是用户输入的参数，也可以是用户配置文件的属性。

站点信息

站点信息是站点必须显示的字符串集合，如“本周产品”、“搜索”和“确定”。可以用不同语言将整个一组可显示的字符串存储在数据库中，也可以将其存储在可扩展标记语言 (XML) 文件中。使用 XML 比使用 HTML 好，因为它的可移植性更好。例如，可以在必要时通过电子邮件将 XML 文件发送给转换器。

应用程序启动时，Global.asa 文件读取 XML 文件。字符串存储在 Microsoft® Commerce Server 2000 MessageManager 对象中，该对象有应用范围，从而确保 Web 窗体中的每一台服务器都有其自身针对每一种语言的字符串集副本。

当必须在站点上显示某一字符串时，可以用以下方法调用从 MessageManager 对象中检索它：

mscsMessageManager.GetMessage(sStringName, sLanguage)

为了加快页的执行，可以将经常显示的字符串（如菜单栏，即串联起来的多个单独的字符串）存储在 CacheManager 对象中以供随后检索。如果是这样，则 MessageManager 对象只需对它们查找一次。

对其他可显示的字符串（如在 Commerce Server Business Desk 中不能更改的折扣说明）可以使用同样的方法。

缓存

Commerce Server Solution Sites 广泛使用 CacheManager 对象。本质上，CacheManager 对象是扩展的 Dictionary 对象，它以名称/值对的形式存储字符串。

如果检查 Solution Site 代码，您会看到名称/值对中的名称部分称为缓存键。如果要实现多语言页，需要指定缓存键生成语言。以下代码就可以做到这一点：

sCacheKey = sCatalogName & sCategoryName & CStr(iPageNumber) & sLanguageCode

使用特定语言的缓存键生成来产生缓存键的语言代码部分，以便 CacheManager 对象可以检测到要显示的语言。

选择语言

经常在欧洲站点使用的基本站点方案是在第一次访问时向用户提供语言选择。用户必须点击链接或按钮才能用所选语言访问站点。然后该选择就被存储为用户配置文件中的一个属性，或存储在用户计算机上的 Cookie 中，这样，每当用户重新访问该站点时，适当的语言就会立即出现。

某些站点在它们的站点中使用另一种方案：他们试图通过从网际协议 (IP) 地址中查看国家/地区的扩展名来猜测用户的语言首选项。例如，如果用户从 proxy.myprovider.co.uk（位于英国的提供商）进行网络冲浪，则这些站点就假定用户是说英语的。这往往是一种很方便的策略，但不一定最准确。例如，许多旅游者在访问其他国家/地区时是从网吧浏览 Web。其他许多用户从 .com、.net 或类似的地址进行浏览，而这些地址与某种特定语言之间并没有明显的关系。

第三个方案是站点可以检查使用 Microsoft® Internet Explorer 的用户的默认语言设置。这种方案的缺点是许多用户都安装英语版的 Internet Explorer，而且即使英语可能不是他们的母语，他们也不会更改其语言设置。这一方案也会出现网吧问题。如果使用 Internet Explorer 的网吧设置了本地语言参数，则使用该方案的站点就会假定从那个位置登录的旅游者希望用那种语言而不是他们自己的语言来查看网页。

对于大多数站点来说最好的解决方案可能就是第一种方案：使用户可以选择一种语言，然后将该语言保存在用户的配置文件中。当用户下一次从任一位置登录时，站点就会自动切换到用户首选的语言。

更改语言

多语言站点应该使用户可以在每一页上都能从一种语言改为另一种语言。某些站点用下拉列表来实现这一点，用户可以在站点的任何一页上从列表中选择一种新语言。某些站点显示国旗图像，用户可以点击这些图像来选择相应的语言。

某些多语言站点只允许在站点的主页上更改语言，这意味着用户必须从站点中的其他位置返回到主页才能选择新的语言。这种方法容易实现，但与允许用户在任何一页上更改语言以保持所执行操作的上下文相比，此方法不便于用户使用。

对语言上下文进行编码的方法有以下 4 种：

• 使用客户端 Cookie 存储活动语言代码。
• 使用 URL 对语言代码进行编码。
• 在用户配置文件中存储语言首选项。
• 使用预生成页。

使用哪种方法取决于项目的限制和开发人员的偏好。

将客户端 Cookie 与语言代码配合使用

只要情况允许，使用客户端 Cookie 是对语言上下文进行编码的最简便的方法。为此，将语言代码（en、fr、nl 等）存储在 Cookie 中，并在每个显示语言相关字符串的页上读取此 Cookie。甚至可以通过使 Cookie 在未来某一日期（如 2100 年 1 月 1 日）过期来使它长久保持，从而使站点总可以注意到用户的语言（假定用户同意使 Cookie 长久保持）。

最好只在可以控制是否接受 Cookie 的情况中才使用这种方法，例如，概念的证实或公司内部项目。如果某个用户的浏览器不支持 Cookie（如移动电话中的微型浏览器），则这种技术将失败。

使用 URL 对语言代码进行编码

可以将语言代码嵌入 URL 中，此方法类似于 Solution Sites 生成会话 ID 票的方法。这意味着改写 GenerateURL 函数将语言代码添加到创建的每一个链接中，以便站点可以显示正确的语言。例如，必须为每个链接调用 GenerateURL，从而使 http://commercesitename.tld/mypage.asp 变为 http://commercesitename.tld/mypage.asp?lang=nl。然后每一页只需读取 lang 参数即可。

注意 不能用静态 HTML 页对语言代码进行编码，因为 HTML 页不能将任何输入参数传递给其他页。

将语言首选项存储在用户配置文件中

对语言首选项进行编码的另一种选择是将用户的语言保存在用户配置文件中。要做到这一点，需要您将 language 属性添加到用户配置文件中。如果用户更改了语言，您就必须更新该属性。这种存储语言首选项的方法可以节省费用，因为所涉及到的唯一性能损失是检索和更新配置文件。

使用预生成页

如果站点主要包含静态 HTML 页，使用预生成页则是在站点上对语言进行编码的另一种选择。预生成页不需要将语言标识传递到其他页，因为页的上下文（即页所在的目录）提供了这种功能。预生成页可以链接到其他页而不提供语言信息。此外，预生成页不需要读取 Cookie、URL 参数或用户配置文件就能确定用来显示的语言。

若要用您所支持的所有语言预生成页，可以将所有页放置在 /source 目录中，并对可以在 Active Server Page (ASP) 代码中用分隔符预生成的所有字符串予以标记。例如，可以将“搜索”按钮指定为：

<INPUT TYPE=SUBMIT VALUE="[[=Search]]"> 

在该片段中，[[=Search]] 是将要被翻译的词的助记键。必须编写一个页生成器用来读取 /source 目录中的所有页，使用 MessageManager 对象查找分隔的助记键，翻译分隔的助记键并将已翻译的页保存在特定语言的目录中。使用支持英语、法语和荷兰语的站点示例，需从 /source 中读取页并在 /en、/fr 和 /nl 目录中生成页。可以使该过程每天自动运行一次或两次，或每当更新站点时自动运行。

页预生成方法节省了运行时的时间并且不依赖于 CacheManager 对象。此外，如果站点有许多静态页（即除了调用 MessageManager 对象查找字符串外不执行其他任何逻辑的页），则它可以大大提高性能，因为现在这些页可以成为真正静态的 HTML 页而不是 ASP 页。将这些静态页放置在只为静态内容提供服务的专用服务器上可以进一步提高性能。

使用多种货币

与支持多种货币有关的问题同关于多种语言的问题相似，但比后者更容易解决。可以支持多种货币并使用户可以在各种货币之间来回切换，也可以同时用所有货币显示价格。对于某些电子商务站点来说，同时用多种货币显示价格可能非常有用，但对于大部分站点来说，尤其是企业到客户 (B2C) 站点，第一种方法则更为简便。

产品定价

如果可能，您应只用一种货币（即“参考”货币）存储产品定价信息。例如，可以用美元或欧元存储价格，然后根据需要用其他货币实时重新计算价格。若要基于参考货币重新计算价格，需要一张兑换率表，这张表指定了其他货币相对于参考货币的兑换率。兑换率表应该包含以下字段：

• 货币符号
• 国际标准化组织 (ISO) 货币代码
• 兑换率
• 显示格式

下例显示了一张兑换率表。

货币符号ISO 货币代码兑换率显示格式$USD（美元）1.0####.##£UKP（英镑）1.2####.##FBEF（比利时法郎）0.023######,00€EUR（欧元）0.9####.##

站点显示价格时，它将根据兑换率重新计算价格，并用相关联的货币符号和显示格式将其显示出来。

重要说明 如果用 CacheManager 对象存储搜索结果和产品详细信息页，则必须将货币包括在缓存键中，否则在尝试用不同货币显示定价时会检索到错误的结果。

针对不同区域设置的不同价格

某些项目针对不同的区域设置需要有不同的定价。例如，某种轿车在德国可能要花 100,000 德国马克，而在美国只有 40,000 美元。不过，这只是特定区域设置的定价，而不是特定货币的定价。居住在美国的德国客户对这辆轿车应该支付相同的价格，而不管是用德国马克还是用美元来查看的。

在大多数情况下，针对不同区域设置的不同价格要求在产品属性中有明确的定价。因此必须在目录中保留若干个价格。可以通过用 Business Desk 中的“目录编辑器”模块创建自定义目录或通过将特定区域设置的定价属性添加到目录架构中来做到这一点。其目标是创建具有吸引力的以市场为导向的定价策略以吸引客户。例如，不是仅仅将一个美国物品价格 9.95 美元与兑换系数相乘，从而产生一个以比利时法郎表示的带零头的价格（如 457 法郎），而是为比利时创建一个自定义目录，这一目录包含针对于比利时市场的价格（如 450 法郎）。

针对不同区域设置的不同折扣

为不同区域设置提供不同折扣的概念类似于为不同区域设置保持不同的定价。但特定区域设置的打折策略不需要自定义目录或多种价格属性。而是可以通过配置 Commerce Server Purchase 管线和 Content Selection 管线来根据区域设置执行不同的折扣。尽管此问题乍一看似乎与货币有关，但实非如此。有关 Commerce Server 管线的更多信息，请参阅 Commerce Server 2000 帮助。

更改货币

与更改货币相关联的问题类似于与更改语言相关联的问题。可以用以下任一方法提供活动货币：

• 使用客户端 Cookie 存储活动货币代码。同更改语言一样，使用客户端 Cookie 是对货币上下文进行编码的最简便的方法。这种方法唯一不好的地方是一些用户不喜欢使用 Cookie。同时，移动用户将不得不重新输入他们的数据。
• 在 URL 中对货币代码进行编码。使用与用来更改语言的函数相同的 GenerateURL 函数包含活动货币。
• 将货币代码存储在用户配置文件中。将适当的货币代码存储在用户配置文件中是一种选择，但显示货币信息的每一页都需要调用该用户配置文件。如果用户的配置文件数据已被缓存，则这是一种可靠而快速的方法，它可以使用户的设置可用于任何位置。

配置国际区域设置

可以对某一站点进行配置以使其使用不同于开发语言的另一种语言。例如，您可能用英语开发了站点，然而又希望用该英语站点的副本来创建法语站点。使用不同的语言创建站点的方法是：

• 在 Microsoft® Windows® 2000 中设置系统区域设置。在“控制面板”中为新的区域设置“区域选项”中的选项。必须分别为每台计算机设置区域设置并启用给定代码页中的文本显示和输入。还必须定义特定于此区域设置的默认设置，如货币、数字格式和日期与时间的格式。
• 配置 Microsoft® SQL Server™ 的排序规则设置。在安装 SQL Server 时设置 SQL Server 的排序规则设置；不能在安装后重新配置它们。排序规则设置决定数据库为非 Unicode 数据接受的代码页和排序顺序。（数据库架构决定了数据是否为 Unicode 数据。）
• 使用 App Default Config 资源更改 Commerce Server Manager 中的以下 Commerce Server 站点属性：
  • 站点默认区域设置
  • 页编码字符集
  • 重量度量单位
  • 货币：基础货币区域设置
  • 货币：基础货币代码
  • 货币：基础货币符号

  如果打算显示一种以上的货币，则还需要为每种附加的货币配置以下属性：

  • 货币：替换货币选项
  • 货币：替换货币兑换率
  • 货币：替换货币区域设置
  • 货币：替换货币代码
  • 货币：替换货币符号
  • 货币：货币显示顺序选项

有关配置 App Default Config 资源的更多信息，请参阅 Commerce Server 2000 帮助中的“配置 App Default Config 资源属性”主题。

在配置 Windows 系统区域设置后，SQL Server 就默认为相应的排序规则。（代码页和排序顺序与此区域设置相匹配。）当配置 Commerce Server 时，Commerce Server 数据库支持已配置的代码页。可以在 Commerce Server Manager 的 App Default Config 中更改任何设置。

在解压缩 Business Desk 后或使用 Solution Sites 之一后，以下站点的配置属性就将基于系统的区域设置，而且不必更改它们：

• 站点默认区域设置（数字和日期格式）。
• 基础货币区域设置。

  注意 Base currency symbol 和 Base currency code 属性的设置方法不同。

• 页编码字符集（设置为支持与系统区域设置关联的语言的默认字符集）。在 Business Desk 头文件中使用此编码字符集为每一页设置字符集。

如果在配置为相同区域设置的系统上用 Commerce Server Site Packager 来解压缩本地化站点，除非要显示多种货币，否则不必更改任何设置。Site Packager 包包括所有其他设置。确保在发布站点之前检查所有设置。

例如，如果在朝鲜语系统上安装英语站点，则可以将朝鲜语语言字符输入到 Business Desk 中而不必进行任何其他更改。

但是如果要在已针对开发语言配置的系统上以另一种语言运行站点（例如在英语系统上运行法语站点），则需要重新配置以下设置：

• 将 Default site locale、Base currency locale 和 Page encoding charset 属性设置为法语。
• 在 BDHeader.asp 和 BDXMLHeader.asp 文件中执行以下步骤：
  1. 移除 <%@ LANGUAGE=VBSCRIPT%>。
  2. 取消注释 <%'@ LANGUAGE=VBSCRIPT CODEPAGE=1252 %> 并将代码页设置为法语的正确值。

  注意 创建货币属性时目录模块使用 Base currency symbol 和 Base currency code 属性。