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

[Stan Silvert]

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/20151008/d94d66cd/attachment.html