A finales de 2021 un cliente de comercio electrónico alemán llegó a Seahawk con un brief que básicamente decía: "Necesitamos nuestra tienda WooCommerce en inglés, francés y polaco. Para marzo." Era noviembre. Y el presupuesto para traducción humana era, digamos, ambicioso en la dirección equivocada. Habíamos usado la API de Google Translate en un par de proyectos antes y el resultado era, honestamente, vergonzoso para cualquier cosa más allá de etiquetas de botones. Así que me puse a buscar.
Fue entonces cuando me senté adecuadamente con DeepL. Lo había visto mencionado en algunos hilos de desarrolladores pero no lo había tomado en serio. El error más grande que cometí en esa media década. Una vez que pasé las mismas descripciones de productos por ambas APIs y mostré el resultado al cliente lado a lado, no había competencia. Entregamos la tienda alemana en tres idiomas antes de Navidad, el cliente agregó holandés seis meses después sin sudar la gota gorda, y ese proyecto sigue siendo uno al que señalo cuando la gente pregunta qué se ve como una buena integración de API.DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.
Este post trata sobre la realidad práctica de integrar DeepL en un sitio web. No el copy de marketing. Las decisiones reales de implementación, el modelo de costo, las sorpresas, y qué me diría a mí mismo en el pasado antes de empezar.
Por Qué DeepL Realmente Supera las Alternativas
Seré directo: para idiomas europeos, DeepL está en otra categoría. El modelo fue entrenado fuertemente en el corpus de Europarl y otros textos paralelos de alta calidad, y lo sientes inmediatamente en la salida para alemán, francés, español, italiano, holandés, polaco y portugués. La estructura de las oraciones se siente meditada en lugar de intercambiada palabra por palabra.
La API de Google Translate (v2 y v3) es más barata y cubre más idiomas. 133 vs los 29 idiomas compatibles de DeepL a mediados de 2024. Si necesitas suajili o bengalí, DeepL no es tu respuesta. Punto final. Pero si tu cliente se está expandiendo por la UE o hacia Japón (DeepL hace japonés de forma excepcional), estarías haciéndole un flaco favor usando Google por hábito.
La otra cosa de la que nadie habla lo suficiente: el parámetro de formalidad de DeepL. Puedes establecer formality=more o formality=less y la API ajustará el registro del resultado en consecuencia. Eso importa enormemente para el alemán, donde du/Sie no es una opción estilística menor. Una marca de moda DTC quiere un registro diferente que una empresa B2B SaaS. He tenido clientes que notaban esta distinción en su copia traducida sin que siquiera tuviera que señalarlo.formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.
Entender el modelo de costos antes de comprometerte
DeepL cobra por carácter traducido. El plan API gratuito (DeepL API Free) te da 500,000 caracteres por mes. Suena como mucho hasta que estás traduciendo un catálogo de WooCommerce con 800 productos y descripciones largas.
El plan Pro comienza alrededor de $6.99/mes por 500,000 caracteres y escala desde ahí. Para la mayoría de los proyectos de agencia que ejecuto, el costo se sitúa entre $15 y $60 por mes dependiendo del tamaño del catálogo y la frecuencia de actualización. Compara eso con las tarifas de traducción humana profesional (típicamente £0.10 a £0.18 por palabra en el mercado del Reino Unido) y la API se paga sola en las primeras 200 palabras.
Una cosa que me quemó al principio: el manejo de HTML. DeepL puede recibir HTML sin procesar e intentará preservar las etiquetas en lugar de traducirlas. Pasas tag_handling=html en tu solicitud. Pero si tu HTML está malformado o tus descripciones de productos contienen scripts inline (mirando a algunos plugins de WooCommerce), el resultado puede quedar dañado. Aprendí a sanitizar el contenido antes de que llegue a la API, no después.HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.
Los dos caminos de integración: WordPress y compilaciones personalizadas
Sitios WordPress
Para WordPress, el camino más directo que he usado es la integración de WPML. WPML tiene un conector DeepL nativo integrado en su módulo Translation Management. Autorizas tu clave API de DeepL dentro de la configuración de WPML, seleccionas qué tipos de contenido traducir automáticamente, y maneja la cola. No es magia, un paso de revisión humana sigue siendo digno de incluir en el flujo de trabajo, pero para un sitio de 300 páginas te ahorra semanas.WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.
La alternativa es Polylang Pro con el complemento DeepL. Licencia un poco más barata, un poco menos pulida en el lado de la gestión de traducciones. Usé Polylang en un sitio de un grupo de restaurantes franceses el año pasado. Funciona bien para esa escala. Pero para cualquier cosa con tipos de publicación personalizados y campos ACF, WPML maneja los casos excepcionales mejor según mi experiencia.
Si estás construyendo WordPress headless (front-end en Gatsby o Next.js que consume WP vía GraphQL), querrás llamar la API de DeepL directamente desde tu pipeline de build o una función serverless. No intentes hacerlo pasar por un plugin en esa arquitectura. No escalará limpiamente.
Builds Personalizados / No WordPress
Aquí es donde se pone interesante. DeepL publica librerías cliente oficiales para Python, Node.js, PHP, Ruby, .NET y Java. La librería de Node.js es sólida. La he usado en un proyecto Next.js donde cacheamos traducciones en Redis para evitar llamadas API redundantes en strings repetidos.official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.
Una llamada básica en Node.js se ve así:
`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' `` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``
Simple. La pregunta real de arquitectura es el caching. No quieres golpear la API en cada carga de página. Almacena traducciones en tu base de datos o en una capa de cache (Redis funciona bien, incluso un archivo JSON simple funciona para sitios pequeños). Invalida el cache cuando el contenido fuente cambia. Eso es todo. La mayoría de la complejidad está en la lógica de invalidación del cache, no en la llamada API misma.
Manejando Placeholders y Contenido Dinámico
Esto confundió a uno de mis desarrolladores en Seahawk en un proyecto SaaS donde los strings de la UI contenían variables como {{user_name}} y {{count}}. Si envías eso crudo a DeepL, a veces traducirá los nombres de las variables. No es ideal cuando {{nombre_de_usuario}} termina en tu UI en español.{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.
La solución: usa el manejo XML de DeepL y envuelve tus placeholders en etiquetas ignore antes de enviar.XML handling and wrap your placeholders in ignore tags before sending.
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
Configura tag_handling=xml e ignore_tags=deepl:ignore en tus parámetros de solicitud. La API preserva cualquier cosa dentro de esas etiquetas. Está documentado en la referencia de API de DeepL pero es fácil pasarlo por alto en una primera lectura. Me costó alrededor de tres horas de depuración en ese proyecto SaaS. Espero que a ti no te cueste ninguna.tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.
Construir un Flujo de Revisión Sensato
La traducción automática no es un botón de publicación. Nunca recomendaría enviar la salida de DeepL directamente a un sitio en vivo sin al menos una revisión de un hablante nativo, particularmente para cualquier cosa orientada al cliente. Pero el flujo de trabajo no tiene que ser doloroso.
Esto es lo que configuro para la mayoría de proyectos de clientes:
- Ejecuta la traducción inicial a través de la API de DeepL.
- Envía la salida a una tabla de traducción de staging (en WPML esto es automático; en compilaciones personalizadas escribo en una tabla de BD translations con una columna status que por defecto es pending).
translationsDB table with astatuscolumn defaulting topending). - Envía un enlace al revisor en el mercado del cliente (a menudo el equipo local del propio cliente o un freelancer de ProZ).ProZ).
- El revisor edita directamente en el CMS o en una interfaz de revisión simple que construyo.
- El estado cambia a approved, el contenido se publica.
approved, content goes live. - Bloquea la cadena para que no se sobrescriba en la siguiente sincronización de API.
Ese último paso importa. He visto configuraciones donde una actualización de contenido en el idioma de origen desencadena una retranducción completa y borra todas las correcciones manuales. Construye el mecanismo de bloqueo antes de construir cualquier otra cosa.
Consideraciones de SEO para sitios multiidioma
El contenido traducido solo no posiciona. Necesitas etiquetas hreflang en tu HTML <head> para cada variante de idioma, y deben ser correctas. Una configuración de hreflang desajustada puede suprimir tus páginas internacionales en los resultados de búsqueda. Lo vi ocurrirle a un cliente que tenía un hermoso sitio traducido al francés invisibilizado durante cuatro meses porque alguien escribió mal los códigos de idioma (fr-FR vs fr).hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( fr-FR vs fr).
Más allá de hreflang: URLs traducidas. Lo ideal es traducir también los slugs, no /fr/how-to-cook-pasta sino /fr/comment-cuire-les-pates. DeepL puede traducir slugs pero querrás pasarlos por un formateador de slugs después (minúsculas, guiones, sin caracteres especiales). WPML lo hace automáticamente. En desarrollos personalizados, hazlo manualmente./fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.
Y metadatos. Títulos de página, meta descripciones, texto alternativo en imágenes. Todo necesita tratamiento de traducción. Paso los metadatos por DeepL por separado en el pipeline, no como parte del lote de contenido principal. Es más fácil controlar los límites de caracteres de esa manera.
Dónde DeepL se queda corto
Respuesta honesta: terminología específica de marca. DeepL no sabe qué llama tu cliente a sus características de producto. Si un cliente fintech usa "Smart Vault" como nombre de producto, DeepL lo traducirá. Cada vez.
La solución es la función de glosario de DeepL. Defines pares de términos mediante la API (término de origen, término de destino, par de idiomas) y adjuntas el ID del glosario a tus solicitudes de traducción. Ese Smart Vault se convierte en "Smart Vault" en cada idioma porque se lo indicaste. Puedes gestionar glosarios mediante programación o a través del panel de DeepL. Ahora configuro glosarios como parte del inicio de cada proyecto. Toma 20 minutos e impide una categoría de errores que de otro modo consumiría horas en revisión.glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.
La otra limitación honesta: la cobertura de idiomas de DeepL. 29 idiomas es genuinamente restrictivo si tu cliente tiene ambiciones más allá de Europa y Asia Oriental. Si necesitas árabe, estás viendo un enfoque híbrido: DeepL para los idiomas europeos, Google Cloud Translation o Microsoft Azure Translator para todo lo demás, unificado detrás de una única capa de API interna que enrute por par de idiomas. Molesto de construir una vez. Muy conveniente de mantener.
FAQ
¿Es la API de DeepL gratuita?
Hay un nivel gratuito con 500,000 caracteres por mes, lo que es generoso para pruebas y proyectos pequeños. El plan gratuito requiere una tarjeta de crédito registrada pero no te cobrará a menos que superes el límite o hagas upgrade. Para sitios en producción con tráfico real o volumen de contenido, casi con certeza querrás un plan de pago. Los niveles Pro comienzan alrededor de $6.99/mes y escalan según el uso de caracteres.
¿Puedo usar DeepL con WordPress sin un plugin?
Técnicamente sí. Puedes llamar a la API REST directamente desde un plugin personalizado de WordPress o functions.php usando wp_remote_post(). Pero a menos que disfrutes reinventar la rueda, las integraciones de WPML o Polylang manejan la cola de traducción, sincronización de strings y bloqueo de contenido por ti. Solo iría directo a API personalizada en WordPress si tienes una razón arquitectónica muy específica.wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.
¿Qué tan precisa es DeepL en comparación con la traducción humana?
Para idiomas europeos, DeepL regularmente obtiene puntuaciones dentro de algunos puntos porcentuales de la traducción humana en benchmarks de puntuación BLEU. Hablando prácticamente: lo suficientemente bueno para descripciones de productos y strings de UI, no lo suficientemente bueno para documentos legales, copy creativo, o cualquier cosa donde el tono y los matices culturales sean el punto completo. Siempre integra un paso de revisión humana en los proyectos con clientes.
¿Afecta la traducción de DeepL al SEO?
El contenido traducido por máquina que no ha sido revisado puede ser marcado como bajo en calidad por los motores de búsqueda, particularmente si se lee de manera poco natural. Google ha declarado que no penalizan el contenido traducido automáticamente por sí mismo, pero el contenido delgado o garbled tendrá un desempeño inferior. Mi regla: revisa antes de indexar, no después.
¿Cuál es la mejor manera de manejar actualizaciones de traducción cuando el contenido fuente cambia?
Rastrear un hash de contenido (MD5 de la string fuente está bien) junto a cada traducción en tu base de datos. Cuando el contenido fuente se actualiza, el hash cambia, lo que marca la traducción como obsoleta. Tu pipeline luego retraducirá solo los strings cambiados en lugar de la página completa. Esto mantiene los costos de API bajos e impide cambios innecesarios en strings que ya fueron revisados manualmente.
---
La API de DeepL es una de esas herramientas que genuinamente cambió cómo defino el alcance de proyectos multilingües. No porque elimine la necesidad del criterio humano, sino porque desplaza el trabajo de la tediosa traducción de primer borrador a la revisión editorial significativa. Es un mejor uso del tiempo de todos, incluido el presupuesto de tu cliente. Conéctalo con cuidado, cachea agresivamente, integra el paso de revisión desde el primer día, y te servirá bien.