On Wed, 6 Mar 2019 at 20:34, Vladimir Sitnikov
<[email protected]> wrote:
>
> 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
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.
Keys can be removed if code is refactored or dropped.
> 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?
How does it work with other languages?
> Vladimir
