
JavaScript Internationalization API - Garbage
https://hacks.mozilla.org/2014/12/introducing-the-javascript-internationalization-api/
======
cj
Shameless plug: I've been working on a i18n / localization SaaS for about a
year now called Localize.js
([https://localizejs.com](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.

~~~
spacefight
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?

~~~
cj
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?

~~~
spacefight
Security guidelines to not have any 3rd party JS.

~~~
chrisrogers
You could audit the code yourself and self-host.

~~~
spacefight
Sure, if the license permits that.

------
tlrobinson
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?

~~~
fourstar
`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.

------
jrochkind1
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.

------
jaachan
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.

------
sutunc
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.

------
califield
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](https://wiki.mozilla.org/L20n/FAQ)

~~~
julenx
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/](http://l20n.org/)

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

------
EGreg
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!

------
1945
[http://formatjs.io/](http://formatjs.io/) provides a nice set of integration
libraries wrapping Intl for Handlebars, React, and Dust.

------
dgl
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.

~~~
jrochkind1
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.

~~~
thomasfoster96
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.

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

~~~
fourstar
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.

------
angersock
A good start!

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

------
xtrumanx
> 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?

~~~
gsnedders
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.

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

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

