Java 类型化 i18n (java)

Question

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

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

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

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

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

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

在 JS/React 领域有 babel-plugin-react-intl 允许在编译时提取仍然在代码中找到的翻译键。然后我们可以使用我们的翻译后端/SaaS 来区分这些密钥，并自动删除未使用的密钥。在 Java 领域有什么类似的经历吗？

---

我正在寻找：

• 任何可以让 i18n 在 Java 中更易于管理的技巧来解决我遇到的这 2 个问题
• 当前可能帮助我解决问题的工具
• 提示在不存在工具的情况下如何实现自定义功能

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

Answer 1

翻译键是一个以开放结尾的域。对于 封闭 域，枚举可以做到。

拥有诸如枚举或常量列表之类的东西可能会导致不同枚举、常量类的增长。

然后是翻译业务的一个非常重要的视角： 你会想要至少一个 glossary（不需要翻译出现），结构上相同的短语分组， cmets 可能有矛盾的术语和用法（按钮/菜单）。这可以减少 时间成本和提高质量。还有诸如在线帮助之类的东西。

到目前为止，XML 就像简单的文档/翻译记忆库 (tmx/xliff/...) 已经足够了。和工具 包括不同形式的评估都是我们自己完成的。

我希望能给出更专业的答案，但我的回答可能会有所启发 关于所需的功能：

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