<div dir="ltr">#1 You're not going to catch all missing keys this way - as I said there's 2 types, custom defined as well which could be missing from default bundle<div>#2 Rendering the whole bundle useless just because you're missing one key is just daft</div><div>#3 There will quite likely be separate teams that do translations to those that do development, which means stack traces and log output is not the solution</div><div>#4 Doing a check each time you pull a message bundle to compare with the base bundle is probably not that expensive, but still pretty daft thing to do</div><div>#5 A proper util that's used to translate bundles is much better - we can implement a page in the admin console that allows you to validate a bundle and print out all missing bundles. This is something that would be more developer friendly and also would be usable by non-developers (aka people with other language skills than Java)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 October 2015 at 13:24, 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/9/2015 6:21 AM, Marko Strukelj
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">And we can always log the missing key situation
into server log - that should be enough for developers to notice
it, and fix it.</div>
</blockquote></span>
This is basically what happens with the code I wrote for the fix:<br>
<a href="https://github.com/keycloak/keycloak/pull/1690" target="_blank">https://github.com/keycloak/keycloak/pull/1690</a><br>
<br>
You get an error in the console and then a stack trace on the
server. The stack trace tells you exactly which key is missing.
But the console doesn't crash or anything like that. You just
switch back to your original language and everything works fine.<div><div class="h5"><br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 9, 2015 at 8:09 AM, Stian
Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@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 dir="ltr">There's two places where keys can be missing:
<div><br>
</div>
<div>* In a translation - this can be an honest mistake,
or the translation wasn't updated when KC was updated</div>
<div>* Custom keys added - for example when keys are used
for display names of clients, roles, etc..</div>
<div><br>
</div>
<div>Manually having to go through all sorts of pages to
look for missing keys is very error prone and time
consuming, so will not be the best option for
developers. In both cases above the correct way to do
this would be to have a way to verify a message
bundle. We need a tool that can quickly identify if
there are missing keys and we could expose that through
the admin console. We currently have a student looking
at providing a UI for defining locales and she is also
going to look at adding some way of identifying if a
locale is missing keys and also to easily list only
missing keys.</div>
<div><br>
</div>
<div>For end users as I've said they will have no clue
what ???key??? is, and even worse if we throw an
exception/error just because a missing key we'll
actually break the whole console just because of a
missing key. It's a much better option to look for the
key in another translation and display that. Chances are
they will be able to interpret one or two English words.
Certainly higher chance of that then them being able to
interpret ???key???.</div>
<div><br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 October 2015 at 07:51,
Thomas Raehalme <span dir="ltr"><<a href="mailto:thomas.raehalme@aitiofinland.com" target="_blank">thomas.raehalme@aitiofinland.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">How about returning something
noticeable like ???key??? for example?</p>
<div>
<div>
<div class="gmail_quote">On Oct 9, 2015 8:10
AM, "Stian Thorgersen" <<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 8 October
2015 at 20:33, 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">
<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><br>
<br>
On 10/8/2015 1:28 PM, Stian
Thorgersen wrote:<br>
</div>
</div>
</div>
<div>
<div>
<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 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 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 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>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>