JavaScript International Methods

Photo by Tim Gouw on UnsplashIntroductionI’m lucky in that the company I work for is based mainly in the US and in English, with a few additional locations in Mexico and Canada.

This makes my job so much easier because I don’t have to worry much about internationalization: not about converting to different date formats, not about the idiosyncrasies resulting from language translations, and certainly not about the oddities regarding lists and currencies in other countries (really — who puts commas after periods when it comes to money??).

Just because these aren’t my problems though, doesn’t mean they aren’t incredibly painful for other engineers.

As an example, a lack of international standardizations (and the inability to convert numbers) resulted in a mismatch of metric units versus English units, causing NASA’s Mars Orbiter to completely miss entering orbit around Mars in 1999, to the tune of $125 million.

Oof… Source: https://www.

reactiongifs.

com/picard-facepalm/While the sums of money my software development team works with aren’t quite so large, and our errors result in bugs in the code we can usually fix in a matter of hours or days, I can definitely empathize with the NASA engineers, and I cringe thinking about how one simple mistake like not double checking everyone was using the same measurements in Orbiter’s code caused such a loss.

Which is why, when I heard the ECMAScript Internationalization API had recently been released, I was excited to see what kinds of improvements were about to make JavaScript around the world better and more standardized for everyone using it.

Today, let’s check out some of the best parts of Intl: the ECMAScript Internationalization API, which provides language sensitive string comparison, number formatting, and date and time formatting.

International Date Time HighlightsAs per usual, Mozilla’s MDN Web Docs, give the best summation of the new international API, and the properties that come with it:The INTL object provides access to several constructors as well as functionality common to the internationalization constructors and other language sensitive functions.

— MDN Web DocsThere’s six properties that come along with the new Intl object, but in my opinion, only five of them deserve their own place in this blog post.

Intl.

DateTimeFormatIntl.

RelativeTimeFormatIntl.

ListFormatIntl.

NumberFormatIntl.

PluralRulesSo without further preamble, I’ll dive into the first property: the international date time format.

International Date Time FormatYes, we’ve all been there.

Yes, it’s really this much of a nightmare with dates and times.

The Intl.

DateTimeFormat object is a constructor for objects enabling language-sensitive date and time formatting.

At its most basic, the date time format takes in locales and options objects and outputs formatted time stamps based on those options.

Here’s an example using locales from around the globe to format this date variable.

format(date));// expected output: "19/12/2012"// Include a fallback language, in this case US English with the Buddhist calendarconsole.

log(new Intl.

DateTimeFormat(['en-US-u-ca-buddhist']).

format(date));// expected output: "12/19/2555"In addition to being able to pass in locations, users can provide additional parameters strung together with the location, like:nu — the number systems used in different countries,ca — the calendar to use,hc — hour cycle ( h11, h24, etc.

).

After the additions to locales, comes the optionaloptions object which can include properties like:timezone — this can be either "UTC” or something like"America/New_York",hourCycle — once again, specs like "h12" or "h23",and my favorite one: formatMatcher — this algorithm can take in properties used to describe date-times and format the outputs to match.

format(date));// expected output: "12/19/2012, 19:00:00"// to specify options but use the browser's default locale, use 'default'console.

log(new Intl.

DateTimeFormat('default', options).

format(date));// expected output: "12/19/2012, 19:00:00"This is such a cool feature.

It’s going to make it so much easier to translate dates and times properly and format them in so many specific ways that packages like moment.

js, made specifically for parsing, validating and manipulating JavaScript dates and times, will become unnecessary.

The next property I want to segue into, since I’m already on the subject of dates, is international relative time format.

International Relative Time FormatThe Intl.

RelativeTimeFormat object is a constructor for objects that enables language-sensitive relative time formatting.

Similar to the Intl.

DateTimeFormat, this object takes in a locales parameter and an options object.

The locales parameter functions exactly the same in this relative time format object as it does in the date time format, so I’ll skip any further explanation here.

As for options, the Intl.

RelativeTimeFormat has a variety of additional properties it accepts:localeMatcher — a locale matching algorithm, with the options "best fit" or "lookup",numeric — the format of the output message,style — the length of the internationalized message.

style follows the same lines as weekday, in that it has three different values:"long" (default, e.

g.

, in 2 months),"short" (e.

g.

, in 2 mo.

),or "narrow" (e.

g.

, in 2 mo.

).

narrow and short could be the same depending on the country.

Below are some samples using Intl.

RelativeTimeFormat in various locales and with various options passed to them.

format(-1, "day"));// > "1 day ago"// Format relative time in English using positive value (1).

console.

log(rtf.

format(2, "day"));// > "in 2 days"Once again, super handy that we, as developers, don’t have to deal with the logic of formatting days or hours or even some words, in multiple languages no less, according to the number passed in.

No complicated if/else if/else logic blocks or even ternary expressions.

With the help of Intl.

RelativeTimeFormat just specify the language to use, the numeric output and the style and it’s good to go.

Nice!.????On that note of the Internationalization API, let’s look next at another thing that varies quite a bit from language to language: how lists are formatted.

International List FormatIt’s tough enough transforming an array in one language into something that resembles a human-readable list with ands or ors added in, try doing that in multiple languages.

The Intl.

ListFormat object is a constructor for objects to enable language-sensitive list formatting.

As is becoming the recurring theme of this article, the first optional parameter ListFormat accepts is a locales specification.

The second object is options with parameters like:localeMatcher — the locale matching algorithm, same options as with Intl.

format(list));// expected output: "BMW Volvo Audi"How awesome is it that finally, finally there’s a built-in API that can make lists look good?.Heck, I’d take this even if it was only available for English-speaking countries or English language-only applications, this is so useful.

But wait!.I’ve got another incredibly useful constructor to introduce: the number formatter!.????International Number Format ????Make it rain, everybody.

七八九// when requesting a language that may not be supported, such as// Balinese, include a fallback language, in this case Indonesianconsole.

log(new Intl.

NumberFormat(['ban', 'id']).

format(number));// expected output: 123.

456,789In my mind, for an international company or website, this has got to be a huge, huge selling point for the Internationalization API.

Instead of hand-coding for all the varieties of currency differences that exist, we can rely on a single API to handle it for us — what a logic and time-saver!Ok, time for the last property I’ll cover today: Intl.

PluralRules.

International Plural RulesWhen you think about rules for plurals in English, the rules are hard: “ one dog” becomes “two dogs” but “one goose” becomes “two geese”, “one” becomes “two” but beyond “two” becomes “a few” or “many” or “other” when describing some vague, larger numbers of items, and so on and so forth— are you starting to see where I’m going with this?Now imagine needing to know unwritten rules like this in more than one language… ugh.

????Well, this is where the International Plural Rules becomes a life saver.

PluralRules('en-US', { type: 'ordinal' });// examples using US English and `options type` specificationconsole.

log(pr.

select(0));// expected output: 'other'console.

log(pr.

select(1));// expected output: 'one'console.

log(pr.

select(2));// expected output: 'two'console.

log(pr.

select(3));// expected output: 'few'console.

log(pr.

select(4));// expected output: 'other'Pretty nice, huh?.I’ll admit, of all the Intl methods, this is less widely applicable than some of the other methods included, but I’m sure it will still have its moments where it’s just the ticket.

It is also worth noting that this method is still in “Draft” status, with the comment “initial definition” in MDN’s docs, so I would hold off for a while longer before attempting to rely on it completely in production.

ConclusionTranslating websites and applications for use in different countries and languages is tough enough, but being able to correctly handle things like date time formats, currencies and lists of items with their many language-specific rules is a real challenge.

The newest version of the ECMAScript Internationalization API aims to make some of these arduous tasks easier by letting its methods do the formatting for you, based on locales and whatever other options you might want to specify.

For JavaScript developers working with international requirements, this stands to be a huge boon, and I for one, am looking forward to incorporating these new features into my own applications just for the total convenience these properties provide.

Check back in a few weeks, I’ll be writing about JavaScript, ES6 or something else related to web development, so please follow me so you don’t miss out.

Thanks for reading, I hope you see the value the ECMAScript Internationalization API can provide to your applications, and are able to incorporate some of the properties into your web apps in the future.

Please share this with your friends if you found it helpful!If you enjoyed reading this, you may also enjoy some of my other blogs:4 Solutions To Run Multiple Node.

js or NPM Commands SimultaneouslyViewport Units, the CSS You Didn’t Know About But ShouldJavaScript’s Async/Await versus Promises: The Great DebateReferences and Further Resources:ECMAScript Internationalization API, MDN Docs: https://developer.