<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 October 2015 at 14:13, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 10/8/2015 12:48 AM, Thomas Raehalme
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr"><br>
On Oct 8, 2015 6:53 AM, "Stian Thorgersen" <<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>>
wrote:<br>
><br>
> With regards to internationalization I have two questions:<br>
><br>
> * 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</p>
<p dir="ltr">A missing key is a bug and showing the message in the
default locale may hide the problem. </p>
<p dir="ltr">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.</p>
</blockquote></span>
For our bundles, we could catch missing keys at build time. <br>
<br>
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.<span class=""><br>
<br>
<blockquote type="cite">
<p dir="ltr">> * Should we change message bundles to UTF-8? Or
is ISO 8859-1 going to work for all languages?</p>
<p dir="ltr">Depends what those all languages are :-)</p>
<p dir="ltr">I think UTF-8 is the best choice as it will handle
practically any character. </p>
<p dir="ltr">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.</p>
</blockquote></span>
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.<br>
<br>
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.<br>
<br>
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?<div><div class="h5"><br>
<blockquote type="cite">
<p dir="ltr">Best regards,<br>
Thomas<br>
</p>
<p dir="ltr">><br>
> On 7 October 2015 at 18:42, Stan Silvert <<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>>
wrote:<br>
>><br>
>> Marko brought this to my attention yesterday. For some
things, we<br>
>> dynamically create UI. In this case, the java code
contains the English<br>
>> text and it needs to be localized. Luckily, the
solution was pretty<br>
>> straightforward. We just replace the English text with
a key into the<br>
>> message bundle. The html template that displays this
text already pulls<br>
>> from an Angular scope so we just leave that alone and
pass it through<br>
>> the |translate filter. You do need to also add the
double-colon.<br>
>><br>
>> One nice side effect is that if the key is not found in
the bundle then<br>
>> the output of the translate filter is the unchanged
text. This means<br>
>> that any code which has not converted to using bundle
keys will still<br>
>> work as expected. And, any third-party providers can
just pass in<br>
>> plain text if they don't care about l10n. If they ever
do care about<br>
>> l10n we will just need to provide a means for them to
add key/value<br>
>> pairs to the resource bundles.<br>
>><br>
>> Here is an example for anyone who needs to localize
English text<br>
>> embedded in java:<br>
>> <a href="https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549" target="_blank">https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549</a><br>
>><br>
>> Stan<br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</p>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>