Traducir formularios de WordPress: los campos son solo la mitad del problema

Por qué la traducción de formularios es más amplia que las etiquetas de los campos

Un formulario no es un bloque estático de entradas visibles. Es un pequeño flujo de trabajo que recopila datos, reacciona a las elecciones del usuario, valida los envíos y, a menudo, envía mensajes tanto al propietario del sitio como al visitante. Cada una de esas etapas puede exponer texto específico de un idioma.

Eso significa que un formulario puede parecer traducido en la página y, aun así, filtrar el idioma de origen en los mensajes de error, el texto de confirmación, el texto de los marcadores de posición o el contenido de los correos salientes. En la práctica, la experiencia del usuario solo es tan multilingüe como la parte menos traducida del flujo del formulario.

Las cadenas visibles para el usuario que necesitan traducción

Las etiquetas visibles de los campos son solo una capa. Los formularios suelen incluir marcadores de posición, texto de ayuda, avisos de campos obligatorios, mensajes de validación, confirmaciones de éxito y mensajes de error. Estas cadenas forman parte de la interacción, no de la decoración.

Si un visitante envía un formulario incompleto y la respuesta de validación aparece en el idioma incorrecto, el formulario ya ha fallado en su propósito multilingüe. Lo mismo ocurre cuando un mensaje de confirmación o un destino de redirección no coincide con el idioma de la página donde se envió el formulario.

Por qué los marcadores de posición y el texto de validación importan técnicamente

Los marcadores de posición y los mensajes de validación influyen en cómo los usuarios interpretan el formulario antes y después del envío. Los marcadores de posición pueden orientar el formato de entrada, mientras que el texto de validación explica qué salió mal y qué hay que corregir. Si esas cadenas no se traducen, el formulario puede seguir funcionando, pero la interacción se vuelve inconsistente.

Esto importa especialmente cuando el formulario depende de una entrada precisa. Una etiqueta traducida por sí sola no ayuda si el mensaje de validación se refiere a un nombre de campo o a una regla de formato en otro idioma. El usuario tiene que entender tanto el campo como la regla que lo rige.

Los mensajes de confirmación y las notificaciones por correo electrónico forman parte de la misma superficie de traducción

Un envío correcto suele activar un mensaje de confirmación en pantalla y, a menudo, una o más notificaciones por correo electrónico. Esos mensajes son contenido visible para el usuario, incluso cuando se generan después de enviar el formulario.

Si el texto de confirmación está traducido pero la notificación por correo electrónico no, la experiencia multilingüe se rompe en el paso del navegador a la bandeja de entrada. El mismo problema aparece cuando los asuntos de las notificaciones, el cuerpo del mensaje o los valores dinámicos de los campos se dejan en el idioma de origen. El formulario puede haber aceptado el envío correctamente, pero la capa de comunicación sigue mostrando contenido sin traducir.

La lógica condicional cambia lo que debe traducirse

La lógica condicional convierte la traducción en algo más que un problema de sustitución de cadenas. Cuando una respuesta revela un campo, un mensaje o una rama diferente, cada rama puede contener sus propias etiquetas, texto de ayuda y reglas de validación.

Eso crea una dependencia entre el idioma y el comportamiento. Si la lógica se traduce de forma inconsistente, los usuarios pueden ver una rama que es técnicamente correcta pero lingüísticamente incompleta, o pueden encontrarse con un mensaje que se refiere a un campo que nunca vieron en su idioma. En los formularios multilingües, el árbol de lógica y el árbol de texto tienen que mantenerse alineados.

Los valores dinámicos pueden filtrar el idioma incorrecto incluso cuando el formulario está traducido

Los formularios suelen insertar valores dinámicos, como títulos de páginas, opciones seleccionadas, datos introducidos por el usuario u otro contenido dependiente del contexto, en confirmaciones y notificaciones. Esos valores no siempre son cadenas estáticas, por lo que deben considerarse por separado de las etiquetas traducidas.

Un formulario traducido aún puede producir una salida mixta en varios idiomas si el valor dinámico proviene de una fuente que no tiene en cuenta el idioma. Eso se ve especialmente en los mensajes de confirmación y en los correos electrónicos, donde el formulario puede combinar texto de plantilla traducido con contenido dinámico sin traducir o no coincidente.

Consecuencia operativa: la traducción tiene que seguir el ciclo de vida del formulario

La conclusión práctica para quienes implementan WordPress es que la traducción debe evaluarse a lo largo de todo el ciclo de vida del formulario: visualización, orientación de entrada, validación, envío, confirmación y notificación. Cada etapa puede exponer un conjunto diferente de cadenas y valores.

Para los propietarios de sitios WordPress, esto significa revisar no solo lo que aparece en el editor, sino también lo que se genera cuando el formulario se ejecuta. Un formulario puede estar localizado visualmente y aun así fallar en producción porque un mensaje posterior, una rama o un valor dinámico nunca se tradujeron.