[keycloak-dev] Internationalization for model data

[Stian Thorgersen]

I'm concerned that allowing any variable in any message would result in horrible performance. We'd have to use FreeMarker or something else to template each individual message, and it couldn't be cached either as the variables change. Would doing it on a case-by-case basic be enough?

For example:

  invalidPassword.minlength.message=Invalid password: must contain at least {0}

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Michael Gerber" <gerbermichi at me.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 9:30:45 PM
> Subject: Re: [keycloak-dev] Internationalization for model data
> 
> invalidPassword.minlength.message=Invalid password: must contain at
> least ${realm.passwordpolicy.minLength}
> 
> Would need a way to resolve non message property properties.
> 
> On 2/25/2015 2:21 PM, Michael Gerber wrote:
> > How do we want to internationalize messages which contains variables like:
> > „Invalid password: must contain at least „ + min + " upper case characters"
> >
> > ${invalidPassword.minLength} This doesn’t work.
> >
> >
> >> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
> >>
> >> There's data stored in a bunch of places that should be
> >> internationalized.  i.e. Role descriptions.  I was thinking for this
> >> type of stuff, for both simplicity and ease of migration, we still
> >> continue to input this type of metadata through one field.  Then if the
> >> user wants to internationalize a piece of data, they just replace the
> >> text with a property variable.
> >>
> >> Role Description: "Admin access to main application"
> >>
> >> could be replaced with
> >>
> >> Role Description: "${role.admin.description}"
> >>
> >> Then the variable 'role.admin.description' is just replaced with a
> >> theme-based property.
> >>
> >> This way, users dont' have to learn about internationalization until
> >> when and if the need it, existing deployments will still just work, and
> >> we don't have to expand our data model.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev