Localization is no simple matter. And for designers and developers who build mobile apps for audiences that speak languages other than their own, that complexity will never be clearer. That's why you have to carefully consider how your design and choice of typography may affect your users' experience. In this guide, we'll explore how the software and design strategies we currently use may not be sufficient for global app design, and what to do about it.

App localization might seem like a simple enough thing to execute. Design with global-friendly colors, add a language widget to the top of the app, and allow shoppers to switch currencies. But is that enough?

The fact is, language is complex. And I'm not just talking about the differences in how languages conjugate verbs or how easy they are to speak. Did you know that certain language sets are inherently shorter in height than others? And that some languages require a right-to-left orientation as opposed to the more common left-to-right?

These types of complexities can make app designers' and developers' jobs more difficult. However, if you're designing an app that's meant to be in the hands of a global set of users, you have to consider how language and the typography you've chosen to represent it affects their experience.

In the following guide, I'm going to give you a number of reasons why localizing typography should become part of your process.

Localizing Typography for Mobile Apps

While it would be great if you could find just one typeface to work across all localized versions of your mobile app, that's just not realistic.

Many fonts only work with a limited set of languages, which means you'll need to program your app to use a number of typefaces to cover all of the languages (and regions) you're targeting. To complicate things further, you also have to find ones that won't interfere too much with the branding.

So, before you start designing your next app, first consider how these physical attributes of your typography may affect the user experience and how to make them work.

Alphabet Compatibility

Before you do anything else, make a list of all the regions your app targets and which languages you'll need it translated into. The smaller your set of languages and the more alike their character sets are, the less of a need you'll have to hunt down multiple typefaces for your app.

That said, do your due diligence in inspecting the thoroughness of your chosen typography's character set. Even something like missing diacritical marks (like accents over vowels) could hamper the reading experience, let alone entire characters that are missing from the page and replaced with an empty box.

Plus, don't forget about languages that used mixed character sets. Japanese is a good example of this.

Amazon's navigation in Japanese

Above is a screenshot of Amazon's navigation menu in Japanese. There are four alphabets present:

  • English
  • Katakana
  • Hiragana
  • Kanji

While you might think you can get away with downloading a font that works in your target language, make sure you understand all the nuances of how their text is written first. It's not just a matter of accounting for missing characters either. It's a matter of using fonts for varying character sets that match one another.

If you want help with this, use the Monotype catalog to sift through typography options:

Monotype typography search by language

You can filter the search results to locate fonts that support your specific languages and, more importantly, their full character sets.

What's nice about this tool is you can explore more details about any font you're interested in using. See which languages are supported as well as which UIs are compatible.

Test language compatibility with Monotype

And if you want to be extra safe about it, you can do your own test like the one I did above. The language set does not include CJK (Chinese, Japanese, Korean), but I still wanted to confirm the characters weren't supported.

Device Support

If you want to greatly simplify things when choosing fonts for your mobile app, you can always just use Google's new universally-friendly font called Noto by Google.

Google's Noto font sets

For apps designed for a fully global audience, Google has packaged up 582 languages, covering 237 regions. Or, if you have only a few languages you need covered, you can download individual packages for them and conserve your server space.

For starters, this is a good option if you want to give your app's typography a consistent look regardless of which language it's in.

It's also a good choice if your users are primarily on Android devices. (Google supports both Roboto and Noto. For iOS users, it would be worth exploring San Francisco and New York.)

When designing mobile apps, you thankfully don't have to factor in something like browser support. (For those of you designing websites or PWAs, though, make sure to account for that in your own typography localization strategy.) But finding ones that are compatible with mobile devices and that allow you to flex your creative muscle can be tough enough.

Do a search in a font repository like Adobe Fonts and you'll find the licensing rules don't allow for their fonts to be used in mobile apps.

Adobe font licensing rules

Unfortunately, if you want to get custom with your mobile fonts, you'll have to license them from a source like Fontspring.

Language Orientation

Now, this one has less to do with choosing a typography and more about knowing how to manipulate your content's orientation so it doesn't compromise your design.

In some cases, app designers don't always follow the directional rules of languages. For instance, a language like Japanese which is traditionally written in top-to-bottom, right-to-left columns is written in its most modern form, from left-to-right. This makes it convenient for fitting a Japanese translated text into a space for other left-to-right languages.

But what about those that aren't as flexible? Let's use Al Jazeera's mobile app as an example.

This is what the English language edition of the app looks like:

Cover page of Al Jazeera in English

All text reads from left-to-right.

In the Arabic version of Al Jazeera, however, this is how the text appears:

Cover page of Al Jazeera in Arabic

Because the designers have strategically placed a solid background behind the titles of the news stories, the orientation of the text has no effect on the ability to see the image behind it or interpret the content on top of it.

That said, what if your design doesn't include an opaque background layer for text? For instance, if the primary language you designed for runs left-to-right, you'd choose images that wouldn't interfere with the legibility of the text. Would the same hold true if text were to run right-to-left over that same image?

And don't forget about smaller "text" details like icons, toggles and other text-adjacent design elements.

What if you designed a button to say Start Here with a right-facing arrow beside it? Shouldn't the arrow be moved to the other side of the text and flipped around to point in the other direction?

What about this example of the toggle switch in Al Jazeera's settings panel?

English settings options for Al Jazeera

In English, the toggle appears on the right side of the text and in orange when toggled on. But in Arabic:

Arabic settings options for Al Jazeera

The toggle appears on the left and in green.

These are small details, but are sure to be noticed by your readers.

Consistent Styling

When it comes to writing content for a web page — whether it's a couple hundred words or a few thousand — you have to build in breaks for the reader. This is especially important for mobile apps where scrolling can become painful very quickly if you can see no relief in sight.

Built-in breaks like section headers, bulleted lists, and stylized text are the only way to effectively encourage them to get through everything that's on the page.

It's not as though you can't use font stylizations in the localized versions of your app. However, in some cases, the way styles appear is inconsistent from version to version. There's also the issue posed by publishing in a language with only a limited number of available fonts. You're going to have very little wiggle room in terms of what you can do with styles like bolding and italics, let alone header tags.

That said, font designers are getting better at addressing this need. While you might not be able to present a 100% consistent face for your app from language to language, you can get it pretty close.

For instance, this is Haaretz, the Israel news app in Hebrew:

Haaretz in Hebrew

This is the English language version of that news app:

Haaretz in Hebrew

There are actually a number of notable differences, like the colors used in the header and for shading behind the news titles. However, if we just focus on the text itself, you can see that the bold style varies. However, within the context of how the app itself is designed, the bold face works great in both instances.

So, perhaps that's the way to resolve any issues you might encounter with inconsistent styles — to customize the interface design so that it fits within the context.

Language Length

Languages vary in size thanks to two factors. The first has to do with how their words are constructed.

A good example of this is evident in this example from BBC News. This is the English language app:

English language version of BBC News

Notice how all of the titles are succinct and exist within each article's card. I want to call your attention to card #2, which is titled:

"Hunt to face Johnson in Tory leader race"

Now, look at the Russian version of the app:

Russian language version of BBC News

The article titles are all excessively long here, most of which result in a final ellipsis to indicate that there's more to the title.

The Tory race title is far longer than the English counterpart I pointed out above. As best as I can tell, the text that's visible here says:

"In the final race for the leader of Britain, Boris Johnson will meet..."

Russian is just one language that tends to run on the longer side due to how lengthy its words are and how bulky the Cyrillic alphabet can be at times. German is another example of a "long" language.

When designing your app interfaces, be mindful of this. While a brand like the BBC can get away with incomplete article titles or any kind of cutoff or incomplete text, readers and users of your own app might not be as forgiving.

One way to fix this potential issue is to work closely with your translators. Give them a wireframe to work within so they know how much physical space is allotted to them. If you don't work with translators, you can always create custom but consistent dimensions for spaces that encapsulate longer (or even shorter) languages.

Language Height

On a related note, there's the question of how legible certain writing systems will appear when presented in the same vertical spaces as others.

This is the Strong workout app:

Strong app in English

Notice the navigation bar at the bottom. In particular, focus on the button highlighted for "Start Workout." It fits well, right? That's because this app was designed first for English users, so the text is going to fit seamlessly into the spaces built for it.

Now, let's move over to German:

Strong app in German

Although English and German both use the Latin alphabet, you can see that it's starting to get cramped in the navigation bar. And rather than decrease the size of the "Workout beginnen" button (which has 16 characters versus the 13 in English), the designer has reduced the tracking in order to make it all fit.

Similar to what I suggested above, I don't know that I'd suggest that fix for this spacing issue. While you certainly can't allow this text to wrap or to trail off to an ellipsis, you might want to consider working with your translators to ensure that text is written to fit your design.

Finally, let's compare these to the Japanese version:

Strong app in English

This is where it becomes apparent how the differences in alphabets can affect legibility when they're placed in a space not properly built for them.

You'll see this with some Asian languages, where glyphs with super-fine details become difficult to read if not allowed room to breathe. The Japanese example demonstrates that issue with the last couple of characters in the highlighted button.

You'll also encounter this issue with languages like Arabic that tend to appear smaller even when sized consistently with other language types. This is mostly due to the cursive-type style of the language along with the diacritical marks that appear above and below the words.

If your app is going to be translated into languages with different alphabets, it's important to think about how the height (or perceived height) will affect readability.

So, as you design your app's interface, you're going to have to consider one of two courses of action. Either design the app and its spaces with more than enough height for all languages to fit or customize key engagement areas for the languages that need it — things like the navigation, buttons, forms, and so on.

Wrapping Up

Building a mobile app is no easy feat, nor is writing the content for it. But the promise of reaching a global audience with it — and, more importantly, one that stays engaged with your app — makes it worthwhile.

That said, there's more to creating a localized experience for app users than choosing an agnostic color palette or writing dates and currencies in the right format. There's an intersection between language and design here and it's something you can take control of by paying closer attention to your app's typography.