HomeNewsShowing UX respect to our non-English speaking users

Showing UX respect to our non-English speaking users

medium bookmark / Raindrop.io |

How we cheaply localised our indie iOS apps to Spanish, while avoiding common pitfalls that often worsen the experience for many users.

Offering our apps in multiple languages is been a priority since we started our collaboration. While our shared language is English, it’s not the primary for two of the three of us. We come from different countries and cultures, so we have spent much time discussing the effect of these nuances in the experience of our iPhone apps Money In & Money Out.

Apple technologies make very easy for developers to structure apps for multiple languages. Xcode supports incremental localisation, so even if you only support one language at launch, you are reducing a lot of the pain of adding additional languages to your app in the future. 

This makes possible to launch apps in other languages very fast and cheap, but not necessary taking the time to consider what type of experience the international user is getting. The translation approach varies greatly,  from apps that merely replace words with machine translation, to others that carefully interpret the content and context to fit regional mental models. In our case, we opted to provide in our Spanish apps the same clarity and efficiency of use as the English ones.

The translation work per se didn’t take great deal of work: content seemed to fit nicely, as well as labels and headings. A few tests and amends later, the app was polished and ready for the App Store in Spanish. It sounds fast and easy because it was. But there was some up-front work we did for this to be efficient and cheap, and it was addressed at the start of the project when Matt, our designer, started sketching solutions.

Our localisations strategy

We didn’t want to be just “available” in multiple international App Stores, we wanted to provide an inclusive product, one that fits the needs and expectations of different users around the world, not only the English-speakers. As we were building our English-first apps, we kept this goal in our heads along the way, and it guided many of our decisions during design and development.

1. Design for inclusion

When designing our apps, we always tried to keep “the other” users in mind. We took in consideration how elements such as images, icons, colours, typography, forms, buttons, labels, action sheets, alerts, notifications… would work in different languages and cultures.

We made design compromises to benefit clarity and efficiency in different contexts, and always prioritised accessibility and inclusion over aesthetic choices.

We made sure our interface was adaptable, so elements wouldn’t overlap and text wouldn’t truncate, to avoid ruining an otherwise good experience. It’s important to note that English has larger vocabulary than most languages, including Spanish. So often translations in other languages contain more characters or words to communicate the same thing. Truncation issues  are quite frequent in localised apps:

2.  Contextual translation of words and user experience

Content is “king” everywhere, independently the language spoken. Our apps speak plain English and are jargon-free. They provide clear feedback, allowing the user to feel in control and confident in the task they are completing. 

With the Spanish version, we wanted to keep clarity and ease as the backbone of our user experience, which meant the apps had to hablar en cristiano (“speak in Christiano”- an old Spanish expression which means”speak to me in a way I can understand”). As you can see with this example, translating words is not the same thing as interpreting them. This sometimes became a challenge when translating to Spanish, as words rely heavily on context to provide their exact meaning. For instance, in Spanish the word contabilidad means both accountancy and bookkeeping, which are two different things.

3. Understanding of iOS regional conventions

Apple localisations save great deal of work, as you don’t have to worry about translating the iOS interface elements in your app. Said that, if you care about your users micro-interactions, it is important to get familiar with iOS region-specific conventions, so you can use the right terminology in the user onboarding or in the app settings.

In the case of Spanish iOS conventions, there are some subtle differences to the English ones. 

For instance, what in English is known as “Background Refresh”, in the Spanish iOS is named “Actualización en segundo plano”. However, if you search for background refresh in Google Translator, it translates it as “Actualización de fondo”, thus the mistake many developers make when labelling their app permissions. Thus it’s super important that the person translating is familiar with the conventions of the regional variations of iOS. Other labelling issues can easily be found with the Photos app (“Fototeca“) and the Mail app, (Apple themselves can’t figure out this one, so they inconsistently use both “Mail” and “Correo” as labels).

4. Translation in Xcode, testing constantly on device

It seems there are two main ways to do the translation work of your localised text files. The common approach is to export the localised files for translation, either by machine (e.g Google Translate), or with a human. The translated files are then imported back into the Xcode project. While this might feel simpler and cost-effective, it carries its own problems, like the translator can’t see ad hoc how the translation works on the app, and then things like these happen:

To avoid these issues, we translated directly the localisation strings in our Xcode project (no coding experience is needed to edit the localisations strings, just a little bit of guidance from your developer). This enables the translator to first translate, and then test on device, amending and testing as many iterations as needed, to make sure the experience is interpreted correctly. All without impacting development time or cost. Once complete, the translator can push to Github and the developer can simply merge the localisations branch to the project. Then, before submitting to the App Store, try sharing a build through TestFlight with a few users from your target region to make sure there are no holes in the experience.

5. Localisation of product website, support and privacy policy pages

There is no point in translating the apps and launching them internationally if we can’t communicate their benefits, answer FAQs, support users, or highlight our commitment to privacy and security of personal and financial data.   

Once we were ready to submit, we included new iTunes Connect properties for the Spanish App Store, including localised screenshots, video preview, description and key words. We translated our promo page, help & support and privacy policy so users could access them from the App Store. All the good localisations work you’ve done in your app won’t shine without putting same effort on communicating the app benefits and key features to your target users… in their own language.


No matter how you deal with your localisations strategy, keep in mind that being available in the App Store is not enough. If you want to have a chance of making money in other markets, make sure you treat your international users with some UX respect, otherwise they will say adios as they delete your app from their iPhone without mercy.

Featured articles on Prototypr: