Shameless plug: I've been working on a similar project for about a year now called Localize.js (https://localizejs.com), with the goal of automating the entire process of internationalization / localization. It works by scanning the DOM for translatable content, and injecting translations on-the-fly after the page loads (this happens so quickly that the user never sees the text in the original language).
>It works by scanning the DOM for translatable content, and injecting translations on-the-fly after the page loads
I don't like this approach because it makes the framework/library harder to integrate with other DOM-modifying frameworks like data binding frameworks that are very popular these days. A more modular approach in my opinion would be to simply provide a function/functions to do the localization conversions. That can easily be integrated to any data binding framework.
>(this happens so quickly that the user never sees the text in the original language)
And if you use it with something like AngularJS, the end result is visual flicker after DOM changes..
Yeah, for a simple plural that can be a bit longer. In other languages, though, the pluralization rules get rather complicated[1]. (For example, Arabic has both complicated pluralization rules -and- a lot of people who speak it.)
The strength of the ICU message format, in my mind, is that the messages can be "nested" so that the translation can be customized for multiple concerns (plural, gender, whatever).
Also, with the integrations (dust, handlebars, react) the details of translation and display of data lives in the message format and/or template. This is the "view layer", and means that your controller/code isn't littered with a bunch of calls to a translation library.
I haven't look into i18n-js library in details, but this is what I can spot so far:
* the message format in i18n-js seems to be compatible with ICU message syntax, the industry standard used in other programming languages and the one used by formatJS as well. we will have to check if they really implemented all the specs, which makes the messages more advanced, e.g.:
```
Cart: {itemCount, plural,
=0 {no items}
one {one item}
other {# items}
}
```
including the fact that itemCount from `other` option will be formatted as a number, saying "1,030" in EN, vs "1 030" in FR.
* i18n-js is a js library, which means you have to do the formatting in your js code, then passing the formatted data into the template engine where you have the placeholders for them, while FormatJS focuses more on the high-level declarative form that you can use in your templates directly, which makes things simpler, if you use handlebars, you could do: {{formatMessage "Cart" itemCount=numItems}} right in your template.
Currently I use i18next with custom functions, where I just write strings like _("car"), ngettext("window", "windows", number) in files.
I Can use translator comments, context and everything. (Like //TRANSLATORS: this is used in this way etc.)
https://www.gnu.org/software/gettext/manual/html_node/PO-Fil...
Babel extracts all translatable strings to POT file. I Translate POT file to my wanted languages PO files with GUI tool of my choice. Then PO file is converted to json and used in translations with i18next library.
When New translations are added I just rerun Babel new translations are added, are retranslated if needed and converted to JSON.
I looked into a lot of JS libraries and extractors and these was the only one that supported Plurals, context, translator comments, etc.
I looked into Mozilla's L20 which seems nice. But there is no GUI translation editor. You have to find all translatable strings yourself etc. End it seems it's the same here.
One better things is that with FormatJS I wouldn't need moment.js for date localization.
The workflow is, for now, out of the scope of this project, we assume developers will figure how to produce a javascript object that contains key=value pairs, where each value is a message written in ICU message syntax, and where values are feed into the template engine for helpers/methods to use them.
Internally at Yahoo (just like facebook, and other big companies), we have an infrastructure for translation that works based on a source file written in english by developers, and the whole thing just work. But we have no plans to open up any of that. We believe, such system will grow from the community once people realize that ICU is good enough to internationalize their apps.
As for moment.js, you're right, if you will never need to parse a date, or massage a date value, and the only thing you care about is to format a timestamp that is coming from an API, then `formatRelative` helper should be good enough.
A related thought: I wonder if we will some day live in a world where translation is not required. Where everyone knows English and has no trouble using English tools and consuming English content.
Same goes for measurement systems (metric), time, currency, and other formats. I reckon it would simplify our lives greatly and spare us the trouble of dealing with 1000s of encodings, multi-byte strings and different text directions.
Technological landscape is the only place where such unity between nations is possible, I tend to think that this is what should be pursued instead of translate-everything-everywhere approach.
Pedantic Englishman here: 14/10/2014 is used all over Europe, including England. If only we could persuade the world to use an international format: 2014-10-14, for example.
I like using "14 Oct 2014" to avoid any ambiguity. 2014-10-14 is good too but it comes off a bit technical, like dropping scientific notation in an everyday message.
I'm currently using Moment.js, i18next and Numeral.js with AngularJS. I wonder how FormatJS compares with this. At least one benefit FormatJS could have is having a unified collection of translation files.
the main benefit of formatjs is that it offers a declarative syntax at the template level, which simplifies things drastically. we don't have an integration for AngularJS or Ember just yet, but we are planning to do so very soon.
Hmmm... after very quickly looking at Globalize, I'd say there are two things about formatjs.io that I see as main differences:
* Integrations with Handlebars, Dust, and React hopefully make formatjs.io easy to use (since people are already using one of these).
* Focus on the ICU message format, which is fairly simple yet fairly expressive. (Professional translators should hopefully be familiar with this syntax, and it's actually fairly straightforward for us engineers to use.)
One thing that looks interesting (to me) about Globalize is the way the latest/freshest CLDR data is loaded.
Super shameless plug, but easy internationalization for email is something we've added to Sendwithus. We're working with multiple partners on it (sample at https://www.sendwithus.com/translations), but are still looking for more beta users of the feature.
This may be offtopic, but is there an editor for translating ICU messageformat strings?
There are many tools to extract gettext strings from source and editors to translate PO catalogs, but I do not know of any that works with ICU messageformat syntax.
Hi! There are helpers for dealing with dynamic content like numbers and dates, but also there's message formatting for when you have your own translations like "I have {numCats, number} cats.". Here's the explanation for the Handlebars integration: http://formatjs.io/guide/#messageformat-syntax.
cj|11 years ago
nawitus|11 years ago
I don't like this approach because it makes the framework/library harder to integrate with other DOM-modifying frameworks like data binding frameworks that are very popular these days. A more modular approach in my opinion would be to simply provide a function/functions to do the localization conversions. That can easily be integrated to any data binding framework.
>(this happens so quickly that the user never sees the text in the original language)
And if you use it with something like AngularJS, the end result is visual flicker after DOM changes..
mikewhy|11 years ago
drewfish|11 years ago
The strength of the ICU message format, in my mind, is that the messages can be "nested" so that the translation can be customized for multiple concerns (plural, gender, whatever).
Also, with the integrations (dust, handlebars, react) the details of translation and display of data lives in the message format and/or template. This is the "view layer", and means that your controller/code isn't littered with a bunch of calls to a translation library.
[1] http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/la...
caridy|11 years ago
* the message format in i18n-js seems to be compatible with ICU message syntax, the industry standard used in other programming languages and the one used by formatJS as well. we will have to check if they really implemented all the specs, which makes the messages more advanced, e.g.:
``` Cart: {itemCount, plural, =0 {no items} one {one item} other {# items} } ```
including the fact that itemCount from `other` option will be formatted as a number, saying "1,030" in EN, vs "1 030" in FR.
* i18n-js is a js library, which means you have to do the formatting in your js code, then passing the formatted data into the template engine where you have the placeholders for them, while FormatJS focuses more on the high-level declarative form that you can use in your templates directly, which makes things simpler, if you use handlebars, you could do: {{formatMessage "Cart" itemCount=numItems}} right in your template.
MaBu|11 years ago
Currently I use i18next with custom functions, where I just write strings like _("car"), ngettext("window", "windows", number) in files. I Can use translator comments, context and everything. (Like //TRANSLATORS: this is used in this way etc.) https://www.gnu.org/software/gettext/manual/html_node/PO-Fil... Babel extracts all translatable strings to POT file. I Translate POT file to my wanted languages PO files with GUI tool of my choice. Then PO file is converted to json and used in translations with i18next library. When New translations are added I just rerun Babel new translations are added, are retranslated if needed and converted to JSON. I looked into a lot of JS libraries and extractors and these was the only one that supported Plurals, context, translator comments, etc.
I looked into Mozilla's L20 which seems nice. But there is no GUI translation editor. You have to find all translatable strings yourself etc. End it seems it's the same here.
One better things is that with FormatJS I wouldn't need moment.js for date localization.
caridy|11 years ago
Internally at Yahoo (just like facebook, and other big companies), we have an infrastructure for translation that works based on a source file written in english by developers, and the whole thing just work. But we have no plans to open up any of that. We believe, such system will grow from the community once people realize that ICU is good enough to internationalize their apps.
As for moment.js, you're right, if you will never need to parse a date, or massage a date value, and the only thing you care about is to format a timestamp that is coming from an API, then `formatRelative` helper should be good enough.
gear54rus|11 years ago
Same goes for measurement systems (metric), time, currency, and other formats. I reckon it would simplify our lives greatly and spare us the trouble of dealing with 1000s of encodings, multi-byte strings and different text directions.
Technological landscape is the only place where such unity between nations is possible, I tend to think that this is what should be pursued instead of translate-everything-everywhere approach.
sambeau|11 years ago
caridy|11 years ago
http://yahooeng.tumblr.com/post/100006468771/announcing-form...
hopefully it will help to clarify few of the questions...
BruceM|11 years ago
alexchamberlain|11 years ago
Pedantic Englishman here: 14/10/2014 is used all over Europe, including England. If only we could persuade the world to use an international format: 2014-10-14, for example.
pimlottc|11 years ago
nawitus|11 years ago
caridy|11 years ago
macca321|11 years ago
https://github.com/jquery/globalize
drewfish|11 years ago
* Integrations with Handlebars, Dust, and React hopefully make formatjs.io easy to use (since people are already using one of these).
* Focus on the ICU message format, which is fairly simple yet fairly expressive. (Professional translators should hopefully be familiar with this syntax, and it's actually fairly straightforward for us engineers to use.)
One thing that looks interesting (to me) about Globalize is the way the latest/freshest CLDR data is loaded.
mrmch|11 years ago
grakic|11 years ago
There are many tools to extract gettext strings from source and editors to translate PO catalogs, but I do not know of any that works with ICU messageformat syntax.
joshdance|11 years ago
juandopazo|11 years ago
nols|11 years ago
drewfish|11 years ago