Locale - 仅用于国际化？
我需要类似语言环境的功能，用于国际化以外的目的。
例如，我想使用资源包机制，并为不同的定制提供不同的资源包，例如客户端 A 的一个文件，客户端 B 的另一个文件和另一个默认文件（对于特定中不存在的值）客户的文件）。唯一的方法是“强制”每个客户端的区域设置，但我不想这样做。
对于这种事情有不同的结构吗？
I need a locale-like functionality, for purposes other than internationalization.
For example, I'd like to use the resource-bundle mechanism and have different resource bundles for different customization, e.g. one file for client A, another file for client B and another default file (for values that don't exist in the specific client's file). The only way to do it would be "forcing" a locale for each client, and I don't want to do that.
Is there a different structure for this kind of things?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我看不出有什么理由不能在简单的情况下将定制作为本地化来处理。区域设置最终是对用户偏好的描述。它主要基于语言和可能的国家的原因只是因为这些是最常见的事情，往往会导致可以在软件中处理的差异。
大多数使用这些的语言环境标识符系统都有某种方式通过某种扩展机制来呈现“变体”。在 ResourceBundle 中，这似乎是“variant”参数。
主要问题是，语言环境系统是原始的，因为它们假定是分层系统而不是正交系统。也就是说，您可以为英语、美国、公司 A 定义 en-US-xA 的语言环境（以使用 BCP 47 语言环境 id），但如果您需要为 A 的员工（喜欢加拿大法语）定义语言环境，则必须为 fr -CA-xA，为此您需要复制 A 特定的设置。
因此，我得出的结论是，至少如果您不需要正常意义上的本地化（不同语言、不同国家/地区），那么使用语言环境进行自定义是可以的。
I don’t see any reason why you could not deal with customization as kind of localization in a simple case. A locale is ultimately a description of user preferences. The reason why it is mostly based on language and possibly country is just that these are the most common things that tend to cause differences that can be handled in software.
Most systems of locale identifiers used these have some way of presenting “variants” with some extension mechanism. In ResourceBundle, this appears to be the “variant” argument.
The main problem is that the systems of locales are primitive in the sense that they presume a hierarchic system rather than orthogonal. That is, you could define a locale for en-US-x-A (to use BCP 47 locale ids) for English, US, company A, but if you need a locale for employees of A preferring Canadian French, it would have to be fr-CA-x-A, and for this you would need to copy the A-specific settings.
So I would conclude that using locales for customization is OK at least if you do not need localization in the normal sense (different languages, different countries).