Hi, my name is Bob Jung.
I manage internationalization at Google.
We know language and culture differ across the globe.
Adapting your app correctly is critical to providing
a great user experience.
But what does this actually mean for software?
First, let me demonstrate how getting it wrong
can be incredibly jarring.
Suppose I gave this talk speaking like Yoda.
Bob Jung, i18n Google Director I am.
I18n what and how about, I will talk.
Did that sound strange?
Maybe a bit hard to understand?
Now, let's look at a real example that Google launched.
A long time ago, in a galaxy far,
far away, Gmail was still in beta.
One of the setting UIs concatenated preferences
to form a sentence reading, forward a copy of incoming mail
to email address, and keep Gmail's copy in the Inbox.
Seems feasible, right?
Then we translated to Japanese.
That translation has the correct meaning,
but sounded like a Japanese Yoda.
Something like, receive messages to the following
address forward mail address, and copies in inbox keep.
Because word order can be very different for languages,
a cardinal rule is to never concatenate phrases.
Now, let's look at a few other things
that will help you internationalize successfully.
Many assume that internationalization is just
about translating all the strings in the UI,
but it's really much, much more.
It impacts back end, as well as front end software.
It affects the whole software stack, including
data storage and protocols; formatting dates, times,
numbers, and currency; entering and displaying of text;
sorting; displaying bidirectional and right-to-left
text for languages like Arabic and Hebrew;
local calendering systems; and of course,
your UI design and much more.
And i18n is not just implementing
basic functionality correctly.
You must design i18n from the beginning.
If you don't plan ahead, things are bound to go wrong.
Now here's an example where Google failed to plan for i18n.
Long ago, pre-YouTube, we had a product called Google Video.
That product launched in the US, and didn't
worry about internationalization.
This diagram shows the data paths
for uploading, indexing, and serving user videos.
The product team told us they used Unicode.
So what possibly could go wrong?
How about uploading a Beyonce video?
You'll notice that she has an accented E in her name.
That accented E broke every single data path
for various reasons relating to non-ASCII data.
Some problems are hard to find.
Some even corrupted user data.
It took several engineers many months
to find and fix all these bugs.
All of them could've been avoided with correct design
decisions, and using existing programming techniques.
Doing so would have had very little impact
on the original development effort and schedule.
So code to implement many of these i18n features
are provided by libraries in APIs.
Now, we don't recommend that you try to write these yourself.
There's a lot of unobvious complexity.
There's no reason for you to reinvent the wheel.
The work has already been done for you.
Hundreds of engineering staff years
have gone into their development.
Massive amounts of data for these APIs
have been collected and vetted.
Two key examples are CLDR and ICU.
CLDR contains tens of megabytes of language
and regional data that drives the i18n APIs.
Experts around the world continue
to compile and vet this data.
This graph of CLDR data shows the amazing growth
of that data over the past 10 years.
So it would be very difficult to replicate this on your own.
Tried, true, and trusted.
ICU is a mature, widely adopted library,
with quite extensive features.
It's embedded in Android, Chrome,
and other companies' platforms.
Because it underpins APIs on these platforms,
you might be using ICU indirectly.
And it's open source, it's free to anyone to use.
It's used by major companies and major products.
And here are a few of those.
Besides ICU and CLDR, there are just many more tools
to help your i18n efforts.
Now, besides APIs, your apps need platform support
to display text in your users' languages.
Google has developed the Noto font family,
which covers hundreds of languages.
Noto is embedded in the Android and Chrome OS.
It's also open source, so it can be
used by any other platform or app.
The platforms also provide input services
that let your apps get input from your users
in their own languages.
There's keyboards for alphabetic language-- Chinese, Japanese,
Hindi, Korean, and more.
Gesture for swiping, emoji, virtual cloud-based keyboards,
and of course, handwriting and voice.
Now, as I mentioned, i18n touches nearly
all your software stack.
Make sure you test it all.
But I want to mention one very useful tool.
Before you spend your money and your valuable time
translating your app, how do you know it's going to work?
Some of you may have had the experience of getting back
a translation that was just a mess because
of hard coded strings, broken UI layouts, and problems
with displaying non-ASCII characters.
Pseudo-localization automatically
creates fake translations.
These allow you to test and debug
without knowing another language.
The strings are transformed to expose
some of the problems I just mentioned,
but they're still readable to you.
Now here, the string, "Share what's new,"
was made longer by adding, "one, two, three," to the end.
All the ASCII characters are converted
to similar-looking non-ASCII characters.
Now you don't need to know German, or some other language,
to test and debug your app.
And the tools will automatically pseudo-localize all the strings
in your UI to help you find those problems-- the hard coded
strings and UI layout problems.
Now, if you look closely at this example,
it found a real problem.
In Google+, you could see that the icons were being clipped
by that long text.
On the right side, you've lost the side of those icons.
Now, once you've completed all this-- design for i18n,
used the APIs, and tested your app, you're ready to translate.
The process is pretty well known.
You extract the resources and send them for translation,
rebuild the localized apps, test, and repeat.
Now Google provides a simple and streamlined process
for Android and Chrome apps.
This is covered in a related Google I/O talk.
Check out, "The world is your playground--
go global with Google."
To get your app ready for global users,
make sure you visit these links to learn more.
I hope this video will help you produce
some great apps for the world.