Office 解决方案的全球化和本地化
全球化和本地化 Microsoft Office 解决方案过程中所遇到的大多数问题与您使用 Visual Studio 创建其他各种解决方案时遇到的问题相同。 有关常规信息，请参见对应用程序进行全球化和本地化。 在 MSDN 网页使用 Microsoft Visual Studio Tools for the Microsoft Office System 创建的解决方案的全球化和本地化问题上也提供了全球化和本地化信息。
**适用于：**本主题中的信息适用于 Microsoft Office 2010 和 2007 Microsoft Office system 的文档级项目和应用程序级项目。有关更多信息，请参见按 Office 应用程序和项目类型提供的功能。
本地化文档文本
项目中的文档、模板或工作簿中可能包含静态文本，静态文本必须与程序集及其他托管资源分开进行本地化。 完成此任务的一个直接的方法是，创建文档的副本，然后使用 Microsoft Office Word 或 Microsoft Office Excel 对文本进行翻译。 即使您不对代码做任何更改，此过程仍然有效，因为任意数量的文档都可以链接到同一程序集。
您还必须确保与文档文本进行交互的任何代码部分都要与文本的语言保持匹配，并确保书签、命名范围以及其他显示字段能够适应根据不同的语法和文本长度的需要对 Office 文档重新调整的格式设置。 对于包含相对较少文本的文档模板，可以考虑在资源文件中存储文本，然后在运行时加载该文本。
文本方向
在 Excel 中，可以设置工作表的属性，以从右向左呈现文本。 放在设计器上的宿主控件或任何具有 RightToLeft 属性的控件将在运行时自动匹配这些设置。 Word 没有针对双向文本的文档设置（您只能更改文本的对齐方式），因此这些控件不能映射到此设置。 但您必须为每个控件设置文本对齐方式。 可以编写代码遍历所有控件，强制这些控件从右向左呈现文本。
更改区域性
文档级自定义代码通常共享 Word 或 Excel 的 UI 主线程，因此对线程区域性所做的任何更改都会影响该线程上运行的其他内容；该更改不仅限于自定义。
Windows 窗体控件在宿主应用程序启动应用程序级外接程序之前进行初始化。 在这些情况下，应在设置 UI 控件之前更改区域性。
安装语言包
如果 Windows 具有非英语设置，则可安装 Visual Studio Tools for Office Runtime语言包来以 Windows 使用的语言查看 Visual Studio Tools for Office Runtime消息。 如果有最终用户在 Windows 非英语设置下运行解决方案，则必须安装相应的语言包才能以 Windows 使用的语言来查看运行时消息。Visual Studio Tools for Office Runtime 语言包可从 Microsoft 下载中心 获取。
此外，可再发行的 .NET Framework 语言包对于 ClickOnce 消息是必需的。 .NET Framework 语言包可从 Microsoft 下载中心获得。
区域设置和 Excel COM 调用
每当托管客户端对 COM 对象调用一个方法并且需要传入特定于区域性的信息时，它都使用与当前线程区域设置匹配的 CurrentCulture（区域设置）来执行这些操作。 默认情况下，当前线程区域设置是从用户的区域设置继承而来的。 但是，当您从使用 Visual Studio 中的 Office 开发工具创建的 Excel 解决方案中调用 Excel 对象模型时，会自动将英语（美国）数据格式（区域设置 ID 1033）传递到 Excel 对象模型。 在将数据传递到 Microsoft Office Excel 或从项目代码中读取数据之前，必须使用英语（美国）数据格式对具有区分区域设置格式的所有数据（如日期和货币）进行格式设置。 有关更多信息，请参见 使用各种区域设置对 Excel 中的数据进行格式设置。
存储数据的注意事项
为确保正确解释和显示数据，还应考虑到应用程序在字符串（硬编码）而不是强类型的对象中存储数据（包括 Excel 工作表公式）时可能会出现的问题。 应使用采用区域性固定的或英语（美国）（LCID 值为 1033）样式进行格式设置的数据。
使用字符串的应用程序
可硬编码的可能值包括用英语（美国）格式编写的日期文本，以及包含本地化函数名的 Excel 工作表公式。 还可能是包含数字（如“1,000”）的硬编码字符串；在某些区域性中，“1,000”被解释为一千，而在另一些区域性中它表示一点零。 根据错误的格式执行计算和比较会导致不正确的数据。
Excel 根据随字符串传递的 LCID 解释所有字符串。 如果字符串的格式与传递的 LCID 不对应，则会出现问题。 使用 Visual Studio 中的 Office 开发工具创建的 Excel 解决方案在传递所有数据时都使用 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 中的 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 格式。