How to Translate a PrestaShop Store Without Breaking It

Adding a language to PrestaShop takes about two minutes. You open the back office, install the language, and it appears in the front-office selector. Then you visit the new version of your shop and find the same problem everyone finds: the interface is translated, and your actual store is not.

That gap is where most PrestaShop translation projects go wrong. Not because the tools are bad, but because people misunderstand what PrestaShop already does for them and what it deliberately leaves empty.

PrestaShop is already multilingual. That changes the whole problem

WordPress needs a plugin to even have the concept of a second language. PrestaShop does not. Every translatable piece of content lives in a dedicated language table: products, categories, CMS pages, meta titles, URL rewrites. The store was built multilingual from day one.

So the question is never "how do I make my store multilingual". The store is already multilingual. The question is "how do I fill thousands of empty rows without hiring an agency and without wrecking my URLs".

That distinction matters, because it rules out an entire category of tools before you even start comparing them.

What the official language pack really gives you

When you install a language, PrestaShop downloads the community language pack. It is free and genuinely useful, but its scope is narrow and worth knowing precisely.

The pack fills the interface strings plus a short list of database rows: the default static pages and their URL rewrites, the standard colour and size attributes, order statuses, carrier delivery times, the default categories. On a fresh store that is a few dozen rows.

What it never touches: your product catalogue and your CMS pages. Not one product name, not one description, not one custom page. Those are your content, so the pack leaves them alone.

That is the exact boundary of the work. Everything the pack covers, you should never pay an AI to translate. Everything past it is the real job.

The overlay trap

A lot of translation tools, especially the ones ported over from the WordPress world, work by rewriting the page as it is sent to the browser. The store stays monolingual underneath and a layer swaps the text on the way out.

On PrestaShop this is a bad deal, for reasons that show up a few weeks in rather than on day one.

Your store does not know the translated pages exist. So the sitemap, the hreflang tags, the canonical URLs and the structured data all describe a single-language shop. Search engines index what PrestaShop declares, not what an overlay paints on top.

Transactional content stays behind. Order confirmation emails, invoices and PDF delivery slips are generated server side, outside the page the overlay intercepts. Customers get a translated shop and an email in the wrong language.

You also pay twice for the free part. An overlay translates whatever is on screen, including the interface strings and order statuses the language pack already delivered for nothing.

And if you already run a multilingual store, an overlay is simply incompatible with it. You end up with two competing sources of truth for the same content.

The last problem is the one that costs the most later: switch the tool off and every translated page disappears at once.

Filling the native tables instead

The alternative is unglamorous and much stronger: write the translations into the language tables PrestaShop already uses.

Once those rows are filled, PrestaShop does the rest of the work itself, because that is what it was designed to do. Routing, hreflang tags, the sitemap, the language selector already in your theme, emails, PDF invoices. None of that needs a plugin. It needs data.

It also means the translations are yours in a literal sense. They sit in your own database, in your own backups, in your own export. Disable the module that wrote them and the translated pages keep serving.

That is the approach the TrueLang PrestaShop module takes: catalogue, combinations, features, categories, CMS pages, faceted search filters, URL rewrites and meta fields, written natively, on PrestaShop 1.7.6 through 8.x.

URLs are where live stores get hurt

If you translate anything on a shop that already has traffic, read this section twice.

PrestaShop default routes carry the object ID, like /3-clothes or /content/1-delivery. Because the ID is in the URL, changing the rewrite does not break the old address: the front controller recognises the ID and redirects to the new one. That covers you on products and categories.

Static pages are the exception. Their rewrites have no ID in them, so the moment you translate one, the old address becomes a genuine 404. If those pages have backlinks or sit in the index, you need redirects from the old addresses, not good intentions.

Translated URLs are still worth having. A /femmes/robes-ete beats /3-summer-dresses in a French SERP. Just do it with the redirect plan in place, rather than after the traffic drops. The same discipline applies to any multilingual migration: the rankings you already have are the asset you are protecting.

Checkout, emails and invoices are part of the store

It is easy to declare victory once the product pages look right. Customers do not stop at product pages.

Checkout labels, payment step wording, order confirmation emails, invoices and delivery slips are all part of the buying experience, and all of them are places where a half-translated store loses trust at the exact moment it was about to earn money. A native approach covers them, because PrestaShop generates them from the same language tables.

Protect what you already wrote

Two rules save an enormous amount of cleanup later.

Never overwrite human work. If someone on your team rewrote a product description in German, no automated pass should touch it again. A field edited by hand should be recognised as such and left alone, permanently.

Keep a glossary. Brand names, product ranges, industry terms, the words you never want translated. AI translation is good enough now that the failures are rarely grammatical. They are terminology failures: your model name turned into a common noun, your trademark helpfully localised. A glossary costs ten minutes and prevents all of it.

What this should cost

Translation pricing is where a normal project turns into an unpredictable operating expense. Subscription tools bill you every month for pages you translated once and published long ago, and the bill grows with your catalogue.

For a store, that model is backwards. A catalogue is not a stream, it is a stock. You translate a product once and it sells for two years.

Credit-based pricing fits far better: you pay for the translation work you actually run, and nothing while your catalogue sits there selling. TrueLang licences ship with 5 EUR of credit included, roughly a hundred-page store into two languages, with no subscription behind it. If you want the arithmetic in detail, we broke it down in how much website translation costs.

A sane order of operations

1. Install the official language pack for each target language first. It is free and it covers the interface.
2. Check your source language. On PrestaShop the source is whichever language your content was actually written in, which is not always the store default.
3. Translate the catalogue and the CMS pages. That is the part nothing else covers.
4. Reread the pages that sell: bestsellers, landing pages, delivery and returns policies.
5. Keep redirects on any static page whose URL changed.
6. Check hreflang and the sitemap once, in the front office. If the translations are in the native tables, PrestaShop generates both correctly on its own.

The short version

PrestaShop already knows how to be multilingual. It just ships with the shelves empty.

Fill the shelves properly, in the store's own tables, and everything downstream works the way the platform intended: URLs, SEO, emails, invoices, and translations that stay yours whatever you later decide about the tool that produced them.