一、 ASP.NET全球化信息
在我的网站中，在创建资源文件并加入一些本地化数据后，我首先开始使用显式本地化来设置控件（例如，在我的网站中的标签）的文本，以便它们可以从资源文件中得到它们的值。既然存在四种语言；所以，除一个完全可依赖的资源文件之外(没有本地化命名)，我创建了四个资源文件。
注意，这些资源文件都以本地化标记作为它们的中间名称，因此，我需要把UICulture设置为与该本地化相同的名字以便ASP.NET存取这些资源文件。
但是，问题是：我该怎样在PostBack事件中动态地改变文化呢？幸好，ASP.NET在Page类中提供了一种可重载的方法： InitializeCulture()。这个方法在页面生命周期(在生成任何控件之前)中执行得很早，并且在此，我们能够设置当前线程的UICulture和Culture。
由于这个方法位于Page类中，并且我不想针对每一个web页面都重复相同的代码，所以我创建了一个BasePage类，我的应用程序中的所有的aspx页面都派生自这个BasePage类。但是现在，我又面临另一个问题。
回到UI设计：我使用了一个MasterPage和一个Header用户控件(在一个ContentPlaceHolder内)。我把一个缺省的页面与该MasterPage相关联。整个站点必须动态地实现本地化。因此，在顶部，有一个下拉框，用户可以从中选择一种语言/文化。在BasePage的 InitilializeCulture方法中，我必须取得用户从下拉框选择的项的值；但是，因为它还没有被初始化，所以，我还不能存取任何控件的值。答案是：使用表单集合(从响应对象内)。
一旦我们从web应用程序中提取了所有的内容并且基于用户选择和使用Resources.TestWebSite.XXXPropertyName设置好了Culture和UICulture，那么，我们就已经为我们的全球化框架作好了准备。现在，剩下的唯一事情是把资源特定的数据添加到相应的资源文件中。针对每一种文件类型，我们需要有一个单独的(和适当命名的)资源文件。这个过程称为本地化。在我的web.config文件中，我使用了下列属性：
- <globalization responseEncoding"=utf-8" requestEncoding="utf-8" fileEncoding="utf-8" />
二、设置语言方向相应的dir属性
许多时候，我们还需要设置本地化文本的方向(这是使用<html> 或<body>标签的dir属性设置的)。这是必需的，因为有些语言从右到左(RTL)读取，例如Arabic，不同于象Hindi和 English这样语言的标准的从左到右(LTR)的读取方式。这可以通过把.resx文件中的dir属性设置为适当的值来实现。
首先，你可以在所有资源文件中创建一个Direction(你可以使用任何名)域，并基于单个资源文件把它的属性设置为RTL或LTR。对于Arabic，这个域的值是RTL，而对于Hindi则是LTR。然后，把<body>标签的dir属性设置为如下：
- <body runat="server" dir="<%$ Resources: TestSiteResources， Direction %>">
三、使用数据库实现本地化
我们已经看到了如何本地化控件的文本和UI描述。但是，存储在数据库中的内容会怎么呢？其实，这一部分内容也需要本地化，但是由于它存储在一个DB中，所以我们不能使用资源文件来实现相同目的。为此，我们需要创建新的表格。
假定我有一个存储用户评价的表格。该表格结构如下所示：
现在，我们想实现以本地化的文本来显示Comments和Name字段，但是，我们不可能把所有这些域的不同语言版本都存储在同一个表格中(既然存在不需要被本地化但却重复的其它域)。因此，我们需要重新组织该表格结构并且创建另一个表格来存储这两个域的本地化版本。首先，我们需要从这个表格中删除这两个域并创建一个如下所示的新表格：
ASP.NET全球化与本地化之全球化
在此，我们添加了一个新域：CultureID，它等价于LCID（或Locale标识符）。我们能够按如下所示添加文化特定的本地化数据：
现在，我们可以使用以CultureID(LCID)作为参数的SQL查询来取得本地化内容。我们还能够提供一个用户接口来把本地化数据输入到这样的表格以便能够以一种交互方式创建相应的内容。
四、总结
在本文中，我们讨论了有关实现ASP.NET全球化的一些重要方面，并且看到，这是非常容易实现的事情.
【编辑推荐】
