Website localization: a practical guide for site owners

Website localization is the work of adapting a site for people in another market: their language first, and then the formats, prices, images, legal text and search results they expect. Translation is the largest part of it, and the part most tools sell. The rest decides whether the translated site feels like it was made for the reader or converted for them, and at the far end, rewriting a line from scratch for a new audience has a name of its own, transcreation. The steps below follow the order a small team would work in, from choosing markets to the checks on launch day.

What website localization means#

The W3C's internationalization group defines localization as "the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale)." Its list of what that can involve goes well past words: number, date and time formats, currency, symbols, icons and colours, references that may be misread in another culture, legal requirements, and address and phone number formats.

The same page defines internationalization as the design work that makes localization easy later. For a website, that means things like keeping text out of images, storing dates as dates and not as strings, and letting a layout cope with a longer or shorter sentence. Internationalization is done once, on the source site. Localization is done once per market and then kept up as the site changes.

If you want the short version of where translation ends and localization begins, with a worked example, read localization vs translation.

Step 1: choose markets and locales#

A market is a group of people you want to reach. A locale is how software names it. On the web, locales are written as BCP 47 language tags: fr for French, fr-CA for French as used in Canada, es-419 for Spanish as used in Latin America. The W3C's guide to language tags gives a simple rule: keep the tag as short as possible and add a region only where it makes a useful distinction.

That rule maps onto a business decision. If you sell the same thing at the same price to every French speaker, one fr version is enough. If Canadian customers see different prices, delivery terms or spellings, they need their own fr-CA version, and that version needs its own pages.

Where to start is usually visible in data you already have. Your analytics show the languages your visitors' browsers ask for, and Search Console shows the countries your impressions come from. A language that already brings visitors to an English page is a better first market than one you only hope to reach.

In LangRelay, each language you add is a Target locale, either bare (nl) or regional (en-GB), and both kinds can sit side by side on one Site. A bare locale still has a concrete meaning in LangRelay: bare en is American English, and bare pt is Brazilian Portuguese. If you want British English or European Portuguese, you add that regional variant instead. Our glossary entry on locales explains the difference in more detail.

Step 2: scope the pages#

Most sites do not need every page in every language on day one. Make a list of your pages and sort them into three groups:

• Pages that sell or support: home, product or service pages, pricing, contact, checkout, help.
• Pages that bring search traffic: articles and guides that rank for queries people in the new market also search.
• Pages to leave in the source language for now: old news, archived posts, internal announcements.

Legal pages deserve their own decision. Terms, privacy policies and returns pages often need different content per country, written or checked by someone who knows that country's law, so a translation alone may not be the right answer. The W3C lists varying legal requirements as part of localization for this reason.

Scoping also sets the budget. A page you do not translate costs nothing, in words or in review time. Our article on website translation cost shows how word count, languages and monthly change add up.

Step 3: prepare the source site#

Localization goes faster when the source site is ready for it. The checks below are the internationalization work, done once:

• A banner with words baked into the image cannot be translated without a designer. Move the words into HTML where you can.
• Button labels, form errors and messages that live in theme or plugin code need to reach whatever does the translating. WPML, for example, calls this text strings and lists them on their own Strings tab; with its automatic translation and string auto-registration switched on, they are translated alongside your content. WPML's purchase page lists String Translation as included in Multilingual CMS and Agency and not in Multilingual Blog. Our entry on string translation explains the term. Check that they show up in the rendered page and are not drawn by a script after load.
• A translated label can be longer or shorter than the original. Buttons and navigation items that only fit the English word will break.
• Google says it decides a page's language from its visible content, and recommends one language for content and navigation on each page. A page that mixes English navigation with a French body is harder to classify.

Step 4: adapt more than the words#

Translation changes the text. These are the other things a reader in a new market notices.

Numbers, dates and currency#

The same number is written differently per locale. MDN's documentation for the browser's built-in formatter shows the amount 123,456.789 euros written as 123.456,79 € for German, with a full stop between thousands and a comma before the cents. A price written as €123,456.79 on a German page reads as wrong to a German buyer. Dates have the same problem: 03/04 is a different day in the US and the UK.

If your site formats numbers and dates in code, use the locale-aware formatting your platform already has. If prices are typed into page text, plan to change them by hand per market, and decide whether the market sees a converted price or a set local price.

Tone and form of address#

Several languages make you choose how formally to address the reader: German Sie or du, French vous or tu, Dutch u or jij. Which one fits depends on your brand and your readers. Pick one register per language and apply it everywhere, including buttons and error messages.

LangRelay lets you set this per Target locale as a Formality register (Language default, Formal or Informal) for German, Spanish, French, Italian, Dutch and Turkish. Every new machine translation for that locale follows it.

Names, terms and brand words#

Decide which words stay in the source language: your company and product names, feature names, sometimes industry terms your buyers use in English. Write them down per language before anyone translates, so the same term is handled the same way on every page. Our guide to building a translation glossary covers how to set one up.

Images, examples and references#

Screenshots show the interface in one language. Photos and examples can carry assumptions about a market, such as a holiday, a sport or a payment method. The W3C's list includes "symbols, icons and colors" and references that "may be subject to misinterpretation or viewed as insensitive." Review the images on your most visited pages with someone from the market.

Forms, addresses and phone numbers#

A checkout form that requires a US state or a five-digit postcode stops a customer in another country. Address and phone formats are on the W3C's list too. Test every form on the localized site with a real address from the market.

Step 5: make each version findable#

A localized page that search engines cannot find does little for the market. Google's documentation sets out the main rules:

• Give each language its own URL. Google recommends different URLs per language over using cookies or browser settings to change the content, and notes that its crawler usually sends requests without an Accept-Language header and mostly crawls from the US.
• Mark the versions with hreflang. Google supports hreflang in the HTML head, in HTTP headers or in a sitemap, and says each language version "must list itself as well as all other language versions." It suggests an x-default fallback for visitors whose language you do not serve.
• Do not redirect visitors automatically by guessed language. Google advises against it because such redirects can stop users and search engines from seeing all versions, and recommends links that let people switch.
• Choose a URL structure. Google's table compares country domains (example.de), subdomains (de.example.com) and subdirectories (example.com/de/), and lists URL parameters (?loc=de) as not recommended.

Translate the parts of a page that appear in search results as well: the title, the meta description and, where your platform supports it, the URL slug. Our hreflang guide goes through the markup in detail, and the multilingual SEO page shows what LangRelay sets up.

Step 6: translate and review#

Many sites start from machine translation and have people review it. The decision that shapes the workflow is who reads a translation before visitors do, and what happens to a page nobody has read yet.

There are two common answers. Some tools publish machine output straight away and let you correct it later. Others hold every translation until someone approves it. The first is faster to launch. The second means a mistake on a pricing page is caught before a customer sees it. Whichever you choose, give the reviewer the page in context, because a short label like "Free" or "Close" can be translated several ways and only the surrounding page shows which one is right.

LangRelay takes the first approach, but its free checks hold a page with untranslated text, the wrong language or a changed price first. Legal pages, pricing pages and sweeping changes wait for you, and you can choose to approve every page yourself. In the Visual editor, a reviewer clicks text on the rendered page, at desktop, tablet and mobile widths, and edits it in a side editor with a live preview. Relay, our agent, can draft changes you describe in a sentence. Relay reviews any page you ask it to, the way a language expert would, and tells you the cost in AI credits before it starts.

Step 7: keep it current#

A localized site starts going out of date the first time someone edits the source. Plan for three questions: who notices a change, who translates it, and who approves it.

LangRelay's WordPress plugin sends each saved edit to LangRelay about a minute later, and only the changed text goes through translation. Elsewhere, your CMS or deploy pipeline can call a Change hook, a secret URL that makes LangRelay re-read the pages. Text that has not changed is not translated or billed again, so keeping a site current costs in proportion to how much changes.

Launch checklist#

Run these on the localized site before you announce it:

1. Every page in scope opens at its own URL in each language, and the language switcher on each page links to the same page in the other languages.
2. The HTML head of each version lists itself and every other version in hreflang, with an x-default, and each version's canonical points to itself.
3. Titles and meta descriptions are translated, and no page shows source-language navigation around translated content.
4. Prices, dates and numbers follow the market's conventions, and forms accept a local address and phone number.
5. Legal pages have been checked for the market or are clearly marked as the source-language version.
6. A person who reads the language has looked at the home page, the top five landing pages and the checkout or contact flow in context.
7. Someone owns the next change: they know how an edit to the source reaches the translations.

How LangRelay fits into localization#

LangRelay covers the translation part of this guide, and the SEO and upkeep around it. On WordPress, the plugin serves translated HTML from your own server under subdirectories such as /fr/, with hreflang including x-default, a canonical per language, and translated titles and meta descriptions. It translates the rendered page, so WordPress keeps one post per page. Glossary terms, with per-language translations and a keep-as-source option, are on paid plans.

It does not convert currencies, swap images or rewrite legal pages for another country. Those are decisions for your store, your CMS and your lawyer. On sites that are not WordPress, a script tag translates approved text in the browser, which works for visitors but makes no SEO claim, because search engines see the source page.

If you are planning a localization project and want to see how this would run on your site, book a demo.

Questions people ask about website localization#

What is the difference between localization and translation?#

Translation replaces the words. Localization adapts the whole page for a market, including formats, prices, images, legal text and tone. Translation is one part of localization.

Do I need a website localization agency?#

Not always. An agency helps when you need human translators in many languages, or market research and legal review alongside the translation. A small team with machine translation, a glossary and a fluent reviewer per language can localize a site of a few dozen pages without one.

How long does website localization take?#

The machine translation itself is quick with software. Reviewing it, adjusting prices and forms, and checking legal pages takes longer, and depends on how many pages are in scope and how quickly your reviewers work.

What is the difference between localization and internationalization?#

Internationalization is preparing the source site so it can be localized: text out of images, flexible layouts, locale-aware formatting. Localization is the per-market adaptation that follows. The W3C writes them as i18n and l10n.