[keycloak-dev] i18n/l10n: English text in java code
Stan Silvert
ssilvert at redhat.com
Fri Oct 9 07:06:07 EDT 2015
On 10/9/2015 1:10 AM, Stian Thorgersen 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.
This is exactly what needs to happen. A missing key is a bug. We don't
want such a bug to get past development. I could improve it by catching
the problem at build time, but that's a little more difficult to
implement and it's only a slight improvement.
Besides, it doesn't render the console useless. It only renders the
bundle useless, which it the state you are in anyway. We don't want a
bundle to "sort of" work if there is a bug in it. We might never get to
the bad page and never notice it until production.
When the RuntimeException occurs from a bad bundle, you can switch back
to your original language and everything works fine.
>
> On 8 October 2015 at 20:33, Stan Silvert <ssilvert at redhat.com
> <mailto: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
>> <mailto: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 <mailto: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 <mailto: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
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> <mailto: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/0ee8e6aa/attachment-0001.html
More information about the keycloak-dev
mailing list