The Complete Guide to Website and App Localization: From Setup to Launch in Every Market
Most localization projects fail before a single word is translated. The product hardcodes strings inside components, the layout assumes English character widths, dates render in a fixed US format deep in a template, and the team discovers all of it three weeks after signing a translation contract. By then the money is committed and the launch date is public.
That is the pattern behind most stalled market launches. Teams treat localization as a content problem and hand it to a vendor, when the first half of the work is an engineering problem no vendor can solve on their behalf. Demand is not the constraint. CSA Research surveyed 8,709 consumers across 29 countries and found that 76 percent prefer to buy products when the information is in their own language, and 40 percent will not buy at all in another language. The market wants the localized version. The obstacle is execution.
This guide covers the full sequence for websites and applications, from internationalization readiness through post-launch measurement. It is organised as five phases because that is how the work actually lands on calendars, and each phase names the specific way projects break there. Knowing where a project fails is more useful than another list of steps everyone already agrees with.
What website and app localization actually covers
Website and app localization is the process of adapting a digital product’s interface, content, formatting and market signals so it behaves and reads as though it were built for each target market. Translation handles the words. Localization handles everything around them.
Four surfaces need adapting, and they rarely belong to the same team. The interface layer covers menus, buttons, form labels, validation messages, empty states and push notifications. The content layer covers marketing pages, help documentation, onboarding flows and email sequences. The transactional layer covers pricing display, currency, tax language, checkout copy, terms of service and privacy notices. The market signal layer covers search metadata, app store listings, structured data and the regional conventions a buyer reads as competence or as carelessness: address field order, phone number format, name order, the position of a currency symbol.
Scope also spans more file types than most teams expect. A single release can involve JSON and YAML resource files from the codebase, XLIFF from the translation system, HTML and Markdown from the content repository, and RESX or PO files from older parts of the stack. Any provider handling this work needs to read all of them without an export and re-import step that strips context.
NexTranslate’s website and app localization services cover websites and web applications, iOS and Android apps, e-commerce storefronts and multimedia assets, with direct integration into WordPress, Shopify, Webflow, React and Flutter projects. The practical takeaway for a buyer is simpler than the feature list: before scoping any project, write down all four surfaces and name an owner for each. Projects that skip that inventory discover the fourth surface after launch, usually through a support ticket.
Phase 1: Internationalization readiness decides whether the rest works
Internationalization (i18n) is the engineering work that makes a product capable of supporting multiple locales at all. It happens before any translation, and skipping it is the single most common reason localization budgets get spent twice.
A product is ready when the following are true. Every user-facing string lives outside the code in a resource file. No sentence is assembled by concatenating fragments, because word order changes between languages and a fragment that reads correctly in English becomes nonsense in German or Japanese. Dates, numbers, currencies and units render through locale-aware formatting rather than hardcoded patterns. The entire pipeline, including the database and the search index, handles UTF-8 correctly. Layouts tolerate text expansion, which typically runs 20 to 30 percent for German, Finnish and Russian against an English source, and contraction of a similar magnitude for Chinese and Korean.
Pluralisation goes through a rules engine rather than an if-else on the number one, because several languages have three or more plural forms. Sorting and search use locale-aware collation. And no text is baked into image assets, because those cannot be translated without a designer.
The W3C internationalization guidance is the reference standard here, and the practical walkthrough for product teams is covered in more depth in NexTranslate’s post on internationalization best practices for SaaS products. The important structural point is that this phase belongs to engineering, not to procurement.
The cheapest way to test readiness is pseudo-localization. Generate a fake locale that replaces every string with an accented, padded version of itself, then run the product.
Strings that stay in plain English are hardcoded. Text that overflows its container will overflow in German. Layouts that collapse will collapse in Arabic. This takes a day or two of engineering time and surfaces almost every issue a vendor would otherwise find at your expense, months later. Run it before a translation contract is signed, not after.
This phase is also where the NEX Framework™ lands in practice. That framework splits market entry into three gates: Need, whether there is validated demand in a market; Economics, whether the commercial case survives the full cost rather than just the translation line; and eXecution, whether the organisation is operationally ready to sustain the locale. Most failed market entries clear Need and Economics comfortably and fail on eXecution. Internationalization readiness is the first concrete test of that third gate, and it is the one that fails quietly.
Phase 2: Inventory the content and route it by risk
Not every string in a product deserves the same workflow. Routing content by risk instead of applying one process to everything is what keeps localization affordable as the number of locales grows.
The default habit is to pick one quality level and apply it to the whole job. That produces one of two outcomes. Either everything gets the cheapest workflow, and a mistranslated billing disclosure eventually becomes a legal problem, or everything gets the most expensive workflow, and the cost of maintaining locales grows fast enough that updates stop shipping. Both outcomes end the same way, with a market that was launched and then quietly abandoned.
The NEX Translation Matrix™ exists to replace that habit. It scores each piece of content on five inputs: content type, business risk, customer impact, regulatory requirement and quality expectation. Those scores produce one of three routing outcomes. AI drafting is sufficient for low-risk, high-volume, internal or evergreen content. Human linguists refine meaning where tone, nuance or terminology need a native speaker on top of the draft. Independent review before publication applies to regulated, legal, safety-critical or high-exposure content, where a second linguist signs off.
The rule that makes the matrix work in a product context is this: it routes content, not projects. A single release almost always produces all three outcomes at once, so routing runs per string or per document, never per job. The release notes and the tooltip text do not need what the payment authorisation screen needs.
| Content Type | Business Risk | Routing Outcome | Review Layers |
|---|---|---|---|
| Tooltips, empty states, release notes | Low | AI drafting sufficient | 1 linguist check |
| Product UI strings, navigation, settings | Low to medium | AI draft, human refinement | Linguist plus in-context review |
| Marketing and landing pages | Medium | Human linguists refine | Translator plus editor |
| Help centre and onboarding | Medium | Human linguists refine | Translator plus editor |
| Pricing, billing and checkout copy | High | Independent review | Translator, reviser, QC |
| Legal, privacy and compliance text | High | Independent review | Translator, reviser, QC, PM |
Phase 3: Translation and review, matched to the route
The AI drafting route
Machine output has improved enough that for stable, low-risk, high-volume strings it is a legitimate starting point rather than a compromise. What makes it safe is the human review layer that follows, which checks flow and correctness rather than retranslating from scratch. Content on this route should be content where a small error is visible, cheap and quickly fixed.
The human refinement route
This is where machine translation post-editing (MTPE) does most of the work in a mature programme. A native linguist edits machine output for meaning, tone and terminology, which is faster than translating from zero and more consistent than either approach alone. ISO 18587 is the international standard that defines the requirements for full post-editing of machine translation output, and it is a reasonable thing to ask a provider whether they work to. The distinction that matters commercially is between light post-editing, which targets comprehensibility, and full post-editing, which targets output indistinguishable from human translation.
The independent review route
modern localization tech stack For regulated and high-exposure content, the defining feature is that the reviewer is not the translator. modern localization tech stack (LQA) is a structured evaluation of translated content against defined error categories, carried out by a second linguist who did not produce the text. Self-review does not catch the errors that matter here, because the person who misunderstood a source sentence will misunderstand it again on the second pass. On this route, terminology management and a maintained glossary stop being nice to have and become the mechanism that keeps a regulated term consistent across every locale.
Two assets underpin all three routes. A Translation Memory (TM) stores previously approved translations and reuses them on repeat content, which is why the second and third locales cost less per word than the first, and why updates to an existing page cost a fraction of the original. A glossary, sometimes paired with a style guide, fixes how product names, feature names and regulated terms are rendered in each language. Neither asset produces value in its first month. Both compound.
These assets live inside a Translation Management System (TMS), which is the coordination layer between the codebase, the content repository and the linguists. Choosing and connecting that layer is its own decision, covered in the guide to building a modern localization tech stack. For teams that would rather not run the layer themselves, multilingual content management covers the ongoing operation as a managed service.
Phase 4: Pre-launch quality assurance is four checks, not one
Localization QA is four separate disciplines that fail in four separate ways, and running them as a single review pass is why teams ship locales with correct translations and broken interfaces.
Linguistic QA reviews meaning, tone and terminology in context. The critical word is context. A linguist reviewing strings in a spreadsheet cannot tell whether a word is a button or a heading, and that ambiguity produces a specific class of error that only appears in the running product. Review should happen against a build or a preview environment wherever the tooling allows it.
Functional QA tests whether the localized build still works. Forms with locale-specific validation, address and postal code fields, payment methods that differ by market, search behaviour with non-Latin scripts, date pickers, sorting, and any feature that behaves differently under a different locale setting. This is engineering work and belongs in the test plan, not in the translation review.
Visual QA looks at what the text does to the layout. Truncation, overflow, line wrapping in the middle of a button, font files that lack coverage for a script, and full bidirectional layout behaviour for Arabic, Hebrew, Urdu and Farsi, where the interface mirrors rather than simply reading right to left. Pseudo-localization in phase 1 catches most of this early. Visual QA catches what pseudo-localization could not predict.
SEO and metadata QA is the check most often skipped, and it is the one that determines whether the localized pages are ever found. Page titles and descriptions need to be written for the target market rather than translated from the English, because search behaviour differs. Structured data needs localizing alongside the visible content. App store titles, subtitles, keyword fields, screenshots and descriptions are their own asset set with their own character limits per store and per language.
Phase 5: Launch, index and measure
A locale is launched when search engines can index it correctly, app stores serve the right listing, and the team has a per-locale measurement view. Publishing translated pages is not the same as launching a market.
On the web side, three technical elements decide whether localized pages compete or cannibalise. hreflang annotations tell search engines which language and region each page targets, and they must be reciprocal, meaning every page in the set references every other including itself. Canonical tags must point within the same language version, not across languages, which is a common and quietly damaging misconfiguration. Sitemaps should list every locale URL. Beyond the technical layer, ranking in a new market is a content problem as much as a tagging problem, covered in more depth in the post on multilingual SEO.
On the app side, store metadata is a separate workstream from the in-product strings. Apple and Google both allow per-locale listings, and both weight the title and subtitle fields heavily in store search. Screenshots with embedded English text are one of the most visible signals of a half-localized product. Where the interface strings themselves are the constraint, software UI translation handles the string layer specifically, including the length limits that make UI copy harder than prose.
Measurement is what separates a launched locale from a maintained one. Four numbers are worth tracking per locale from day one: conversion rate compared against the source market, organic sessions and their trend, support ticket volume in that language as a proxy for confusion, and time to publish an update. That last one is the leading indicator. When the time to publish a change in a secondary locale starts drifting past the source locale, the programme is decaying, and it will show up in the other three numbers a quarter later.
| Phase | Owner | Ready when | Failure signal |
|---|---|---|---|
| 1. i18n readiness | Engineering | Pseudo-locale build runs clean | Hardcoded strings found mid-project |
| 2. Inventory and routing | Localization lead | Every surface has a route and owner | One workflow applied to all content |
| 3. Translation and review | Provider plus reviewer | Glossary and TM in place | Terminology drifts between pages |
| 4. Pre-launch QA | Four separate reviewers | All four checks signed off | QA run as a single review pass |
| 5. Launch and measure | Product plus marketing | hreflang reciprocal, metrics live | No per-locale reporting view |
How long it takes and what it costs
For a product that has never shipped a second locale, expect two to four weeks of internationalization work before translation begins, then three to six weeks to the first locale going live. Subsequent locales run considerably faster, because the engineering work is done once and the translation memory starts absorbing repeat content.
Cost has three components that buyers frequently conflate. There is the per-word translation cost, which is the only one most quotes show. There is the internal engineering cost of readiness, which is real, one-time and usually the larger number on the first locale. And there is the ongoing maintenance cost of keeping every locale current as the product changes, which is the number that decides whether a market survives past its first year.
On the per-word line, the detail worth checking in any quote is whether human proofreading is included or billed separately, since many providers charge it as an add-on and it materially changes the comparison. NexTranslate publishes transparent per-word pricing across three tiers with human proofreading included at every one, which maps closely onto the three routing outcomes above: the entry tier fits AI-drafted low-risk content, the middle tier fits human refinement of product and marketing content, and the top tier fits the independent review route for legal, financial and healthcare material.
Matching tier to route rather than buying one tier for the whole project is where most of the savings sit.
Frequently asked questions
What is the difference between translation and localization?
Translation converts text from one language to another. Localization (l10n) adapts the entire product experience, including formatting, layout, currency, imagery, legal text and market conventions, so it works for a specific locale. A product can be fully translated and still feel foreign if dates, addresses and payment methods follow the source market’s conventions.
Do we need internationalization before localization?
Yes, and doing them in the wrong order is the most expensive mistake in this process. Internationalization is the engineering work that makes a product capable of supporting any locale. Without it, translated content cannot be loaded correctly, and the work has to be redone after the code is fixed.
How many languages should we launch with?
Fewer than most teams plan for. Launching two locales properly, with maintained content and per-locale measurement, beats launching six that go stale within two quarters. The realistic constraint is not translation capacity, it is the team’s ability to keep every locale current as the product ships changes.
Can machine translation handle a product interface on its own?
For low-risk, stable strings it produces a usable draft, but not without human review. Interface strings are short, context-poor and often ambiguous, which is exactly the condition under which machine output fails hardest. A single word like Save or Home has several valid translations depending on whether it is a button, a heading or a navigation item.
What is pseudo-localization and is it worth the effort?
Pseudo-localization generates a fake locale that replaces every string with a padded, accented version of itself so the product can be tested without any real translation. It costs a day or two of engineering time and reveals hardcoded strings, layout overflow and encoding problems before any money is spent on linguists. For a first localization project it has the best return of any single step in this guide.
How do we keep localized content current after launch?
Connect the localization workflow to the release process rather than treating each update as a new project. When source content changes, the changed segments should flow automatically into the translation queue and back into the build. The measurable target is that time to publish an update in a secondary locale stays close to the source locale.
Conclusion: Localization is an engineering sequence, not a translation purchase
The teams that succeed in new markets treat localization as five phases with named owners, not as a procurement decision with a per-word price attached. The translation itself is the most visible part of the work and the least likely place for the project to fail. Readiness and quality assurance are where projects break, and both sit inside the organisation rather than with the vendor.
The sequence also compounds. The engineering work in phase 1 is paid once and benefits every future locale. The glossary and translation memory built in phase 3 make every subsequent release cheaper. The measurement view built in phase 5 is what tells a team whether to add the next market or fix the current one. A first locale done properly is not just one market. It is the infrastructure for all of them.
If you are scoping a website or application launch and want a view of what your specific content mix would route to, we can map it against the five inputs and give you a phased plan with realistic timelines. request a localization quote and we will start with the readiness check rather than the word count.
Written by Karuppusamy Arunachalam, NexTranslate
Published August 2026 · Filed under Localization