i18n only working when rest-default-messages.properties is available

[toedter]

in RC2 i18n of rest messages is only working if the file rest-default-messages.properties is available. Before it was enough to specify rest-messages.properties for the default and for example rest-messages_de.properties for German translations.

[toedter]

An example project is here: https://github.com/toedter/movies-demo
The resource bundles are in: https://github.com/toedter/movies-demo/tree/master/backend/src/main/resources

[odrotbohm]

I can't really reproduce this and also looking at the configuration code in HATEOAS I don't see why this should be the case. We only register no MessageResolver at all if both the lookup for the default messages and the rest-messages resource bundle fails.

Would be cool if you could add a couple of instructions how to reproduce the error using your example.

[toedter]

On my machine I can reproduce this with the following steps, tested with spring-hateoas-1.0.0.BUILD-SNAPSHOT.jar of 21.09.2019 with AdoptOpenJDK\jdk-11.0.4.11-hotspot on Windows 10

• git clone https://github.com/toedter/movies-demo.git

• cd movies-demo

• gradlew build bootrun

• load http://localhost:8080/api/movies in browser
  => i18n works (e.g. _templates.default.title is "Create Movie")

• rename backend/src/main/resources/rest-default-messages.properties to
  rest-messages.properties

• gradlew build bootrun

• load http://localhost:8080/api/movies in browser
  => i18n does not work (e.g. _templates.default.title does not exist)

[odrotbohm]

Okay, looks like the issue was subtly broken in a slightly different way: the resource bundles we configured was only named rest-messages which would result in the lookup of a servlet resource, not a classpath one. We didn't catch that issue as our tests were always mocking the resource lookup to return a file on the classpath.

If we properly configure the basename to classpath:rest-messages, it works as expected. This also fixes your example in the way that you now see "Erzeuge Film" (i.e. the German translation) as it should be.

Fix coming in a second.

[odrotbohm]

"Properly" in the previous comment was a bit exaggerating. The prefix is not needed usually but it seems that Boot's setup of the ResourceLoader does not use the classpatrh lookup as default unless you explicitly add the prefix. That makes it a bit hard to test as the test we have in place also succeeds without it. Still investigating with the Boot team on how to improve on that but the gist is: it should work now.