更正java.util.ResourceBundle组织 [英] Correct java.util.ResourceBundle Organization
问题描述
我有一个包含许多模块的国际化项目。每个模块都有自己的一组包：
I have an internationalized project with many modules. Each module has its own set of bundles:
- 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
但是，许多国际化条款都是多余的（例如确定或取消），我希望将这些条款放在一个地方，以便于维护和开发。
However, many of the internationalized terms are redundant (such as 'OK' or 'Cancel') and I would like have these terms in one place for easier maintenance and development.
我找到了有关ResourceBundle继承的这个有用的解释，但似乎一个（不是？）共同的祖先不会被正确国际化，因为：
I found this helpful explanation of ResourceBundle inheritance, but it appears as though a (not?) common ancestor would not be internationalized properly because:
- 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
我的捆绑组织是否可以离开基地？提供共同的国际化祖先的正确方法是什么？
Am I way off base with my bundle organization? What is the right way to provide a common internationalized ancestor?
推荐答案
你想要的似乎是资源的层次结构，即，你可能希望一个类派生自（或由一些特定部分和一些常见部分组成）。
What you want seems to be the hierarchy of Resources, that is, you probably want one class to derive from over (or being composed of some specific part and some common part).
基本上，ResourceBundle不是为它设计的，而你是你自己的。
Basically, ResourceBundle was not designed for it, and you are on your own.
但我想你想要一些建议。
But you want some advice, I suppose.
-
确保常见术语 真正 常见。这就是OK，Cancel，Next>，< Previous，Open，File等在其上下文中将具有共同的翻译。我的意思是只翻译一次这样的标准项目是相当安全的，但是如果你想在不同的环境中使用它们，你仍然需要另一个条目。为什么？因为打开按钮翻译与不同语言的打开对话框标题翻译不同。
Make sure that common terms are really common. That is things like "OK", "Cancel", "Next >", "< Previous", "Open", "File", etc. will have common translations in their context. I mean it is fairly safe to translate such standard items only once, but if you want to use them in different context, you still need another entry. Why? Because "Open" button translation would be different than "Open" dialog title translation in quite a few languages.
将所有.properties文件移动到一个位置（例如一个名为resources的目录。当然，模块特定的文件应该分成不同的子目录...
Move all the .properties files to one place (for example a directory called "resources"). Of course module-specific files should be separated to different subdirectories...
- 创建一个资源工厂，它将返回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（而是回到默认语言）。
The good practice for large applications is to create some Language Pack, that is to separate language resources to their own directories (i.e. /resources/en, /resources/fr, /resources/zh-Hans). The problem with this approach, however would be the fact that you would need to implement resource fallback by yourself (with the aid of an article you mention in the question, the hierarchy is actually resource loading hierarchy). That means some special cases like falling back from language tag "nb" to "no" but not falling back from "nn"; falling back from "zh-CN" and "zh-SG" to "zh-Hans" and then to "zh" but falling back from "zh-HK" and "zh-TW" and "zh-MO" to "zh-Hant" and then to your default language, not falling from "pt-BR" to "pt" (falling back to default language instead).
好像很多工作？好吧，但之后的维护工作很少。
Seems like a lot of work? Well, but the maintenance work afterwards would be minimal.
有一件事可能派上用场了 PropertyResourceBundle 有两个构造函数，可以让你加载你想要的任何属性文件，即： PropertyResourceBundle（InputStream stream）和 PropertyResourceBundle（Reader reader）。老实说，在大型项目中，标准的ResourceBundle机制有太多限制，所以你真的需要自己的资源访问层......
One thing might come in handy PropertyResourceBundle have two constructors that will let you load whatever properties file you want, namely: PropertyResourceBundle(InputStream stream) and PropertyResourceBundle(Reader reader). Honestly, in large projects standard ResourceBundle mechanism has too many limitations, so you really need your own resource access layer...
这篇关于更正java.util.ResourceBundle组织的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
