Found while following the skill on a Jmix 2.8.2 project.
Problem: silent — the instructions say nothing about this case.
Task
An application for a non-English-speaking organization; every own message written in the target language from the start.
Where
jmix-add-i18n-keys, the "Exact Reference Audit" section. It checks exactly one thing: that every msg:// resolves to a bundle key, case-sensitively. Nothing about the LANGUAGE of the value.
What happened
The project template ships messages_<lang>.properties with ENGLISH values:
com.company.app.entity/User=User
com.company.app.entity/User.firstName=First name
com.company.app.view.login/loginForm.username=Username
com.company.app.view.main/MainView.title=App
com.company.app/menu.application.title=Application
The file is named for the target locale, every key resolves, and the skill's audit passes. Meanwhile the menu section reads "Application", the user list reads "Users", and the login form is in English. Own entities (Order, Invoice) are translated because I wrote them; the seed keys are untouched because the skill says to verify that a key EXISTS, not what it says.
It survived to the very end of the work. Caught by the project owner, visually, from a screenshot of the menu. No gate catches it: clean compile, green clean test, views render, every msg:// resolves.
Suggested fix
Add a second pass to "Exact Reference Audit": when jmix.core.available-locales does not include en, read the whole messages_<lang> file for values left over from the template. A cheap heuristic worth printing in the skill — values made only of Latin characters inside a non-Latin locale file:
grep -nP '^[^#=]+=[\x00-\x7F]+$' src/main/resources/**/messages_<lang>.properties
It also catches MainView.title=App, which is usually left in place because it looks like a product name rather than an untranslated string.
Found while following the skill on a Jmix 2.8.2 project.
Problem: silent — the instructions say nothing about this case.
Task
An application for a non-English-speaking organization; every own message written in the target language from the start.
Where
jmix-add-i18n-keys, the "Exact Reference Audit" section. It checks exactly one thing: that everymsg://resolves to a bundle key, case-sensitively. Nothing about the LANGUAGE of the value.What happened
The project template ships
messages_<lang>.propertieswith ENGLISH values:The file is named for the target locale, every key resolves, and the skill's audit passes. Meanwhile the menu section reads "Application", the user list reads "Users", and the login form is in English. Own entities (
Order,Invoice) are translated because I wrote them; the seed keys are untouched because the skill says to verify that a key EXISTS, not what it says.It survived to the very end of the work. Caught by the project owner, visually, from a screenshot of the menu. No gate catches it: clean compile, green
clean test, views render, everymsg://resolves.Suggested fix
Add a second pass to "Exact Reference Audit": when
jmix.core.available-localesdoes not includeen, read the wholemessages_<lang>file for values left over from the template. A cheap heuristic worth printing in the skill — values made only of Latin characters inside a non-Latin locale file:It also catches
MainView.title=App, which is usually left in place because it looks like a product name rather than an untranslated string.