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