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

[Thomas Raehalme]

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