On 2/25/2015 12:31 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Michael Gerber" <gerbermichi(a)me.com>
> To: "Bill Burke" <bburke(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, February 24, 2015 7:48:56 PM
> Subject: Re: [keycloak-dev] Email Internationalization
>
> Thats written in the jira:
>
> Our built-in themes should strive to only require internationalized message
> bundles and when absolutely required stylesheet overrides (for example for
> right-to-left languages). However, themes should support internationalized:
> • Message bundles
> • Stylesheets
> • Templates
> If internationalization is required for images this should by specifying
> different images either through stylesheets or templates.
>
> So you suggest that every file is overridable by a locale?
I'm not sure we need to support this for templates, stylesheets and images. It could
actually be quite bad practice. There's a lot of logic in templates, so maintaining
multiple versions of the same template would be annoying and could easily introduce bugs
and exploits. Another approach is to avoid text in images and do all translations in
messages. If the locale is made available to the template itself anyone that needs to do
some locale specific things in the template can do that within a single template with
conditions. We should definitively not use multiple templates ourselves. We may need to
support it for others, but I suggest we don't initially and see if anyone really needs
it.
With regards to emails they are simpler now, but we also want to support multi-part (text
and html), where the html template would contain other things than just the text. I
suggest we extract the text into a single message. We should then add support to resolve
variables within messages (for example "resetPasswordEmail=Hello ${user.firstName}
...").
Makes it a lot simpler to deal with translations if it's all done within messages.
Usually devs are not language experts and this would make it easy for non-devs to provide
translations.
Support overriding anything in locales. Make each locale a nested theme
or something like that. IMO, that the additional flexibility will prove
useful to us and users when something unforeseen comes up in the future.
A perfect example of wanting to extend a template is if you wanted to
add data that is specific only to the locale. For example,
sso.company.com profile page might have a "favorite baseball team",
while sso.company.com.uk might have "favorite cricket team".
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com