2

在 ASP.NET 中，可以使用资源文件对应用程序进行本地化。资源文件包含不同的翻译。例如，可能有一个英文资源文件和一个西班牙文资源文件。使用资源文件时，可以将属性应用于网页上的控件，以使用资源文件中的值自动填充该控件。或者，可以以编程方式从资源文件加载这些值并将其分配给控件的属性。

ASP.NET 使用后备机制来加载翻译。它试图找到与当前用户文化最相似的资源文件。如果当前用户的文化是西班牙语，ASP.NET 会尝试从西班牙语资源文件加载适当的资源。如果西班牙语资源不可用，它将回退到默认资源文件。由于这种行为，西班牙用户的文本可能会以默认语言显示，原因有两个：

  1. 没有西班牙语翻译。（翻译人员尚未提供此项目的翻译。）
  2. 文本未本地化。（这可能是页面中出现纯文本或消息在某处被硬编码的结果。）

如果文本以默认语言显示，我想知道是因为原因 1 还是因为原因 2。

对于每个丢失的翻译，我可以在资源文件中插入某种占位符文本。但是，这意味着我正在抛弃回退机制。更糟糕的是，如果占位符文本意外进入生产环境，它看起来比显示默认文本要糟糕得多。

有没有人有任何建议（或解决方案）来确定这两个条件中的哪一个是在手动测试期间出现默认文本的原因？

4

1 回答 1

2

如果我对您的理解正确，您想验证每个可本地化的文本确实是可本地化的，并且没有在代码中烧毁。为此，您不应使用真正的文化（西班牙语），而应为虚假的不受支持的文化创建资源，并为默认资源中可用的每个可本地化资源条目提供自动翻译。

例如，如果您有一个默认资源，其中包含：

  • 条目1：这是一个测试！

你应该在你的虚假文化中创建一个资源，其中包含：

  • 条目 1：Th1s 1s @ t€st！

您甚至可以（并且应该）使用简单的字符映射自动创建假资源。这样，当您将应用程序设置为使用自定义的假文化时，您就知道每个条目都有翻译，因此您可以找到硬编码文本。此策略由 Windows 使用，称为pseudo-locales。使用伪翻译字符串可以使用假文化进行开发，因为文本仍然是可读的，这提高了您找到硬编码文本的可能性。

自 Windows Vista 和 Windows 2008 R2 起，Windows 就支持伪语言环境，因此如果您的构建和测试环境使用这些操作系统，您可以将您的假文化与这些伪语言环境之一相关联（例如qps-ploc）。如果您有不受支持的操作系统，只需将您的虚假资源与您可能永远不会支持的真实文化相关联，或者只是创建自己的文化。

另请注意，即使在受支持的操作系统中，Visual Studio 也不会为这些伪语言环境创建附属程序集，除非您在注册表中启用它们。

于 2012-08-24T20:55:16.383 回答