最近我正在研究 .NET 的本地化。本质上,我学会了如何自定义表单(使用语言和可本地化属性),然后相应地更改文化。
但是,我发现当将我的硬编码英文字符串迁移到自动生成的资源文件中并使用 .GetString("Key") 时——好吧,我们只是说它不太高兴:P。
我决定制作一组单独的 resx 文件,专门用于硬编码字符串翻译。他们遵循 [name].[culture-code].resx 的约定/要求。我为每种相关语言制作了这些;例如appstrings.de.resx(德语)和 appstrings.resx(作为不 rebase 线)。
为了利用这些新资源,我创建了 ResourceManager 和资源集的实例
Dim resManager As New ResourceManager("LanguageTest.appstrings", Assembly.GetExecutingAssembly)
Dim resSet As ResourceSet = resManager.GetResourceSet(My.Application.UICulture, True, True)
当前 UI 区域性已使用设置(例如德语)
My.Application.ChangeUICulture("de")
<小时/>
原始问题
除非在 appstrings.de.resx 中显式定义 resSet.GetString("Key"),否则它将返回空字符串。无论如何,我是否可以将其回退到 appstrings.resx (其中“Key”确实存在),我认为这是默认基线?
更新
Rhapsody 在下面提出了一个建议,虽然实际的提示本身不起作用,但它实际上引发了一个有趣的观点,使用 resManager.GetString("Key") 而不是 resSet.GetString("Key")。到目前为止,这似乎没有任何缺陷。也就是说,返回专用语言文件中存在的值,而当通过单个键访问时,“缺失”值会回退到默认区域性。
后续问题
唯一剩下的问题是使用 ResourceManger 相对于缓存的 ResourceSet 的性能影响是否会那么有害?
最佳答案
您可以尝试为应用程序声明默认文化,如下所示
[assembly: NeutralResourcesLanguageAttribute("en-US", UltimateResourceFallbackLocation.Satellite)]
此代码声明您的默认区域性是 en-US。在您的示例中,如果当前区域性是“de-DE”,它将在“de-DE”中查找资源,然后查找父级“de”区域性,依此类推,最终转到定义的区域性(en-US)资源文件。 see MSDN通过resourceManage 获取后备策略。 上面的代码通常位于 assenblyInfo.cs 中。第二个参数告诉资源管理器资源位于主程序集或卫星中的位置。
不幸的是,在此解决方案中,您必须使用区域性名称,而不是资源文件名。但是,您可以扩展 RM 以通过文件名使用特定资源,但选择默认区域性并将资源文件重命名为该区域性更简单,您就拥有了开箱即用的解决方案。
关于vb.net - 本地化.NET;使用 ResourceManager 时的后备语言,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2272744/