Hi,
JMeter uses messages.properties as a ResourceBundle.
Then there's resources.PackageTest which has three types of tests:
1) testLang. It cross-checks if "language-specific" file like
messages_fr.properties has extra properties when compared with etalon
messages.properties
2) checkI18n which ensures all the translations are available in French
3) checkResourceReferences. It parses source java files and looks for
getResString("...") kind of patterns. The test there is to check if the key
looks sane (e.g. no spaces allowed), and it ensures that resource is
present.
Items #1 and #2 are trivial (those are just a cross-check of the
*.properties) files in "core" module.
The item #3 is more complicated as messages*.properties are located in
"core" module while the source code is scattered all over the place.
While I can duplicate "check resources" test in each module, however does
sound odd.
We store text-based keys, and we invent complicated checks to check
validity of the keys.
We have a strongly typed language, why don't we use types?
At the end of the day, "property keys" are like public API. We can't really
rename or remove the keys.
For instance, we could create Messages interface with relevant methods and
arguments.
Then it would be impossible to call "missing" method.
That approach is used in Calcite to specify exception messages:
https://github.com/julianhyde/hydromatic-resource
Resource interface:
https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/java/org/apache/calcite/runtime/CalciteResource.java
Properties file:
https://github.com/apache/calcite/blob/7c905ff3263bcc6cec826789305f1be9fba0962e/core/src/main/resources/org/apache/calcite/runtime/CalciteResource.properties
Any thoughts?
Vladimir
