<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/9/2015 1:10 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeYcrrO8E4Wy14wjf7PvOXQ_jScS2+a9_9cHTKJtHoYgQ@mail.gmail.com"
type="cite">
<div dir="ltr">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.</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
When the RuntimeException occurs from a bad bundle, you can switch
back to your original language and everything works fine.<br>
<blockquote
cite="mid:CAJgngAeYcrrO8E4Wy14wjf7PvOXQ_jScS2+a9_9cHTKJtHoYgQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 8 October 2015 at 20:33, Stan
Silvert <span dir="ltr"><<a moz-do-not-send="true"
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">
<div>What if English is the bundle that has a missing key?<br>
<br>
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.
<div>
<div class="h5"><br>
<br>
On 10/8/2015 1:28 PM, Stian Thorgersen wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<blockquote type="cite">
<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
moz-do-not-send="true"
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>
<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
moz-do-not-send="true"
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><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><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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
target="_blank">keycloak-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
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>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>