talk

### Intro

Hello everyone,

Thanks for having me. It's a pleasure to be here again. My name is Rafael
Xavier, I'm the project lead for Globalize, which is one of the jQuery
Foundation projects, specifically the one about internationalization.

I'm also part of the ECMA-402 working group, which is the web specification
thing, alongside with Steven Loomis and John Emmons which are here at the
conference.

I've also made a couple of other related but smaller things, like having created the
mailing list that today is ECMA-402 official discussion list and created JavaScript
libraries for making it easier to develop using CLDR.

~~~ Why is internationalization important?

Skipped due to be among globalization experts...

~~~ What is it about?

Skipped too...

When I talk to developers in general they think it's about translations to
non-English languages, which is true but not in its entirety. So, I argue that
i18n is about "talking" in general, it's about making machine language
understandable for humans. Every applicaion at some point has to "talk" to its
users (I hope). This is, to display information to them, i.e., messages that may
require pluralization support, gender inflection, date formatting, number
formatting, currency formatting, etc. Even in English, it might be tricky to get
that done properly.

### Application

~~~ ICU
~~~ (stop) Application using crazy regexps to format them

On programming languages like C, C++, Java and others we have ICU. But, on JavaScript
we have (crazy regexps)... I wasn't convinced by this answer and keep trying
until I found...

### Develop using Intl

~~~ Application using Intl

... we have Intl, which is the browsers' native API. As of today, it supports
number formatting, currency formatting, date formatting, and collation. It's
exactly what we are looking for, a function that we can call and pass the
locales that we want support for and say what we want displayed and it just do
the right thing for us.

~~~ Intl.NumberFormat
~~~ Intl.DateTimeFormat
~~~ Intl.Collator

IE/Edge      Firefor  Chrome  Safari   Opera        Android Browser   Node.js
Yes IE>=11   Yes      Yes     No       Yes          >=4.4             Yes
                              No iOS   But mobile                     *English only by default

Intl would be perfect if it wasn't for some problems. The drawbacks of using
native Intl as of today are:

Limited browser support: it isn't supported on all browsers and environments.
According to GlobalStats, Intl is supported for 67.82% of the global users,
which is a decent coverage. But, it also means it leaves 1/3 behind - including
iOS users which is pretty significant. Intl is supported on Node.js because of
the great work done by Steven Loomis. The only restriction is that Intl comes
with support for English only by default. If you need different locales, you
need to re-compile it.

Beyond browser support, another drawback is reduced functionalities. There are
functionalities NOT supported by Intl at all, they have NOT even been
specified. Common missing ones are message formatting, relative time formatting,
unit formatting, abbreviation; and even text segmentation, address formatting,
postal codes, phone formatting, and timezones.

ECMA-402 2nd edition is supposed to bring some new functionalities in. For example,
there's a draft made by Caridy, from Yahoo, for plural forms. But, it's hard to
say when all those missing functionalities are going to become part of the
specification and then be implemented and supported by the browsers.

~~~ MessageFormat
~~~ - Pluralization
~~~ - Gender Inflection
~~~ RelativeTime
~~~ UnitFormat
~~~ Abbreviation
~~~ Text Segmentation
extra
~~~ Address Format
~~~ Postal Codes
~~~ Phone Format
~~~ Timezones

### JavaScript libraries

To fill in the gap there are JavaScript libraries and here is where the fun
begins.

Each library has its own strenghts and weakness, which I and the lead developer of
several other projects tried to summarize in this link. Feel free to explore it
and pick the one the best suite your needs.

Today, I want to share with you some of the experience I had during this time
leading Globalize where I had to opportunity to discuss this topic with several
smart engineers from various different companies including a team at Twitter.

~~~ 1st CLDR as a peer dependency
~~~ - wrong data issue -> Ideal: resource loading + cldr as peer dependency.

Differently from Intl, where the implementation is already in the client, using
JavaScript library applicaions have to provide that support, they have to ship
that support to the client if it's a client-side application. Directly or
indirectly it has to ship i18n data.

Thanks to Unicode we have CLDR. But as we know, CLDR in its full form is very
large, especially for client side applicaions, (hundreds of MB) which means
that no JavaScript library includes it in its entirety. Usually, they specify
what data they need for their supported features and allow applications to
cherry-pick that data from the locales they need.

Some libraries choose to ship a preprocessed mix of data and code for each of
its supported locales, so we can include it in a script tag and use it. Its file
structure looks something like this and is usually: version X of the library
has version Y of the data, whenever there's new data available, a new library
release must happen, so the updates are made available to the end user. If
developer finds a problem with the data, he needs to patch the library. As soon
as a new update pops up and he downloads it. He loses his previous fixes. Unless
he keeps a list of patches that he can re-apply over and over and, hopefully,
not get any conflicts while doing so. It's a nightmare for maintenance point of
view.

~~~ package.json w/ cldr-data

Instead of that we believe a better approach is having library code
completely separate from i18n data. Data should be a peer-dependency of the
library as simple as that.

cldr-data is a module for npm and bower that holds the official CLDR in the JSON
format.

~~~ 2nd declarative code

We made Globalize to be really flexible, to be modular, to work in several
different environments, and to allow developers to control data loading, which
requires an imperative programming like in this example: require the modules you
need, load the data, set the locale, then use the library. But, most of it can
be usually automated. So, developer has a declarative programming experience like
he does using Intl, which is just use the library. By no means the idea is to
drop the original Globalize flexibility, but we suggest how to configure tools
like webpack to provide such automation.

The end goal is to make usage easier.

~~~ 3rd performance -> Runtime modules
~~~ - Large in its full form -> ideal: minimum set of code, minimum set of data.

Finally, being only easy to use on development is worthless if the final product
is bad. So, we've also managed to avoid performance impacts. There are two major
contributing factors for performance here.

One is load performance, which is especially important for client side applications
where you have to ship code. As I mentioned earlier, the data is considerably
large and even the small slices that libraries make may include a lot of data
that your application won't need. For example, a currency formatter includes all
currency codes for a certain locale. If your application uses US Dollars only,
all other loaded currency data is unnecessary. Similarly, a date formatter
includes all the localized translation names in several lengths (e.g.,
"January", "Jan", "J"). If your application displays dates using numeric form
only, all the loaded translations are unnecessary. We're talking about tens to
hundreds of wasted KB.

The other is related to runtime performance: generating the formatters are an
expensive operation.

On Globalize, we wanted to do something analogous to templating engines, which
can precompile templates during build time for optimal performance at runtime.
So, applications can get the smallest and fastest custom tailored bundle.

By smallest, I mean avoiding the inclusion of unnecessary code and data. No
unnecessary translation messages, no unnecessary CLDR data, so no bandwidth is
wasted.

By fastest, I mean having all formatters (number, currency, datetime, relative
time, etc) generated at build time. So, no CPU clock cycles are wasted on the
client.

### Solution

We've worked to get tools to do all that automatically. So, let me show you an
example application using Globalize and its static compiler configured on
webpack.

Please, note Globalize is unopinionated and its goal is to empower users to use
it the way they want. But, for obvious reasons, this example is very
opinionated. If you don't use webpack, don't worry. You should be able to
reproduce this in the tool of your preference. Globalize and its compiler are
pure JavaScript, so am sure it's possible to wrap it on a different tool. Also,
note that this example uses CommonJS but Globalize also supports AMD.

~~~ examples/app-npm-webpack

In this example, we've created two running environments.

For development, our goal was that coding was
- declarative, the default locale is set automatically, the data is loaded
  automatically.
- optimized for fast live reload, use plaing Globalize where formatters are
  generated dynamically, no need for compiling formatters here, so we get faster
  refreshs.

For production, our goal was to generate precompiled code for optimal
performance. It runs the Globalize compiler on our source code to figure out
the minimum set of data and modules we need and it generates the precompiled
formatters for the supported locales.

In the setup we're using here, it outputs one JavaScript file for all the
external libraries, one for all our application, and one for the precompiled
formatters.

Again, this is a setup we wanted for the example, this could be completely
customized for your own needs.

Show built sizes, it's not even gzipped. Show one of the precompiled JS.

The precompiled stuff: it's smart enough to reuse formatters. For example,
dateformatter and currencyformatter reuses numberformatter and so on.

~~~ Example - BTC as currency code

Remember the bitcoin case I've mentioned, let's see what it would take in
order to get that working

~~~ Example - React.js


~~~ Example - ECMA-402 + Globalize
~~~ Translation Table
~~~ How easy it is to create new features / new functionalities

~~~ - allow to amend or enrich data, BTC.

Allowing the developer to control the data loading has an interesting
consequence. It makes it so easy to amend any content, or even enrich it.

For example, I have recently heard that Kraken is using Globalize, although I
don't know any of the specifics. All I know that Kraken is a bitcoin trade and
bitcoin is the popular cryptocurrency and one usecase that came into my mind is
that unfortunately for them, bitcoin isn't an available currency in CLDR, so
they would not be able to format bitcoin currencies. But, it's so easy to enrich
CLDR with the missing data, so the library can re-use all of the existing
localized currency rules: for example: whether there is a space between the
symbol and the number and where symbol should be positioned (before or after the
number).

### Good bye
~~~ Call for action:
~~~ - use it (let us know if docs are unclear)
~~~ - contribute

I welcome you give it Globalize a try, let us know if the docs are unclear. If
you are already using it and needs additional support, let us know, also feel
free to jump in and contribute. Recently, Andrew Lunny from Twitter just added a
new module in Globalize, the unit formatting. So, it's made to be extended.

Help us to improve it.

Thanks