Java类型的i18n（java）

Question

我想知道是否有可能（以及使用哪种工具）在Java中进行typesafe i18n。 也许不清楚，所以这里有一些细节，假设我们使用基于MessageFormat东西

1）使用类型安全参数进行翻译

我想避免使用像String translate(Object key,Object... values)这样的接口String translate(Object key,Object... values)其中的值是无类型的。 用错误的参数类型调用应该是不可能的。

注意，我可以指定所有键的类型。 我正在寻找的解决方案应该是可扩展的，并且不应显着增加后端启动时间。

2）在编译时应该知道哪些键仍在使用

我不希望我的翻译密钥像许多网站的CSS一样，永远增长，并且每个人都害怕删除密钥，因为我们不容易知道它们是否仍然有用。

在JS / React领域中，有babel-plugin-react-intl ，它允许在编译时提取仍在代码中找到的转换键。 然后，我们可以将这些密钥与翻译后端/ SaaS进行比较，并自动删除未使用的密钥。 在Java领域中，有没有什么接近这种体验的？

---

我在找：

• 关于这两个问题，您有任何可以使i18n在Java中更易于管理的技巧
• 当前的工具可能会帮助我解决问题
• 有关在不存在工具的情况下如何实现自定义的提示

另外，Enum是否适合存储庞大的固定翻译键列表？

Answer 1

转换键是一个开放式域。 对于封闭域，可以使用枚举。

具有枚举或常量列表之类的内容可能会导致不同的枚举，常量类的增长。

然后是翻译业务的一个非常重要的角度：您需要至少一个词汇表 （不需要翻译），结构上相等的短语进行分组，注释可能包含歧义的术语和用法（按钮/菜单）。 这样可以减少时间成本并提高质量。 还有诸如在线帮助之类的东西。

到目前为止，XML就像简单的docbook /翻译记忆库（tmx / xliff / ...）一样，已经足够了。 包括不同形式的评估在内的工具都是我们自己完成的。

我希望会给出更专业的答案，但我的答案可能会为所需的功能提供一些启示：

• 以翻译为中心：这需要最多的工作。
• 版本控制：涉及一些文本列表。
• 检查工具：您提到的内容，完整性，缺失，几乎相等。