[keycloak-dev] Loading message bundles from themes

[Stian Thorgersen]

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> 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.
> 
>