vb.net – 本地化.NET;使用ResourceManager时的后备语言

前端之家收集整理的这篇文章主要介绍了vb.net – 本地化.NET;使用ResourceManager时的后备语言前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
最近我正在深入研究.NET的本地化.基本上,我学习了如何自定义表单(使用Language和Localizable属性),然后相应地更改文化.

但是,我发现在将我的硬编码英文字符串迁移到自动生成的资源文件中时,使用.GetString(“Key”) – 好吧,让我们说它不开心:P.

我决定将一组独立的resx文件专门用于硬编码的字符串翻译.他们遵循[name]的惯例/要求.[culture-code] .resx.我为每种相关语言制作了这些;例如appstrings.de.resx(德语)和appstrings.resx(作为不变基线).

为了利用这些新资源,我创建了一个ResourceManager和Resource Set实例

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对性能的影响是否会有害?

您可以尝试为应用程序声明默认的Culture,如下所示
[assembly: NeutralResourcesLanguageAttribute("en-US",UltimateResourceFallbackLocation.Satellite)]

代码声明您的默认文化是en-US.在您的示例中,如果当前文化是“de-DE”,它在“de-DE”中查找资源,然后查找父“de”文化等等,并且Ultimatly转到定义的文化(en-US)资源文件. see MSDN用于资源管理的后备策略.
上面的代码通常在assenblyInfo.cs中.第二个参数告诉资源管理器位于主程序集或卫星中的资源在哪里.

不幸的是,在此解决方案中,您必须使用区域性名称,而不是资源文件名.但是你可以扩展RM以按文件名使用特定资源,但是它更简单地选择默认文化并将资源文件重命名为该文化,并且你有开箱即用的解决方案.

猜你在找的VB相关文章