A small screen is both limitless and limiting. Mobile applications offer seemingly endless opportunities for creative ideas to flourish, bringing innovation and convenience to the palm of your hand. But, with such limited real estate, your design should be sleek, your text short and sweet, and the experience simple enough for users to figure out on the first (or second) try.

I’ve worked both “vendor-side” (managing outsourced translation) and “client-side” (engaging with internal stakeholders, pushing localization quality upstream), and there are distinct challenges in each. I now work on Snapchat, which is minimalist on the surface, but a very complex app. Comprising creative tools for self-expression, dynamic social interaction, and e-commerce, all on a tiny mobile screen, it presents a host of unique inter­nation­ali­zation (i18n) challenges. Within the Snapchat app, translation is a double-edged sword: We take a creative approach to adapting product names and concepts for international audiences, but we can’t always go all-out due to design constraints or technical limitations. Effectively localizing these products means balancing linguistic perfection with practicality. The former lies with the translators and end users, the latter with the teams that build, iterate, and maintain the products.

Here I’ll share some key takeaways to help mobile development teams on their journey to offering customers a fully localized, globally resonant mobile product experience. I’ll use localizing from a U.S. English app as our reference, but these considerations generally apply across the board.

Do the early work

Also in this issue

Ask an expert: What’s the best way to begin software localization?

PhraseApp’s Frederik Vollert provides an overview of the essentials.

Just because your app is only available in English right now doesn’t mean it’ll never be available in other languages. Internationalize your codebase in the early stages so the software can be localized when you’re ready. This means you should anticipate the challenges of building software that works seamlessly in other languages and locales. Considering the engineering obstacles early on will save you time, money, and the headache of retroactively making product changes to accommodate linguistic and cultural nuance.

A properly internationalized codebase allows you not only to translate the words on the screen, but also to tweak your product to eliminate barriers to use in other markets. These tweaks can be subtle or drastic, and can impact anything from registration flow to reverse logistics. Here are some important things to keep in mind, with examples to consider for each:

Culturally aware elements

You’re probably used to filling out forms or signing up for new services in a certain way, but your global customers may expect things to look a little different.

• Given vs. family name: When a user is signing up to use your product, which name do they typically enter first? What if someone has more than one family name? Does the concept of a middle name (or middle initial) exist for this market?

• Address format: What address elements will users in a given market require, and what’s the standard way to write them? Consider the number of lines required for addresses, and fields like country, state/province, zip/postal codes, and so on.

Date, time, and other number formatting

Numbers are crucial to a successful user experience. A date rendered as “1/2” could mean January 2 to you, but February 1 to me. So, which comes first, the day or month? Are users more accustomed to a 12-hour or 24-hour clock? Should you show a decimal comma or decimal period?

Capitalization

Each language/market has its own conventions for capitalization in different use cases. What are the standard conventions around capitalizing nouns and proper nouns, words in a title, and so on? Does your design involve text shown in ALL CAPS?

Abbreviations

Consider what abbreviations might lead to confusion or misinterpretation. Will “10m” be interpreted as 10 minutes, 10 meters, or something else?

Character corruption

It may seem obvious, but remember that different languages have different character sets. Does your default UI font support all the characters of your desired languages? If not, you may need to look for different fonts for specific languages.

Don’t forget to ask native speakers or in-country reviewers for feedback when making these decisions. Fonts may evoke a different feeling or mood for other markets, so be sure you’re choosing one to match the look you’re going for.

Currency

Consider whether or not users will be impacted by prices shown in your currency or their own. Should prices be converted, or does that lead to further complications for your product teams? What are the legal requirements for displaying prices versus facilitating commerce in other markets?

Text direction

Don’t forget about users who are accustomed to a product experience that’s a mirrored version of your source. Do you plan to support any right-to-left (RTL) languages? The approach is different on iOS vs. Android but, in either case, plan for bidirectional (bidi) text, which is a mix of RTL letters and left-to-right (LTR) elements, such as proper nouns and product names, which are typically left untranslated. Numbers are tricky: Hindu-Arabic numerals are LTR, but Eastern Arabic numbers (used in Arabic script) are RTL.

Auxiliary content

Do you send out automated emails or use customer support macros? What sorts of creative assets or marketing collateral do you use? How can localizing (or choosing not to localize) supplementary content and services affect your business operations—or your users?

Create a separate, centralized file with English strings

You’ve heard it before, and I’ll say it again: Don’t hard-code user-facing strings. Isolating your strings files will simplify the entire process for developers and translation teams alike.

Keep your strings in a designated file to make it easier to manage your source language copy. The higher the quality of the source copy, the more likely you are to receive quality translated content.

If you have multiple strings files, make it very clear how those resource files are related. For instance, are these core UI strings? Error messages? Marketing or creative copy?

As your organization expands and your app grows increasingly complex, establishing basic protocol for formatting resource files becomes even more important. Standardizing these practices will help your teams to work more effectively, efficiently, and autonomously as you scale.

Write user-facing strings in full sentences

Don’t concatenate strings! English syntax is flexible, but other languages may have different subject + predicate constructions.

An example: When Snapchat made it possible to save photos and videos in Group Chat, we ran into some issues with grammar and syntax in our in-chat notifications. We had the subject and verb in one string and the variations of the direct object in separate strings.

This worked for English, but fell short as we translated into other languages. German illustrates a difficulty with this approach:

• Correct English:
  JULIA SAVED YOUR PHOTO

• Incorrect German:
  JULIA GESPEICHERT DEIN FOTO

• Correct German:
  JULIA HAT DEIN FOTO GESPEICHERT

In German, the auxiliary verb conjugated for the third person singular HAT must be used in this construction with the past participle GESPEICHERT at the end of the sentence.

There will always be dynamic elements in strings (username, numbers, etc.). Include placeholders in the string to allow for syntactical changes. If your translators are working in a translation memory, the placeholders should be parsed as “tags” or “inline elements” to prevent them from editing the code. It’s easy for them to move the placeholder to make the phrase grammatically correct for their language.

• English, as seen by the translator:
  Showing payment options for {country}.

• Spanish, as seen by the translato:
  Se muestran las opciones de pago de {country}.

• Japanese, as seen by the translator:
  {country}での支払いオプションを表示しています

• English, as seen by the app user:
  Showing payment options for Canada.

Quantity strings (plural numbers) are complicated. Android and iOS have different approaches and, luckily, there’s a lot of great information available online.

• Android: Use plural arrays for quantity strings. See the Android developer resources as well as this nice tutorial from OneSky.

• iOS: Use the stringsdict file format. See the iOS developer resources, as well as Apple’s general Inter­nation­ali­zation and Localization Guide for localizing apps.

The Common Locale Data Repository (CLDR) page on Language Plural Rules from Unicode is impressive too.

Add screenshots

Cliché, yes, but a picture is worth a thousand words—so always include screenshots of the UI for your translators. This helps avoid confusion around what the string is, what it does, and how the translators can best adapt it for their language or market.

The shorter the string, the more difficult it can be to translate. The appropriate translation may differ depending on whether the text is for a button, a header, a list in the settings menu, etc.

Human language and its rules are illogical at times, and translation quality is subjective—a reviewer may dub a translation excellent due to its simplicity or clarity; another may dub it clear but too generic, therefore mediocre. By helping them understand your product, they can help customers understand—and interact positively with—your product.

Test, test, test!

So much effort goes into building the source version of your product. If you’re serious about growing and maintaining your international user base, you need to invest in the quality of the localized versions of your product, too. If you owned a bakery you wouldn’t spend all week baking and decorating a perfect, beautiful cake for one customer, then bake 15 more cakes only to mash them up before serving them to the other customers. If you’re only focusing tests on one language, or on one version, of your product, you’re leaving your other users with a suboptimal experience.

At the end of the day, no matter how good your translators are, you should always test. There are two kinds of localization testing:

Functional

This concerns functional elements of your product when localized. For instance, does the localized text fit, or does the UI break? This is especially important if you support languages that are long compared to English (or your source language), or any right-to-left languages (think Arabic, Hebrew, Urdu) that require special engineering attention.

Linguistic

This concerns the content and clarity of the text itself. Boiled down, does the localized text make sense? Is it clear to the user what tapping each button does, how to move between various screens, or why they would do so? Does the localized UI match the look and feel of the source? Does the localized version maintain the same style and voice? Aim for consistency in all languages and locales, as well as across all products and platforms.

On the functional front, you can use pseudolocalization to preemptively test your design even before translation is completed to see how the UI is affected by text expansion. This allows you to catch and fix many functional i18n bugs well before release. Leaving this crucial testing for later stages of development is not only costly, but it can also negatively impact launch and the overall international user experience: Once your product is out in the wild, users could have a poor experience, publicly express disapproval (thereby deterring others), and never use your product again. Your problems compound if you spend valuable marketing resources promoting a suboptimal user experience.

The goal is feature parity across all languages and locales. If you only test the source version of your app, how can you be sure you’re providing every user with the experience they deserve?

Use translation memory

There are tons of options on the market, and there’s no one-size-fits-all solution for every aspect of every business. The right set of tools and the ideal translation approach depend on what your product is, how complex your code is, and the scale at which you operate.

A translation memory stores all your previously translated content for future use, which allows you to reduce costs and maintain consistency across multiple platforms and products.

Find yourself a reliable, cost-effective translation management system (also known as a TMS), which may or may not offer outsourced translation services directly in the platform. More and more systems are equipped to handle resource files, which eases the pain for developers.

You will likely need the support of a language service provider (LSP)—and, as you grow, perhaps more than one—which is a good arrangement for the majority of companies. LSPs provide vendor-side project management as well as human translation services, and can maintain all your linguistic assets, including translation memories, glossaries, and style guides.

Machine translation (MT) is a relatively new field, and while its obvious appeal lies in speed and cost-effectiveness, the results are hit or miss if you don’t use it with care. There are a variety of factors to consider (language combinations, type of content, use case, etc.), but going the cheapest, fastest route will be apparent to your international users.

Effective MT with minimal human intervention takes dedicated localization expertise. MT almost always requires post-editing, where human translators edit the MT output to correct basic errors. If you’re committed to global expansion, it’s worth working with an LSP to build up substantial, high-quality translation memories and implement linguistic quality assurance measures. Ask your LSP about their experience with MT and MT post-editing to see how this can fit into your workflows.

Conclusion

With these principles in mind, you’ll start off on the right foot. To keep up with a fast-paced world as you scale your product, plan ahead for localization and inter­nation­ali­zation. If you’re building products with global users in mind, lay the groundwork to optimize for one or two languages beyond your source language from the get-go. From there, adding new languages and locales as well as expanding product offerings will feel more like flipping a switch than rejiggering wires.