Re: [keycloak-dev] Loading message bundles from themes

----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak-dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Thursday, 3 September, 2015 6:30:26 PM > Subject: Re: Loading message bundles from themes > > I'm not sure exactly what you mean by "load message bundles from > themes". Show me where this lives and I'll take a look. Theme.getMessages

> Just remember that we can't mix bundles intended for Java and bundles > intended for Angular. Not sure if that's what you are saying. > > On 9/3/2015 9:57 AM, Stian Thorgersen wrote: >> You should load message bundles from themes not directly from the file >> system. That's how login pages and account management loads messages >> bundles so it should be consistent, but more importantly doing it through >> themes gives the following: >> >> * Support for loading from file or classpath - we also have an SPI for >> theme loaders so they can in the future load resources from other sources >> as well, for example the database >> * Supports overriding messages from themes - users can define custom themes >> that are used on a per-realm basis that can override messages. Themes even >> inherit messages from the theme it extends, so can choose to override only >> some messages >> >> Themes expects the message bundle to be named >> "messages_<locale>.properties". I'd prefer it to be consistent between the >> 3 different things we have internationalized and such admin messages >> should be loaded from themes and the message bundles should have the same >> names. >> >> We can then discuss with the translation team if they are happy with 3 >> separate message bundles or if they'd like a single message bundle for >> everything. We can also query about whether or not we can divide the >> message bundles up further. Dividing message bundles up would require >> adding support for that to themes as well. With classloaders and such it >> would be hard to implement a list available bundles so that's another >> reason for going with a single message bundle for now. >