JavaScript apps go Int(ernationa)l
4_Phil Nash: What's up everybody?
I'm excited to talk to you today about internationalisation or indeed, if you're from the U S you might want to talk about internationaliZation, with a Z for some reason.
But either way, I want to talk to you about how JavaScript can help you build applications that cater to your users and format information in the way that they expect to see it.
If we want to get over the Z or S problem, we can just abbreviate this down to I18N , that 18 stands for all the letters in between, I and N in internationalisation.
And of course you can use this for any long words that you want to, or short words if you want.
So my name is P6H or indeed my name is Phil Nash.
And I'm a developer evangelist at a company called Twilio.
If you do ever want to talk to me or ask me questions about Twilio or any of the things we covered today, do feel free to drop me a line.
I'm pretty much Phil Nash all over the internet or philnash@twilio.com.
Just drop me an email.
Cool.
So I want to talk to you about events to start with, cause this is what got me interested in how the internationalisation APIs work in JavaScrip.
Before the pandemic, I was very fortunate to be able to travel to events and speak at things like this.
In-person with people.
And when you do that, You might get asked a question like what time are you speaking?
And this was relatively easy to answer.
You might be at 1 in the afternoon.
And if you say that a whole bunch of context is brought with that such as you know what the time zone is and the location of that talk is and so people could pretty much easily arrive in the room at 1:00 PM.
When you're speaking.
But when you're online, you lack a lot of that context.
Indeed.
We have the fortune that event organizers much like like uh John and Web Directions pivoted to turn things online.
And we've had whole bunches of online events, which have been great.
But the context for what time are you speaking?
Or what time am I speaking?
Which was really the difficulty I was having was the context around things.
You see Dates, dates and times have a whole lot of context that come with them that you don't necessarily think about in day-to-day life, especially not when you're, in-person in the same country.
So this date might well be the 6th of August, 2021.
And I might read this date is the 8th of June, 2021, but if I was in the UK, it would be 6th of August, and so with that.
If in the U S, objectively that is wrong and this map from Wikipedia proves how wrong it is.
The red countries that they labeled, there are the ones that use month month /day / year year year year as a format.
And it's just wrong.
But again, I'm willing to overlook that because I'll be able to format these dates for the correct audience in the correct way for the correct audience by the end of this talk.
There's further context though, because the 6th of August, 2021 in one place might well be the 8th of May?
No, this is the 5th of August, this 5th of August, cause there's Australia and the U S the way that time zones and international date lines overlap may mean a different day is a different date is the same day for people.
So all of this context is a problem.
And in reality, displaying a time online on a website requires much more than just just the number, just 1:00 PM.
You need to know the time, but also the date and the place, and maybe even the language, the person speaking and not just the place where it's happening, but the, you know that is compared to the place where the person who is reading this time is so there's all sorts of confusion going on there.
So this is where I started digging in to how the platform can help, how JavaScript can help.
And what I found was that we have the ECMA 402 task group.
It sits under TC 39 as part of ECMAScript, and this task group is dedicated to creating a whole bunch of APIs under the INTL namespace.
And these APIs are dedicated to formatting or providing rules for us to help us format text and other things for users depending on where they are in the world.
So let's take a look, let's dive right into what that means.
By looking at dates and times cause that's what my problem was in the first place.
And so, under Intl.
We have the Intl date, time format API, this allows us to provide a date and then format it for the user who is reading it.
So let's jump into the consol.
And have a look at that.
So I have a date I'm going to go with this is 1:00 PM on August the 6 th 2021.
And using that date, I can then create myself a, an Intel date, time format.
I can create a plain one to start with and use it to format that date.
And then we go, we get it in 06 0 2021 because uh uh this uses my default language format for it.
And my default language format, well I can find that out, if I just actually look at an Intl date time format, it doesn't matter what I do with it.
And then look at the resolved resolved options.
This is what the date time format knows about me and knows actually have my locale set to ngb because I'm originally British and apparently I can't get over that and set it to nau cause I'm in Australia.
But it also shows my calendar's Gregorian uh uh the default day month and year format and my time zone as well.
So this knows not only where and when I am but how to format that as well.
So that's pretty cool because if you actually look back up at this date here, this is an ISO 8 6 0 1 date string JavaScript format using just UTC time.
And so this is 3:00 AM UTC on the 6th of August.
But if we format this date and I'll give it some other options.
So I am ngb, but if I give it some options like I actually want to see the hour hours to be numeric.
And a minute to be numeric and second to be numeric.
And thus, I will show a time, a second.
It was It wasn't numeric.
And formatt that, I can see this 3:00 AM UTC time is actually 1:00 PM in Australia, and we can go bigger than this as well, Like let's let's take a whole bunch of options.
For example taking the time zone to be in Paris and then setting a whole bunch of the other things let's format our dates.
And we can see that that in Paris.
It's 5:00 AM central European time.
But I also need to point out that we can set a different language here and then get the date, the time, everything here in French as well or any language we want to do any language that the platforms support.
So Date Time formats allow us to go for a date string that has initially only UTC time available to it and format it and produce it in the correct language, the correct time zone and even the correct format for what you wanted to look at.
Let' s just look at one last thing, which is uh you know you can format it in month/ day/ year format for for those that wanted.
So that's Date Time Format.
We also have access to relative time, which I think is really cool.
Relative time is interesting, because Date Time Format does produce you a full formatted string that you're allowed to see, whereas Relative time, it gives you a format, but it's also a bit of a building block as well.
Because it actually requires you to set a time period and an offset, and then it will give you the translation about how you format that time set time period and offset is up to you.
So let's look at our Relative Time Format and again, dive into the console to see it in this case, we're going to look at Intl Relative Time Format.
Let's do it in au, why not?
And format for example the time that is three n hours.
So this is three hours in the future in three hours.
So it gives me that and and uh you know I can then get that, you know the languages.
Which is great.
And I can also do it backwards.
So minus three hours is three hours ago.
That's pretty cool.
But what I mean by this building building block is that if we said that right this was, you know 24 hours ago.
You might want that to say one day, but you don't get the opportunity for that.
Indeed, you know you can keep going up and it's just going to keep telling you how to format it and hours instead of days.
So one day ago is the one day ag.
One of the nice parts about this though, is we can actually set the uh Uh change here to use auto numeric.
So um if If a string version of this time period exists, we can use that to display it.
So here yesterday and indeed tomorrow and we can have things also, like next year and last year for this kind of non-numeric version, which I think is very very cool.
And again, that still works.
If you change the language as well, it So uh works in French as well.
And that what's in the future.
la en production, of course.
That's all the French you're going to get out of me for this for this one.
So Relative Time Format is very cool, but if you want to do an automatic kind of ability to change from minutes - to hours - to days - to months - to quarters - to years you have to write the code for that.
So it still becomes a building block.
Plurals, therefore get even more into the building block territory.
So plurals in Intl API are indeed rules and not formatters.
And pluralization is difficult because it actually needs you to have the translations of the words available.
Sadly our browsers do not contain or all languages and dictionaries and format is for all languages all over the place.
We started to provide our own translations.
And so in terms of plurals, we get rules and not formatters so you need your own translations and once you have them, we can start to make up or Cardinals and Ordinals for our languages.
So Cardinals are counting numbers, like 1, 2, 3 cats, for example, an Ordinals are like positional.
So first, second, third, fourth.
I have some cats to show you in a second as we look into what this API looks like.
So as I said, it comes as a bunch of rules.
And so if I were to, for example, let's just take a look at Intl plural rules for English.
We get an object here and that object has it actually has a method on it called select in which you give it a count.
And so this actually returns you, what kind of plural this is and so in English we have one or other because we have a singular and a plural.
And so if we actually look at an example here, I've got a function which is going to pluralize the word Cats.
And in this case, we get the suffixes like no S or S for one or other.
And I can say for any number of cats one cat, one cat, two cats is two.
And you know it doesn't matter how many we add.
It's always going to have an S on the end.
Now you might think that was the same for all languages.
In the research for this talk.
I discovered that one example is Welch in which there are six potential counting version 0 1, 2, few, many, and other catch up there.
So I'm definitely not going to try and pronounce this in Welsh.
But if we if we look at plural Welsh cats, I go with zero, you can see we'll have zero cathod.
I genuinely don't know how to pronounce it.
You might see that one and two are the same, but one and two could be different in Welsh.
Just cat happens to be the same three falls under few.
And in fact, so does four and five up until six, which has many it turns out and then seven, which is other.
So um When you are translating this kind of thing, this is where you need your your translation.
But the platform itself can give you how to pluralize this and give you the options for this.
So I think that's really interesting.
I just want to show you Ordinals as well.
Cause it works kind of the same, but you can just see here.
Okay.
First, second, third, and fourth instead.
And so if you set up your plurals and type Ordinal, it will give you different suffixes.
And so in this case, if we format English Ordinals, we get one, we get first we get second, third, fourth, and beyond there, we continue to use TH even zeros zeroth.
So that's what those rules can give us.
Let's move on.
Numbers seem like they would be really easy to format for people to see.
But I'm not talking about just numbers in terms of strings of digits, formatting of numbers requires, you know separators and things to make it more obvious how things work.
And so for that, we have our Intl number format.
And I'll just, as I start writing this out, I want you to think about how you might write down like a really large number.
Um uh I need I need a new Intl format number there and let's do it in AU again.
And we're going to format yeah, a number that's 1, 2, 3, 4, 5, 6, 7.
That's a 1 million, 234 thousand, 567 eight, nine.
Cool.
You might think, yes.
I would write that out.
I put some commas in between numbers, every third number, maybe decimal place using a period and then eight, nine, and that's perfectly reasonable, but if we choose another English format such as Indian we would start to place the comments differently.
You might've seen that before, but it certainly happens.
And then if we were to go say to Germany with this then we can swap the periods and the commas.
And if we go to France, then uh we'll we'll just drop those periods here, but the ones between separating the things, just put a space in there.
That's fine.
Moving on.
We don't just want numbers, but there's units as well.
So when we're thinking about our our interfaces.
Units are actually important, especially one that definitely comes to mind is prices in terms of what you might be displaying for people online.
And so if we have a number format in AU and we'll set the style to currency.
And we'll set the currency itself to AUD for our Australian dollar.
Then we can format a number like 999.
And that's going to give us $9 99.
Brilliant.
What's what's interesting about this is if we then take off the context that we're actually in Australia, that's going to tell us those are Australian dollars.
So that's a good start.
And then as we, you know move into other languages we see that we start to use the comma there, but also it changes where the currency, where the the symbol uh kind of sits.
And so now we have $9.99 Australian dollars in French, same, I think in German also moves it to the back or in this case, then we get Australian dollars.
I suppose it's French is 999 dollars Australian and the German is 9 99 Australian dollars.
But if we ever want to provide price to somebody online and we want them to recognize and read it in the way that they expect the format.
They want to see this number format and the style, and this currency is going to do that for us.
We can also format, for example, a unit.
So the style will be unit other units other than currency.
So we have a style of unit and we've been set the units to be for example, megabytes.
And if we format say 256 of them that's going to get us 256 MB.
I can actually ask for the unit display to be even longer than that because we have the full translation.
Long and to be general megabytes which is what we had in the first place.
But then we can change the language into say French for mégaoctets and let's see what German does as well, just Megabyte, but with a capital M it's important.
So this units available in the number format as well.
Now those are the Intl APIs.
I want to show you today.
There are more available, but I want to take a quick diversion off into web components.
For these things, I thought it was really important that we should be able to use them and use them easily and using them easily doesn't tend to mean writing JavaScript that's going to run over your page, find all the places that you need to format something differently for somebody, and then provide and perform these Intl APIs over them.
And when I came to using and working with that to date time format in the first place, I definitely thought that this could be a more declarative thing.
And so I ended up writing a web component myself for it.
It's called time formatter, and you can find out my get hub.
I'll give you a link for that in a minute.
And with the time formatter, you just provide a date time attribute on the element using that ISO 8, 6 0 1 format.
To give it as much context as possible.
And then you can have a fall back date inside the element, and then it will display the time in the dates all the time in the format that you want.
You can also add other attributes to say how you would like to display it.
I thought that was really useful.
It's really simple.
There is another one also built by GitHub, which does a few more things and I think actually manages to restrict it to just English.
If that's, if you want to keep your dates or keep your entire site in that language and such.
Github time elements they actually have one for Relative Time Format as well.
And finally, I just want to talk a little bit about the future of Intl and 402, basically if you've been sat here thinking.
I am internationalized and localizing sites all the time.
And I have I APIs for this, that, and the other.
And I didn't even see a version.
I didn't see an API for that within uh uh Intl today.
Then you can help you can help pave these Cowpaths.
And I say pave for cowpaths because ECMA402 are constantly looking for more things that can be brought into the browser that help with internationalisation and localization of sites.
As I said with the plural rules, we can't just include translations for everything inside a browser.
But if there are libraries out there that you're using or building that do individual elements, things like times or numbers like this and include shipping a bunch of translations to the front end.
Then those are the kinds of things that have that are candidates to become a proper platform API.
And so if you have something like this, then head on over it's under the TC 39 organization on ECMA402 to the read me is right there, and will tell you how to start getting involved.
These APIs go through the same process as any other JavaScript API with a stage zero to stage four process of checking them out.
And you can also, at the read me here, see the other proposals that are in state influx as well, including some improvements to the ones we've seen today.
Other than that I implore you go out there and find ways that you can make your applications work for the people, who are viewing them at the time.
Give them the context of their own language, of the way they format things and how they expect to see things like dates, like times, like numbers, currencies, all of that thing.
The platform is there for you to go out and use the platform and make this a more international web and give people that context.
Thanks again.
my name is Phil Nash, a developer evangelist for Twilio, and I would love to answer your questions if I'm in the chat or just drop me a note online and thank you very much.