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 / ...）一樣，已經足夠了。 包括不同形式的評估在內的工具都是我們自己完成的。

我希望會給出更專業的答案，但我的答案可能會為所需的功能提供一些啟示：

• 以翻譯為中心：這需要最多的工作。
• 版本控制：涉及一些文本列表。
• 檢查工具：您提到的內容，完整性，缺失，幾乎相等。