[keycloak-dev] Loading message bundles from themes

[Stan Silvert]

On 9/3/2015 1:08 PM, Stian Thorgersen wrote:
>
> ----- 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
I'll ping you in the morning about this.  It looks like the Theme API 
probably needs a separate method for Angular bundles. Otherwise, we'll 
have Java messages  mixed with Angular messages.

>
>> 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.
>>