-1000 To using FreeMarker for this - we don't want all pages to be templated
If you prefer angular-translate I'd go for that. With regards to messages I'd have
the bundles as regular message bundles on the file system, but have an endpoint on the
admin console that exposes it as json.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Monday, 10 August, 2015 10:25:39 PM
Subject: Re: [keycloak-dev] Evaluation of i18n/i10n tools
On 8/10/2015 1:55 PM, Bill Burke wrote:
> Our translation team is used to message bundles/property files. Don't
> know if that is an issue or not.
We would use message bundles/property files if we did i18n/l10n on the
server side with Java and Freemarker. It's a possibility.
The default way Freemarker solves the problem is to have you create
localized versions of each template. So there would be lots of
duplication and a maintenance nightmare. According to [1], you would
have login_en.ftl, login_fr.ftl, login_es.ftl, etc. So you've just
multiplied the number of template files by the number of languages
supported.
Another approach using Freemarker would be to use Freemarker itself as a
localization tool. Then you only need a single template for all
languages and you use Freemarker and Java to do the substitutions. But
it looks like this solution gets complicated very quickly[2][3].
That being said, I'm not very familiar with Freemarker. If you guys
think I should look into a server-side solution let me know and I'll
give it a try.
[1]
http://freemarker.org/docs/ref_directive_include.html#ref_directive_inclu...
[2]
http://sourceforge.net/p/freemarker/discussion/2346/thread/5a29eee0/
[3]
http://mnmlst-dvlpr.blogspot.com/2012/06/know-your-library-i18n.html
>
> On 8/10/2015 1:45 PM, Stan Silvert wrote:
>> I've been evaluating tools to help us localize Keycloak. The tools I
>> looked at were angular-translate, angular-localization, and
>> angular-gettext. All use the MIT license.
>>
>> I took a static version of our login page and localized with
>> angular-translate. Then I did the same thing using
>> angular-localization. Both worked well and it was pretty cool to see
>> the language change between English and French with the click of a
>> button. Both use ordinary JSON files for the translations.
>>
>> In doing this, I was able to explore the features, strengths, and
>> weaknesses of each library. Of the two, I prefer angular-translate.
>> The reason mostly has to do with a greater feature set, maturity, and a
>> larger community. I can go into much greater detail if anyone is
>> interested.
>>
>> For angular-gettext, it seems to be somewhat popular, but it takes a
>> very different approach. I'm rejecting it based on the fact that it
>> relies a great deal on tools and automation. I don't think that
>> translators and developers want to learn new tools and a new file format
>> for the translations (.po files vs. JSON). Plus, angular-gettext
>> automatically uses the English version of the word or phrase to generate
>> keys in the .po files. The whole process looks error-prone.
>>
>> If you have any experience using these or other packages please let me
>> know. In researching this topic, I've found that some people even roll
>> their own angular translation tools. So let me know if you have
>> experience with that as well.
>>
>> 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