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

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(a)redhat.com <mailto:ssilvert@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(a)redhat.com > <mailto:ssilvert@redhat.com>> wrote: > > On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >> >> >> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >> <sthorger(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:ssilvert@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/c9437595b70810c4472325373dd88... >> >> >> >> Stan >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >