When your startup is planning to enter new markets, supporting local languages becomes a top priority. However, that’s not all product managers must consider when building a product localization strategy for the first time.

If your product localization journey is just about to begin, you probably don’t know what to expect.

The following 7 steps can help you avoid the most common pitfalls you may encounter along this bumpy road.

Product localization strategy step #1:
Spread the word

There’s a long list of things that you should consider prior to releasing any of your languages. To begin, you should define your potential target markets and their corresponding languages. If the list is too long, decide which ones should be a priority for the experiment.

Secondly, remember: product localization is never a self-isolated thing.

Product localization impacts nearly every function in the company: engineering, product, marketing, customer support, and even legal and compliance. Communication is key!

Make sure to share your product localization plans with each team, since all of them will have a stake in this project:

• Product and engineering teams will prepare the product for localization
• Marketing will plan ad campaigns in the new markets
• Legal and compliance will likely need to adapt existing Terms of Services for foreign markets

Don’t forget about customer support, since the launch of new languages will greatly impact their work.

They will need to know when and which languages will be released, so they can decide how to support users in these languages. One of the options here is to localize your product FAQ or Help Center. In this case, users will be able to access a help menu themselves, even if customer support is not provided in their language.

Product localization strategy step #2: Revise your product design

After the ground rules are set and all stakeholders are updated, it’s time to start the preparation phase.

Before you spend a dollar on your app translation, ask yourself: Is our product ready for localization?

Something to consider:

Is our design suitable for non-English languages?

Some languages require more space in UI than English. For instance, the German language takes on average 30% more space, as shown in the example below:

English: “Supported crypto”

German: “Unterstützte Kryptowährungen”

What does this mean for your product?

Longer strings can get truncated or overlapped by others. They can even break the whole screen layout by severing the alignment of surrounding elements.

A good solution for the problem of “long languages,” is allowing more space for every text element and text wrapping. Otherwise, your non-English product versions might look untidy or even misleading.

Here’s an example of how to avoid it:

Screenshots are taken from coinbase.com (English and German languages):

Are the images in the product setting you up for failure?

An additional risky area is visuals.

If icons, pictures, or even GIFs in your product contain any embedded text, your design team will need to create a language-specific version for each image.

This is a lot of work! To avoid it, ask your design team to follow these simple rules:

• Visuals must contain only illustrations and graphics, with no embedded text.
• All banners must be assets, not pictures i.e. banner texts must come from the code, not from the graphic file. In this case, banner strings can be automatically extracted and localized the same way as other product copy.

NOTE: Does your product have business potential in Arabic, Hebrew, or Urdu-speaking markets? These languages are written from right to left (RTL), and you’ll need to support UI mirroring to display them correctly. RTL support also impacts user input. Enabling RTL support in a product is a huge engineering task, so make sure you plan enough time for it.

Product localization strategy step #3: Challenge your product copy

After the design, comes product copy. For most products, the initial language is English, so I’ll be referring to it as to “source language.”

However, your source language can be any language, of course.

So, ask yourself: Is our product copy good?

Is it consistent in style and tone of voice? Is it clear and understandable? Is it written by professional UX writers or non-native English-speaking developers or designers?

What often happens is that startups neglect the quality of original product copy or assume it’s good – until translators start asking too many questions (what does this string mean?) or report grammatical, logical, or stylistic issues in it.

Rule #1: No good translation ever comes from a poor source text

Before sending your product copy for translation, ensure it’s coherent, clear, and stylistically consistent. Otherwise, your product language versions can sound messy or misleading, and you’ll likely blame your translators for it, yet the root cause will lay elsewhere.

A good practice is to create your product style guide.

It should describe your user persona and define user addressing rules (formal/informal) and tone of voice. All this information is critical for keeping all your languages in good shape, starting with the ”source one.”

NOTE: Unlike English, many languages have different variants of ‘user addressing,’ which depends on the context and style requirements. User addressing must remain consistent throughout the product, otherwise, it will sound confusing to a user.

Rule #2: Begin by translating your product Glossary

Don’t forget your Glossary is a critical asset for building high-quality product localization.

It’s a termbase containing all your product key concepts and terms, including their descriptions. Any new language begins with getting the Glossary translated – that’s how you ensure consistency of translations across all your content.

Product localization strategy step #4: Internationalize your product

The internationalization of a product means changing its code in a way that UI can be shown to users in different languages.

It’s a process of making all strings localizable, i.e. separated from the code. After it’s completed, it needs to be collected to a locale file(s), say localizable_strings.arb (example from Flutter framework). Later on, you’ll send your English locale file(s) for translation to your language service provider(s) or upload them to a translation management system.

Most programming languages and frameworks have existing internationalization libraries that extract translatable strings from the code. Plus, they provide local formatting for numbers, currencies, dates, and times.

This is especially important for products where users frequently see these things, ex: in payment or booking services.

NOTE: Not all the product strings come from your code. Some may derive from third-party services, which may or may not support your languages. Remember to pass the locale parameter to these services – it’s how users will see the whole product in their language. If a third-party service doesn’t support some of your languages, check to see if they provide the opportunity to add custom languages. Otherwise, simply use a fallback to the English language.

Give users the chance to choose their preferred language

Always make sure your users can easily select the language at any step of their user journey, starting from onboarding (when a user doesn’t have an account yet).

Store the user’s selected language as a parameter that you’ll pass to external services. If a user switches to the Spanish language in the product, they should also receive emails, SMS messages, and push notifications in Spanish.

You may also try to initially detect a user’s language from their device or browser – but always allow your user to switch it at any time.

The language switcher should be located in a visible place (header, footer) and must be easily found even in the event a user switched to the wrong language.

It’s common to use country flags to represent the languages, but it’s not always the best idea. Some languages are spoken not only in specific countries but in regions (for example Latin Spanish), and some languages may even be spoken in regions of territorial dispute.

Product localization strategy step #5: Go beyond

Localization is not just about getting all your app strings translated. It’s about showing culturally relevant content to local users.

Try to look at your product from the local perspective: Do the images you see look like they could be local to a specific region? Do you offer local payment methods? Do you comply with local regulations?

If you show any news on or within your product – is this news local? Consider every aspect of your product that might need fine-tuning for local markets – they all impact your conversion rates and the company’s bottom line.

Product localization strategy step #6: Focus on the process

Now we’re getting to the core.

Establish the delivery process

Think of your current product feature delivery process – at some point, you’ll need to incorporate localization into it.

Do you want to release new features in all the languages simultaneously?

In this case, you’ll need to allow some time for content localization and localization testing, which will delay the feature release.

Alternatively, you may release new features in English and let other languages catch up later. This approach is used in products with short release cycles, but has its drawbacks: at any given moment of the time, users will see some untranslated strings.

Implement a translation management system (TMS)

Regardless of the language delivery approach, there’s one core thing that must be in place – a translation management system (TMS).

You’re not going to have your strings translated in Google Sheets, right? Well, it will work for one of two iterations, but you can’t build an efficient and scalable localization process on Google Sheets.

A translation management system (like XTM, CrowdIn, Lokalise, SmartCAT, etc) is a professional translation tool where you import (manually or automatically) your source content, it gets translated, and then your export the multilingual content back.

It’s not just a translation interface, but also a database of translations that you can re-use to speed up the process and save up some budget.

Also, there’s always a Glossary where each term has an assigned translation and therefore always gets translated in the same way. Besides, most TMS have multiple integration options that allow you to automate the language delivery.

Don’t forget about good old project management: assigning tasks to translators, providing them with context, managing multiple translation projects (websites, web and mobile apps, marketing materials, etc).

Finally, most TMS have machine translation functionality – if used in a smart way, it can save you tons of time and money.

Selecting a TMS is a key decision that will impact all your localization activities. As practice shows, companies rarely change their TMS, since the migration to a new one is almost always painful and resource-consuming.

So take your time comparing different tools and finding one to rule them all that’s most compatible with your existing tools used by product, marketing, and customer support teams.

Eventually, you’ll manage all your company translations in one place.

Product localization strategy step #7: Help the translators

No good translation can be done without context.

It’s unlikely your translators will log in to your product and start translating strings right there in UI. This is not how it technically works.

Your translators will work in TMS, where you’ll be uploading your product locale file(s) for translation. Your product locale file will contain hundreds if not thousands of strings. Each string will have an identification key. Translators will be dealing with the text part of the string, while the keys will always remain the same.

For every string, your translators will need to know the context. Here’s how you can (and should!) provide it:

• Via screenshots (most TMS allow attaching screenshots to strings)
• Via dev comments (some locale files formats allow adding context info)
• Via answering the translator’s questions (good linguists always ask questions when in doubt)

So if you want your languages to make sense, take your time and upload every possible screenshot of your product to TMS before translation begins.

And please do regularly answer the translator’s questions!

Ideally, you should go the extra mile and provide product training for the linguists who will be working on its localization. The better they understand the product, the better the product will look in non-EN languages.

Bonus: Put quality first

Ok, translations are ready. Now what? Now you need to make sure they make sense and look good in the product.

This is when the time comes for localization quality testing (LQT). This is a process of in-context reviews for each language.

During this phase, translators look through each screen of your product and make the necessary corrections to the translations. Additionally, ask them to report code-related issues like “untranslated” strings or cases of broken layout. Ask your QA team how they can contribute to testing the languages, and how localization bugs should be reported. Beyond that, your QA team can help you arrange access to the test environment or test builds for your translators. The main task is to get the in-context review completed before the languages go to production.

Postscriptum

As you can see, product localization is so much more than just a simple translation. It’s an adaptation of your product to foreign markets, and it has one clear goal: to create a native user experience for your users in different counties. It takes a lot of work to get there (it’s called “localization management”), but it’s worth it. So if you’re not sure how to combine your existing duties with launching new languages, hire a competent localization manager who’ll help you with the tools, processes, and resources.

—

About the author:

Anna Iokhimovich, CEO and founder of LocLaunch, former Localization Director in Paxful, localization expert with 10+ years of experience in the localization industry. Guest lecturer of Estonian entrepreneurship university of applied sciences and TalTech University, Estonia. IKEA fan, Hebrew, and Estonian learner.