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..
We've also spent a ton of time making sure there's zero visual flicker as the DOM changes take place. We have a bunch of companies using it to translate Angular and Backbone apps (for example, http://venzee.com/ and https://www.verbling.com).
Cart: {itemCount} {itemCount, plural,
one {item}
other {items}
}
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...
Though i18n-js does let you write your own pluralizations rules (taken from the readme), while supporting zero/one/many out of the box:
I18n.pluralization["ru"] = function (count) {
var key = count % 10 == 1 && count % 100 != 11 ? "one" : [2, 3, 4].indexOf(count % 10) >= 0 && [12, 13, 14].indexOf(count % 100) < 0 ? "few" : count % 10 == 0 || [5, 6, 7, 8, 9].indexOf(count % 10) >= 0 || [11, 12, 13, 14].indexOf(count % 100) >= 0 ? "many" : "other";
return [key];
};
* 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.
Not sure I follow, taken from a React component:
Component = React.createClass
render: ->
@div null,
@t('welcomeMessage', username: @props.CurrentUser.displayName)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.
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.
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.
http://yahooeng.tumblr.com/post/100006468771/announcing-form...
hopefully it will help to clarify few of the questions...
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.
* 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.
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.
I had to re-read the last line several times before I looked up at the function arrow and realized it was coffeescript, and that the "@" were not part of the i18n library, but rather the syntactic sugar for "this".
The last one actually is sometimes called "little chinese boy" in circles of language tutors due to how young children can easily pick up languages different from their native one due to lack of bias. My cousin thats 5 years old now is already dual-languaged due to her parents exposing her to their native languages at all times.
edit: Looking at the EF English Proficiency Index[1], English doesn't seem quite as universal as it feels like in the Anglosphere anyway.
[1]: http://en.wikipedia.org/wiki/EF_English_Proficiency_Index
Our goal with Localize.js is to make everything completely "plug and play", and require as little extra development work as possible. We're hoping this will make localization more accessible to startups / companies who don't have weeks or months to spend manually internationalizing their application.
I wouldn't use it for greenfield development, but it's definitely a great option for websites that wouldn't otherwise be localized. It's great for people to have a near-zero-development option to translate existing sites.
I'd certainly rather have websites translated using this approach than not translated at all!