Multi-language store setup: getting PrestaShop ready for international sales

Reviewed June 2026, steps apply to PrestaShop 1.7, 8 and 9; the Translations tool and per-language _lang fields work the same across those versions.

Adding a second language to PrestaShop looks like a two-minute job: install a language pack, tick a box, done. Then the cracks appear, half-translated emails, a checkout button still in English on the German store, product descriptions that never got filled in, a back office where your warehouse staff are now staring at French. The platform's multilingual engine is genuinely strong (every translatable field is stored per-language at the database level, not bolted on), but "supports many languages" and "is correctly set up for international sales" are two very different states. This guide is about closing that gap: the exact back-office steps to add and configure a language, where every category of translatable text actually lives, and the order to do it in so you don't ship a store that's 80% translated and 100% confusing.

This is the language-setup half of going international. Currency, tax and the country-by-country picture each have their own treatment, multi-currency setup and the wider selling across Europe guide pick those up. Here we stay on languages.

How PrestaShop stores languages (and why it matters)

Before touching a setting, it helps to know what you're actually configuring. In PrestaShop a language is a row in the lang table, and almost every piece of content has a companion _lang table, product_lang, category_lang, cms_lang, meta_lang, holding one record per language per item. When you add a language, you are not switching a display mode; you are creating a parallel set of empty content fields that someone now has to fill.

So what? Two consequences flow from this, and they explain most multilingual mistakes:

• A newly added language starts empty, not auto-translated. PrestaShop will fall back to showing the default language's text in untranslated fields on some surfaces, which is exactly how you end up with English product names sitting under a German menu.
• Interface text (buttons, error messages, email wording) is not stored in those _lang tables. It comes from translation files and the Translations tool, a completely separate workflow. Getting your products translated does nothing for your checkout button. You have to do both.

Adding a language the right way: Localization → Languages

The fastest correct route is to install a full localization pack rather than a bare language. Go to International → Localization (in older 1.6 stores it's Localization → Localization). Pick the country, and crucially review the checkboxes for what to import: States, Taxes, Currencies, Languages, Units and Change the behavior of the taxes. Importing the language this way also pulls the matching number/date formats and a language pack of core translations, so you start with the PrestaShop interface already translated instead of a blank slate.

[SCREENSHOT: International → Localization import panel with a country selected and the States / Taxes / Currencies / Languages / Units checkboxes visible before importing the pack]

After import, go to International → Localization → Languages and open the new language to check the fields that quietly break stores:

• ISO code and Language code, the ISO code (e.g. de) drives the language-pack filename and the flag; the language code (e.g. de-DE) drives the lang attribute and date formatting. A mismatch here is a common cause of "the translation file won't load."
• Date format. Set per language, so a single store shows DD/MM/YYYY to French visitors and the right format elsewhere without custom code.
• Is RTL language, flip this on for Arabic, Hebrew or Farsi and PrestaShop loads the right-to-left stylesheet. Forgetting it leaves an RTL store laid out left-to-right, which looks broken to the customer.
• Status. Disabled languages stay installed (so you can prepare translations privately) but don't appear in the front-office switcher until you enable them.

Shop language vs employee language, keep them separate

One detail that saves a lot of grief: the languages your customers see are not the languages your team works in. Enabling German for the storefront does not force your back office into German. Each employee sets their own admin language under their profile (Advanced Parameters → Team → Employees, or their own preferences). So you can sell in six languages while your warehouse staff keep the admin in English. New merchants often panic that adding a customer language will scramble their own admin, it won't.

The five layers of content you actually have to translate

"Translate the store" is really five separate jobs living in different places. Skip one and that's the layer customers notice. Here's the map, in the order that matters:

Layer	Where it lives	How you translate it	If you skip it…
Catalog (products, categories, features, attributes)	_lang tables	Language flag/dropdown on each edit page	English product names under a translated menu, the most visible failure
CMS pages (terms, shipping, returns, privacy)	cms_lang	Per-language tabs in the CMS editor	Legal pages in the wrong language, a compliance and trust problem
Interface strings (buttons, labels, errors)	Translation files	International → Translations	"Add to cart" stays English mid-checkout
Email templates	Mail translations + .tpl/.html	Translations tool, "Email translations" type	Order confirmations arrive in the wrong language. The first impression after they pay
Module strings	Each module's translation files	Translations tool, per-module	A third-party block in English on an otherwise translated page

Catalog content: the per-field language switcher

Every translatable field on a product, category or CMS page carries a small language selector (a flag dropdown in 1.6, a language tab/dropdown in 1.7+). Switch it, type the translation, save. The field you don't fill stays empty for that language. There is no silent auto-fill, which is the point. For a large catalogue this is the bulk of the work, and where you decide your translation strategy: professional translation for top sellers and legally sensitive copy; AI translation with native-speaker review for the long tail; raw machine output only where the alternative is genuinely nothing. Whatever you choose, don't paste the English text into every language field to "avoid blanks", that's worse than empty, because it manufactures duplicate content across your language URLs.

Interface, email and module strings: the Translations tool

[SCREENSHOT: International → Translations, the "Modify translations" panel with the translation type dropdown open showing Front office / Email / Installed modules / Back office options]

This is the layer merchants forget, because the catalogue looks done and the store feels translated until a customer hits a button. Go to International → Translations. Choose the translation type. The important ones are:

• Front office translations, theme strings the customer reads while shopping.
• Email translations, the wording inside order, shipping and account emails. Translate and send yourself a test, because German and Finnish text can be 30–40% longer than English and break a fixed-width email layout.
• Installed modules translations, pick the language and the specific module; each one carries its own strings. A freshly installed third-party module is a frequent source of stray English.
• Back office translations. Only if your team works in that language.

Edits made here are stored as translation overrides for the selected theme, module and language, so back them up or export them before you change a theme, update a module or run a major upgrade, because those operations can affect them. If a string won't appear in the tool, it's almost always because the developer didn't wrap it in PrestaShop's translation function, a real limitation worth knowing before you blame yourself.

The setup order that prevents a half-translated launch

Sequence matters because some steps unlock others. A workable order:

• 1. Import the localization pack for the country (Localization screen). Gets you the language, core interface translation, date/number formats and units in one move.
• 2. Confirm language settings (Languages screen), ISO/language codes, date format, RTL if needed. Leave the language disabled for now so customers don't see a half-built version.
• 3. Translate CMS and legal pages next. These are finite, high-stakes, and professionally translated, so get them done while the language is still hidden.
• 4. Translate the catalogue, the big job; at least your top sellers and main categories before launch.
• 5. Run the Translations tool for front office, emails and every active module, then send yourself a real test order in that language to catch layout breaks and stray English.
• 6. Enable the language only once the above is genuinely done. The point of the disabled state is to never expose a 70%-translated store.

Where the language switcher and flags live (and where they don't)

Once a language is enabled, PrestaShop's default theme exposes a language selector in the header automatically, via the ps_languageselector module. You can move or restyle it through the theme, and the long-standing debate over flags-versus-language-names is its own usability question, a flag implies a country, not a language, which annoys, say, an Austrian shown a German flag. We dug into that and the small front-end touches that keep international visitors from bouncing in currency selector and language flags, so we won't re-litigate it here.

SEO: don't let translations cannibalise each other

The moment you have the same page in multiple languages, you have to tell Google they're alternates of each other, not duplicates. That's what hreflang annotations do, and it's a deep enough topic that it has its own guide: hreflang tags. The language-setup decisions that feed into it, though, belong here:

• Per-language meta, written not translated. Meta titles and descriptions are stored per language, in the meta_lang table for static and CMS pages, and in product_lang / category_lang for catalogue pages. The best-performing keyword in English is rarely the literal translation, so meta should be written in the target language by someone who searches in it, don't auto-translate your meta tags.
• Friendly URLs per language. With Friendly URLs on (Shop Parameters → Traffic & SEO), each language gets a localized slug, /en/shower-drain, /de/duschrinne, /fr/caniveau-de-douche, far stronger than carrying English slugs across every language. Our Smart SEO Friendly URL Manager keeps those slugs clean and language-appropriate so you're not editing them one product at a time.
• Per-language sitemaps with hreflang. A sitemap that lists each language version and cross-references them helps Google index the full set instead of one. Our Advanced SEO Sitemap Builder generates per-language sitemaps with the right annotations.
• Link within a language. A German blog post should link to German product pages, not their English equivalents, mixed-language internal links waste authority and confuse crawlers. The Automatic Internal SEO Linker respects the current language when it builds links, so this stays correct as your catalogue grows.

Translation vs localisation: the part teams underestimate

Translating the words is necessary; adapting to the market is what actually converts. PrestaShop handles some of this for you once languages and the localization pack are set, but only some:

• Date and number formats, handled per language by the settings above (1.234,56 for Germany, 1,234.56 for the UK), provided you set the format field correctly.
• Measurement units. The localization pack sets metric/imperial defaults, but your product descriptions still need to speak the right units.
• Cultural fit, a Valentine's banner or a US-centric reference lands flat in the wrong market; that's editorial judgement, not a setting.
• Payment expectations, Dutch shoppers expect iDEAL, Polish shoppers BLIK. That's a payment-method decision, but it's why a "fully translated" store can still feel foreign at checkout.

Currency sits here too, a German-speaking Austrian expects EUR, a German-speaking Swiss expects CHF, and language alone won't get that right. Because currency is a genuinely separate axis from language, we keep the full treatment in the multi-currency guide rather than half-cover it here.

One admin or several? When languages aren't enough

Everything above runs multiple languages inside one store, sharing one catalogue. That's the right model for most international sellers. But if your markets need genuinely different catalogues, pricing structures or branding, not just translations of the same shop, you've crossed into multistore territory, which is a different architecture with its own trade-offs. We compare the two and when each is worth it in PrestaShop multistore. For the large majority of stores, multi-language on a single shop is simpler, cheaper to maintain, and fully sufficient.

The mistakes that quietly cost you

• Enabling a language before it's translated. Use the disabled state. A live half-English store erodes trust faster than no translation at all.
• Translating the catalogue but skipping the Translations tool. Products in German, buttons and emails in English, the layers most often left behind because the store looks done.
• Copying English into every language field. Done to avoid blanks, it manufactures duplicate content. Empty is recoverable; duplicated is a self-inflicted SEO wound.
• Auto-translating meta and slugs. Your URLs and search snippets deserve native keyword choices, not literal translations.
• Forgetting module strings after every new install. Each third-party module ships its own translations; re-run the tool whenever you add one.

Frequently asked questions

Does adding a customer language change my back office into that language?

No. The languages your customers see and the language your team works in are separate. Enabling German for the storefront does not touch your admin. Each employee sets their own admin language under Advanced Parameters → Team → Employees (or their own preferences), so you can sell in six languages while your warehouse staff keep the admin in English.

Why is my product translated but the "Add to cart" button still in English?

Because they live in different places. Catalogue content (product names, descriptions, CMS) sits in the per-language _lang tables and is translated via the language switcher on each edit page. Interface strings, buttons, labels, error messages, emails, come from translation files and the Translations tool (International → Translations), a completely separate workflow. You have to do both, and re-run the tool for every module after each new install.

Should I copy the English text into the empty language fields to avoid blanks?

No, that's worse than leaving them empty. Pasting English into every language field manufactures duplicate content across your language URLs, which is a self-inflicted SEO problem. An empty field is recoverable; duplicated content is a wound you have to clean up later. Translate properly, or leave it empty and translate it next.

Can I prepare translations without customers seeing a half-built store?

Yes. Keep the language disabled while you work. A disabled language stays installed and editable but doesn't appear in the front-office switcher, so you can translate CMS pages, the catalogue, emails and module strings privately, then enable it only once it's genuinely done. The disabled state exists precisely so you never expose a 70%-translated store.

Should I auto-translate my meta titles and URL slugs?

No. Meta titles and descriptions are stored per language and should be written in the target language by someone who searches in it. The best keyword in English is rarely the literal translation. Friendly URLs should get a localized slug per language (/de/duschrinne, not the English slug carried across). Our Smart SEO Friendly URL Manager keeps those per-language slugs clean so you're not editing them one product at a time.

Related reading

• Hreflang Tags. Once you have multiple language URLs, this is how you stop them cannibalising each other in search.
• Multi-Currency and International Selling. Currency is a separate axis from language (a German-speaking Swiss expects CHF, not EUR).
• Selling Across Europe. The map that sits above language, currency and the EU VAT rules.

A correctly set-up multilingual PrestaShop store opens markets your monolingual competitors can't touch, and the platform gives you the machinery to do it properly, per-language content fields, a real translation interface, localized formats and URLs. The work isn't in any single setting; it's in knowing there are five layers of text, doing them in an order that never exposes a half-built store, and keeping language, currency and SEO as the separate problems they actually are. Get the sequence right and the store reads as if it were built natively in each language, which, to the customer deciding whether to trust you with a payment, is the whole game.