Traducir una tienda WooCommerce parece un problema resuelto: instalas un plugin de traducción, conectas una IA, le das a traducir y ya está. Y funciona… para el ochenta por ciento de la tienda. El veinte por ciento restante es justo el que el cliente ve cuando ya te ha pagado.
Este artículo va de las tres capas que hay que traducir, en qué se diferencian, y del fallo que se cuela en casi todas las tiendas multiidioma: los correos de pedido llegando en español a un cliente francés.
Una tienda no es una sola cosa que traducir, son tres
El error de fondo es tratar la tienda como un conjunto de páginas. No lo es. Tiene tres capas con mecanismos distintos:
- El contenido: fichas de producto, categorías, atributos, páginas legales. Vive en la base de datos y se traduce como cualquier contenido.
- La interfaz: los textos de WooCommerce y de tu tema — «Añadir al carrito», «Finalizar compra», los mensajes de error del formulario. No son contenido tuyo: vienen del código del plugin y se traducen por otro mecanismo.
- Los correos transaccionales: confirmación de pedido, pedido en proceso, pedido completado, reembolso. Se generan fuera de una petición de página normal, y esa diferencia lo cambia todo.
La mayoría de plugins de traducción resuelven muy bien la capa 1, razonablemente la 2, y la 3 es donde aparecen las sorpresas.
Capa 1: el catálogo
Es la parte agradecida. Con un plugin de traducción con IA conectada, un catálogo de doscientos productos se traduce en una sesión.
Tres cosas que conviene vigilar:
Los atributos y variaciones se olvidan. Si vendes ropa con atributo «Color» y valores «Rojo», «Azul», eso son términos de taxonomía, no texto del producto. Se traducen por separado y es muy fácil dejarse la mitad. Revisa un producto variable en el idioma nuevo antes de dar el catálogo por bueno.
Las unidades y formatos no se traducen solos. Una talla española no es una talla británica, y una IA traducirá «Talla 40» como «Size 40» sin avisarte de que en Reino Unido eso es otra cosa. Esto no lo arregla ningún plugin: es una decisión de negocio sobre tu tabla de tallas.
El SEO del producto traducido. El título y la meta descripción de cada ficha también necesitan traducción, y no siempre viajan con el contenido. Si usas Yoast, comprueba que los campos SEO del idioma nuevo no están vacíos: nuestra guía de trucos de Yoast a nivel pro tiene la parte de revisión masiva de estos campos.
Capa 2: la interfaz de compra
Aquí hay una distinción que ahorra mucho tiempo entender: los textos de la interfaz de WooCommerce ya están traducidos a decenas de idiomas por la comunidad. No hay que traducirlos, hay que cargarlos.
Si el idioma del sitio está bien configurado y los ficheros de idioma están actualizados, «Add to cart» sale como «Añadir al carrito» sin que hagas nada. Cuando ves inglés en botones de WooCommerce, casi nunca es un problema de traducción: es que faltan los ficheros de idioma o el idioma activo no es el que crees.
Lo que sí tienes que traducir tú son los textos de tu tema, los de plugins pequeños sin traducción y los que hayas personalizado a mano. Esos sí pasan por el plugin de traducción.
Prueba el proceso completo en el idioma nuevo antes de abrirlo al público: añadir al carrito, ir al carrito, iniciar el pago, provocar un error a propósito dejando un campo vacío. Los mensajes de error son el sitio donde más se cuelan textos sin traducir, porque nadie los mira.
Capa 3: los correos, donde falla casi todo el mundo
Este es el motivo principal de este artículo.
La mayoría de plugins de traducción funcionan interceptando la generación de la página: cuando WordPress va a mostrar contenido, el plugin lo intercepta y devuelve la versión traducida. Es un mecanismo eficaz y es el que usan casi todos.
El problema es que un correo de pedido no es una página. Se genera cuando cambia el estado de un pedido, muchas veces desde una tarea programada o desde una llamada de la pasarela de pago, sin que haya ninguna visita de por medio. En ese contexto no hay idioma «activo» de navegación: hay el idioma por defecto del sitio. Y por eso el cliente francés recibe su confirmación en español.
There's a second nuance that's even more confusing: a WooCommerce email has two distinct parts. The template —header, footer, the labels of the product table, the "Thank you for your purchase"— and the body, with the specific order data. They are generated at different moments of the process. It is perfectly possible for one to be translated and the other not, and end up with an email half in one language and half in another. If it has happened to you, you weren't seeing visions.
How to really check it
Don't trust the plugin's preview. The only valid test is this:
- Create a one-euro product, hidden from the catalog.
- Browse the store in the language you want to test, from an incognito window.
- Buy that product with an email address you have access to.
- Then go through the order statuses from the dashboard: processing, completed.
- Open each email that arrives and check template and body separately.
Repeat it for each language you have open. It's boring and it's the only way to know.
What to do if they are not translated
In order from least to most effort:
- Check that the order saves the customer's language. Translation plugins that support WooCommerce well store the language in the order to be able to use it later. If it is not saved, there is nothing to do later.
- Check WooCommerce language files. Much of the text in these emails is from WooCommerce and is already officially translated. If the files are missing, it appears in the base language.
- Translate email templates separately. The texts you have customized usually have their own place in the translation plugin, separate from the page content.
- If you sell abroad seriously, verify it with real money. A one-euro test order per language costs less than a customer who doesn't understand their invoice.
Before choosing a plugin, it's worth asking support directly if they translate transactional emails and if they save the language in the order. The answer separates the wheat from the chaff quite a bit. We review the alternatives in our comparison of translation plugins for multi-language WordPress, and if you are looking for one that uses AI for the bulk of the catalog, you have the listing for WP Translate Master.
AI translates well, but it doesn't know about commerce
A note on the quality of machine translation in a store, which is different from that of a blog.
A modern AI translates a product description very well. What it doesn't do is adapt:
- The terms of your sector. If you sell technical components, there are words that are said in a specific way in your market. Give the plugin a glossary if it supports it; if not, manually review the twenty most repeated terms.
- The legal obligations. Return, warranty and privacy texts are not translated, they are are redone according to the regulations of the destination country. Literally translating your Spanish policy to German leaves you with a text that does not comply there.
- The commercial tone. The sales record changes quite a bit between markets. A literal translation from Spanish to German usually sounds excessive.
The reasonable rule: catalog with AI, legal texts with a professional. The catalog is volume and forgives minor errors; legal is not.
Frequently Asked Questions
Do I need a different domain per language?
No. The most common and simplest to maintain is to use subfolders of the type /en/ o /fr/ within the same domain, which also concentrates authority in a single place. The important thing is that each version has its own stable URL and that the tags hreflang correctly declare the alternatives.
Do I translate the entire catalog or only what I sell most?
Start with what you sell, not everything. Translating four hundred references only to discover that only thirty are sold in that market is a waste of time. Open with the main categories and checkout process pages, measure for a couple of months and expand with data.
Does it affect store speed?
It depends on how the plugin works. Those that translate on the fly with each visit add work to the server; those that save the translation in the database are faster to serve but take up more space. If you notice that the store slows down after activating multi-language, look there first. Any store with multiple languages should have page caching well configured.
Can I translate only with AI, without a plugin?
For a small and stable catalog, yes: you export, translate with AI and import as products of the new language. It's more manual work but zero dependencies. It stops being worthwhile as soon as products change often, because each change has to be replicated manually in each language.
Summary
Translating a store is three jobs, not one. The catalog is the easy one and where AI performs. The interface is usually already translated and just needs to be loaded correctly. And transactional emails are the blind spot: they are generated outside the browsing context, have separate template and body, and the only way to know if they work is to place a real order in each language.
If you do that test before opening the language to the public, you save yourself an email from a customer asking why their invoice is in a language they don't understand. It takes half an hour and it's the best half hour invested in the entire project.
