Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FormatJS – Internationalize your web apps on the client and server

formatjs.io

Post reply on HN
Print view View original

11–20 of 39 posts

Re: FormatJS – Internationalize your web apps on the client and server

#11

Post by drewfish »

macca321 wrote: post #5

I would be interested to know if it offers anything over Globalize https://github.com/jquery/globalize

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.

Re: FormatJS – Internationalize your web apps on the client and server

#12

Post by nawitus »

cj wrote: post #10
nawitus wrote: post #6

Earlier quoted context omitted.

>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…

Localize.js is fully compatible with all DOM-modifying frameworks (Backbone, Angular, etc). Localize.js doesn't actually replace existing DOM elements, rather it simply changes the existing elements' contents as to not interfere with bindings. 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 ap…

But when the contents change, how does Localize.js know to translate the DOM again? If you need to call something like 'Localize.translatePage', then you need to track the changes yourself, which is not the correct way. I noticed that one can bypass the DOM modifying by calling Localize.translate to directly translate text, which is what I would do with Angular.JS. I'd just write a simple directive which uses the Localize.js function to translate text.

Re: FormatJS – Internationalize your web apps on the client and server

#14

Post by cj »

nawitus wrote: post #12
cj wrote: post #10

Earlier quoted context omitted.

Localize.js is fully compatible with all DOM-modifying frameworks (Backbone, Angular, etc). Localize.js doesn't actually replace existing DOM elements, rather it simply changes the existing elements' contents as to not interfere with bindings. 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 ap…

But when the contents change, how does Localize.js know to translate the DOM again? If you need to call something like 'Localize.translatePage', then you need to track the changes yourself, which is not the correct way. I noticed that one can bypass the DOM modifying by calling Localize.translate to directly translate text, which is what I would do with Angular.JS. I'd just write a simple directive which uses the Loc…

We use MutationObserver (https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...) to detect when content on the page changes, so when you add (or change) a on your page, we're able to immediately translate the new content, on-the-fly, as it's being inserted into the DOM.

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.

Re: FormatJS – Internationalize your web apps on the client and server

#15

Post by drewfish »

mikewhy wrote: post #13

Are there any advantages over i18n-js[1]? Can't say I'm a huge fan of this method of pluralization: Cart: {itemCount} {itemCount, plural, one {item} other {items} } [1]: https://github.com/fnando/i18n-js

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.

[1] http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/la...

Re: FormatJS – Internationalize your web apps on the client and server

#16

Post by caridy »

mikewhy wrote: post #13

Are there any advantages over i18n-js[1]? Can't say I'm a huge fan of this method of pluralization: Cart: {itemCount} {itemCount, plural, one {item} other {items} } [1]: https://github.com/fnando/i18n-js

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.

Re: FormatJS – Internationalize your web apps on the client and server

#17

Post by mrmch »

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.

Re: FormatJS – Internationalize your web apps on the client and server

#20

Post by ttty »

cj wrote: post #14
nawitus wrote: post #12

Earlier quoted context omitted.

But when the contents change, how does Localize.js know to translate the DOM again? If you need to call something like 'Localize.translatePage', then you need to track the changes yourself, which is not the correct way. I noticed that one can bypass the DOM modifying by calling Localize.translate to directly translate text, which is what I would do with Angular.JS. I'd just write a simple directive which uses the Loc…

We use MutationObserver ( https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... ) to detect when content on the page changes, so when you add (or change) a on your page, we're able to immediately translate the new content, on-the-fly, as it's being inserted into the DOM. Our goal with Localize.js is to make everything completely "plug and play", and require as little extra development work as possible. We'r…

Please stop.. Don't do things this way. This is like jquery monkey patch hell..
Post reply on HN