5 ms·

JavaScript Internationalization API

93 points by Garbage 12y ago

xtrumanx 12y ago
> 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 12y ago
  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 12y ago
    Agreed. This is probably the biggest upside to browsers providing localisation natively - it saves roundtrips or downloading large tables.
EGreg 12y ago
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!
cj 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      Security guidelines to not have any 3rd party JS.
      - chrisrogers 12y ago
        You could audit the code yourself and self-host.
        spacefight 12y ago
        Sure, if the license permits that.
- thomasfoster96 12y ago
  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!
tlrobinson 12y ago
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 12y ago
  `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.
sutunc 12y ago
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.
afsina 12y ago
I am almost sure initial implementations will fail for Turkish. "sorting": probably, "Upper-lower casing" most likely, "pluralization" definitely will fail.
dgl 12y ago
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 12y ago
  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 12y ago
    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 12y ago
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 12y ago
  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 12y ago
A good start! However, how come the time stuff isn't sorted out yet? Why do I still have to use MomentJS?
jrochkind1 12y 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.
califield 12y ago
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 12y ago
  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 12y ago
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
1945 12y ago
http://formatjs.io/ http://formatjs.io/ provides a nice set of integration libraries wrapping Intl for Handlebars, React, and Dust.
jaachan 12y ago
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.

93 points by Garbage 12y ago

> 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 12y ago
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 12y ago
  Agreed. This is probably the biggest upside to browsers providing localisation natively - it saves roundtrips or downloading large tables.

EGreg 12y ago

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!

cj 12y ago

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 12y ago
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 12y ago
  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 12y ago
    Security guidelines to not have any 3rd party JS.
    - chrisrogers 12y ago
      You could audit the code yourself and self-host.
      - spacefight 12y ago
        Sure, if the license permits that.
thomasfoster96 12y ago
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!

tlrobinson 12y ago

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 12y ago
`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.

sutunc 12y ago

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.

afsina 12y ago

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

dgl 12y ago

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 12y ago
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 12y ago
  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 12y ago

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 12y ago
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 12y ago

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

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

califield 12y ago

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 12y ago
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 12y ago

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

1945 12y ago

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

jaachan 12y ago

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.