[keycloak-dev] Internationalization for model data

[Michael Gerber]

The definition in the message property file should be like this.
invalidPassword.minlength.message=Invalid password: must contain at least {0}

The current password validation for example returns messages like this:
return count < min ? "Invalid password: must contain at least " + min + " numerical digits" : null;

I can't replace this with a single key, because of the variable min.

However, I can replace the return type with an object which contains the message key and their parameters or a string lilke ${invalidPassword.minlength.message:min} or something similar.
I think there are other places where we need a possibility to internationalize a message with variables.

Am 26. Februar 2015 um 07:17 schrieb Stian Thorgersen <stian at redhat.com>:

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150226/c7a57324/attachment.html