我有一个包含多个模块的国际化项目。每个模块都有自己的捆绑包集：
- 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
但是，许多国际化术语是多余的（例如“确定”或“取消”），我希望将这些术语放在一个地方以便于维护和开发。
我找到了有关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
我的捆绑软件组织是否可以脱离基础？提供共同的国际化祖先的正确方法是什么？
您想要的似乎是资源的层次结构，也就是说，您可能希望从一个类派生一个类（或由某个特定部分和某个公共部分组成）。
基本上，ResourceBundle并不是为此而设计的，而您是一个人。
但是，我想您需要一些建议。
确保通用术语 确实很 通用。也就是说，“确定”，“取消”，“下一个>”，“ <下一个”，“打开”，“文件”等在其上下文中将具有通用翻译。我的意思是只翻译一次这样的标准项目是相当安全的，但是如果您想在不同的上下文中使用它们，则仍然需要另一个条目。为什么？因为“打开”按钮翻译在许多种语言中与“打开”对话框标题翻译不同。
将所有.properties文件移动到一个位置（例如，一个名为“ resources”的目录）。当然，特定于模块的文件应分开到不同的子目录…
似乎需要很多工作？好吧，但是之后的维护工作将很少。
可能有用的一件事PropertyResourceBundle有两个构造函数，可让您加载所需的任何属性文件，即：PropertyResourceBundle（InputStream stream）和PropertyResourceBundle（Reader reader）。老实说，在大型项目中，标准的ResourceBundle机制存在太多限制，因此您确实需要自己的资源访问层…
