在 ASP.NET 中，可以使用资源文件本地化应用程序。资源文件包含不同的翻译。例如，可能有一个英语资源文件和一个西类牙语资源文件。使用资源文件时，可以将属性应用于网页上的控件，以使用资源文件中的值自动填充该控件。或者，可以通过编程方式从资源文件加载这些值并将其分配给控件的属性。
ASP.NET 使用回退机制来加载翻译。它试图找到与当前用户的文化最相似的资源文件。如果当前用户的区域性是西类牙语，则 ASP.NET 会尝试从西类牙语资源文件加载适当的资源。如果西类牙语资源不可用，则会回退到默认资源文件。由于此行为，西类牙语用户的文本可能会以默认语言显示，原因有两个:
- 没有西类牙语翻译。 (译者尚未提供该项目的翻译。)
- 文本未本地化。 (这可能是页面中出现纯文本或消息在某处被硬编码的结果。)
如果文本以默认语言显示，我想知道是由于原因 1 还是由于原因 2。
对于每个缺失的翻译，我可以在资源文件中插入某种占位符文本。然而，这意味着我要放弃后备机制。更糟糕的是，如果占位符文本意外地进入生产环境，它看起来比显示默认文本要糟糕得多。
是否有人有任何建议(或解决方案)来确定这两个条件中的哪一个是手动测试期间出现默认文本的原因？
最佳答案
如果我理解正确的话，您想要验证每个可本地化的文本实际上确实是可本地化的，并且没有被烧录在代码中。为此，您不应使用真正的区域性(西类牙语)，而应为虚假的不受支持的区域性创建资源，并为默认资源中可用的每个可本地化资源条目提供自动翻译。
例如，如果您有一个默认资源包含:
- 条目1:这是一个测试!
您应该在您的虚假文化中创建一个资源，其中包含:
- 条目1:Th1s 1s @ t€st!
您甚至可以(并且应该)使用简单的字符映射自动执行虚假资源的创建。这样，当您将应用程序设置为使用自定义的假文化时，您就知道每个条目都有翻译，因此您可以找到编码文本。 此策略由 Windows 使用，称为 pseudo-locales 。使用伪翻译字符串可以使用假区域性进行开发，因为文本仍然可读，并且这提高了找到硬编码文本的概率。
Windows 自 Windows Vista 和 Windows 2008 R2 起支持伪区域设置，因此，如果您的构建和测试环境使用这些操作系统，您可以将您的虚假区域性与这些伪区域设置之一关联起来(例如 qps-ploc)。如果您的操作系统不受支持，只需将您的虚假资源与您可能永远不会支持的真实文化相关联，或者只是创建自己的文化。
另请注意，即使在受支持的操作系统中，Visual Studio 也不会为这些伪区域设置创建附属程序集，除非您enable them on the registry .
关于c# - 识别未本地化的文本，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11927671/