Java类型的i18n（java）

Question

I'd like to know if it's possible (and with which tooling) to do typesafe i18n in Java. Maybe it's not clear so here are some details, assuming we use something based on MessageFormat

1) Translate using typesafe parameters

I'd like to avoid having an interface like String translate(Object key,Object... values) where the values are untyped. It should be impossible to call with a bad parameter type.

Note I'm fine specifying the typing of all the keys. The solution I'm looking for should be scalable and should not increase the backend startup time significantly.

2) It should be known at compile time which keys are still used

I don't want my translation keys base to be like many websites' CSS, growing and growing forever and everybody being frightened to remove keys because we don't know easily if they are still useful or not.

In JS/React land there is babel-plugin-react-intl which permit to extract at compile time the translation keys that are still found in the code. Then we can diff these keys with our translation backend/SaaS and delete the unused keys automatically. Is there anything close to that experience in Java land?

---

I'm looking for:

• any trick you have that could make i18n more manageable in Java regarding these 2 problems I have
• current tooling that might help me solve the problem
• hints on how to implement something custom if tooling does not exist

Also, is Enum suitable to store a huge fixed list of translation keys?

Answer 1

Translation keys are an open ended domain. For a closed domain an enum would do.

Having something like enums or constant lists likely causes a growth of different enums, constants classes.

And then there is the very important perspective of the translating business: you would want at least one glossary (not needing translation occurrences), structurally equal phrases grouped, comments maybe on ambivalent terms and usages (button/menu). This can reduce the time costs and improve the quality. There also are things like online-help.

Up till now XML, like simple docbook / translation memory (tmx/xliff/...), was sufficient for that. And the tooling including different forms of evaluation was done ourselves.

I hope a more professional answer will be given, but my answer might shed some light on the desired functionality:

• translation centric: as that needs the most work.
• version control: some text lists involved.
• checking tools: what you mentioned, integrity, missing, almost equal.