Localization support for entity fields

[ΚΩΝΣΤΑΝΤΙΝΟΣ ΓΕΩΡΓΙΛΑΚΗΣ]

We are interested in adding support for localized entity fields in Keycloak. This feature has also been discussed in the Keycloak dev group. Specifically, we are referring to “4. Entity-specific (for example display name for a specific client)” part of this discussion. There are other fields, like display name in Identity Provider, that need to support localization. We believe that it is very useful for Keycloak users to see these fields translated, for example in the Identity Provider discovery page (WAYF). The current implementation for client name and description does not support localization without modifying messages properties files. Furthermore, it lacks support for importing/exporting localized information from/to entity metadata. Both SAML and OIDC protocol support fields with multiple  language attributes. The default realm locale could be used if a language translation does not exist.

We would like  to discuss how such an extension could be done. Based on the previous discussion, we are thinking of having a separate table to hold the localization information for every entity field which needs translation. Client and Identity Provider will be the first entities to incorporate this logic. Each table could consist of the following fields:

• id

• clientId/intentityProviderId ( foreign key for entity table)

• field ( field name, same as in the entity table)

• language ( String same values as realm supported locales)

• value ( translation , utf8 field)

Do you see any issues with this implementation? Would you recommend a different approach?

Regarding the UI, admin can add/change/remove language value for each field.

[Stian Thorgersen]

I'd say there's 3 level of translations:

1. Server-wide - these are what we support today with message bundles in custom themes

2. Realm - overriding server-wide on a realm level, including ability to add shared translations available to the realm

3. Entity specific - ability to provide translations for some attributes for an entity

Taking client names for example we support using 1 today with ${messageKey}, this can also be extended with 2. by simply combining the "message bundle" of the realm and the server/theme.

With regards to 3 these translations should be added directly to the entity attributes themselves rather than in a separate table. We can take some inspiration from OAuth/OIDC here: https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts. For example for a client you would add an attribute name#no-NO for example to add Norwegian translation for the name.

In the admin console for fields supporting translations it would be nice to be able to add translations directly to the field (3), or to select from a list of shared attributes (1 and 2).

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/a39b9ff7-fb03-4f08-9c28-0b5d7924f4c6n%40googlegroups.com.

[ΚΩΝΣΤΑΝΤΙΝΟΣ ΓΕΩΡΓΙΛΑΚΗΣ]

I believe that the approach you proposed for third translation level is not the best solution and it might have performance issues. You can not search inside a map for key containing specific String. The only solution is to loop inside the map. This might produce performance issues. Translations must be easy to be extracted. The same problem exists for displayName in IdentityProvider. A solution could be to save value in a JSON object ( example value: {"en": "Register", "it": " Registrati”}). 

Regarding ui , I believe that a better solution is to add only new translations. 

[Stian Thorgersen]

On Mon, 27 Jul 2020 at 15:54, ΚΩΝΣΤΑΝΤΙΝΟΣ ΓΕΩΡΓΙΛΑΚΗΣ <costas...@gmail.com> wrote:

I believe that the approach you proposed for third translation level is not the best solution and it might have performance issues. You can not search inside a map for key containing specific String. The only solution is to loop inside the map. This might produce performance issues. Translations must be easy to be extracted. The same problem exists for displayName in IdentityProvider. A solution could be to save value in a JSON object ( example value: {"en": "Register", "it": " Registrati”}). 

I don't understand what you are saying here. By 3rd solution are you referring to "entity specific"? If so there's no performance issue there, as you know what you want to display. Say you are displaying the client name then the logic is:

* Locale is no-NO

* Check if attribute "name#no-NO" exists, if it does display this

* Otherwise fall back to just "name"

Then the value can be templated as well. So if "name" is "${myClientName}" then template that in based on the message bundle as we currently do.

 

Regarding ui , I believe that a better solution is to add only new translations. 

Don't know what you mean about that.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/a14d3b14-b444-4d72-9191-a925e151f9efn%40googlegroups.com.

[ΚΩΝΣΤΑΝΤΙΝΟΣ ΓΕΩΡΓΙΛΑΚΗΣ]

Our team is interesting to make a PR for  "entity specific"  multilanguage based on your response.

We will implement the multilanguage  "entity specific"  support for client name, description and identity provider name.

[Stian Thorgersen]

Great, for clients please take a look at the following:

https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

https://openid.net/specs/openid-connect-registration-1_0.html#LanguagesAndScripts

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/1671967d-c599-45f4-a279-440b07ceace7n%40googlegroups.com.

[ΚΩΝΣΤΑΝΤΙΝΟΣ ΓΕΩΡΓΙΛΑΚΗΣ]

I have created jira issue https://issues.redhat.com/browse/KEYCLOAK-15472 for this

[ΚΩΝΣΤΑΝΤΙΝΟΣ ΓΕΩΡΓΙΛΑΚΗΣ]

I want help about showing localized client name and description. Ui and model changes for supporting multilanguage name and description have been implemented.

Where - in code - should I do changes in order to user see localized Client name and description? Which rest api should be changed?

Thanks in andance.