[keycloak-dev] i18n/l10n: English text in java code

Fri Oct 9 06:21:38 EDT 2015

And we can always log the missing key situation into server log - that
should be enough for developers to notice it, and fix it.

On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> There's two places where keys can be missing:
>
> * In a translation - this can be an honest mistake, or the translation
> wasn't updated when KC was updated
> * Custom keys added - for example when keys are used for display names of
> clients, roles, etc..
>
> Manually having to go through all sorts of pages to look for missing keys
> is very error prone and time consuming, so will not be the best option for
> developers. In both cases above the correct way to do this would be to have
> a way to verify a message bundle. We need a tool that can quickly identify
> if there are missing keys and we could expose that through the admin
> console. We currently have a student looking at providing a UI for defining
> locales and she is also going to look at adding some way of identifying if
> a locale is missing keys and also to easily list only missing keys.
>
> For end users as I've said they will have no clue what ???key??? is, and
> even worse if we throw an exception/error just because a missing key we'll
> actually break the whole console just because of a missing key. It's a much
> better option to look for the key in another translation and display that.
> Chances are they will be able to interpret one or two English words.
> Certainly higher chance of that then them being able to interpret ???key???.
>
>
> On 9 October 2015 at 07:51, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> How about returning something noticeable like ???key??? for example?
>> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>
>>> That's not putting it to rest at all! Throwing a RuntimeException and
>>> rendering the whole admin console useless just because there's a missing
>>> key is a horrible idea.
>>>
>>> On 8 October 2015 at 20:33, Stan Silvert <ssilvert at redhat.com> wrote:
>>>
>>>> What if English is the bundle that has a missing key?
>>>>
>>>> Let's just put this to rest and solve it once and for all.  The
>>>> simplest solution I can think of is to just compare keys when a new bundle
>>>> is loaded.  If any bundle has a missing key or it has key not found in the
>>>> previous loaded bundle, we throw a RuntimeException.  I can submit a patch
>>>> for that in just a few minutes.
>>>>
>>>>
>>>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote:
>>>>
>>>> I'm not sure I'm buying into the argument that displaying the key is
>>>> better for developers. Having English suddenly pop-up in a German
>>>> translation is just as obvious as a key. Besides as Stan points out you
>>>> catch missing keys by comparing missing keys between English and German.
>>>>
>>>> However, if there is a mistake in a translation then a user may quite
>>>> likely be able to interpret English text, while a user will not be able to
>>>> interpret a key. So if a key is missing in a translation (which is
>>>> obviously a "bug") it's better to display English than to display the key.
>>>>
>>>> On 8 October 2015 at 14:13, Stan Silvert <ssilvert at redhat.com> wrote:
>>>>
>>>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote:
>>>>>
>>>>>
>>>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" <sthorger at redhat.com>
>>>>> wrote:
>>>>> >
>>>>> > With regards to internationalization I have two questions:
>>>>> >
>>>>> > * Should we fallback to English messages if a key is missing in a
>>>>> translation? Alternative is to show key, but that's not going to help anyone
>>>>>
>>>>> A missing key is a bug and showing the message in the default locale
>>>>> may hide the problem.
>>>>>
>>>>> Even though showing the key does not help the end user it helps the
>>>>> developer and identifies the problem. For this reason I think showing the
>>>>> key would be a good idea.
>>>>>
>>>>> For our bundles, we could catch missing keys at build time.
>>>>>
>>>>> Failing that, I agree that displaying the key is better than falling
>>>>> back to English.  This is especially true right now while we haven't
>>>>> completed the task of converting everything.  If we fall back to English we
>>>>> won't know if the problem is a missing key or if the text just hasn't been
>>>>> converted yet.
>>>>>
>>>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going
>>>>> to work for all languages?
>>>>>
>>>>> Depends what those all languages are :-)
>>>>>
>>>>> I think UTF-8 is the best choice as it will handle practically any
>>>>> character.
>>>>>
>>>>> But if you're referring to Java resource bundles the encoding for
>>>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character.
>>>>>
>>>>> Yes, an UTF-8 character can be encoded in ISO-8859-1.  Java provides a
>>>>> native2ascii tool for converting entire files.  The resource bundle tools
>>>>> in most IDE's do this for you automatically.  So you just edit as UTF-8 and
>>>>> it saves the bundle as ISO-8859-1.
>>>>>
>>>>> We can read our bundles as UTF-8 if we want to do that.  I'd rather
>>>>> not, because I'm not sure what we might run into down the road with Java
>>>>> assuming resource bundles are always ISO-8859-1.
>>>>>
>>>>> But I'd like to get the perspective of people who have handled
>>>>> resource bundles in languages that are not fully supported by ISO-8859-1.
>>>>> Is it too much of a pain to do a conversion or do the tools make the
>>>>> process seamless?
>>>>>
>>>>> Best regards,
>>>>> Thomas
>>>>>
>>>>> >
>>>>> > On 7 October 2015 at 18:42, Stan Silvert <ssilvert at redhat.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Marko brought this to my attention yesterday.  For some things, we
>>>>> >> dynamically create UI.  In this case, the java code contains the
>>>>> English
>>>>> >> text and it needs to be localized.  Luckily, the solution was pretty
>>>>> >> straightforward.  We just replace the English text with a key into
>>>>> the
>>>>> >> message bundle.  The html template that displays this text already
>>>>> pulls
>>>>> >> from an Angular scope so we just leave that alone and pass it
>>>>> through
>>>>> >> the |translate filter.  You do need to also add the double-colon.
>>>>> >>
>>>>> >> One nice side effect is that if the key is not found in the bundle
>>>>> then
>>>>> >> the output of the translate filter is the unchanged text.  This
>>>>> means
>>>>> >> that any code which has not converted to using bundle keys will
>>>>> still
>>>>> >> work as expected.   And, any third-party providers can just pass in
>>>>> >> plain text if they don't care about l10n.  If they ever do care
>>>>> about
>>>>> >> l10n we will just need to provide a means for them to add key/value
>>>>> >> pairs to the resource bundles.
>>>>> >>
>>>>> >> Here is an example for anyone who needs to localize English text
>>>>> >> embedded in java:
>>>>> >>
>>>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549
>>>>> >>
>>>>> >> Stan
>>>>> >> _______________________________________________
>>>>> >> keycloak-dev mailing list
>>>>> >> keycloak-dev at lists.jboss.org
>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > keycloak-dev mailing list
>>>>> > keycloak-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
> _______________________________________________
> 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/20151009/2230b5e1/attachment.html 