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

Jak*_*rds 7 vb.net resources localization embedded-resource

最近我正在深入研究.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)
Run Code Online (Sandbox Code Playgroud)

使用当前的UI文化(例如,德语)设置

My.Application.ChangeUICulture("de")
Run Code Online (Sandbox Code Playgroud)

原始问题

除非resSet.GetString("密钥"),在明确定义appstrings.de.resx,它会返回一个空字符串.无论如何,我可以让它回溯appstrings.resx(其中"Key"确实存在),我认为这将是默认基线?

更新

Rhapsody在下面提出了一个建议,而实际的提示本身并不起作用,事实上它确实引发了一个有趣的点,使用resManager.GetString("Key")而不是resSet.GetString("Key").到目前为止,这似乎没有任何缺陷.也就是说,返回专用语言文件中存在的值,而当通过单个键访问时,"缺失"值会回退到默认文化.

后续问题

唯一剩下的问题是使用ResourceManger而不是缓存的ResourceSet对性能的影响是否会有害?

Mos*_*iur 5

您可以尝试为应用程序声明默认文化,如下所示

[assembly: NeutralResourcesLanguageAttribute("en-US", UltimateResourceFallbackLocation.Satellite)]
Run Code Online (Sandbox Code Playgroud)

此代码声明您的默认文化为 en-US。在您的示例中,如果当前文化是“de-DE”,它会在“de-DE”中查找资源,然后查找父“de”文化等等,最终转到定义的文化(en-US)资源文件. 见 MSDNresourceManage 的回退策略,。上面的代码通常在 assenblyInfo.cs 中。第二个参数告诉资源管理器主程序集或卫星中的资源在哪里。

不幸的是,在此解决方案中,您必须使用文化名称,而不是资源文件名。但是,您可以扩展 RM 以通过文件名使用特定资源,但是选择默认文化并将资源文件重命名为该文化的方法更简单,并且您拥有开箱即用的解决方案。


Rha*_*ody 2

尝试

Public Function GetString(ByVal Name As String) As String
    Return My.Resources.Strings.ResourceManager.GetString(Name)
End Function
Run Code Online (Sandbox Code Playgroud)

Strings项目中 resx 文件的名称在哪里。当基线值不适用于当前区域性时,这将自动返回基线值。

这是一个简单的例子,你可能想让它更加简单。