Selling in several languages
Your catalogue translated, with AI doing the heavy lifting and you reviewing it.
Your catalogue translated, with AI doing the heavy lifting and you reviewing it.
It lives in Panel → Languages.
The base language
The first one you add is the base language: the one your catalogue is already written in. It is not translated — everything is translated against it. That is why it cannot be removed.
All the others are translations of it.
Adding a language
The dropdown carries more than fifty languages, Catalan, Basque and Galician
included. If yours is not there, type its code by hand (ca-ES, pt-PT…):
it works just the same.
Translating
Each language shows how much of each thing is translated: products, categories, collections, variants, options, option values and tags. The question the screen answers is what is missing, not what you have already done.
The button translates 25 at a time. There is deliberately no "translate the whole shop": every batch is calls to a paid model, and the one who decides whether to continue is you, seeing what came out and what it cost.
It uses whatever AI you configured in Panel → AI, with your key and against your daily spending cap.
What it does not touch
Anything already translated stays as it is. A person may have corrected it, and overwriting would throw away the only reviewed work there is.
It translates, it does not rewrite. What gets translated is the text you already approved. If each language were generated from scratch, every version would say something different and only the original would have been reviewed.
It also checks for forbidden claims. A model can slip into English what did not slip in Spanish, and whoever publishes the page answers for what it says. Anything that smells of a health or guarantee promise comes back flagged in the report.
How the shop asks for it
A storefront asks for a language like this:
curl "https://your-shop/tienda/productos?locale=en-US" \
-H 'x-pcc-clave: pk_...'If it arrives in more than one way, this is the order in which they win:
?locale=, ?idioma=, the x-pcc-locale header and, last, the
Accept-Language header the browser sends by itself.
The catalogue comes back translated on two routes: the product list
(/tienda/productos) and the product page (/tienda/productos/:handle). There
it translates the whole record — a product carries its variants, options,
categories and collections inside, and half a translated page looks worse than
none.
Your text pages come back translated too, on /tienda/paginas and
/tienda/paginas/:handle. The address does not change: /condiciones is
/condiciones in every language, so the links in your theme and the ones people
have saved keep working.
Anything untranslated comes back in the original language. A Spanish product page inside an English site beats an empty one.
The storefront
Translating the catalogue is not enough: the theme has to ask for it. The factory themes (Atelier, Mascotas, Cinematográfico and Dulce Obrador) always speak English and Spanish, with nothing to turn on, and English is the default.
What the URLs look like
| Language | URL |
|---|---|
| English | /en/tienda, /en/producto/whatever |
| Spanish | /es/tienda, /es/producto/whatever |
Every address carries its language. One without a prefix (/producto/whatever)
answers with a temporary 307 redirect to the same page with a language: the
one the visitor chose before, if the theme remembers it, or otherwise the one
their browser asks for, and English if it asks for neither.
Switching language takes you to the same page in the other language, not to the home page. Someone looking at a product does not want to lose it by changing language.
What the theme translates and what the shop translates
- The shop translates the catalogue: product names, descriptions, categories, collections, variants, options and their values. It arrives already translated and is the same for every theme.
- The theme translates its interface: buttons, notices, the checkout and the age gate.
- Your text pages (legal notice, terms, privacy, "about us") are yours, not the theme's: you write them under Content › Pages, and each one has a language selector to write the other version. Leave a field blank and that field is served in the base language, so a half-translated page still reads.
This matters more than it looks: your terms and your privacy policy are a contract with whoever buys. Selling in Spanish with the terms only in English is a consumer-law problem, not a cosmetic one.
Reviews are not translated, and that is not an oversight: a review is what a person said, and rewriting it in another language is inventing a quote and signing it with their name.
If you add a language in the panel that the theme cannot write, the catalogue
will come out translated but the theme will not offer it: the factory themes
only know en and es. Their texts live in src/i18n/en.json and
src/i18n/es.json (in Dulce Obrador, in client/src/i18n/en/ and
client/src/i18n/es/); for a theme to speak another language, it has to be
added there.
The seller panel and the emails
The language does not stop at the storefront. The seller panel is in English and Spanish too, and every email goes in the recipient's language, with English when it is not known.
Removing a language
It stops being sold in, but its translations are kept. It is a reversible decision, and throwing the work away just in case would turn one click into hours of paying the AI again.
Details worth knowing
- Translations live apart from the product. Each one is its own row. The catalogue is never touched, so you can add a language, look at it calmly and remove it with no risk at all to what you are selling.
- If translating fails, the shop carries on. The visitor sees the original language, which is exactly what they would see without any of this.
- Prices and currencies go by region, not by language: they are different things.