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

Fri Oct 9 01:10:09 EDT 2015

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