Google I/O 2012 - Developing for a Global Audience: Tools for Localization and Internationalization


Uploaded by GoogleDevelopers on 02.07.2012

Transcript:

MANISH BHARGAVA: OK.
Let's get started.
I'm Manish Bhargava, product manager for
internationalization and
localization efforts at Google.
And we have Andrew Warren, a product
manager in the same team.
He'll help us with the awesome demos that we have
lined up for you.
So today, we are going to talk about developing for global
audience for every web user, for every smartphone user.
Let's start by me asking you a few questions.
How many of you here speak more than one language?
Great.
How many of you here are Chrome developers?
How many of you are Android developers?
OK.
Looking at the audience, we'll focus more on the Android
developer perspective.
And then, how many of you have your app or product localized
in more than one language?
More than five?
More than 10?
More than 20?
More than 40?
Great.
You are definitely ahead of the pack.
So let's talk a little bit about what we're
going to talk today.
We'll start by talking about developing
for a global audience.
Is it worth it?
What does it entail?
How do I go about doing it?
And then once I've done it, how do I get the global
customers that I intend to reach?
In our journey of the what, [INAUDIBLE], why and how, we
will essentially also do an in-depth look at various
internationalization and localization tools
available to you.

So the very first question is is it worth developing for a
global audience?
To answer that question, let's first look at what is needed
to have a successful business.
You need users and a lot of them.
And you need revenue, and probably, a
lot of that as well.
But the question is where are these users located?
How do we get to them?
So let's quickly do a quick demo.

Here, we have the--

OK, full screen.
So what we're looking at is a gapminder.org chart.

We are looking at internet users in terms of how internet
users have changed over time.
We'll do a time travel starting from 1990 onwards.
The size of the bubble represents the number of
internet users.
So the bigger the size, more internet users in that region.
So let's start in 1990.
Only noticeable dots at this point are US and Japan.
And even within that scenario, it's mostly coming from
universities, I believe.
So now, let's fast forward to 2000.
Notice here.
In addition to US and Japan, we now also have some of the
European languages show up.
Now let's fast forward from 2000 to 2010.
And during this phase, I would like you to
focus on two aspects.
One is the explosive growth in terms of internet users in the
BRIC countries--
Brazil, Russia, India, and China.
And especially, look at the last five years.
So let's run through that starting from 2000 And notice
how it changed.
Let me, again, run it from 2005 again just to highlight
the difference.
So based on the chart, what is the percentage of internet
users that do not use English as a native language?
That is correct.

26% use English as their native language.
Now let's look at another similar chart.

This time, we are looking at cellphone users instead of
internet users.
And the size of the bubbles would represent number of cell
phone users over time.
Let's do a time travel starting from 1980 to the
current time.
So let's first fast forward from 1980 to 2000.
Notice the penetration or the number of cell phone users is
nearly very similar to what we saw in internet users with US,
Japan, and some of the European countries having
enough presence.
Now, let's do the same from 2000 to 2010.
What we see is very similar phenomenon that we saw in the
number of internet users.

The number of cell phone users have grown in explosive
numbers during the last five years,
especially in the BRIC countries.

OK.
So clearly based on what we have seen, you can nearly
triple the number of users by essentially developing for the
global audience.
And when you triple the number of users, you thereby increase
your revenue as well.
So let's look at the revenue numbers a
little bit more carefully.
So we'll talk about the Android opportunity available
to you from a global perspective.
Remember the keynote speech on Wednesday?
We talked about, and we showed on the world heat map the
explosive growth in terms of Android activations over the
last few years, especially outside United States.
The same is true for the app installs as well.
And we believe your app should now take advantage of this
huge opportunity.
And we have the right infrastructure in place for
you to do that.
So starting with Apps availability, the free Apps
are available in 190 languages--
190 countries.
And 132 of these countries have access to the
paid apps as well.
Globally, 92% of all Google Play users have
access to paid apps.
And not surprising, 67% of all Google Play revenue comes from
outside United States.
We have revenue infrastructure in place.
Carrier billing is available in seven key countries and is
expanding rapidly.
Why is that important?
Because 73% of all Google Play app purchases happens using
carrier billing when it is available.
And you also have access to all monetization methods that
include the in-app billing, paid apps, subscription, as
well as ad funded as well.
Last but not least, we have now the dev infrastructure in
place with the Wednesday announcement
of the new Dev Console.
You can now localize your listing in 22 languages as
well as tweak your international offerings based
on slicing and dicing on country and language
dimensions available on the analytics
section of the Dev Console.

So clearly, there's a huge opportunity
which cannot be ignored.
But the next question is, what does it entail?
How do I make use of this opportunity?
What you need to do to make this happen, the two things
that you need are internationalization and
localization.
Internationalization--
i18n, I followed by 18 characters and N. And
localization--
L followed by 10 characters and N.
What does internationalization mean?
It essentially means designing and coding to enable support
for languages, countries, and cultural differences.
It includes things like extracting your strings for
localization, presenting date, time, currency, number formats
in the local relevant form, sorting in language specific
ways, able to work on or process user input in the
given language.
It also means handling bi-directional display in
Middle Eastern languages, handling diacritics for
central European languages, handling double byte
characters for East Asian languages.
And what is localization?
Localization is the process of adapting the look and feel of
your app for languages, regions, and culture.
What does it entail?

Essentially, it includes things like translation, local
defaults, and custom features.
Let's take an example.
So what you're looking at is Google Sites, specifically the
image upload menu.
What is wrong here?
And again, I've given you a hint right there with
highlighting the region.
Anyone knows Arabic here?
What's wrong?
Yes.
Notice how in English, we have the size of the image-- small,
medium, or large--
where translated in Arabic, it actually became Saturday,
medium, and then large.
Why?
What happened?
Well, two aspects.
When this was sent for translation, the small,
medium, and large were sent as separate words and with no
description being provided.
And the second, when the translator got this for
translation, they had little context of where these were
coming from.
So again, S became Sat, which essentially was
translated as Saturday.
Let's take few more examples.
Here, what you're looking at is Google Earth mobile app.
And we are focused in the Zurich view.
Anybody from Zurich here?

Can you tell us what is wrong?
Notice how the two places, the names of the two places have
been garbled.
The non-ASCII characters have been removed, specifically the
u with the umlaut is not being displayed correctly.
This is clearly an example of an internationalization, or
i18n, issue where the text has not been rendered correctly.
When we talked to the engineers and tried to find
out what happened, the real issue was that third party
JSON library was being leveraged to do
deserialization of the JSON file.
And that did not handle the escaping characters in
meaningful ways.
So here was an example of internationalization.
Let's look at another example of--
here, we are talking about Google Maps in Swedish.
And on the on the left-hand side, you also see the
corresponding English version as well.
I'll tell you a little bit more background on this one.
A phenomenon that we saw was in Sweden, specifically
driving direction functionality, we were seeing
about 10% to 15% less usage of that functionality compared to
nearby places, compared to all our average worldwide.
And we wanted to understand what is happening.
So we put an engineer in Mountain View for about a week
to try to find what is happening.
This person essentially, very smart engineer, went through
all the algorithms that we're using for driving directions
and how we are pulling them.
They looked at all our data sources in terms local data
and displaying the street names and
all of those correctly.
And it turned out, yes, all of that was being done correctly.
Anyone know Swedish here?
Can you tell what might have been wrong?

And the problem was the Get Direction as in English was
translated as Instructions in Swedish.
And again, as a Google Map user, when I see instruction,
I would not really think of getting driving directions
based on seeing that instruction.
And that really what happened.
When we changed that to really mean get direction in Swedish,
we suddenly saw a sudden jump in terms of the usage for the
functionality.
And then, it became on par with other regions in the
world as well.
So what we want to highlight from these examples is that
the user experience is impacted in a big way by how
you do internationalization and localization
implementation.

So we have talked about what i18n is, what localization is.
But the next question is what do I need to do?
What does it really mean for me?
So let's talk a little bit about a globalized application
architecture or the design in terms of how you will design
your application in meaningful ways to make it happen.
First is your application or your common code base.
And that would essentially be common across all countries.
It would contain the code of your functionality.
And this would be language neutral.
This is where all your key algorithms and
everything would go.
The next set, which you would essentially separate out in
meaningful ways, is the globalization services.
Anything that is language-dependent, so it
could be things like handling of date, time, currencies,
displaying them correctly, extraction, anything which is
language-dependent would essentially fall under here.
And you would essentially use different libraries to handle
them effectively.
The next set is the locale data.
So essentially, it's important to separate localizable
resources from your main code base.
So examples of localizable resources would be text,
images, and so on.
So notice here how the English, Japanese, and French
version are all separated out?
So if you were to use, for example, Java, you would
essentially use the resource bundles to handle these
language sources.
And having those separated makes it easy for
localization as well.
And then, finally, is the plug-in, which essentially,
think of that as a custom feature
for your local markets.
Why is that important?
It really brings the wow factor for your app.
Think of like we had the transit app in German.
And when we introduced German train schedules, that really
made people feel, wow, this app has been made for me
rather than something which will just ported over from US
with some cosmetic changes.
Another example is we introduced cricket scores on
Google News in India.
When we did that on the days when the cricket match was on,
we saw about 8% to 10% increase in daily traffic.
Why?
People were able to essentially-- again, cricket
and Bollywood are pretty popular in India.
And people would essentially come and see those scores on
Google News when the game was on those days.
So here is the complete picture of
internationalization.
It is how you would typically do your internationalization
from a design perspective and how you would have your
different parts of your code base separated out in
meaningful ways so that you can essentially then extend in
meaningful ways and make your code base ready for
localization.
Now, let's look at some of the available tools that will help
you to make this happen.
Here are some tools that are listed for
internationalization.
Some of these tools, we are actively working on.
Some of these tools, we actively contribute to.
But in either of those scenarios, these are the exact
same tools that we use at Google for our
internationalization as well.
So the first is the ICU, International
Component for Unicode.
Think of that as a hidden gold mine for you.
It really provides you the right libraries in various
programming languages--
C/C++, Java--
for you to handle Unicode and globalization
in meaningful ways.
So you can handle things like date, time, currency,
formatting, and much more using this library.
The next library is the libphonenumber library.
It essentially handles the international
phone numbers for you.
It essentially incorporates all world regions, so things
like area code, country codes, and all of
the intricacies involved.
It essentially encapsulates all of that and gives you a
simple interface by which you can essentially do parsing,
formatting, storing, and validating of phone numbers
across any region in the world.
And again, pretty powerful in respect to that.
In terms of JavaScript, the Google Web Toolkit and closure
tools provide internationalization support
for JavaScript.
We're extending that support using the ECMAScript standard
process for that as well.

For input, research has clearly showed that users tend
to use an app more if they're able to input
in their own language.
And that's where Google Input Tools, a Chrome extension
comes into play.
It is a tool that allows users to input in 80 plus languages
on any text box on any web page.
Why don't we first look at a quick introductory video?
And then, Andrew will do a quick demo of that as well.

[VIDEO PLAYBACK]
-There's this word in Chinese, Xiang, that kind of means
smells good.
It could describe flower, food, really anything.
But it's always a positive description for things.
It's hard to translate into something other than Mandarin.

-We have this word in Fiji-Hindi called Talanoa.
Really, it is the feeling that you get late on a Friday night
surrounded by your friends shooting the breeze.
But it's not quite that.
It's a sort of warmer and friendlier version of small
talk, just about everything that you could think of off
the top of your head.

-There's this Greek word, Meraki, that means to really
put your soul, put your entire being into what you're doing,
whether it's your hobby, or it's your work.
You're doing it with love for what you're doing.
But it's one of those cultural things that I've never been
able to come up with a good translation.
Meraki, with passion, with love.

[END VIDEO PLAYBACK]
MANISH BHARGAVA: Great.
Andrew, why don't you give us a quick demo of lesson.
ANDREW WARREN: Certainly.
So as Manish was mentioning earlier, the majority of web
users online, and the majority of users of cell phones, and
the majority of pretty much all of Google's users and
internet users are not from English-speaking countries and
don't speak English natively.
What's more, and much more important, the majority of
users coming online at this point, the majority of users
who are just beginning to use these technologies are not
native English speakers, and in most cases, are not English
speakers at all.
So one of the things that we're trying to do at Google
is make it easier for these new users to actively engage
online to create content, to communicate with people in
their own languages.
And so one of the ways that we're doing that is this
project called Input Tools, which is a project to make it
easy to enter text in whatever language you'd like to.
So I'll be giving a brief demonstration of the Chrome
extension that we've recently put out for this purpose.
All a user needs to do after installing the Chrome
extension is choose the languages that he or she might
want to type in.
So in this case, I'll add some Chinese input methods and some
Hindi input methods.
And then, that's pretty much it.
From there, If the user wants to enter text in one of those
languages or in a language that they don't have the right
keyboard for, don't have the right input tools for on their
computer, all they need to do is enable the Chrome extension
and tell it which language they'd like to type in.
And from there, we use server side dictionaries and language
models to determine what words they're looking for and what
words they might want to type.
So we have this available for IMEs for Chinese and Japanese,
which includes the keyboard shortcuts that Chinese and
Japanese users are probably familiar with already from
clients site IMEs.
We have a number of transliteration tools for
speakers of Indic languages and others.
And then, we also have a number of virtual keyboards
which we offer which can both be used to literally type
using the mouse, or which can be used just as a keyboard
mapping if the users already familiar with that keyword but
doesn't have it available where they are at the moment.
So this is something that we have available for over 80
different languages already in the Chrome extension for
online users and are also working to bring to other
platforms as well.
So we have all of the 20 plus transliteration languages and
Chinese and Japanese available on Windows.
And then, we also brought Chinese, Japanese Korean, and
a number of other languages to Android and are continuing to
build out the number of languages we support so that
more users can create content.
More users can communicate with one another in whatever
language they like to.

So, post demo, there's a couple of important
implications of this for developers as
well for input tools.
The first of these is that you never know what tools people
might be using to enter text into your website or into your
application.
So specifically, they may be using
this Input Tools extension.
They may be using a client site IME of some kind.
Or they may be using other accessibility tools, like
Chrome Box, to read what's on the screen, or what's in a
text box, or know where a text box is.
And so it's very important that when you build
applications, particularly web applications but also Android
applications, that you're using standard components and
standard pieces of HTML and don't do anything terribly
fancy with input boxes, with editable DIVs, so that these
tools will work for users not just within the US and Europe,
but also for users around the world.
The second key takeaway for developers is that you don't
really know what types of content are coming into your
application or where they're coming from.
So you may be getting all types of content, in all kinds
of languages, in all kinds of encodings, where you may not
have designed it for that.
So it's important for applications to be built from
the ground up supporting Unicode and assuming Unicode
is coming into the application and processing all of the
strings in any other aspects of what the application does
assuming Unicode and in Unicode.
So from the developers' perspective, there's a lot of
other things that need to go into an application to ensure
that technologies like these work for
users around the world.
MANISH BHARGAVA: Great.
Thank you, Andrew.
So up to this point, we have looked at
internationalization, what it entails, what does the global
design look like, global architecture looks like.
And then, we have also looked at some other
internationalization tools.
Now, let's do the same for localization.
First of all, here are the five points that you would
need to do for localization irrespective of what you're
localizing.
So it could be your Android apps.
It could be your Chrome maps.
It could be a website.
It could be your static files documents.
First of all, you need to determine your
target language set.
And again, that's a very important decision
that needs to happen.
And again, that may change over time as well.
We will talk about some of the considerations for that in our
next slide.
Second is separating localizable resources from
your source code.
And again, we saw on the global architecture design,
that was essentially the third set of boxes.
And that is very critical for you to essentially have a good
localized experience.
You don't own hard-coded strings in your application to
show up, especially when people are accessing in
different languages.
The third aspect is test your application for
localizability issues.
How do you know whether it's ready for actual localization?
You would essentially at the point when you are ready for
translation, you should not require any re-engineering or
code changes.
In that case, we have taken care of most of the
localizability issues.
And so the localization tools are really your friend here at
this point for that.
If those tools can help you find problems like text
swirling, hard-coded strings, not handling accented
characters, even before you actually do the localization.
And again, we would highly encourage you to use that
phase in terms of your pseudolocalization.
The fourth is you will choose a localization vendor.
And either them or you will choose the localization tool
that you use.
Important consideration for localization tools are, it
should have advanced technologies like translation
memory, glossary, and so on.

As we've talked in the previous slide, let's talk a
little bit more about the key considerations that you have
when deciding which locale, a combination of your country
and location, you would like to have your app or your
product available in.
Broadly, the considerations could be
divided into two types.
One is the key matrix based on various key metrics.
And again, there could be a variety of them.
And the second is based on the effort required for
implementation of these.
So let's talk more about the key metrics.
So again, there could be a variety of different key
metrics that you could base your decision in terms which
countries or which languages to go after.
You could essentially decide based on top
languages used on the web.
You could essentially base it on top countries by cell phone
usage, top countries by paid app installed.
You could essentially go by what my competitor offers.
If competitor is localized in 15 languages, you might do the
same as well.
And then, finally, there could be some
app-specific metric as well.
So for example, if you are a game developer, you might want
to go by the top countries by paid game downloads.
So let's say we picked one.
We go by top languages used on the web.
And we localize in 10 languages.
So you essentially pick the top 10 languages on the
internet and say, OK, I will localize in those.
Question for the audience?
What is the percentage of users you can cover if you
essentially do that?
You would essentially localize your app in top 10 languages.
What percentage of internet users would you cover?

Yes.
It is 82%.
Absolutely right.
You essentially-- and again, let's see a little bit more
details here.
So this is the breakdown of the top 10 languages and then
the remaining set.
So notice English is about 26%.
Chinese is pretty close, 24%.
And then, you can see the remaining ones.
After the top 10, which is about 82%, the rest of the
languages constitute about 17.8%.
So let's look a little bit more carefully here.
If you pick the top 5, you include Chinese in here.
If you include the top 10, you also include Arabic here.
These are languages that require special handling for
doing localization and internationalization correctly
for these languages.
So you might want to do some cherry picking in terms of
which languages you want to localize your app into based
on where you are.
And that's a good segue into our second aspect in terms of
effort required for implementing those languages.
So there's a natural grouping of languages.
So let's say your app currently is in English.
Now, what is the next set of languages that
you could go after?
The next set, which adds a little bit of complexity but
not that much is the Latin script languages.
These are languages which include FIGS--
French, Italian German, Spanish--
Indonesian, Romanian, Vietnamese, and so on.
There are three things that this set of languages add in
terms of complexity for your app.
First is the ability to handle the language preference.
So users should be able to choose from a dropdown, so a
language picker, and say OK, I want now my app to be in
German, Spanish, and so on.
The second is the ability to search in those
languages in your app.
And for that, you need language detection
mechanism as well.
So with those, you can pretty much try and target the Latin
script languages.
You will probably need some bit of testing as well.
The next set of languages that you can target are non-Latin,
European languages.
These would include languages like Russian, Ukrainian,
Serbian, and Greek.
In addition to what we described for Latin script
languages, there are added complexities in terms of
transliteration is important for these languages.
Plus for languages like Serbian, the
interchangeability between the Latin script keyboards and the
Cyrillic keyboards becomes an important aspect
to consider as well.
The next set of languages are the CJK--
the Chinese, Japanese and Korean.
Here, the complexities first is the font size.
You need to take care of that because characters typically
tend to be bigger in size.
The second is the display mechanism might change.
So some of these languages are displayed vertically as well.
And the third aspect is input.
So input method iterators become an important aspect.
Why?
Because just the enormous number of
characters in these languages.
The next set of languages are the South and Southeast Asian
languages, specifically Thai and Hindi.
They are typical because you need to handle
the contextual display.
Characters in these languages essentially change based on
the context.
And the second important aspect is the size
segmentation.
So in Thai, where the words are not separated by wide
space, you need to take care of, especially from a search
perspective, how the
segmentation is done correctly.
And the last of languages are the bi-directional languages,
which include Arabic, Hebrew, Persian, Urdu.
And these are really the most challenging languages from
engineering perspective.
Why are these called bi-directional languages?
Mainly because the text flows from right to left and the
numbers go from left to right.
Special attention is needed for the user interface,
especially in those languages.

Now, let's look at some of the available tools for each of
these kind of applications, so Android apps, Chrome web store
apps, your website, and your static file and docs as well.
So let's take them one by one.
So first is localization of your Android apps.

As we mentioned earlier as well, it is important for you
to have a localization strategy.
By that, we mean you need to know which languages and which
countries you are going to localize your app into, which
is your default set of language and country, and
finally, what happens when somebody accesses your app in
a locale in which you are not localizing into.
So here are the three things where that
happened in that scenario.
First, as I said, you create your resource sets for each of
the locale that you want to go in.
At run time, the resource set is matching the
device, locale is loaded.
And if locale specific resources are not available,
Android falls back to the defaults.
Let's talk a little bit more about some of the technical
details here.
So strings.xml file contains your translated strings.
So under res/values, that's where your strings.xml in that
directory would contain the default translations.
So let's say if you were to translate in French and
Arabic, you would also have directories called
res/values-fr and res/values-ar respectively.
And strings.xml within those directories would contain the
translated strings for French and Arabic as well.
And let's say you had other resources as well that needed
to be translated.
So graphics, for example, you would have res/drawable-ja for
handling the graphics in Japanese, for example.
So here's the typical Android localization process.
You essentially have three steps here--
the planning and design phase, the actual translation, and
then, finally, testing and publishing.
Right at the very bottom, you see the link to the guide for
localization in developers.android.com.
In that, you will find essentially all details for
each of the steps what you need to do there.
What I would highly encourage for everyone to do here, if
you haven't done that already, is to take the Hello L10
example, so Hello Localization example, similar to the Hello
world example when you try a new language.
You would list in a very simple way all the steps that
you need to do to have your first
localized version of that.
And it's a very simple app, just has few phases, and the
map for that country and displays that.
So again, if you haven't done this, I would highly encourage
you to try this, the Hello L10n example.
And again, you will find that in localization guide at
developers.android.com.

So let's look at localization of the Chrome web store apps.
One important aspect here is that you can do your listing
in 43 locales from the Chrome
dashboard, developer dashboard.
And the second, depending on whether you have an extension,
or packaged app, or hosted app, your app localization
mechanism would be different.
So let's look a little bit more at the extension and
packaged app where you have more control over the files
right in your dashboard.
From a technical perspective, your messages.joson will
contain the translations.
You will define your default locale in your
manifest or JSON file.
And you would essentially have your different translations in
_locale directories.
So for example, again, taking the same example, if you are
French and Arabic, you would essentially have _locale/fr.
And then, within that, you will have the
message or JSON file.
And same form, _locale/ar/json file to contain the Arabic
translations as well.
In terms of localization process, it is again very
similar to what we described in the Android process as
well-- the planning and design phase, the translation phase,
and then the testing and publishing phase.
One important distinction is that you essentially provide
the localized description and screenshots and the time when
you're uploading for each language at one time.
So again, the reference there at the bottom,
code.google.com/ chrome/extensions/i18n.html,
you will find all the details about the Chrome web store
localization as well.
Now, let's talk about localizing your website.
With Google Website Translator, you can instantly
translate your website into 60 plus languages.
Sounds interesting.
Want to find out more?
Let's look at a video.

[VIDEO PLAYBACK]
-The Website Translator plug-in powered by Google
Translate allows you to quickly and easily make your
website or blog instantly
available in 60 plus languages.
Just add the plug-in code snippet to your page, where
you'd like to language selector to appear.
And whenever an international user visits your page, they
can select their language in the dropdown, and your page
will be instantly translated into the language.
While the quality of translation from Google
Translate is quite good, it's not always perfect.
For these situations, the Website Translator plug-in
allows you to publish and improve the translation.
After you translate the page, just hover over the translated
sentence you'd like to improve and enter the correction in
the pop-up.
Your correction will now be used whenever someone
translate your page.
Users visiting your site can also suggest translations
using the same process.
However, these suggestions won't be
used until you approve.
You can manage these suggestions in the Website
Translator's web management interface.
Just select and improve the suggestion, and it will be
used whenever someone translates your page.
Add the Website Translator plug-in into your website now
and make your website globally accessible.
[END VIDEO PLAYBACK]
MANISH BHARGAVA: This was Jeff Chin, again on our team, who
works on the Google Website Translator.

So again, as was described in the video, you can instantly
translate in 60 plus languages.
But what we launched about a month back is very powerful.
We're not just using the machine translation.
You can now customize and improve your website
translation by manually going in and correcting
what might be wrong.
In addition, you can also collect and use the
translation selections from your users as well.
And again, you can invite editors to manage your
translations.
And that way, you essentially, again, make your website
instantly available for a lot of users worldwide.
So we already did that.
Let's now look at localization of your documents,
localization of your static files.
You could essentially use Google Translation Toolkit,
GTT, for doing that.
What is GTT?
GTT is Google's localization platform for human
translators.
They can essentially use this to do translation faster and
more correctly.
You edit by technologies like Google Translate.
It essentially supports a wide variety of document types.
To name a few, you essentially get your Word documents, your
Open Office files, your rich text file formats, your HTML
text files, PO flies, Android resources, Chrome extensions,
Edward campaign, Wikipedia articles.
So again, a slew of stuff that you can essentially localize
using the tool.
It supports more than 300 standard
source and target languages.
And it has a simple what you see is what
you get wizard editor.
And the best part of all of this, it's essentially a
totally free tool.
So you can essentially leverage that for your
translations as well.
We would also like to talk a little bit more about things
that are in works.
Given what you have heard over the last two years, Android
apps and Chrome apps are a very
important part of our ecosystem.
And given that, we want to now optimize on our app
localization platform, especially for Android and
Chrome apps.
We also would like to-- essentially working on
optimizing our YouTube caption localization process as well.
With respect to the apps' localization platform, Andrew,
why don't you give us a sneak peek into that?
ANDREW WARREN: Sure.

So as Manish mentioned, we're working on a new form of the
Google translation toolkit that is focused on application
translation and localization.
So in particular, the main point of this tool is to make
it so that developers don't really need to understand what
goes on behind the scenes for translator and all of the
tools that they need to use to properly localize something.
And a translator doesn't need to understand what's going on
behind the scenes of an application and need to
understand the structure of the application and where the
files sit in the application, all of that information.
So we're trying to make it as easy as possible for
developers and for translators to do their job without
needing to understand each other's roles as much.
So given that, all the developer needs to do upon
coming to the system is add the resource files from their
application, from whatever framework they've been using.
So we support Java properties files, Ruby on Rails YAML
files, a number of other file formats from popular
frameworks, and are continuing to add more
files as we go along.
And then, choose the languages that the developer wants their
app to be translated into.
So in this case, we've chosen Arabic, Chinese,
Spanish, and Thai.
And then, the last step from a developer's perspective is to
add collaborators to that project.
So decide who you want to come help you translate this.
It could be friends or family who speak other languages and
have offered to help translate.
It could be community members or members of your user base
who offered to help translate your
application to their language.
Or it could be professional translators who you decided to
hire to come in and translate your application in your first
international launch to five languages or
something of that nature.
So after adding collaborators and the translators, the
developer's job is effectively done here.
They don't need to understand what happens after that point.
But if you want to, you can go into that part of the process.
And we'll show you a little bit of what that
looks like as well.
So when a translator gets an invitation to come in and work
on a translation project for any of the apps that
developers might upload here, what they'll see is the actual
translation interface where we basically laid out all of the
messages that need to be translated and kind of
abstracted away all of the different files those came
from, where they sit in the application.
And the translator can just go ahead and enter translations
as they go along.
A few other features that make this a little bit more
convenient is we've also abstracted away the individual
placeholder support for each language.
So a translator can use placeholders without needing
to understand how the programming language that was
used actually implements placeholders.
And we just go ahead when the developer comes back to export
the file and replace it with the placeholders that that
language is using.
Another thing that's convenient, particularly for
application translation, is the suggestions feature, which
allows us to offer suggestions both from Google Translate,
but also from previous translations within that
application or within that project.
So if you have a number of translators coming in, and the
word photos has been translated somewhere earlier
on, but you now have a new phrase in the application,
view my photos, then that translator will get a preview,
a suggestion, of what word to use there so that you maintain
a consistent translation throughout the entire project.
The most important thing that we found when looking at why
applications are very different from static files
and from other types of content that you might want to
localize is that applications have very short UI strings.
And so it's very difficult to get a sense of what an
individual string or message might mean for a translator,
which leads to issues like Manish described before.
Small, medium, and large becomes
Saturday, medium, and large.
These sorts of things stem from translators not
understanding what a message is supposed to be in the
actual application.
So what we worked hard to do is make sure that we give
developers the ability to capture very easily the
context of their application and to capture snapshots so
that the translator can translate in context exactly
what the message means and can see in real-time how that
impacts what the message looks like in the UI.
A couple of other very convenient aspects of this
that help the localization process significantly is that
the developer can come through after the fact and take a look
at all messages that have or haven't been translated and
get a sense of everything looks fine in Chinese except
there's this English word over here that's still in English.
So clearly I missed something when I was putting things into
my resource bundles.
The other thing that's somewhat nice about this is a
developer can come back to this UI if they want to after
the translation is complete and can see the impact that
the translation has on the UI.
Because the process we used to capture the messages from the
application not only captures the HTML and the actual
snapshot, but it also captures the CSS.
So we actually have the style information.
And you can see in real-time what happens when a particular
message breaks the UI.
In this case, a very long message might push some of
these items onto the next line which would break the UI and
break the CSS.
So the developer can get a sense of where problems are in
their interface and can fix those problems before
redeploying the app in new languages.
So this is something that we're continuing to work on
and are looking forward to making available publicly in
the near future.
MANISH BHARGAVA: Great.
That was great, especially the screenshot part.
Thank you, Andrew.

OK.
So we are at the point where we have looked at
globalization and getting your app for a global audience
makes lot of sense.
We also looked at what it entails and how do we achieve
that in terms of both internationalization and
localization.
We looked at available tools.
Now, let's say you have done all of that.
You have now a localized app.
What's next?
The natural question is how do I get my app now
to the right audience?
So how do I find the customers, and do the global
customers find me?
So listed here are some of the practical tips for you to
market your app, especially where is Google marketplaces,
including Chrome web store, including Google Play for
Android app as well.
So first and foremost, if you do nothing else, you should
localize your marketplace metadata
into different languages.
That by itself significantly boosts your app's ranking in
the marketplace, especially for that locale.
So that's the first and foremost part.
The second is maximize your search potential.
Why is that important?
Because search accounts for about 2/3 of all installs and
sales on Google Play.
How do you do that?
How do you maximize your search potential?
Think of the keywords.
Think of the keywords that somebody would search for when
your app should show up and include those in your title,
in your description.
Both of these fields are indexed from a search
perspective.
And once you have included those keywords in the
respective locales as well, the findability of your app
increases multi-folds in terms of a search perspective.
One key insight in terms of, again, ranking of your app in
these locale, there are three main factors
that go into that.
One is high number of installs.
The second is low number of uninstalls.
And the third is long term usage.
So how many users are using your app over a
long period of time?
So for that, the steady effort on your part for
internationalization and localization becomes a very
key factor here.
So think of your investment in terms of advertising campaign
and so on over a period of time rather than just be in
short bursts.
And lastly, localize your app listing.
Localize your app screenshots.
If your apps screenshot reflect the actual user
experience, the number of the installs go higher.
And more importantly, number of uninstalls go lower.
And that again helps in terms of findability of your app on
various marketplaces.

So take home message.
Important thing to note here is--
like again, we covered a lot of details here.
If you forget most of the stuff, please remember these
four things.
First is it is never too late to start.
So if you haven't done that, you still have your app only
in English or one of the languages, get started now.
Get started today.
Opportunity, as we have showed in the initial slide,
opportunity is just too big for you to ignore.
So focus on that.
The third is it is relatively very simple to get started.
And again, it will not get you in the perfect state right
away, but you will get there.
So things like just remove any hard-coded string.
Externalize them.
Make them as resource bundles and send them for translation.
Use a few libraries so that you do the number handling
date format, currency formats, et cetera, correctly.
And then, get your friend, get your family to come and help
you translate in just one language.
So you can essentially take all your strings and say, OK,
we're good to go.
Let's essentially use these and just
do it for one language.
It will not be perfect as I said.
But it will put you in the right direction
on the right path.
Finally, localize your marketplace
metadata as I just mentioned.
This, by itself, significantly improves findability of your
app on marketplace, specifically the Chrome web
store as well as Google Play as well.
That brings us to the conclusion of our talk.
Most of the stuff that we have referenced here, you can--
reference what we have covered here, you can essentially find
on developer.google .com/international.

As the [? GTTA ?]
comes out, you will essentially
find the updates here.
So again, it's developers.google.com.
That's pretty much it.
We are out of time for questions.
Thank you.