JavaScript Internationalization API | Hacker News Reader

JavaScript Internationalization API

hacks.mozilla.org

93 pointsGarbage27 comments

Shameless plug: I've been working on a i18n / localization SaaS for about a year now called Localize.js (https://localizejs.com), with the goal of automating the localization process. It works by scanning the DOM for translatable content, and injecting translations client side, on-the-fly (happens fast enough that the user never sees the text in the original language).

Internationalization is a notoriously difficult problem, and it's great to see some native API browser support. We definitely have a long way to go.

I might be a potential target of your SaaS for one of my not yet fully localized web based applications.

But there is just no way that I can src="" your .js directly into my web application and therefore access to the DOM.

Could I still use your service somehow?

Localize.js requires adding our Javascript library to your page (like you do with Google Analytics, Optimizely, Mixpanel, etc). If you don't mind me asking, what is preventing you from adding a line of js code to your website?

Security guidelines to not have any 3rd party JS.

You could audit the code yourself and self-host.

Sure, if the license permits that.

Localize.js looks awesomely convenient.

I've just spent much of the past 10 days trying to think of how to internationalise and translate a web app. I'd resorted to writing my own dodgy JS client side solution, backed by something on the server side, but I'll take a good look at your solution now that I've seen it!

As an aside, this is sort of a strange pattern:

    var ctor = "Collator"; // or the others
    var instance = new Intl[ctor](locales, options);

What's the purpose "ctor" here? i.e. Why not just do "new Intl.Collator(locales, options)"? Is it just to demonstrate the other constructors have the same arguments?

`ctor` could be an array and `instance` could be initialized for each index in the array. I've done stuff like that when initializing Backbone views awhile ago.

It is amazing how complicated internationalization is when you actually need to do it right.

And I am continually amazed by how good the solutions Unicode and the CLDR provide are. It's complicated, because the domain is complicated.

Bringing these tools to JS in the browser is great.

Formatting is nice and all that, but if you have input fields, then parsing is equally important. I don't see any of that in this api.

It's great that intl is getting more visibility! If you're working with intl, please make sure to use standard only methods. I've recently noticed v8 has some legacy/nonstandard methods exposed on stable build. As expected I've already filed a bug on v8 regarding this issue but a heads up for the developers.

It would be a little more clear if they compared it to L20n[1] (their internal Mozilla browser localization API) and how this is going to bring those open standards to browsers.

Let's get deeper than money classes.

[1] https://wiki.mozilla.org/L20n/FAQ

Just mention that L20N is not being used in Gecko/Firefox yet (if that's what you mean with internal Mozilla browser), even if they have been cooking this for years.

To give more insight: L20N is a localization format plus its backing libraries which adds some "scripting capabilities" [1] thus empowering localizers, who will be able to leverage some logic to make their localizations feel more in par/natural with the grammar rules of their target language.

The post OTOH is an overview through the implementation of the ECMAScript i18n API in Firefox, which has been available to developers since Firefox 29. As it mentions, the browser itself includes general language knowledge (think of it as system locales in a UNIX env., which knows how to format dates, times, currency etc. for a given locale), gathered from Unicode CLDR and the ICU i18n library.

[1] Check out the examples at http://l20n.org/

Technically it's an ECMAScript API :)

The fuzzy search examples they give look as though they'll save a lot of time for me. Seeing as Mozilla says it's implemented in JavaScript, I think I might see if it it's easily turned into a standalone I18n library for node.js

Technically it's not pushing external libs into a language, it's pushing the functionality into standard libraries which expose objects. Nice!

Now if only PhoneGap was natively implemented. At least web-based notifications from websites!

http://formatjs.io/ provides a nice set of integration libraries wrapping Intl for Handlebars, React, and Dust.

I wish more sites would use this (even with a fallback). Twitter right now is showing me timestamps in Pacific time because they trust their geolocation too much.

Is there anything in these tools that will help web apps determine your timezone any better then they can now? I did't catch that. I'm not sure how they possibly would.

Well, I'm not sure if JavaScript's date constructor has issues with accuracy, but I'm pretty sure you can get the timezone offset in minutes using the following:

    (new Date()).getTimezoneOffset()

I'd assume it's returning the system time zone offset, and for me it's correct.

This is pretty nice! One thing I wish were mentioned is pluralization. I see far too many checks for length !== 1 in JS code.

That should directly be a part of the templating language directly. Since this js parses your DOM, add a helper to the template language (if it doesn't already exist), spit out the pluralized version, then localizejs will take over.

A good start!

However, how come the time stuff isn't sorted out yet? Why do I still have to use MomentJS?

> Server roundtrips just to format amounts of money. Yeesh.

Really? Why not just use a browser-based js library?

I don't really care much about i18n and I don't think there's a library around that does all the stuff mentioned in the post but it am I missing something to assume you could solve this without server roundtrips?

The problem is for a generic library, and for some locales in particular, you need huge data tables to do it accurately: it may well be cheaper to just do it server-side rather than move those data tables over the wire.

Agreed. This is probably the biggest upside to browsers providing localisation natively - it saves roundtrips or downloading large tables.

I am almost sure initial implementations will fail for Turkish. "sorting": probably, "Upper-lower casing" most likely, "pluralization" definitely will fail.

Reply on news.ycombinator.com