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

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