在 ASP.NET 中，可以使用资源文件对应用程序进行本地化。资源文件包含不同的翻译。例如，可能有一个英语资源文件和一个西班牙语资源文件。使用资源文件时，可以将属性应用于网页上的控件，以使用资源文件中的值自动填充该控件。或者，可以通过编程方式从资源文件加载这些值，并将其分配给控件的属性。
ASP.NET 使用回退机制来加载翻译。它尝试查找与当前用户的区域性最相似的资源文件。如果当前用户的区域性是西班牙语，ASP.NET 尝试从西班牙语资源文件加载相应的资源。如果西班牙语资源不可用，它将回退到默认资源文件。由于此行为，西班牙语用户的文本可能会以默认语言显示，原因有两个：
- 没有西班牙语翻译可用。（翻译人员尚未提供此项目的翻译。
- 文本未本地化。（这可能是由于页面中出现纯文本或邮件在某处被硬编码的结果。
如果文本以默认语言显示，我想知道是因为原因 1 还是因为原因 2。
对于每个缺少的翻译，我可以在资源文件中插入某种占位符文本。但是，这意味着我正在丢弃回退机制。更糟糕的是，如果占位符文本意外进入生产环境，它看起来比显示默认文本要糟糕得多。
有没有人有任何建议（或解决方案）来确定这两个条件中的哪一个是手动测试期间出现默认文本的原因？
如果我理解正确，您想验证每个可本地化的文本确实是可本地化的，而不是在代码中刻录的。为此，您不应该使用真正的区域性（西班牙语），而应该为虚假的不受支持的区域性创建资源，并为默认资源中可用的每个可本地化资源条目提供自动翻译。
例如，如果您有一个默认资源，其中包含：
- 入口1：这是一个测试！
您应该在虚假文化中创建包含以下内容的资源：
- 条目 1： Th1s 1s @ t€st！
您甚至可以（并且应该）使用简单的字符映射自动执行假资源的创建。这样，当您将应用程序设置为使用自定义的假区域性时，您就知道每个条目都有翻译，因此您可以找到编码文本。此策略由 Windows 使用，称为伪区域设置。使用伪翻译字符串可以使用假区域性进行开发，因为文本仍然是可读的，这提高了找到硬编码文本的可能性。
自 Windows Vista 和 Windows2008 R2 以来，Windows 支持伪区域设置，因此，如果您的生成和测试环境使用这些操作系统，则可以将虚假区域性与这些伪区域设置之一相关联（例如 qps-ploc ）。如果您有不受支持的操作系统，只需将您的虚假资源与您可能永远不会支持的真实文化相关联，或者只是创建自己的文化。
另请注意，即使在受支持的操作系统中，Visual Studio 也不会为这些伪区域设置创建附属程序集，除非您在注册表上启用它们。