Office 解决方案的全球化和本地化
更新：2007 年 11 月
全球化和本地化 Microsoft Office 解决方案过程中所遇到的大多数问题与您使用 Visual Studio 创建其他各种解决方案时遇到的问题相同。有关常规信息，请参见对应用程序进行全球化和本地化。在 MSDN 网页使用 Microsoft Visual Studio Tools for the Microsoft Office System 创建的解决方案的全球化和本地化问题上也提供了全球化和本地化信息。
本地化文档文本
项目中的文档、模板或工作簿中可能包含静态文本，静态文本必须与程序集及其他托管资源分开进行本地化。完成此任务的一个直接的方法是，创建文档的副本，然后使用 Microsoft Office Word 或 Microsoft Office Excel 对文本进行翻译。即使您不对代码做任何更改，此过程仍然有效，因为任意数量的文档都可以链接到同一程序集。
您还必须确保与文档文本进行交互的任何代码部分都要与文本的语言保持匹配，并确保书签、命名范围以及其他显示字段能够适应根据不同的语法和文本长度的需要对 Office 文档重新调整的格式设置。对于包含相对较少文本的文档模板，可以考虑在资源文件中存储文本，然后在运行时加载该文本。
文本方向
在 Excel 中，可以设置工作表的属性，以从右向左呈现文本。放在设计器上的宿主控件或任何具有 RightToLeft 属性的控件将在运行时自动匹配这些设置。Word 没有针对双向文本的文档设置（您只能更改文本的对齐方式），因此这些控件不能映射到此设置。但您必须为每个控件设置文本对齐方式。可以编写代码遍历所有控件，强制这些控件从右向左呈现文本。
更改区域性
自定义代码通常共享 Word 或 Excel 的 UI 主线程，因此对线程区域性所做的任何更改都会影响该线程上运行的其他内容；该更改不仅限于自定义。
Windows 窗体控件在宿主应用程序启动 Visual Studio Tools for Office 外接程序之前进行初始化。在这些情况下，应在设置 UI 控件之前更改区域性。
安装语言包
如果 Windows 具有非英语设置，则可安装 Visual Studio Tools for Office 语言包来以 Windows 使用的语言查看 Visual Studio Tools for Office 运行时消息。如果最终用户使用非英语 Windows 设置运行解决方案，他们必须具有正确的语言包，才能以 Windows 使用的语言查看运行时消息。Visual Studio Tools for Office 语言包可从 Microsoft 下载中心获得。
此外，可再发行的 .NET Framework 语言包对于 ClickOnce 消息是必需的。.NET Framework 语言包可从 Microsoft 下载中心获得。
区域设置和 Excel COM 调用
每当托管客户端对 COM 对象调用一个方法并且需要传入特定于区域性的信息时，它都使用与当前线程区域设置匹配的 CurrentCulture（区域设置）来执行这些操作。默认情况下，当前线程区域设置是从用户的区域设置继承而来的。但是，调用 Excel 对象模型时，Visual Studio Tools for Office 会自动传入一个区域性固定的区域设置标识符 (LCID)。在将数据传递到 Microsoft Office Excel 或从 Visual Studio Tools for Office 项目代码中读取数据之前，必须使用英语（美国）数据格式（LCID 1033）对具有区分区域设置格式的所有数据（如日期和货币）进行格式设置。有关更多信息，请参见使用各种区域设置对 Excel 中的数据进行格式设置。
此行为由属性 ExcelLocale1033Attribute 控制。可以通过将 ExcelLocale1033Attribute 设置为 false 来更改行为，以便使用当前线程的 LCID 传递数据。然后您就可以编写自己的代码来处理 Excel 和托管代码之间的交互。有关更多信息，请参见 如何：使用反射使字符串在 Excel 中是区域安全的。
存储数据的注意事项
为确保正确解释和显示数据，还应考虑到应用程序在字符串（硬编码）而不是强类型的对象中存储数据（包括 Excel 工作表公式）时可能会出现的问题。应使用采用区域性固定的或英语（美国）（LCID 值为 en-US）样式进行格式设置的数据。
使用字符串的应用程序
可硬编码的可能值包括用英语（美国）格式编写的日期文本，以及包含本地化函数名的 Excel 工作表公式。还可能是包含数字（如“1,000”）的硬编码字符串；在某些区域性中，“1,000”被解释为一千，而在另一些区域性中它表示一点零。根据错误的格式执行计算和比较会导致不正确的数据。
Excel 根据随字符串传递的 LCID 解释所有字符串。如果字符串的格式与传递的 LCID 不对应，则会出现问题。在传递所有数据时，Visual Studio Tools for Office 使用 LCID 1033 (en-US)。Excel 根据区域设置和 Excel 用户界面语言显示数据。Visual Basic for Applications (VBA) 的工作方式如下：字符串被设置为 en-US 格式，而 VBA 通常将 0（非特定于语言的）作为 LCID 传递。例如，下面的 VBA 代码根据当前的用户区域设置显示 2004 年 5 月 12 日的正确格式：
'VBA
Application.ActiveCell.Value2 = "05/12/04"
当用于 Visual Studio Tools for Office 解决方案并通过 COM 互操作传递到 Excel 时，相同的代码在日期格式为 en-US 样式时会产生相同的结果。
例如：
Me.Range("A1").Value2 = "05/12/04"
this.Range["A1", missing].Value2 = "05/12/04";
应尽可能使用强类型数据而不要使用字符串。例如，不将日期存储为字符串格式，而是存储为 Double，然后将其转换为 DateTime 对象进行操作。
下面的代码示例获取用户在单元格 A5 中输入的日期，将其存储为 Double，然后转换为 DateTime 对象以在单元格 A7 中显示。必须设置单元格 A7 的格式以显示日期。
Private Sub ConvertDate_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
Handles ConvertDate.Click
Try
Dim dbl As Double = Me.Range("A5").Value2
Dim dt As System.DateTime = System.DateTime.FromOADate(dbl)
Me.Range("A7").Value2 = dt
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub
private void ConvertDate_Click(object sender, EventArgs e)
{
try
{
double dbl = (double)(this.Range["A5", missing].Value2);
System.DateTime dt = System.DateTime.FromOADate(dbl);
this.Range["A7", missing].Value2 = dt;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
Excel 工作表函数
Excel 大多数语言版本都在内部转换了工作表函数名。但是，因为潜在的语言和 COM 互操作问题，强烈建议您在代码中仅使用英语函数名。
使用外部数据的应用程序
对于打开或以其他方式使用外部数据（如包含从旧系统导出的逗号分隔值的文件（CSV 文件））的任何代码，如果这些文件是使用除 en-US 格式之外的任何格式导出的，则这些代码也会受到影响。由于数据库中的所有值都应为二进制格式，因此只要数据库不将日期作为字符串存储且不执行不使用二进制格式的操作，数据库访问就不会受到影响。另外，如果使用 Excel 中的数据构造 SQL 查询，则可能需要根据使用的函数来确保数据为 en-US 格式。