How to Translate 2000 PrestaShop Products Without a Team

A catalogue of two thousand products is not a bigger version of a catalogue of twenty. It is a different problem. At twenty products you can translate everything, read everything and fix everything in an afternoon. At two thousand, any approach that requires you to look at every page has already failed.

So the question is not "how do I translate my catalogue". It is "what do I actually need to translate, in what order, and what do I check when I cannot check it all".

First, measure what you really have

Most merchants overestimate their catalogue by a wide margin, because they count products rather than distinct text.

A store with 2000 products usually has a few hundred genuinely distinct descriptions. The rest are variants of the same text, sometimes identical apart from a size or a colour. Attributes, features and category names repeat across the entire catalogue: forty attribute values might cover every product you sell.

Before you price any translation project, count these separately:

• Product names and short descriptions, the fields that appear in listings and are read the most.
• Long descriptions, the heaviest text but not the most read.
• Attributes, features and their values, a small set reused thousands of times.
• Categories, their descriptions and their meta fields, few in number and high in traffic.
• CMS pages, the ones that build trust and earn links.

That list, in that order, is also a decent priority order. The last two are the smallest and among the most valuable.

What the store already gives you for free

PrestaShop's official language pack fills the interface, the default static pages, order statuses, carrier delivery times and the standard colour and size attributes. That is genuine work you should never pay to redo.

Install the language pack for every target language before running any translation. It costs nothing, it takes a minute, and it removes a slice of content from the bill. Everything it covers is already correct and idiomatic, reviewed by the PrestaShop community rather than generated.

What it never touches is product_lang and cms_lang: your catalogue and your pages. That is the real project.

Translate in the order that pays

With a large catalogue, the temptation is to press the button and translate everything at once. It works, but it spends your budget uniformly across pages whose value is anything but uniform.

A more sensible sequence, especially on a first target language:

Categories first. There are usually a few dozen of them, they rank for the broad commercial queries, and they are the pages a new visitor lands on. Include their descriptions and meta fields.

Then your bestsellers. Take the products that make eighty percent of your revenue, which on most stores is a couple of hundred references. Translate names, short descriptions, long descriptions and meta fields.

Then attributes and features. Small volume, catalogue-wide effect. A product page with a translated description and untranslated attribute values still reads as broken.

Then the CMS pages. Delivery, returns, contact, terms. These convert, and abroad they carry more weight than at home because the visitor has no other reason to trust you.

Then the long tail. Everything else, in one pass, without ceremony.

The value of this order is that you can stop between two steps, publish, and see whether the market responds before spending on the rest.

The mistakes that make a large catalogue expensive

Re-translating what a human already fixed. On a store that has been running for years, some German descriptions were probably written by hand. Any tool that overwrites them costs you twice: once for the translation, once for the outrage. A field edited manually should be recognised as such and never touched again.

Translating the same string a thousand times. If your tooling sends every product's attribute values individually, you pay a thousand times for forty distinct words. This is usually invisible in the interface and very visible on the bill.

Ignoring the codes. Product references, EAN codes, model numbers and sizes should come out the other side unchanged. When they do not, you get a catalogue where the reference of a product differs between languages, which breaks search inside your own store and confuses your suppliers.

Letting brand terms drift. Over two thousand products, an unmanaged vocabulary produces three names for the same product family. A glossary set up before the run is ten minutes that saves a week.

How to check a catalogue you cannot read

You will not read two thousand translated product pages. Nobody does. You can still get real confidence out of a sample, if you sample deliberately rather than randomly.

Pick fifteen pages: your five bestsellers, three products with unusual formatting, two with long technical descriptions, the two biggest categories, and your delivery and returns pages. Then check for the failures that machine translation actually produces, which are rarely grammatical.

Look for numbers, units and codes that changed. Look for a product name that turned into a common noun. Look for a size chart where the columns no longer align. Look at the checkout in the target language, end to end, including the order confirmation email.

That is an hour of work and it catches nearly everything that would embarrass you. Our own method for that check is in how to review a translation in a language you do not speak.

What it costs, honestly

The reason large catalogues used to stay monolingual is that agency pricing per word makes two thousand products a five-figure project. Machine translation moved that by an order of magnitude, and modern models moved it again.

The cost that matters is not the price per word, it is whether you keep paying after the work is done. A catalogue is a stock, not a stream: you translate a product once and it sells for years. A subscription that bills you monthly for pages translated last spring inverts that logic and grows exactly as your catalogue grows.

Credit-based pricing fits the shape of the work. You pay for the run, you pay again when you add products, and nothing in between. TrueLang licences include 5 EUR of credit, which is around a hundred pages into two languages, so a large catalogue is a matter of topping up once rather than signing up for anything.

The practical sequence

1. Install the official language pack for each target language.
2. Count your distinct content, not your products.
3. Translate categories, then bestsellers, then attributes, then CMS pages, then the tail.
4. Set the glossary before the first run, not after the third.
5. Sample fifteen pages and check the mechanical failures.
6. Reread and improve by hand only the pages that sell. That is where human time earns the most.

The TrueLang PrestaShop module writes all of it into PrestaShop's own language tables, so the routing, the hreflang tags, the sitemap, the emails and the invoices keep working the way the platform intended, whatever you decide about the tool later.