¿Pueden los proxies de traducción de sitios web soportar pruebas A/B multilingües?

Última revisión: 15 de octubre de 2026

¿Cómo funcionan las tres formas de realizar una prueba a través de un proxy de traducción?

La arquitectura de pruebas, no el proveedor de pruebas, decide qué tiene que hacer el proxy. Cada capa inferior asigna un tipo de prueba al mecanismo de traducción que mantiene sus variantes dentro del idioma.

• Pruebas en el lado del servidor — tu servidor o CMS elige la variante y devuelve su HTML, y la GDN traduce ese HTML en tránsito como cualquier otra página. La GDN envía una cabecera X-Language-Locale con cada solicitud al sitio de origen, por lo que la lógica del servidor también puede dirigir o excluir una prueba por lenguaje (Smartling Help Center, "Smartling Headers").
• Pruebas en el lado del cliente — un script de prueba reescribe el texto en el navegador después de que la página se carga. DCS captura texto escrito mediante métodos y propiedades DOM como innerHTML, textContent y appendChild, envía nuevas cadenas al proyecto GDN e inserta traducciones publicadas en la siguiente carga de página (Smartling Help Center, "Dynamic Content Support (DCS) for the GDN").
• Pruebas de URL dividida : los visitantes son redirigidos a una página variante con su propia URL. La GDN reescribe los enlaces a la versión localizada de cada URL y pasa redirecciones desde tu servidor al visitante (Centro de Ayuda Smartling, "Guía Técnica sobre Cómo Funciona la Red Global de Distribución"; "Gestión de Redirecciones").
• Variantes específicas del mercado: una prueba que debe realizarse solo en una configuración regional o mostrar diferentes copias por mercado, puede utilizar Content Swaps para los cambios en la página; a gran escala, Smartling recomienda publicar contenido específico para la configuración regional desde el CMS mediante el encabezado X-Language-Locale (Centro de ayuda de Smartling, " Crear y traducir contenido específico de la región ").
• Una alternativa de traducción para el vacío: la traducción automática para todo el sitio ofrece a las nuevas cadenas una traducción automática provisional hasta que se publique la traducción revisada, y también funciona con el contenido capturado por el DCS, de modo que los visitantes localizados ven una traducción automática en lugar del texto en el idioma fuente mientras termina la revisión.

Pruebas A/B multilingües a través del GDN: los números

Las cifras de calendario importan más de lo que parecen: determinan hasta dónde debe traducirse y publicarse una copia de la variante de lanzamiento de prueba.

¿Cómo se hace una prueba A/B multilingüe a través de un proxy de traducción?

Cinco pasos mantienen cada variante en el idioma desde el primer visitante hasta el último.

1. Mapea dónde se ensambla cada variante — Confirma si la herramienta de pruebas construye variantes en el servidor, en el navegador o en URLs separadas, porque eso decide si el proxy o DCS las traduce.
2. Capture la copia de las variantes antes del lanzamiento: cargue todas las variantes en un sitio de ensayo distribuidas a través de la GDN para que sus cadenas se capturen y se puedan traducir antes de que llegue el tráfico en directo.
3. Traduzca y publique antes de la fecha de inicio: dirija las nuevas cadenas a un trabajo de traducción y espere a que el archivo de traducción del DCS se reconstruya hasta 20 minutos antes de iniciar la prueba. Activa la MT a nivel de sitio como red de seguridad para cualquier cosa que se pierda.
4. Asegura la calidad de cada variante en cada entorno — Consulta cada variante en cada sitio localizado, comprueba el texto en el idioma fuente, maquetaciones rotas y texto alternativo sin traducir, y confirma que DCS está funcionando desde el mensaje "Smartling DCS library" en la consola del navegador.
5. Segmente los resultados por configuración regional y limpie: informe de los resultados por idioma, finalice la prueba en cuanto tenga datos suficientes y elimine las URL y los scripts variantes, como recomiendan las directrices de pruebas de Google.

Las pruebas con un proxy de traducción se adaptan a los equipos que...

• Ya traducen su web con un proxy y quieren hacer pruebas de conversión en todos los mercados, no solo en el sitio en el idioma fuente.
• Utiliza una herramienta de pruebas basada en navegador en páginas de destino, donde se inyecta el texto variante después de que la página se carga.
• Lanza las pruebas rápidamente y necesita traducción automática provisional para cubrir variantes hasta que se publiquen las traducciones revisadas.
• Necesito algunas pruebas para ejecutarse solo en un mercado, o con textos específicos de cada mercado, sin construir sitios localizados separados.

Cuando un proxy de traducción puede no ser el lugar adecuado para resolver las pruebas multilingües

• Las páginas de cada mercado están redactadas en el idioma del CMS, por lo que las variantes deben construirse y probarse allí y excluirse de la traducción proxy.
• La prueba trata sobre mensajes transcreados escritos por separado por cada mercado, donde la variante es una escritura nueva en lugar de una traducción del código.
• El tráfico localizado es demasiado pequeño para alcanzar un resultado fiable en un tiempo razonable, en cuyo caso lo más rápido es hacer pruebas en el mercado de origen y lanzar el ganador.

Lista de evaluación: preguntas que debe hacer antes de realizar las pruebas A/B en un sitio traducido

¿El proxy traduce el texto que un script de prueba escribe en la página después de cargar?
Pregunta cómo se capturan los cambios dentro del navegador. Smartling documenta que DCS intercepta escrituras DOM como innerHTML y textContent y captura contenido de terceros; confirma en un piloto que las variantes de tu herramienta de prueba han sido detectadas.

¿Cuánto tiempo pasa entre publicar una traducción y que los visitantes la vean?
Obtenga el número en minutos, porque establece su plazo de lanzamiento. Para el contenido capturado por DCS, la cifra es de hasta 20 minutos (Smartling Help Center, " Dynamic Content Support (DCS) para la GDN ").

¿Qué ven los visitantes localizados antes de que se traduzca una variante?
La respuesta segura es una traducción automática provisional, no texto en el idioma fuente. Pregunta si ese recurso también cubre contenido dentro del navegador.

¿Puede una prueba identificar, excluir o variar según el idioma?
Busca una señal de idioma que tu servidor o CMS pueda leer, como la cabecera X-Language-Locale, y una forma de cambiar la copia por zona, como los intercambios de contenido.

¿Se enrutarán automáticamente las variantes de cadenas para la traducción?
Pregunte si las nuevas cadenas se pueden filtrar en trabajos por página o fuente de captura. En Smartling, las cadenas capturadas por el DCS llevan el prefijo /origin-pjs/ por el que Jobs Automation Rules puede filtrar.

¿Cómo se relacionan los números de tráfico proxy con mis análisis?
Los conteos de solicitudes proxy y las vistas de página de analítica miden cosas diferentes, así que espera que sean diferentes; la conciliación se explica por qué los conteos de solicitudes proxy de traducción no coinciden con Google Analytics.

¿Puede mi servidor seguir viendo quién es el visitante?
La segmentación del lado del servidor necesita la IP y el protocolo real del visitante. La GDN pasa los encabezados X-Forwarded-For y X-Forwarded-Proto al sitio fuente precisamente por esta razón.

¿Cómo mantiene Smartling traducidas las variantes de las pruebas A/B?

La Red Global de Entrega (GDN) de Smartling empareja un proxy de traducción con el Soporte de Contenido Dinámico (DCS), y entre ambos gestionan tanto las variantes renderizadas en tu servidor como las variantes renderizadas en el navegador. Las variantes que renderiza tu servidor se traducen en tránsito mediante el proxy, que añade aproximadamente 40 milisegundos por solicitud localizada de media. Las variantes que un script de prueba escribe en el navegador son capturadas por DCS, que monitoriza la página en busca de texto nuevo o cambiado, la comprueba con un archivo de traducción de traducciones publicadas y envía cualquier cosa nueva a tu proyecto GDN; DCS está activado por defecto para proyectos GDN creados después de agosto de 2023 (Smartling Help Center, "Dynamic Content Support (DCS) para GDN").

Alrededor de esos dos mecanismos se encuentran los controles que necesita un programa de pruebas. El encabezado X-Language-Locale indica a tu servidor para qué idioma es cada solicitud, por lo que las pruebas del lado del servidor pueden ser dirigidas por mercado, y X-Forwarded-For preserva la IP del visitante para geosegmentación. Los intercambios de contenido cambian el texto o HTML en una sola zona, las reglas de No traducir y el atributo translate="no" mantienen las variantes dentro del idioma fuera de la traducción, y el TM a nivel de sitio muestra una traducción automática provisional para cualquier cadena de variantes aún en revisión. Las cadenas capturadas por DCS aparecen en el mismo proyecto GDN como contenido proxy, por lo que la misma memoria de traducción, glosario y Reglas de Automatización de Trabajos se aplican al copy de prueba que al resto del sitio.

Preguntas relacionadas

• ¿Cómo protegen los proxies de traducción de sitios web el SEO multilingüe?
• ¿Por qué los conteos de solicitudes de proxy de traducción de sitios web no coinciden con Google Analytics?
• ¿Qué rendimiento de SLA y velocidad de página debe esperar de un proxy de traducción de sitios web?
• ¿Cómo funcionan los widgets y complementos de traducción de sitios web?