Internationalisation 101. How To Take Your Product Global (And Stay Sane) - by Galina Ryzhenko - Noteworthy - The Journal Blog

09/02/2021 Internationalisation 101.
tionalisation 101. How to take your product global (and stay sane) | by Galina Ryzhenko | Noteworthy - The Journal Blog
Internationalisation 101. How to take your

product global (and stay sane)
Galina Ryzhenko
Jan 16, 2020 · 17 min read
Photo by Kyle Glenn on Unsplash
“Our product is already popular in the domestic market, so now we’re thinking about going
international. Where do I start as a product manager?”
“Entering a new market looked like no rocket science at first glance, but the team keeps
coming with more and more questions…and the deadline is getting closer.”
— these are the questions I often hear from product people starting their
“international” journey. It is common for teams to underestimate the complexity of
https://blog.usejournal.com/internationalisation-101-how-to-take-your-product-global-and-stay-sane-1b0a2c51cc91 1/20
09/02/2021 Internationalisation 101. How to take your product global (and stay sane) | by Galina Ryzhenko | Noteworthy - The Journal Blog
going international, which leads to delays, over-spending and epic fails.
In this long-read, I would like to share my checklist based on industry best practices
and my 10+ years of experience scaling software products globally (from mobile
games, mass-market B2C apps to B2B SaaS products).
Note: this list is by no means exhaustive; it is focused on things product managers can do
to ensure a smooth launch of a software product in a new market (so I am not diving deep
into sales, marketing and legal aspects here).
First, let’s review the j̶a̶r̶ g̶o̶ n̶ basic concepts:
Globalisation — ensuring product readiness for operating in different markets,

covering various aspects of marketing, design, and tech.
Internationalisation (shortened to i18n) — making products as flexible as possible,

creating a solid basis for localisation and translation.
Localisation (l10n) — adapting a product to a region/culture/locale.
Translation (t9n) — translating the product to the new language.
Underestimation of i18n and l10n efforts is often caused by seeing it only as a synonym
for “translation of the user interface and documentation”, while they are substantially
more complex processes:
How do they relate to each other. Source: Adobe blog.
On to the checklist!
I will break it down into three categories of questions: business and marketing, design
and engineering, account management and support.
Business and marketing

☑ What type of international strategy are we going to use?
Depending on your product and audience, you may consider a global, transnational, or
multi-domestic international strategy. A few examples:
Global: Microsoft offers the same product experience around the world but adjusts
the programs to match local languages. The company sacrifices responsiveness to
local requirements in favour of emphasising efficiency.
Transnational: McDonald’s tries to balance the desire for efficiency with the need to
adjust to country-specific preferences. Their menus have both “iconic” and local
options — you’ll find Big Mac everywhere, but seafood in Macau and traditional
Ukrainian potatoes in Kyiv. Back in the days when I used to work on their digital
platform, our team could use global tools (web templates, mobile app), but had a
lot of flexibility in adding custom promo pages for local audiences.
Multi-domestic: Uber offering varies significantly by region, so riders can use hyper-
local offers like motorcycles for busy cities in India or boats to explore the coast of
Croatia. Another example is Pokémon Go - it has been released in 35+ countries,
and heavily customised for each region. Some Pokémons only live on specific
continents, and all of them are renamed per unique features of each language:
Pokémons names variety. Source: Applanga.
An experienced product person will figure out the international strategy as early as
possible and share it with stakeholders and the team. It is likely to impact the core
business and architecture decisions, which are quite hard and expensive to reverse at
the later stages of product evolution.
☑ What are our international expansion priorities?

It is crucial to select regions for international expansion in some priority order instead
of picking them based on gut feeling. Prioritisation frameworks like ICE are particularly
useful for this purpose (here’s how Dropbox used it).
Don’t try to assign strict deadlines or plan to launch in multiple countries at the same
time, especially when you’re just starting the international expansion. Best is when you
end up with regions grouped into tiers — such as: 1) top priority, 1–2 countries to be
launched ASAP; 2) high importance, to be considered for the next 2–3 quarters; 3)
everything else — and tackle them in order of that priority. There’s a great blog post on
this topic from Uber’s first Head of Product, Mina Radhakrishnan.
☑ How are we going to measure success?

Why do we push products to the new markets? In a nutshell, by doing so, your product
benefits from multiplier effect — an increase in reach, acquisition, engagement, and
monetisation, multiplied by each new market you enter.
However, if we want a simple localisation ROI formula, it will go like this:
ROI = (added value of l10n — cost of l10n) / cost of l10n
Next question will be — “how to calculate the added value”? Think of the incremental
revenue that your company can get by offering localised software product. Ideally,
product people should cooperate with sales and marketing to make this projection,
based on demand signals from target markets. In reality, this data is not always
available; so you will need to measure the added value of localisation through indirect
indicators:
Potential market share increase as a result of the localisation;
Website pageviews and app downloads increase;
Conversion rates before localisation and after it;
Social media engagement and media mentions in the target region;
SEO keywords ranking;
A decrease in customer support cases from the new market.
As for the time horizon, my recommendation is to calculate value and costs on an

annual (or at least bi-annual) basis. This way, you can factor in the long-term effects of
localisation, as well as the budget of internationalisation that typically covers all the
regions.
☑ Is there a competition in a new market, and how do we compare?

Well, this one is obvious :) Good product managers will do their homework on
competitive research, and then decide to update the functionality or even revisit the
product pricing and packaging.
☑ How are the needs, context and habits of our target audience different in a new market
(vs our current user/customer base)?
This one is tricky. L10n may require a complete rethinking of business logic, UI/UX
design, or pricing and packaging if user needs and habits in a given locale differ
substantially from the domestic market.
I faced this challenge while scaling Netpulse (engagement platform for fitness clubs) to
the EU market. It worked perfectly for its’ home country, the US, where the majority of
gyms are low-cost, and personal training is charged as a premium service. In European
countries such as Germany, the situation was a bit different — monthly memberships
are more expensive and include help from personal trainers on the gym floor. We
adapted the product by adding 1:1 connection between gym-goers and trainers to be
relevant for this region.
As a part of l10n strategy, analyse product preferences in the new region, and find a
couple of potential users/customers from that market to interview and check your
assumptions. Tools like Respondent will help recruit research participants from the
right location and social group.
☑ Do we need to change the App Store content and ASO?

Think of your app screenshots, videos and descriptions, as they can (and should) be
localised when the new locale is added. It is also useful to update app keywords as they
will increase your apps’ searchability in app stores.
☑ Is there anything we can do to boost our SEO?

British look for holidays, Americans will google vacations, and Italians type in vacanze.
Find out the right terms people use to google for your product online and start using
these keywords in your texts and metadata (title, meta descriptions and keyword meta
tags). Check Google’s guide for more tips.
Ah, and when we say people “google” — it is not always the case. In some countries,
you may want to optimise for locally popular search engines, such as Baidu in China or
Yandex in Russia.
☑ What are the data protection regulations in our target markets?

Ah, this is where the real fun begins. If your product is originally from the EU, you are
(hopefully) already compliant with GDPR; if it is from sunny California, then you’re
likely to be covering CCPA. But how about scaling to China? Australia? Japan? Chat
with the legal team before deciding on new market priorities — local data protection
requirements can have a significant impact on your ROI calculation, and therefore —
your product roadmap. Chinese data localisation requirement is one good example:
since 2017, an operator of critical information infrastructure has to store “personal
information” and “important data” within China, unless the business passes the
government security assessment. This means that if some companies need to transmit
data overseas, they had to restructure their mechanisms regarding data transfer, to
avoid violation of the data localisation requirements.
I use DLA Piper website to quickly compare data protection regulations in various
countries and formulate specific questions to the legal team.
☑ Are there any specific content restrictions in the new region?

Back in the days when I was in mobile gaming, we had to make numerous edits to
content for the Chinese market. First, it appeared that local censors wouldn’t allow
skeletons, so they were edited out. Later, they rejected all the games mentioning
“rebellion”. Finally, the pools of blood were removed.
One of our favourite games — CatoCalypsis (0% chance of release in China…)
Design an engineering
☑ Which principles/process are we going to follow in our i18n and l10n policy?
Product managers need to discuss the whole process with the team and document it to
get everyone on the same page. Think of the following:
Changes to your shared product requirements library and design system;
Translation management system (TMS) you’re going to use, e.g. Lokalise;
Who is doing the translation: in-house staff, freelancers, or agencies;
Guidelines for translators on specific terminology, tone of voice etc.;
Localisation workflow: e.g., importing the source XLIFF file to your TMS,
translation, review, delivery to end-users;
Creating and maintaining a shared text strings repository;
Level of automation (is it OK to update texts with a slight delay, or you need to do it
on the fly — the latter requires specialised SDKs integration);
The budget for initial l10n and ongoing maintenance.
Postponing this conversation will cost you time and money; like it happened to me
when I inherited a ~2-year-old mobile app with ~10K strings of text, hardcoded. We
had to pay for translating the same texts twice (for iOS and Android), and then spend
engineering time on adding new translated strings to the code. It took about 4–5
months to clear this mess and migrate to a single texts repository for iOS/Android
connected to Lokalise for translations.
The costs of addressing i18n after a product ships can become astronomical. Source: Adobe blog.
☑ Country, region, language… locale?

After deciding which country to target, your next step will be to check locales covering
it (“locale” refers to the lingual/cultural expectations for a region).
Let’s take the United States. You may think entering this market requires the product to
“speak English”, but millions of people in the US use other languages at home. So for
the mass-market product, you may need to consider supporting Spanish and Chinese:
Source: Statista, United States; US Census Bureau; 2018; 5 years and over
However, depending on the region, your product may need to support multiple locales
for one language, e.g. for Spanish in the US those will be: es_mx (Spanish — Mexico),
es_us (Spanish — US) and a couple of others. Finally, to cover Spain, it might not be
enough to localise in es_es (Spanish — Spain); from my experience, ca_es (Catalan —
Spain) appeared to be critical for one of the mass-market products I launched in this
region.
☑ How does our UI look with texts in different languages?

The golden rule here is “the more flexible is the design of your layout, the better”. I
advise designers to keep in mind average expansion rates for texts translated from
English into other languages, for instance, those published in IBM Globalisation
Guidelines:
Source: IBM Globalization
General rules for i18n/l10n should be a part of your products’ design system so the
team can apply them consistently across all the features. It will include a reserve for
text expansion, rules for long text wrapping or truncation, requirements to images and
icons etc. (Meetup’s system is a good example).
☑ How is localisation going to be applied? Will we allow users to change it?

With mobile apps, it is a common practice to apply the locale based on user’s device
language: person from the US who sets their phone to Spanish — US will see the app in
es_us locale.
It is not so straightforward on the web. You may choose to rely on the browser language
settings; however, it won’t be correct for a lot of users. Think of an American working in
Germany on a corporate laptop. They wish to use en-us (English — US) locale, but their
browser comes in de-de (German — Germany), and only the company admin has the
rights to change it. Oops.
To avoid confusion, consider adding the option for the end-users to change to the
preferred language, and make sure you support runtime switches.
It applies to other elements of the i18n as well, such as changing from imperial to
metric system; or seeing prices in a preferred currency:
Currency switcher on Booking.com
☑ Which locale will be the base (default) one?

Typically, it will be English — but you’ll need to pick a base locale, e.g. UK or US. All the
translations will be based on this locale, and it will also be used by default, in cases
when your product does not support user’s device language.
☑ Do we need to support various scriptwriting directions?

Languages like Arabic and Hebrew are written in right-to-left (RTL) script; Traditional
Chinese allows both left-to-right (LTR) and top-to-bottom (TTB) scripts. Depending on
the type of your product and target audience profile, it may require complete re-build
of your UX or just a slight update:
Source: Airbnb Design blog.
Note how the order of items in Airbnb’s menu is swapped in Hebrew, as speakers of this
language not only write RTL, but they also read the same way:
Airbnb mobile app in Hebrew and English.
☑ Does our product have any forms to be localised?

If the answer is “yes”, you will have a lot of fun!
Take people’s names. We are often unaware of how different names can be in other
countries. I learned it the hard way: the app we launched in Indonesia required new
users to enter first and last name to register. Next day after the launch we received a
bunch of complaints… from mononymous people who don’t have a “last name” and
could not complete the sign up. Uh oh.
Other names-related changes in forms include swapping first and last name (for Korea,
Hungary), validation that accepts special symbols, spaces and non-ASCII characters,
e.g. ë in Zoë (check W3.org for more examples).
Another challenge is dealing with addresses and phone numbers.
Depending on the region, the order of elements in an address order varies quite
drastically. Common pitfalls are: unnecessary required fields (state), non-flexible
postcode format (US only), confusing labels and placeholders.
When it comes to phone numbers, you will need to think of using local vs international
format, and decide whether to structure it or have a generic one:
Source: Flexport blog
Depending on the specifics of the product, you may choose one of three common
approaches to internationalise your form: specific, changing, or generic formatting —
more on this in a great post by Luke Wroblewski.
My advice is to balance the need to get accurate data via forms and making them easy
to use. Whenever possible, use context, such as geo-location, SIM card data, or
postcode to pre-fill the form and make users’ task easier.
☑ Do we need to localise prices and currencies?

If you’re lucky to display prices, then it’s time to make sure that users will see the right
ones, in a local currency, and familiar formatting.
Users who browse your site from Germany expect to see the prices in Euro, while those
who browse from the US want to see dollars. Canadians will also expect dollars, but
they’ll also want to know if these are CAD or USD… (read more on currency formatting
in a great post by Etsy):
Source: Etsy blog.
Think of a price as a structure that has a number, currency, decimals and separators.
Depending on the use case, it can be broken down into base price and taxes like VAT.
Discuss your multi-currency support plans with colleagues in engineering and design
well in advance. It helps factor in the necessary level of flexibility and avoid heavy
refactoring in case you need to support multiple currencies.
☑ How about different metric systems?

At Netpulse, we were building a product for gyms and fitness lovers, so the team had to
keep in mind that different countries have their preferred system of measurement. For
users in the US the app defaults height, weight and distances to an imperial system
(ft/in, lbs, mi), for Europeans — to metric (m/cm, kg, km). Of course, they can switch
Imperial/Metric in settings.
Source: Statista.
☑ Do we show date and time in the product?

The variety of date formats will keep your team so very “excited”… I will just quote one
engineer here:
I hope that every time someone comes up with a new date format they will be hit in a face
with a red hot frying pan untill they give up programming in favour of growing cactuses.
— DevRant.com
Source: DevRant.com
When picking the right date is critical for user’s task (e.g., flight booking), provide
users with calendars and spell the month out:
Source: Google flights.
☑ How about timezones? Daylight savings observed?

Working with time zones is hard because it’s a colossal mess of edge cases, and every
one of them is waiting to get you if the team decides to cut corners:
Daylight saving — one day a year it’ll be 23 hours long and one day a year the day
will be 25 hours long (but some regions do not observe it);
Countries switch to daylight savings at a different time;
There are not 24, but 38 time zones (source: How Many Time Zones Are There?).
They are not always offset on one hour; e.g. India is UTC +5:30;
Time zones do not line up with geographic boundaries;
Main takeaway: assume nothing; clarify the time zone in your UI if it is not obvious,
think of edge cases, and reserve plenty of time for quality assurance.
☑ What is the meaning of icons and symbols in the new market?

Be careful with icons, symbols, pictograms in the UI; they may not be understood in the
same way in your new region.
For instance, animal symbols can be dangerous; owls that symbolise wisdom in the US,
but mean stupidity in some parts of Asia. So an e-learning website may use an icon of an
owl to express that a user or student is performing well in a course, while Asian
students may be insulted by such an image.
☑ Do we have any images of people or avatars?

Look at these with a fresh eye: do they look like the local population, is there a gender,
race, age balance?
In one of the apps I managed, our team had to cut off all the avatars and replace them
with profile pictures uploaded by users and apply first/last name initials as a default
placeholder, before launching globally. This way we could be sure that each person is
correctly represented and won’t be offended by the lack of the right avatar (find more
avatar ideas in this UXCollective post).
☑ How does our new audience perceive colours?

Depending on your target market, the colours should be carefully chosen to reflect the
local cultural variations (use this symbolism chart as a reference).
☑ What about the fonts we are using, will they look good in all the scripts?
If you plan to launch in regions that use the non-Latin script, then it is time to check the
fonts to avoid “tofu” and ensure they support special characters and symbols. Google
Fonts provides a nice filter by languages support:
Source: Phase.com
☑ Does our current login / identity management solution suit the new market?
Let’s say your product allows users to log in with Facebook or email, and you are
planning to launch in South Korea. Since 83% of the audience in this country uses
KakaoTalk, they may expect social login with Kakao account.
Apps people prefer for social sharing may or may not be the same as those used for
login. If your product relies on social sharing and/or referrals, it will be a good idea to
look at the messengers and social networks popular locally (e.g. WhatsApp for South
America, WeChat for China).
☑ Can we accept payments in a way that works for us and our audience?
International payments are one big hairy problem — everything can go wrong here,
from hidden fees to security issues and exotic legal requirements. A few things to
consider:
penetration of your preferred payment method in the target market;
regulatory requirements for online payments, such as the need for a local merchant
account or asking for CVV with each transaction;
can you leverage well-known systems such as PayPal and Stripe, for the beta
launch, and add other (cheaper in terms of fees) options later.
☑ Is our API ready to return data in local formats and locales?

If you have public APIs, it will be essential to allow the inclusion of specific or multiple
locales in API requests and return the expected data in responses.
Account management and support

☑ Is our account management (customer success) team equipped with the data and
product insights related to the new market?
It is an essential duty of a product manager to onboard the new colleagues in sales and
customer success, so they know how to present the product in a new region. “Localise”
your onboarding assets with stats and insights for each new market (you are a data-
driven product manager after all 😉)
☑ What is our sales strategy in the new market?
In some of the markets, your company will sell directly, while in others it will go
through local partners. When it is the latter, you may start getting questions, comments
and feature requests from those partners… so you’d better understand their needs and
motivations sooner than later.
☑ Do we have local customers (B2B) or end-users (B2C) for a beta launch?

Start small and polish the product before its’ full roll-out. No matter how hard you work
and how good is your plan, there will be surprises, and it is better to handle them on a
smaller scale.
☑ Is there any difference in Service Agreements and other documents?

Again, legal stuff is boring but vital; sit with your account management and legal teams
to review contracts and service agreement templates to be used in the new region. It
saves a lot of time and nerves when done in advance.
☑ Do we have localised support assets?

Same as with internal onboarding materials, your user support assets will need an
update. It applies to tutorials, FAQs, help pages — they have to appear in the right
(local) version, language and be regularly maintained. Otherwise, prepare to see a
bunch of support tickets from the new market.
☑ Are we hiring local support representatives to cover the new market?

By the way, someone will need to understand and respond to those support tickets,
promptly. This means your company may want to add global/local support lines,
translate status pages, hire support representatives speaking local languages and
change support shifts to cover new timezones.
☑ Is there a change in weekly/daily load patterns we’ll need to accommodate?

When the product is launched in a new region, it may get popular (that’s what you
expect, right?), and the load patterns will change. You may want to revisit the release
and maintenance schedule not to impact the system during peak times, or ask the
DevOps team to arrange for a “zero-downtime deployment”.
Good luck, and may your products live long and prosper everywhere
in the world! 🌎
Thanks for reading! Questions? Feel free to comment below or drop me a line via LinkedIn:
https://www.linkedin.com/in/galina-ryzhenko/
📝 Read this story later in Journal.

Wake up every Sunday morning to the week’s most noteworthy stories in Tech
waiting in your inbox. Read the Noteworthy in Tech newsletter.
Product Management Localization Internationalization Software Development Process
About Help Legal
Get the Medium app

Internationalisation 101. How To Take Your Product Global (And Stay Sane) - by Galina Ryzhenko - Noteworthy - The Journal Blog

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internationalisation 101. How To Take Your Product Global (And Stay Sane) - by Galina Ryzhenko - Noteworthy - The Journal Blog

Uploaded by

Copyright:

Available Formats

09/02/2021 Internationalisation 101.

Internationalisation 101. How to take your

Photo by Kyle Glenn on Unsplash

going international, which leads to delays, over-spending and epic fails.

First, let’s review the j̶a̶r̶ g̶o̶ n̶ basic concepts:

Globalisation — ensuring product readiness for operating in different markets,

Internationalisation (shortened to i18n) — making products as flexible as possible,

Localisation (l10n) — adapting a product to a region/culture/locale.

Translation (t9n) — translating the product to the new language.

How do they relate to each other. Source: Adobe blog.

Business and marketing

Pokémons names variety. Source: Applanga.

☑ What are our international expansion priorities?

☑ How are we going to measure success?

However, if we want a simple localisation ROI formula, it will go like this:

ROI = (added value of l10n — cost of l10n) / cost of l10n

Potential market share increase as a result of the localisation;

Website pageviews and app downloads increase;

Conversion rates before localisation and after it;

Social media engagement and media mentions in the target region;

SEO keywords ranking;

A decrease in customer support cases from the new market.

As for the time horizon, my recommendation is to calculate value and costs on an

☑ Is there a competition in a new market, and how do we compare?

☑ Do we need to change the App Store content and ASO?

☑ Is there anything we can do to boost our SEO?

☑ What are the data protection regulations in our target markets?

☑ Are there any specific content restrictions in the new region?

One of our favourite games — CatoCalypsis (0% chance of release in China…)

Changes to your shared product requirements library and design system;

Translation management system (TMS) you’re going to use, e.g. Lokalise;

Who is doing the translation: in-house staff, freelancers, or agencies;

Guidelines for translators on specific terminology, tone of voice etc.;

Creating and maintaining a shared text strings repository;

The budget for initial l10n and ongoing maintenance.

☑ Country, region, language… locale?

☑ How does our UI look with texts in different languages?

Source: IBM Globalization

☑ How is localisation going to be applied? Will we allow users to change it?

Currency switcher on Booking.com

☑ Which locale will be the base (default) one?

☑ Do we need to support various scriptwriting directions?

Source: Airbnb Design blog.

Airbnb mobile app in Hebrew and English.

☑ Does our product have any forms to be localised?

Another challenge is dealing with addresses and phone numbers.

Source: Flexport blog

☑ Do we need to localise prices and currencies?

Source: Etsy blog.

☑ How about different metric systems?

☑ Do we show date and time in the product?

Source: Google flights.

☑ How about timezones? Daylight savings observed?

Countries switch to daylight savings at a different time;

Time zones do not line up with geographic boundaries;

☑ What is the meaning of icons and symbols in the new market?

☑ Do we have any images of people or avatars?

☑ How does our new audience perceive colours?

penetration of your preferred payment method in the target market;

☑ Is our API ready to return data in local formats and locales?

Account management and support

☑ Do we have local customers (B2B) or end-users (B2C) for a beta launch?

☑ Is there any difference in Service Agreements and other documents?