Whats the Difference Between Translation and Localisation for Apps

An app gets translated. The text is now in French, or Japanese, or Brazilian Portuguese. The team ticks the box, the product ships, and then the reviews start coming in from those markets, confused users, low ratings, and a conversion rate that barely moves. The translation was accurate. Every word was correct. And yet something was deeply wrong.

Underneath language are cultural assumptions that get baked into a product from the very first wireframe.

This is the gap between translation and localisation, and it tends to go unnoticed until a team has already shipped. Translation converts words from one language to another. Localisation adapts the entire product experience for a specific culture, market, and context. The two are related but they are not the same thing, and treating them as interchangeable is one of the most common ways an app expansion quietly fails.

Across our work in emotional design and behavioural UX, the question of how a product feels to someone from a different background comes up constantly. Language is only the surface layer. Underneath it are assumptions, about how people read, what they trust, what they find reassuring, and what they find confusing, and those assumptions get baked into the product from the very first wireframe.

Understanding where translation ends and localisation begins is the first step to building something that actually works in a new market.

What Translation Actually Does

Translation is a linguistic operation. It takes the words in your app, button labels, error messages, onboarding copy, marketing text, and renders them in another language. A good translator handles grammar, idiom, and register, so the output reads naturally rather than like something fed through a dictionary one word at a time. That is not a small thing. Poor translation produces text that native speakers find jarring, and jarring text erodes trust before the user has even engaged with the product.

Translation is also the necessary foundation for anything else. You cannot localise a product that has not been translated. In that sense, it comes first.

What translation does not include

What translation does not do is change anything about how the product is structured, how the interface behaves, or what cultural signals the design is sending. A translated app still uses the same layout, the same colour palette, the same images, the same date formats, the same pricing structure, and the same assumptions about what a user already knows. If those things were calibrated for a British audience, they remain calibrated for a British audience, just in French.

Translation also does not account for meaning that shifts across cultures. A phrase that is warm and reassuring in one language can be formal or even cold in another. A word that signals trust in one context carries no such weight elsewhere. Good translation can get close, but the translator's brief is fidelity to the source, not redesign of the experience.

What Localisation Actually Does

Localisation is a design and strategy operation as much as a linguistic one. It asks a different question: what would this product look like if it had been built for this market from the start? That question reaches into visual design, information architecture, interaction patterns, pricing, and trust signals, everything the user encounters, not just the words they read.

A localised product adjusts date and number formats so they match what users expect. It considers whether the reading direction changes the natural flow of a layout. It checks whether images, icons, and colour choices carry the right cultural weight. It prices the product in a way that makes sense for local purchasing power. It adapts the tone of the copy to match how that culture communicates in a commercial context, which is not the same everywhere.

The emotional layer

Localisation also touches the emotional layer of the product. What makes a user feel confident, reassured, or welcomed varies across cultures. The social proof that works in a Western European market may carry little weight in South-East Asia, where different signals, community endorsement, family trust, institutional credibility, matter more. The emotional design of a product needs to be calibrated for the culture, not just the language.

According to CSA Research's "Can't Read, Won't Buy" study, 40% of users will not buy a product if the content is in a foreign language. Translation removes that barrier. Localisation is what determines whether the product actually converts once that barrier is gone.

Where the Two Overlap, and Where They Diverge

The overlap is real. Translation is part of localisation, it would be strange to localise a product and leave the text in the original language. And the best translators think about cultural fit as they work, flagging phrases that do not transfer cleanly and suggesting alternatives that carry the right tone. In that sense, good translation already leans towards localisation at its edges.

But the divergence is sharper. Translation works at the level of content. Localisation works at the level of experience. A translated product might read correctly and still feel foreign, because the experience around the words has not changed. Layout, visual hierarchy, interaction patterns, and trust cues are all part of how a product communicates, and none of those are addressed by a translation process.

A translated product might read correctly and still feel completely foreign to its new audience.

Consider colour. Research from Build Grow Scale found that orange converts 34% better in the Netherlands but 12% worse in Colombia, the same colour, the same function, opposite effects. Translation would not touch the colour palette. Localisation would.

Scope and cost

The Assumptions Hidden Inside Your App

Every app is built with assumptions. They are the defaults that the team reaches for because they match the team's own experience of the world. Left-to-right reading direction. Dates written day-month-year or month-day-year depending on where the team is based. Prices in a currency the team uses. Images of people who look like the team, or the team's idea of a typical user. Trust signals borrowed from products the team already trusts.

These assumptions are invisible to the team that made them. They only become visible when someone from a different background encounters them and experiences something slightly off, a friction they cannot quite name, a product that technically works but does not quite feel right.

Audit your app for assumptions before entering a new market. Ask: if this product had been built by a team in the target country, what would they have done differently? The answers are usually in the layout, the imagery, the trust signals, and the payment flow.

On the gifting product we worked on, one that let parents build wishlists and enabled grandparents and family friends to contribute to them, we ran focus groups across different age groups and demographics to make sure what we built felt universal. The tech-savvy parents who sought out and downloaded the app needed a different onboarding experience from the grandparents who arrived via a family message with no prior context. The same product, the same language, but the assumptions embedded in the default onboarding experience only served one of those two groups.

What Localisation Changes Beyond the Text

The visual layer is often where cultural mismatch shows most clearly. Images that feel warm and familiar to one audience can feel generic or even alienating to another. Icons that are immediately legible in one cultural context require learned interpretation in another. A shopping trolley icon makes sense in a UK app and less sense in markets where supermarket layouts and shopping conventions differ. These are small things individually, and they accumulate into a product that feels like it was made for someone else.

Pricing is another layer that translation does not touch. The same subscription price in US dollars might be affordable in one market and prohibitive in another. When Spotify set its India premium plan at $1.45 per month rather than the standard $10.99, revenue grew by 92.6% over four years, according to Mirava. It is a localisation decision that required understanding the purchasing context of a specific market.

When planning localisation for a new market, start with the payment flow and pricing before touching the copy. A perfectly translated checkout that asks for an unaffordable amount will not convert regardless of how well the words read.

Layout and reading patterns

Layout direction is routinely underestimated. In right-to-left languages like Arabic and Hebrew, the interface logic needs to mirror the visual hierarchy, button placement, and flow of information, text included. Applying a translation to a left-to-right layout produces something that technically contains the right words in the wrong order of attention. Users read differently, and the product needs to lead them through the experience in the direction they naturally follow.

When Getting This Wrong Breaks the User Experience

The failure mode for translation-only expansion is usually gradual and quiet. The product ships in the new language. Downloads arrive. And then retention drops, conversion underperforms, and reviews in that market cluster around vague complaints, it feels unfamiliar, it does not quite work, something is off. These are hard to diagnose from a distance because the product technically functions. The words are correct. The app loads. But the experience is wrong in ways that users struggle to articulate.

We ran into a version of this with a currency exchange product we worked on, which was originally designed to let people transfer leftover foreign currency to each other at an agreed rate. The product had to pivot midway through development when we found that both legal regulations and Apple's App Store policies prohibited direct peer-to-peer payment transfers. We shifted to a location-based, in-person model instead, where users could meet and physically exchange currency. The social dimension of seeing map pins and movement was actually a positive, it gave the product a more social feel.

But requiring physical proximity cut the scale of the product significantly, limiting users to exchanging with people nearby. Then Apple raised further concerns about money laundering, which meant we had to impose a cap of approximately €100 to €150 on any single transaction. Each of those constraints changed what the product could mean to a user in a specific location and with a specific need, and none of those issues were linguistic.

When the product architecture is the real problem

We also worked on a grassroots football app where the client kept insisting the booking process needed to be more intuitive. We pushed back but complied with the changes. They made little difference. The real problem was that the client was trying to do too many things in one product, there was a reason those features existed across several separate apps. Despite our best efforts to build something cohesive and emotionally grounded, the result was overly complex, too verbose, and not fit for its core purpose. No amount of translation or surface-level localisation would have fixed that, because the structural problem sat underneath the language layer entirely.

How to Localise an App Properly

Proper localisation starts before a word of translation is commissioned. It begins with research into the target market, how users in that context make decisions, what signals trust and safety to them, what visual conventions they are accustomed to, and what they expect a product in this category to feel like. That research informs the design decisions before the design decisions get made, rather than being retrofitted afterwards.

The process runs in a sequence rather than all at once.

1. Research the target market: decision-making patterns, trust signals, visual conventions, and pricing expectations.
2. Audit the existing product for embedded assumptions in layout, imagery, colour, and interaction patterns.
3. Adapt the design layer: reading direction, visual hierarchy, icons, and imagery before touching the copy.
4. Commission translation with cultural context briefed in, not just a word count and a source file.
5. Adapt pricing, payment methods, and account requirements to local norms and purchasing power.
6. Test with real users from the target market before launch, not after.

On the travel product we worked on, we integrated with a third-party aggregator at the client's request, then midway through development the client decided the aggregator's added costs made the financial model unworkable. They switched to a different supplier with a fundamentally different API approach, which forced us to go back and re-engineer significant portions of the integration layer. Later, a third external service was added for specific bookings, requiring another round of integration work. Each change required careful review and rewriting of integration code. The lesson there applies directly to localisation: late changes to foundational architecture cost far more than building with those requirements in mind from the start.

Brief your translator on the emotional tone of each screen, not just the words. A payment confirmation screen needs a different register from an error message. Translators who understand the intended feeling of a screen will make better choices at the edges where language gets ambiguous.

Conclusion

Translation and localisation are not competing options, and one does not substitute for the other. Translation handles the language. Localisation handles everything that language sits inside, the visual logic, the cultural signals, the pricing, the trust architecture, and the emotional calibration of the whole experience.

The mistake is treating translation as the destination when it is really the entry point. A product that reads correctly in French but still feels like it was designed for a British user has been translated. A product that genuinely belongs in the French market has been localised, and those are meaningfully different things to the person using it.

Getting this right requires research before design, design before copy, and testing with real users from the target market before any of it ships. It also requires being honest about what the existing product assumes, about reading direction, about what makes people feel safe, about what a fair price looks like, because those assumptions do not disappear when the words change.

Building products that work across cultures is something we think about carefully. If you are planning an expansion into a new market and want to make sure the experience holds up beyond the language layer, let's talk about your localisation approach.

Frequently Asked Questions