Globalization and RingoJS

[Edwin Hoogerbeets]

Has anyone created a globalized site using RingoJS with Stick and Reinhardt? The site I'm creating needs to be fully internationalized so that it can be localized to many different languages. Is there any effort under way already to solve this problem, or am I bringing this up for the first time?

I have browsed the Django documentation to see how it does localized templates, and I found the LocaleMiddleware class and the {% trans %} template tag which are not implemented in Ringo/Reinhardt. Although, I think the trans tag is a little messy. The reality is that many web sites, and even web applications, have different features in the localizations than in the source language and hence different templates, which cannot be handled with the trans tag alone. It might be possible to use the "if" and "trans" tags together for smaller differences, but for major differences, this becomes pretty messy.

Also, I'm browsing the existing Ringo and Reinhardt source code and I'm finding all manner of i18n problems.

Examples: Hard-coded English strings in various places, especially error messages. The truncatechars filter cuts off strings between Unicode chars without considering decomposed Unicode characters or Unicode surrogate characters and whether or not it is cutting in the middle of them. The truncatewords filter cannot handle non-Western languages where words may not written with spaces between them or where they use different punctuation.  Upper-, title-, and lower-casing strings are locale-sensitive functions and the upper, lower, and title casing filters do not heed the locale. The date filter requires a SimpleDate format template -- but how are users of the filter supposed to know what the correct format template is for every locale and for every length of format or combination of date components? Also, because you pick a format template when you create your reinhardt template, how do you switch that format template per locale? All I can think of right now is a big ole set of "if else" conditions that switches on the current locale.

There are many more of these. Should I create a bug for each of these problems so that we have a record of all of them? Or write them down on a wiki somewhere?

Just so you know, I've been doing globalization for 24 years now, the last 6 with Javascript. I'm new to RingoJS, however. Hence these questions.

Thanks,

Edwin 

[si...@nekapuzer.at]

I've written most of Reinhardt and intentionally left out the i18n part because if implemented properly it's not just the {% trans %} tag but it also requires support for gettext (allowing "_()" in lots of places). And this effects the parser and how the Tokens do their variable lookup. Also, i18n in JS has another big problem: timezone support in JavaScript's Date object is nonexistent. You would have to either use Java's Date everywhere or write your own JS wrapper.

All those problems and the additional complexity made me decide to not do this yet. I'm also not doing any i18n work myself and am not sure how good Django's concepts are.

> ... have different features in the localizations than in the source language and hence different templates, which cannot be handled with the trans tag alone

Did you see the {% blocktrans %} tag? It seems to handle more complex cases: https://docs.djangoproject.com/en/1.8/topics/i18n/translation/#blocktrans-template-tag

> Also, because you pick a format template when you create your reinhardt template, how do you switch that format template per locale?

I'm not sure what you mean. But the {% extends %} tag accepts a variable as an argument.

The one thing you mention, which could be fixed quite easily, is unicode support in the filters (truncate, etc.). There's probably prior art for doing this in JS.

And regarding english language error messages: I'm not sure I would translate them. What kind of messages do you mean?

If you could create one issue for all the i18n problems you found in Reinhardt, i would be grateful. And if you decide to implement the {% trans %} and/or {% blocktrans %} tags I will gladly review your PR.

hope that helps and sorry for the bad news.. I guess you are the first to bring this up :)
 Simon

--
You received this message because you are subscribed to the Google Groups "RingoJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ringojs+u...@googlegroups.com.
To post to this group, send email to rin...@googlegroups.com.
Visit this group at http://groups.google.com/group/ringojs.
For more options, visit https://groups.google.com/d/optout.

[Edwin Hoogerbeets]

Hi Simon,

Thanks for the response. Question: as a general policy, do you want Reinhardt to remain compatible with the Django template syntax? I'll have to implement something and I can probably share it when I get a chance, but I would definitely prefer to deviate from Django as I disagree with some of the design choices in the Django syntax.

Also, I have built a pretty comprehensive open-source i18n library in pure JS called "ilib" (on source forge see http://sourceforge.net/projects/i18nlib/ ) that I could use to implement proper pluralization, translations, etc. Much of what it does can be done with the standard Java libraries, but only on the server side under Rhino of course. It does provide a number of things that the JDK doesn't have though (such as name parsing/formatting, phone number parsing/formatting, etc.). It is really useful for client-side JS as well where there is very little other support for i18n, and a big advantage is that it has the same API on various browsers as on Rhino, nodejs, Qt, etc. What is the policy for Reinhardt to depend on other libraries such as ilib? I can create an ilib ringo package and submit it to rpm. Ilib is open-source under Apache2, so licensing should not be a problem.

Edwin

[Mike Schwartz]

That library would be much better hosted on github.

Add bower.json and it will be even more useful.

$.02

[si...@nekapuzer.at]

Hi Edwin,
deviating from Django syntax won't be a problem. e.g. if you add a bunch of new template tags they wouldn't even have to be in Reinhardt core but we could put them in a reinhardt-contrib package (similar to how django does it). Hard to give suggestions without knowing what you want to add, but if it's useful for others we will find a way.

ilib looks interesting. Certainly a welcome addition to rpm :)

 Simon

June 13 2015 3:45 AM, "Edwin Hoogerbeets" <ehooge...@gmail.com> wrote:

Hi Simon,

Thanks for the response. Question: as a general policy, do you want Reinhardt to remain compatible with the Django template syntax? I'll have to implement something and I can probably share it when I get a chance, but I would definitely prefer to deviate from Django as I disagree with some of the design choices in the Django syntax.

Also, I have built a pretty comprehensive open-source i18n library in pure JS called "ilib" (on source forge see http://sourceforge.net/projects/i18nlib ) that I could use to implement proper pluralization, translations, etc. Much of what it does can be done with the standard Java libraries, but only on the server side under Rhino of course. It does provide a number of things that the JDK doesn't have though (such as name parsing/formatting, phone number parsing/formatting, etc.). It is really useful for client-side JS as well where there is very little other support for i18n, and a big advantage is that it has the same API on various browsers as on Rhino, nodejs, Qt, etc. What is the policy for Reinhardt to depend on other libraries such as ilib? I can create an ilib ringo package and submit it to rpm. Ilib is open-source under Apache2, so licensing should not be a problem.