El cliente solicita un sitio web multilingüe en Tilda. Conectas la traducción, revisas las páginas, todo se ve bien.
Pero luego abres el formulario de contacto: los nombres de los campos están en ruso, el botón «Enviar», el mensaje de error «Rellene el campo». Todo esto en el contexto de una página en inglés.
Así es como funcionan la mayoría de las soluciones de traducción de Tilda. Y esto no es un error de un servicio específico, sino un problema arquitectónico.
Por qué los formularios en Tilda se traducen de manera diferente
El texto normal en una página de Tilda es estático. Está incrustado en HTML, y el traductor puede encontrarlo, reemplazarlo y entregárselo al usuario. Todo es predecible.
Con los formularios, la historia es diferente. Tilda los genera a través de JavaScript: después de que la página se carga, un script crea campos, nombres de campos, sugerencias dentro de los campos y botones dinámicamente. Para cuando el traductor intenta encontrar el texto, aún no está en la página. O ya está allí, pero los scripts de Tilda lo reemplazan inmediatamente.
Esto se llama contenido dinámico, y es lo que rompe la mayoría de las soluciones de traducción. Google reconoce oficialmente, que la renderización de JavaScript crea problemas incluso para la indexación, los traductores de navegador se enfrentan a las mismas limitaciones.
Google reconoce oficialmente, que la renderización de JavaScript crea problemas incluso para la indexación, los traductores de navegador se enfrentan a las mismas limitaciones.
Además de los nombres de los campos, el formulario contiene varias categorías de elementos:
- mensajes de error al rellenar («Introduzca un correo electrónico válido», «Campo obligatorio»)
- texto después del envío, «Gracias, nos pondremos en contacto con usted»
- sugerencias dentro de los campos antes de rellenar
- etiquetas de las casillas de verificación, incluido el consentimiento para el procesamiento de datos
- botón de envío
Cada uno de estos elementos requiere un procesamiento separado, y cada uno tiene sus propias características técnicas.
Un caso aparte: formularios en Zero Block
Tilda permite crear formularios de dos maneras: a través de bloques estándar y a través de Zero Block (un constructor visual con total libertad de maquetación). Técnicamente, son implementaciones diferentes, y su lógica de funcionamiento difiere.
En la práctica, esto significa que si la traducción funciona para formularios estándar, no garantiza un funcionamiento correcto para los formularios en Zero Block. Algunos elementos pueden no traducirse o traducirse de forma impredecible. Esto no es una excepción, sino una consecuencia de cómo está estructurado Tilda: la misma funcionalidad se implementa de varias maneras independientes.
¿Qué falla específicamente en la competencia?
Weglot
Weglot está orientado a la traducción de contenido HTML estático de la página. Dado que los formularios de Tilda se crean dinámicamente a través de JavaScript, su contenido no siempre entra en el área de procesamiento, por lo que los formularios pueden permanecer en el idioma original.
Se puede intentar evitarlo a través del "editor visual" de Weglot: agregar manualmente elementos del formulario para traducir. Esto funciona parcialmente: los campos principales se traducirán, pero los mensajes de error y el texto después del envío seguirán sin traducirse. Además, cada cambio de formulario en Tilda debe volver a escribirse manualmente en Weglot.
Linguise
Linguise utiliza una capa adicional en el lado del navegador. Funciona mejor con contenido dinámico, pero sigue dependiendo de las características de carga de formularios en Tilda. Como resultado, la traducción puede funcionar de manera inestable: en algunas páginas, los formularios se muestran correctamente, en otras, parcial o con omisiones, dependiendo de la configuración de los bloques.
Soluciones personalizadas
Algunas agencias resuelven la tarea manualmente: duplican la página para cada idioma, crean formularios separados con campos traducidos. Este es un enfoque confiable, pero requiere mantener múltiples copias de formularios y sincronizarlos con cada cambio, lo que aumenta la carga de trabajo.
Cómo funciona la traducción de formularios en Multify
Multify funciona como un proxy inverso entre el usuario y el sitio: la solicitud pasa a través de los servidores de Multify, donde el contenido se traduce en el servidor, y el resultado final ya llega al navegador del usuario.
En lugar de capturar elementos creados dinámicamente en la página, Multify intercepta las respuestas de Tilda y traduce el contenido en el servidor. El usuario recibe un HTML ya traducido, y los scripts de Tilda muestran el formulario en el idioma correcto.
Todos los elementos del formulario se traducen:
- nombres de campos
- sugerencias dentro de los campos antes de rellenar
- botón de envío
- mensajes de error al rellenar
- texto después del envío
- etiquetas de las casillas de verificación
Al mismo tiempo, la lógica de los formularios de Tilda no se rompe: las integraciones con amoCRM, Bitrix24 o cualquier otro CRM siguen funcionando. Los datos se envían como de costumbre.
Una historia aparte: el consentimiento para el procesamiento de datos
Hay un elemento del formulario que requiere especial atención: la casilla de verificación de consentimiento para el procesamiento de datos personales.
En un sitio web en ruso, generalmente se refiere a la «Política de privacidad» con texto según la Ley Federal 152. En un sitio web alemán o un sitio para una audiencia europea, ya es GDPR, y los requisitos de formulación son legalmente diferentes: el consentimiento debe ser explícito, separado para cada propósito, sin casillas de verificación premarcadas.
Esto no es solo una traducción de texto. Es la localización del contenido legal , es decir, la sustitución de un contexto legal por otro.
Multify traduce el texto de la casilla de verificación como contenido normal. Pero la redacción legal correcta para un mercado específico debe ser preparada por el equipo. Esto va más allá de la traducción automática.
Consejo práctico: si lanza un sitio web para una audiencia europea, prepare un texto de consentimiento separado para la versión lingüística y entréguelo como «traducción manual»; la mayoría de las herramientas serias admiten la anulación de líneas individuales.
Texto después de enviar el formulario
Otro punto donde todo se rompe: el mensaje que el usuario ve después de hacer clic en el botón.
Técnicamente, no aparece como texto estático, sino como resultado de un evento después de una respuesta exitosa del servidor. Muchos traductores omiten este estado: la página está traducida, pero «Gracias por su solicitud, le llamaremos en 30 minutos» permanece en ruso.
Para un usuario que completó el formulario en inglés, esto parece un error, especialmente si no lee ruso.
En Multify, el texto después del envío se traduce junto con el resto del contenido del formulario, porque la traducción se aplica a todos los estados de la página, no solo a la carga inicial.
Por cierto, en una tienda en línea en Tilda, el proceso de pago también es un envío de formulario. Los mismos campos, los mismos mensajes de error, el mismo texto de confirmación. Todos los mismos problemas de traducción, solo que el precio del error es mayor.
Lista de verificación: qué revisar antes de publicar un formulario multilingüe
Antes de entregar el sitio al cliente, revise cada formulario en cada idioma:
- Todos los nombres de los campos están traducidos
- Las sugerencias dentro de los campos están traducidas
- El botón de envío está traducido
- Intente enviar el formulario con un campo obligatorio vacío — verifique el mensaje de error
- Intente introducir un correo electrónico incorrecto — verifique el mensaje de error
- Envíe el formulario con éxito — verifique el texto después del envío
- El texto de consentimiento para el procesamiento de datos cumple con la jurisdicción
- Si hay formularios en Zero Block en la página — revíselos por separado
Esto le tomará 10 minutos por cada formulario, pero le ahorrará una llamada del cliente diciendo «¿por qué el formulario no está traducido?».
Preguntas frecuentes
¿Por qué Weglot traduce todo el sitio web, pero no los formularios de Tilda?
Weglot trabaja con el HTML que ya está en la página en el momento de la carga. Los formularios de Tilda se crean dinámicamente a través de scripts; su contenido aún no existe cuando Weglot recorre la página. Por lo tanto, simplemente no los ve.
Si se duplica la página para cada idioma, ¿se traducirán los formularios?
Sí, funciona. Crea una página separada con el formulario en cada idioma y cambia a los usuarios entre ellos. La desventaja es que, con cualquier cambio en el formulario, debe actualizar todas las copias manualmente. En dos idiomas es tolerable, en cinco ya es un problema de mantenimiento grave.
¿Se transmiten los datos del formulario correctamente después de la traducción?
Sí. La traducción solo afecta al texto mostrado: nombres de campos, sugerencias, botones. Los datos que el usuario introduce en los campos se transmiten tal cual: el nombre, el correo electrónico y el teléfono se envían al CRM sin cambios. Las integraciones con amoCRM, Bitrix24 y Google Sheets siguen funcionando.
¿Se puede especificar manualmente el texto para un elemento de formulario específico?
Sí. En Multify, puedes establecer la traducción manualmente para cualquier cadena. Esto es útil específicamente para textos legales: consentimientos, políticas, descargos de responsabilidad, donde la traducción automática puede no tener en cuenta el contexto legal local.
Conclusión
Traducir formularios en Tilda no es «seleccionar el idioma en la configuración». Es una tarea separada con varios niveles de complejidad: creación dinámica de elementos, estados de error, contenido legal, diferentes implementaciones de una misma funcionalidad.
La mayoría de las herramientas lo resuelven parcialmente o no lo resuelven en absoluto. Si la traducción de formularios es crítica para su proyecto, verifique esto primero antes de conectar y configurar todo lo demás.
