Lo que shipping DIALØGUE me enseñó sobre productos de AI multilingües
DIALØGUE soporta 7 idiomas, pero el trabajo multilingüe de verdad no fue traducir strings. Fue corregir fechas locales para cada audiencia, mantener consistencia en TTS, arreglar el language drift de la UI y decidir dónde la calidad importa lo suficiente como para ir más lento.
Una de las cosas más seductoras que AI nos deja hacer ahora es añadir idiomas rápido. Lo sé porque no paro de hacerlo. Añadí 5 idiomas a DIALØGUE en 48 horas y luego traduje todo mi archivo del blog a 10 idiomas en 4 días.
Esos posts eran sobre la velocidad. Este es sobre todo lo que la velocidad no cubre.
La traducción es la parte más fácil de mostrar en una demo y la parte más peligrosa de sobreestimar.
La máquina puede mover texto de un idioma a otro a una velocidad asombrosa. Eso no significa que el producto ahora se sienta nativo. En mi experiencia, el trabajo multilingüe real aparece en cuatro lugares: tiempo, voz, sistemas de UI y comportamiento de fallback. Ahí es donde el producto empieza a sentirse thoughtful o empieza a sentirse falso.
Así se vio en la práctica:
| Translation Work | Product Work | |
|---|---|---|
| Qué cubre | Strings, copy, labels | Fechas, layout, voz, fallbacks |
| Quién nota el error | Reviewers bilingües | Cualquier usuario en ese locale |
| Cómo ayuda AI | Genera traducciones rápido | No puede juzgar el fit a nivel producto |
| Esfuerzo para arreglarlo | Re-traducir el string | Rediseñar el componente |
| Cuándo lo descubres | En code review | Después de que alguien usa la app |
El primer bug no fue de traducción. Fue de tiempo.
Uno de los fixes que me dejó esto clarísimo no tenía nada que ver con el copy.
Para shows recurrentes, DIALØGUE genera títulos de episodio automáticamente. La versión obvia suena inocente: nombre del show más la fecha de hoy.
Eso suena inofensivo hasta que tu audiencia está en Tokio y tu servidor sigue pensando en California.
Si una persona en Japón abre un daily show cuando en Tokio ya es 14 de marzo, pero el título todavía dice 13 de marzo porque eso cree el servidor, el producto se siente inmediatamente off. No roto. Solo descuidado.
Así que terminé cambiando los títulos de episodio para que usaran la fecha local de la audiencia, en el locale y timezone de la audiencia, no en el default del servidor.
Ese es un detalle pequeño de implementación. Y justo ese es el punto.
Los productos multilingües no van solo de palabras. Van de contexto.
Idioma sin contexto local muchas veces es solo una versión más amable de estar equivocado.
Lección 1: La voz es parte del producto
Eso se me hizo mucho más claro cuanto más me metí en DIALØGUE.
El producto está construido alrededor de dialogue, pacing, personalidad y audio. Eso sube mucho la quality bar frente a una interfaz SaaS normal.
Cuando añadí nuevos templates, aprendí rápido que el soporte multilingüe no era solo:
- traducir el nombre del template
- traducir el copy de la landing
- y shipping
Para un template tuve que pensar en todo esto:
- host profiles
- audience profiles
- dialogue guides
- voice instructions para TTS
- naming conventions localizadas por idioma
Ese trabajo ya existía en inglés, pero también necesitaba versiones en japonés y vietnamita porque la química entre hosts es parte del producto, no una capa cosmética por encima.
Si tu producto genera contenido, la voz no es decoración. La voz es infraestructura.
Algo puede ser gramaticalmente correcto y aun así sentirse muerto.
Lo noté con fuerza en las variantes de Chinese y en el contenido hablado en general. El mandarín estándar puede ser técnicamente correcto y aun así sonar demasiado formal en cierto contexto. Un ritmo conversacional relajado en inglés puede volverse burocrático cuando pasa por lenguaje de producto demasiado literal en otro idioma. Un chiste que funciona en un mercado puede convertirse en exposición plana en otro.
Por eso ahora me importan tanto las tone guides y los host profiles. No porque quiera que todo suene "branded". Sino porque el voice drift es una de las formas más rápidas de hacer que un producto de AI multilingüe se sienta genérico.
Y lo genérico sale caro.
Lección 2: La longitud de UI es un problema de producto, no de traducción
Esto suena menor hasta que de verdad shipping una app.
Y entonces está por todas partes.
Cuando localicé la app iOS de DIALØGUE, no fue cuestión de traducir unas cuantas pantallas. Se convirtió en 253 strings en 7 idiomas.
Y aun así el trabajo no había terminado.
Tuve que rewiring los input components para que el app language picker controlara de verdad el idioma de la UI de forma consistente. Placeholders, buttons, pricing labels, status text, todo. Si no, acabas con el problema de la app medio traducida:
- una screen respeta el idioma elegido
- otra todavía muestra el placeholder en inglés
- los status labels siguen en el idioma original
- la app técnicamente soporta varios idiomas, pero la experiencia no
Un button limpio en inglés se vuelve torpe en alemán. Una línea de pricing compacta hace wrap en francés. Un settings label corto y punchy se comporta distinto en japonés.
Si tu workflow de localization termina en generar texto, vas a descubrir estos problemas vergonzosamente tarde.
Por eso cada vez pienso más que el trabajo multilingüe tiene que tratarse como un sistema de producto completo:
- copy
- layout
- spacing
- truncation rules
- component behavior
- screenshot QA
La máquina puede generar las palabras. Alguien igual tiene que abrir el Simulator.
Lección 3: El fallback behavior revela qué tan maduro es realmente el producto
Esto importa todavía más en productos de audio que en productos de texto.
Uno de los fixes más útiles que hice recientemente en DIALØGUE se veía aburrido desde fuera: TTS thresholding y consistencia por segmento.
El whole-script TTS gate original era demasiado optimista. Los podcasts largos cruzaban el límite real de input, desperdiciaban varios retries fallidos y solo después hacían fallback. En algunas runs, eso significaba unos 12 segundos de latencia evitable antes de que el sistema se corrigiera.
Eso ya molesta en inglés.
En flows multilingües es peor, porque la consistencia de voz ya es más difícil de sostener.
El fix no fue "usar un mejor modelo". Fue trabajo de producto:
- bajar el threshold para whole-script synthesis
- mover episodios largos antes al modo per-segment
- añadir opening / middle / closing guidance para la energía de cada segmento
- pasar unas líneas del dialogue anterior como continuity context para que el siguiente segmento no sonara como otro show
Eso es fallback behavior. Eso es madurez.
Si una voz TTS específica de un idioma suena mal, ¿qué pasa? Si una respuesta generada mezcla idiomas, ¿qué pasa? Si aparece un untranslated error message en medio de un flow localizado, ¿qué pasa? Si un script largo cruza el model limit, ¿qué pasa?
Esos momentos te dicen si el soporte multilingüe es una feature o una foundation.
La gente suele perdonar cuando el sistema claramente está intentando ayudar. Perdona mucho menos cuando el producto se siente descuidado.
Lección 4: Saber cuándo el coverage no vale la pena
La pregunta de negocio no es "¿Puedo soportar otro idioma?"
Es:
- ¿este idioma va a desbloquear uso real o distribución real?
- ¿puedo sostener una quality bar creíble tanto en UI como en output?
- ¿puedo soportar los failure cases sin crear support debt?
Si la respuesta es no, entonces lo que estás lanzando no es multilingual capability. Es multilingual surface area. Y el surface area sin calidad debilita la confianza en silencio.
Lección 5: Los productos multilingües necesitan su propia capa de evals
Quizá este sea mi takeaway más grande tanto de DIALØGUE como del archivo del blog.
No puedes juzgar la calidad multilingüe solo por instinto, especialmente a escala.
Necesitas explicit checks:
- comportamiento de fechas y timezone por locale
- consistencia de terminología
- UI overflow
- fallback language rules
- consistencia de TTS entre segmentos
- host/personality drift
- calidad del output en real user flows
En otras palabras, los productos multilingües también necesitan evals.
Y aquí es donde creo que quienes construimos con AI podemos caer en la trampa. Nos fascina cuánto puede producir el modelo y pasamos menos tiempo definiendo de forma durable qué significa "bueno".
En escala pequeña, eso todavía se puede manejar.
En escala mayor, se vuelve peligroso.
Dónde me deja esto
Estoy más optimista que nunca sobre los productos de AI multilingües.
AI cambia por completo la economics. Amplía de verdad lo que una persona o un equipo pequeño puede shipping. Hace posibles ambiciones de producto que hace no mucho habrían parecido poco realistas.
Pero también eleva el estándar del product judgment.
Porque en cuanto expandir idiomas se vuelve fácil, la calidad se vuelve el diferenciador. Y la calidad en productos multilingües no viene solo de la traducción. Viene del contexto, la voz, el interface fit, los fallbacks, los review loops y una definición muy honesta de qué significa realmente "lo bastante nativo."
Eso es lo que DIALØGUE me enseñó. Cuantos más idiomas soportas, más product management estás haciendo de verdad, lo llames así o no.
Si tu producto es realmente multilingüe, el trabajo no termina cuando los strings están traducidos. Ahí es donde empieza el trabajo real.
Si quieres ver el resultado de esa forma de pensar, DIALØGUE ya está live en 7 idiomas. Y sospecho que la capa multilingüe me va a seguir enseñando lecciones nuevas cuanto más gente lo use. Normalmente de las humildes.
Si tú también estás construyendo productos multilingües, me encantaría saber: ¿cuál fue el momento en que te diste cuenta de que el bug más difícil no tenía nada que ver con la traducción?
Cheers, Chandler
Preguntas frecuentes
¿Cuál es la parte más difícil de construir un producto de AI multilingüe?
No la traducción. AI ahora maneja esa parte sorprendentemente bien. Lo más difícil es todo lo que rodea la traducción: formato con timezone correcta, consistencia de voz entre segmentos de TTS, UI components que se rompen con longitudes distintas y fallback behavior cuando algo falla en un locale específico. Esos son problemas de producto, no solo problemas de idioma.
¿Debería añadir más idiomas a mi producto de AI?
Solo si puedes mantener la calidad. Cada idioma que añades crea trabajo de producto continuo: layout QA, voice tuning, formato de fechas y números por locale y fallback paths. Si tu producto depende de nuance y generated content, como podcasts, escritura larga o conversational AI, la vara es más alta que en una interfaz transaccional simple.
¿Cómo pruebas features multilingües de AI?
Construyendo una capa explícita de evals. Para DIALØGUE, eso significa revisar fechas específicas por locale, consistencia de segmentos TTS, UI overflow en los 7 idiomas y personality drift en los diálogos generados de los hosts. No puedes confiar en el instinto cuando soportas más de dos o tres idiomas. El surface area es demasiado grande para hacer spot-check manual.
¿AI hace la localización más fácil o más difícil?
Las dos cosas. AI hace la traducción inicial muchísimo más rápida y barata. Pero también crea una falsa sensación de haber terminado. Tienes las palabras correctas y asumes que el producto ya está listo. El trabajo real, contexto, voz, UI fit y fallbacks, sigue necesitando human judgment. AI elevó el piso del multilingual coverage, pero el techo sigue siendo product craft.
