A truly global application will need to support many different languages and cultures. Translating static text is the primary concern, but what about more dynamic content? There are numerous formatting differences around the world for dates, numbers, currencies, and more — even between cultures using the same base language.
Translating this dynamic content on the web has traditionally involved specialised libraries with reams of formatting data, all of which needs to be loaded over the network. But today’s browsers are providing ever more in-built formatting options via the Intl.* APIs. This talk will give you an overview of what they do, and how you can support a wide array of locales without adding Yet Another Library to your stack.
Gilmore Davidson – Intl we meet again
— Simeon Johnson (@lostumbrellas) October 31, 2019
Internationalisation is hard to say, everyone just says i18n. Localisation becomes l10n.
Fun fact, this method of shortening a word is called a numeronym.
Key things to remember are that languages are not countries, locales are not countries, countries are not languages… don’t use flags to show languages! But the fundamental is that you are having to think about how content needs to work for people in places other than the place you happen to live in.
World-Wide Web, not Wealthy Western Web. – Bruce Lawson, 2016
The problem here is supporting i18n really well is mostly done with lots of libraries; and that has a cost, including a weight and processing cost. In countries where internet access is very expensive the code used to support the local language can be very expensive to download.
An attempt to bring this together natively is the
Intl formatting API. The general idea is to convert things on the fly instead of having to bring entire data sets for each locale.
Intl.numberformat for the vast array of ways numbers (and particularly currencies) can be formatted
Some common libraries like Numeral and D3-format are very light; but they still have a cost. Then when you add in the separate data for each locale it begins to add up; and even if you manage that in clever ways it’s getting very complex. Then how do you know your data is correct when you can’t read it?
Intl.DateTimeFormat for dates and times
In this case many of the libraries are really big. MomentJS is notorious for blowing out bundle sizes. Date-FNS is lighter but still needs its own data.
There are some new ones like Luxon that build on top of the new APIs, which is the best of both worlds. But still you pay the cost.
Intl.RelativeTimeFormat for “friendly” dates like “yesterday” or “3 days ago”
This is a very new API, so it doesn’t have a lot of options yet.
Open source libs: timeago.js, HumanizeDuration, date-fns – with the current state of the API you are probably still better off using these. But you should know what’s coming in the API.
Ignoring ListFormat and PluralRules for today.
Intl.Collator for sorting things – which is really hard across language, country and locale.
So that’s an overview of the APIs, can you actually use them? NumberFormat, DateTimeFormat and Collator have good support in modern browsers (and nodejs).
But the IE-lephant in the room is IE11, because IE11 won’t die until Windows 10 dies. Which means IE11 is not going anywhere in the forseeable future.
Surprisingly, IE11 does support NumberFormat, DateTimeFormat and Collator! The rest will need polyfills. The plus side here is that the data comes from the same source; and the API is the same. So it’s a good option to consider over libraries.
Do you need to use this stuff? As always… it depends. The product Gil currently works on is legally only able to operate in a single locale, so they’d be overkill. The open source libraries do a good job; and if your app can bear the weight they might work for you. But if your app needs to support lots of locations and needs to trim down the weight these new APIs might be ideal.
As always, it depends, and the choice is yours!
Read Gilmore’s script and see the slides for this presentation at his site: https://shoehornwithteeth.com/talks/web-directions-summit-2019-intl-we-meet-again/