我有一个包含许多模块的国际化项目。每个模块都有自己的一组 bundle :
- database-module
+ com_naugler_project_database.properties
+ com_naugler_project_database_fr.properties
- mapping-module
+ com_naugler_project_mapping.properties
+ com_naugler_project_mapping_fr.properties
但是，许多国际化术语都是多余的(例如“确定”或“取消”)，我希望将这些术语放在一处，以便于维护和开发。
我找到了this helpful explanation ResourceBundle 继承，但似乎(不是？)共同祖先无法正确国际化，因为:
- common-module
+ com_naugler_project.properties
+ com_naugler_project_fr.properties <-- this is not an ancestor
- database-module
+ com_naugler_project_database.properties
+ com_naugler_project_database_fr.properties <-- of this
我的捆绑组织是否偏离了基地？提供共同的国际化祖先的正确方法是什么？
最佳答案
您想要的似乎是资源的层次结构，也就是说，您可能希望从 over 派生一个类(或者由某些特定部分和某些公共(public)部分组成)。
基本上，ResourceBundle 并不是为此而设计的，您只能靠自己了。
但我想你需要一些建议。
确保常用术语确实常见。也就是说，“确定”、“取消”、“下一步 >”、“< 上一步”、“打开”、"file"等在其上下文中将有常见的翻译。我的意思是，仅翻译此类标准项目一次是相当安全的，但如果您想在不同的上下文中使用它们，您仍然需要另一个条目。为什么？因为在很多语言中，“打开”按钮翻译与“打开”对话框标题翻译不同。
将所有 .properties 文件移动到一个位置(例如名为“resources”的目录)。当然，特定于模块的文件应该分开到不同的子目录中......
- 创建一个资源工厂，它将返回 ResourceBundle 类的实例(或您自己的 Facade - 这种方法实际上可以让您共享一些常见的包)。
大型应用程序的良好做法是创建一些语言包，即将语言资源分离到它们自己的目录中(即/resources/en、/resources/fr、/resources/zh-Hans)。然而，这种方法的问题在于，您需要自己实现资源回退(借助您在问题中提到的文章，层次结构实际上是资源加载层次结构)。这意味着一些特殊情况，例如从语言标签“nb”回退到“no”，但不从“nn”回退；从“zh-CN”和“zh-SG”回落到“zh-Hans”，然后回落到“zh”，但从“zh-HK”和“zh-TW”和“zh-MO”回落到“zh” -Hant”，然后到您的默认语言，而不是从“pt-BR”下降到“pt”(而是回退到默认语言)。
看起来工作量很大？嗯，但是之后的维护工作会很少。
有一件事可能会派上用场 PropertyResourceBundle有两个构造函数，可以让您加载所需的任何属性文件，即: PropertyResourceBundle(InputStream stream)和 PropertyResourceBundle(Reader reader) 。老实说，在大型项目中标准的ResourceBundle机制有太多限制，所以你确实需要自己的资源访问层......
关于java - 正确的 java.util.ResourceBundle 组织，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11416375/