> 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.
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.
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?
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!
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'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.
I am almost sure initial implementations will fail for Turkish. "sorting": probably, "Upper-lower casing" most likely, "pluralization" definitely will fail.
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.
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.
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.
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.
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
27 comments
[ 4.1 ms ] story [ 38.3 ms ] threadReally? 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?
Now if only PhoneGap was natively implemented. At least web-based notifications from websites!
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.
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?
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!
However, how come the time stuff isn't sorted out yet? Why do I still have to use MomentJS?
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.
Let's get deeper than money classes.
[1] https://wiki.mozilla.org/L20n/FAQ
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/
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