A Developer’s Guide To User Experience In App Localization

A Developer’s Guide To 

User Experience In App Localization 

phraseapp.com | sales@phraseapp.com | +49-40-357-187-76 | twitter.com/phraseapp | facebook.com/phraseapp | linkedin.com/company/phraseapp

A Developer’s Guide To User Experience In App Localization 

Table of Content 

Why You Never Really Knew About User Experience, Until Now 3 

Even Big Software Vendors Struggle With UX 4 

A Localization UX Issue Sampler 4 

Start As You Mean To Go On 5 

UX, UI, And Usability In App Localization 5 

What Is Your App Localization UX Role As A Developer? 6 

Don’t Make Users Think About Your Localized App 6 

Internationalization And User Experience 7 

Practical Aspects – Language Length And Font Sizes 7 

Double-Length Pre- Or Pseudo-Localization To Find Problems 8 

Handling App Localization UX Issues Caused By Layouts 8 

Right To Left And Left To Right Displays 9 

UX Issues With Partial Localization 10 

Translation Contexts And Glossaries 10 

Conclusion 11 



If you have not yet met the term “user experience,” then now is the time, especially given its 

huge impact on app localization success. 

Your app’s user experience – what the user experiences when using your app – is typically the 

one thing that makes or breaks the success of your app. It’s simple. If users do not see value in 

your app, or have fun using your app, or get something out of it that they appreciate, they will 

not use it. Your software will become shelfware. All the days you spent coding and testing will 

have been for nothing. But how much impact do you have on user experience? Probably much 

more than you think. And when it comes to app localization, even more. 

Why You Never Really Knew About User Experience, 

Until Now 

I know what you are thinking. If user experience, or UX for short, is so important, how come that 

there is so little emphasis put on UX compared to the code-writing aspects of software 

development? There are two main reasons: 

1. UX is often mistakenly viewed as a marketing or UX specialist-only responsibility, a kind 

of touch-feely domain involving users “on the other side of the wall.” You might get 

instructions or requests to design or modify an interface in a certain way, but nobody ever 

seems to explain why. 

2. Apart from a catch-all approach of “making sure the app user has a good time”, many 

people only have a hazy notion of what UX is about and cannot explain the little they 

understand to others. 



Even Big Software Vendors Struggle With UX 

Try this definition of user experience from one of the biggest software vendors on the planet 

(yes, Microsoft, I’m looking at you): 

“An activity of encounter by a computer user with the auditory and visual presentation of a 

collection of computer programs. It is important to note that this includes only what the user 

perceives and not all that is presented.” 

This is akin to a restaurant offering “cold, dead fish,” instead of lip-smacking, gourmet sushi. We 

need a better way to delight users with localized versions of your app, build solid and loyal user 

bases in different countries, and keep app subscriptions rolling in (if such is your business 

model.) 

A Localization UX Issue Sampler 

Before getting to a more effective definition of user experience, take a look at some of the ways 

that poor app localization might negatively affect UX: 

● Foreign language text is longer or shorter than the original version, and makes the layout 

look strange or simply wrong 

● Variable handling generates grammatical errors that make localized strings look 

ridiculous to native speakers of the localization language 

● Minimum font sizes that were acceptable in the default language (the one you have been 

working in to build the original version of the app) make other languages unreadable 

● Right-to-left and left-to-right language localizations leave users with different 

impressions or just plain confused. 

These examples of UX issues concern technical aspects of app localization, and therefore they 

concern you as a developer directly. However, there are many more potential UX problems (see 

below) that will also involve you as you manage app localization cycles, sending text strings off 

for translation, and working with your product management or marketing colleagues to ready 

your app for new markets and cultures. 



Start As You Mean To Go On 

If you are going to build better user experiences into your app localizations, you will need to 

know what to aim for. So, let’s try another definition of user experience to start off on a better 

track, this time from the Nielsen Norman Group. 

“All aspects of the end-user’s interaction with the company, its services, and its products. The 

first requirement for an exemplary user experience is to meet the exact needs of the customer, 

without fuss or bother. Next comes simplicity and elegance that produce products that are a joy 

to own, a joy to use. True user experience goes far beyond giving customers what they say they 

want, or providing checklist features. In order to achieve high-quality user experience in a 

company’s offerings there must be a seamless merging of the services of multiple disciplines, 

including engineering, marketing, graphical and industrial design, and interface design.” 

This is far more inspiring. A big reason is that one of the persons contributing to this definition is 

Don Norman, who invented the term “user experience”. The other person in the “Nielsen 

Norman” pair is Jakob Nielsen, who was already reinventing website usability in 1999 with his 

book “Designing Web Usability: The Practice of Simplicity.” 

UX, UI, And Usability In App Localization 

To position things properly for what follows, let’s see why user experience, user interface, and 

usability are different. Of the three, only user experience encompasses the whole range of 

impressions, feelings, likes or dislikes that users have when using your app. That does not mean 

the other two things are unimportant. The user interface must offer access to functionality that 

is of value or of interest to the user. The app and its UI must also display good usability by being 

clear and simple to use, pleasing to the eye, easy to learn, and efficient (as in the minimum 

necessary number of taps, swipes or clicks) in taking users where they want to go. UX groups 

together the quality of the UI and the level of usability, and then adds further aspects: for app 

localization, for example, this includes the correct use of colors, symbols, backgrounds, and 

indications of direction (how to navigate a localized page.) 



What Is Your App Localization UX Role As A 

Developer? 

While it is true that marketing and product management may spend more time on profiling 

culture-related app localization requirements, as a developer you are likely to be involved in 

ways that go beyond your IDE. For example, you may well handle the translation process, 

sending content (text, graphics, audio) to translators, integrating feedback from localization 

reviewers, and making the final localized versions of content available as part of the app 

package. And frankly, it does no harm to be sensitized to ways in which not just 

language-dependent, but also culture-dependent elements can affect the UX of localized 

versions of your app. Then it won’t seem so strange when marketing asks you to change the app 

screen background image for an app localization into Japanese to one that has brighter colors 

and a sun-ray effect, because culturally these changes will better match expectations of 

customers in Japan (yes, really!). 

Don’t Make Users Think About Your Localized App 

Steve Krug wrote his book “Don’t Make Me Think” to help people think like a usability expert (a 

large part of creating the user experience), even if they have a different job role, like being a 

developer. He aimed his ideas at web applications, but they carry over naturally to mobile apps 

too. Among some of his pithy suggestions are: 

● Don’t make people think. People typically don’t want to have to puzzle over apps to get 

what they want out of them. 

● Apps should explain themselves, at a glance, from the first screen onwards. 

● Don’t waste people’s time. Keep text short and sweet, and minimize distances over 

layouts and through menus. 

● The back button is good. If people guess, don’t penalize them. Let them back out again 

easily. 

Further care is needed when it comes to app localizations. The interface and the usability for 

your app are likely to have been created according to your own cultural norms. However, what 



may seem natural in one culture may look strange or different in another. For example, this 

could affect the UX of a localized version of your app in these ways: 

● Translation of terms, especially short phrases or single words for buttons. The shorter the 

phrase, the more important it is get to the intention behind the phrase, and work from 

that to find the appropriate translation or equivalent for localization. 

● Forms for user input. Some cultures (Anglo-Saxon, for instance) often offer three fields for 

users to enter their names: given name, middle name, and family name. Elsewhere, in 

Asian countries for example, the norm may be just two fields. If you insist on offering 

three fields, you are “making them think,” which from a UX standpoint is not the way to 

go. 

Internationalization And User Experience 

The ideas above for improving user experience are more effective when they are integrated into 

an app from the start, instead of being layered on as an afterthought. A similar concept already 

applies in the internationalization phase that precedes language-specific app localizations. 

Internationalization is the process of separating out as much user-facing content as possible 

from the app, to make it language independent. The separate user-facing content can then be 

localized into one language after another, according to marketing or end-user requirements. 

Internationalization also covers graphics and audio content, and by extension, can cover any 

other aspect of an app that is not only language dependent, but also culture dependent. 

Platforms like Android and iOS make it relatively easy to separate out content and also provide 

convenient functions to automatically handle localized formats for numbers, dates, and 

quantities. On the other hand, while offering considerable help in ensuring good UX, 

internationalization, like UI and usability, is just one part of the whole user experience of a 

localized app. 

Practical Aspects – Language Length And Font Sizes 

Foreign language equivalents of texts in your own language will tend to be either shorter or 

longer. In some cases, the difference can be dramatic. For example, the word “User” in English is 

usually translated as “Benutzer” in German (twice as many characters) and “Utilisateur” in 



French (almost three times as many characters. Clearly, trying to squeeze all these extra letters 

into a space tailormade for the shortest version will cause problems with display and layout, 

usability, and therefore UX. 

Minimum font sizes that work (just) with languages like English may make other more complex 

language characters unreadable: 漢字 , for instance. Additionally, line height used for English or 

similar Western languages may be too small for Chinese and other languages needing greater 

line heights. Whatever the font size or line height, the characters for any localized language 

must be readable. This may mean increasing minimum values for all language versions, or 

possibly using different layout criteria for different localizations (see below.) 

Double-Length Pre- Or Pseudo-Localization To Find 

Problems 

Word length problems caused by volume expansion as in the English/German/French example 

above can be detected by making a double-length version of separated text strings and 

displaying this double-length version. Text overruns will be much more obvious. However, for 

app localizations that lead to volume contraction (English to Chinese, for example), the services 

of a native speaker with an eye for layout may be indispensable to identify where too much 

blank space is being generated and where fields, buttons, or layouts may need to be modified. 

If your app runs on a PC or via a PC browser, using a keyboard, watch out for hotkey or 

macro-style key combinations that may not be available on keyboards for other languages. You 

may find it better to use function keys (F1, F2, F3, etc.) which are often available no matter 

which keyboard is being used. Alternatively, avoid this kind of hotkey functionality from the 

design stage onwards. 

Handling App Localization UX Issues Caused By 

Layouts 

A localized version of an app can lead to unsightly changes in layout, even when automatic 

adjustment is used (like Auto Layout in iOS.) The examples in the previous section indicate why 

this can happen. A layout that lined up nicely in the default language may become distorted as 



it struggles to display foreign language equivalents. Efforts to standardize on one set of 

dimensions for a language with medium space requirements may not work either, especially 

when volume expansion and contraction can double or halve text lengths, respectively. 

The best solution or compromise may be different in each case. It is likely you will only recover a 

reasonable UI and UX that works for different localizations by trying different options and 

getting native speaker input. However, some options might include: 

● Using dropdown menus to disguise length differences (this may lead to more clicks/taps 

being required, thus degrading usability) 

● Dynamic layouts that display longer texts on two lines instead of one (visually, this may 

look inconsistent between different localizations) 

● Programmatic changes to layouts, driven by the language or locale (country/language 

combination) of the localization. This is a possible solution to the changing number of 

name fields between different localizations – See the “Don’t Make Users Think” section 

above. 

Right To Left And Left To Right Displays 

Right to left (RTL) languages such as Arabic and Hebrew not only change the direction of text 

compared to English, for instance, but they also change notions of time and sequences of 

actions. RTL native language speakers may therefore expect to see a “trash can” on the left of 

the screen, rather than the right, because that is where they naturally end up before taking a 

final action to throw something away. Similarly, “next” and “back” buttons will logically be on 

the left and the right, respectively, instead of on the right and the left, as in English language 

screens. In RTL displays, time runs from right to left. Watch out also for icons used to indicate 

functions such as text justification. They too will need to read from right to left, for example, 

with a “ragged left” icon, instead of a “ragged right” one. 

App interfaces that are highly dependent on lateral movement to make their logic and user 

experience work properly for LTR languages, may need to be rethought and redesigned for RTL 

languages, if the same quality of UX is to be achieved. This is yet another aspect that is best 

handled in the initial design phase, rather than trying to change an existing app. Sometimes you 

will not have the choice. However, if you are in the fortunate position of starting to design a new 

app, you can take these aspects into account, according to the different localizations you think 



you will require. You can also avoid the issue by using a vertical navigation design from the 

start, which obviates the need to start either from the left or the right. 

UX Issues With Partial Localization 

By now, you may well realize that localizations may be partial or incomplete in a number of 

different ways. Unfortunately, few if any partial localizations allow reasonable levels of user 

experience. 

● Partial translation. Mixing of phrases in different languages goes against the 

overwhelming preferences of native language speakers to buy and use products that 

work in their language. In mixed LTR/RTL language situations, the result may be even 

worse. 

● Partial cultural localization. Inappropriate colors and symbols can also wreck the user 

experience in a localized version, when the original or default items are reused without 

due care and attention. 

● Partial localization of formats. Omitting to change number separators from periods to 

commas, for example, when localizing into French from an initial English version, will 

make the interface look strange to a French speaker. With automatic formatting methods 

built into various operating systems, there is little excuse for getting this wrong. Some 

uses of variables may need more thought however, to make sure that grammatical 

structures are converted properly into their localized equivalents. 

One possible exception to partial localization is the localization of only the promotional 

information about the app for use in an app store, such as Apple App Store or Google Play. This 

ploy allows marketers to see how many native speakers download the app, helping the 

marketers to gauge sales potential for a specific localized market. However, this can only be a 

temporary situation, and the product must then be properly localized or revert to the full 

default version afterwards, to avoid user disappointment and possible negative feedback. 



Translation Contexts And Glossaries 

In Spanish, the English word “run” can be translated in more than 100 different ways. If a user is 

using a localized map app, “run” might mean a jog from A to B, but for a home automation app, 

“run” might mean “execute a program” as in setting the alarm, or switching a house into night 

mode. Context is vital in such cases, especially when there is only one right choice and so many 

other wrong ones. 

Translation notes and comments that you append to text strings help translators pick the right 

translation, maintaining user experience quality for the localized language. Useful information 

includes: 

● Subject context, as in the feature or domain most closely related to the word 

● Sentence/syntax context, for instance, whether the word is a noun, a verb, etc. 

● Definition, an alternative way of expressing the word 

● Specific usage, about how the word is being used in this specific case 

A translation glossary can also help preserve a good user experience in localized versions, by 

ensuring that certain words are always translated in the same way, that brand names remain 

untranslated, and so on. Such glossaries should always be reviewed by native speakers before 

being distributed for general use. 

Once again, remember that translation must sometimes go beyond words and make sure that 

cultural differences are properly reflected. On the Google home page in English for example, 

there is the link entitled “I’m feeling lucky.” In some cultures, luck is viewed differently, and the 

phrase may be changed to “I choose to trust in God” to correspond better to native speaker 

expectations. 



Conclusion 

App Localization is an essential step towards good user experiences for your app in 

international markets. However, it needs more than word-for-word translation. As a developer, 

one of the most important qualities you can develop to improve localized user experience is 

empathy with your users. This is, for instance, the understanding that what looks like a small 

detail from a non-native speaker’s point of view can sometimes derail the user experience for 

the native speakers. By working with your marketing and product management colleagues, you 

can then design and develop apps that combine efficiency in coding with excellence in user 

experience, boosting sales, adoption, and customer loyalty wherever your localizations are 

applied. 



phraseapp.com 

sales@phraseapp.com 

+49-40-357-187-76 

Große Theaterstraße 39 

Hamburg, Germany

A Developer’s Guide To User Experience In App Localization

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?