O Que Shipping DIALØGUE Me Ensinou Sobre Produtos de AI Multilíngues

Uma das coisas mais sedutoras que a AI permite fazer agora é adicionar idiomas rápido. Eu sei porque continuo fazendo isso. Adicionei 5 idiomas ao DIALØGUE em 48 horas, depois traduzi todo o meu arquivo do blog para 10 idiomas em 4 dias.

Aqueles posts eram sobre o lado da velocidade. Este aqui é sobre tudo que a velocidade não cobre.

Tradução é a parte mais fácil de demonstrar e a parte mais perigosa de superestimar.

A máquina consegue mover texto de um idioma para outro numa velocidade impressionante. Isso não significa que o produto agora pareça nativo. Pela minha experiência, o trabalho multilíngue real aparece em quatro lugares: tempo, voz, sistemas de UI e comportamento de fallback. É aí que o produto começa a parecer thoughtful ou começa a parecer falso.

Foi assim que isso apareceu na prática:

	Translation Work	Product Work
O que cobre	Strings, copy, labels	Datas, layout, voz, fallbacks
Quem percebe quando está errado	Reviewers bilíngues	Qualquer usuário naquele locale
Como a AI ajuda	Gera traduções rápido	Não consegue julgar o fit no nível de produto
Esforço para corrigir	Retraduzir a string	Redesenhar o componente
Quando você descobre	No code review	Depois que alguém usa o app de verdade

---

O Primeiro Bug Não Foi Tradução. Foi Tempo.

Um dos fixes que deixou isso óbvio pra mim não tinha nada a ver com copy.

Para shows recorrentes, o DIALØGUE gera títulos de episódio automaticamente. A versão mais direta parece inofensiva: nome do show mais a data de hoje.

Isso parece tranquilo até sua audiência estar em Tóquio e seu servidor ainda estar pensando em horário da Califórnia.

Se uma ouvinte japonesa abre um daily show quando já é 14 de março em Tóquio, mas o título do episódio ainda diz 13 de março porque é isso que o servidor acha, o produto imediatamente parece off. Não quebrado. Só descuidado.

Então acabei mudando os títulos dos episódios para usar a data local da audiência, no locale e timezone da audiência, e não o padrão do servidor.

É um detalhe pequeno de implementação. E esse é exatamente o ponto.

Produtos multilíngues não são só sobre palavras. São sobre contexto.

Idioma sem contexto local costuma ser apenas uma versão mais educada de estar errado.

---

Lição 1: Voz Faz Parte do Produto

Isso ficou muito mais claro conforme fui mais fundo no DIALØGUE.

O produto é construído em torno de diálogo, pacing, personalidade e áudio. Isso eleva a quality bar muito acima de uma interface SaaS comum.

Quando adicionei novos templates, aprendi rápido que suporte multilíngue não era simplesmente:

• traduzir o nome do template
• traduzir o copy da landing page
• e shipping

Para um template, tive que pensar em tudo isso:

• host profiles
• audience profiles
• dialogue guides
• voice instructions para TTS
• naming conventions localizadas por idioma

Esse trabalho existia em inglês, mas também precisou de versões em japonês e vietnamita, porque a química entre hosts faz parte do produto, não é uma camada cosmética por cima.

Se o seu produto gera conteúdo, voice não é decoração. Voice é infraestrutura.

Uma coisa pode estar gramaticalmente correta e ainda assim parecer morta.

Senti isso com mais força nas variantes de Chinese e em conteúdo falado de forma geral. O mandarim padrão pode estar tecnicamente correto e ainda assim soar formal demais em certo contexto. Um ritmo conversacional leve em inglês pode soar burocrático quando passa por uma linguagem de produto literal demais em outro idioma. Uma piada que funciona em um mercado pode virar exposição sem vida em outro.

É por isso que hoje eu ligo tanto para tone guides e host profiles. Não porque eu queira que todo output soe "branded". Mas porque voice drift é uma das maneiras mais rápidas de fazer um produto de AI multilíngue parecer genérico.

E genérico sai caro.

---

Lição 2: Tamanho de UI é um Problema de Produto, Não de Tradução

Isso parece pequeno até você shipping um app de verdade.

Depois, o problema está em todo lugar.

Quando localizei o app iOS do DIALØGUE, não era só uma questão de traduzir algumas screens. Virou 253 strings em 7 idiomas.

E mesmo assim, o trabalho não estava terminado.

Precisei refazer o wiring dos input components para que o seletor de idioma do app realmente controlasse a língua da UI de forma consistente. Placeholders, buttons, pricing labels, status text, tudo. Senão, você cai no problema do app meio traduzido:

• uma screen respeita o idioma selecionado
• outra ainda mostra placeholder em inglês
• os status labels ficam no idioma original
• o app tecnicamente suporta vários idiomas, mas a experiência não

Um button limpo em inglês pode ficar estranho em alemão. Uma linha de pricing enxuta pode quebrar em francês. Um settings label curto e punchy pode se comportar diferente em japonês.

Se o seu workflow de localization termina na geração de texto, você vai descobrir esses problemas tarde demais e de um jeito meio constrangedor.

Por isso eu penso cada vez mais que trabalho multilíngue precisa ser tratado como um sistema completo de produto:

• copy
• layout
• spacing
• truncation rules
• component behavior
• screenshot QA

A máquina pode gerar as palavras. Alguém ainda precisa abrir o Simulator.

---

Lição 3: Fallback Behavior Revela o Quão Maduro o Produto Realmente É

Isso importa ainda mais em produtos de áudio do que em produtos de texto.

Um dos fixes mais úteis que fiz recentemente no DIALØGUE parecia boring por fora: TTS thresholding e consistência por segmento.

O whole-script TTS gate original era otimista demais. Podcasts longos cruzavam o limite real de input, desperdiçavam várias retries falhas antes de cair em fallback. Em algumas runs, isso significava mais ou menos 12 segundos de latência evitável antes de o sistema se corrigir.

Isso já é irritante em inglês.

Em fluxos multilíngues, é pior, porque a consistência de voz já é mais difícil de segurar.

O fix não foi "usar um modelo melhor". O fix foi product work:

• reduzir o threshold para whole-script synthesis
• mover episódios longos mais cedo para o modo per-segment
• adicionar opening / middle / closing guidance para a energia de cada segmento
• passar algumas linhas do diálogo anterior como continuity context para que o próximo segmento não pareça um show novo

Isso é fallback behavior. Isso é maturidade.

Se uma voz TTS específica de um idioma soar errada, o que acontece? Se uma resposta gerada misturar idiomas, o que acontece? Se um untranslated error message aparecer no meio de um fluxo localizado, o que acontece? Se um script longo cruzar o model limit, o que acontece?

São esses momentos que mostram se o suporte multilíngue é uma feature ou uma foundation.

Usuários costumam perdoar quando o sistema está claramente tentando ajudar. Eles perdoam muito menos quando o produto parece descuidado.

---

Lição 4: Saber Quando Coverage Não Vale a Pena

A pergunta de negócio não é "Posso suportar mais um idioma?"

É:

• esse idioma vai destravar uso real ou distribuição real?
• eu consigo manter uma quality bar convincente na UI e no output?
• eu consigo dar conta dos failure cases sem criar support debt?

Se a resposta for não, então o que você está lançando não é capacidade multilíngue. É surface area multilíngue. E surface area sem qualidade enfraquece a confiança em silêncio.

---

Lição 5: Produtos Multilíngues Precisam da Própria Camada de Evals

Talvez esse seja o meu maior takeaway tanto do DIALØGUE quanto do arquivo do blog.

Você não consegue julgar qualidade multilíngue só por instinto, especialmente em escala.

Você precisa de checks explícitos:

• comportamento de data e timezone por locale
• consistência de terminologia
• UI overflow
• fallback language rules
• consistência de TTS entre segmentos
• drift de host / personalidade
• qualidade do output em real user flows

Em outras palavras, produtos multilíngues também precisam de evals.

E é aqui que eu acho que builders de AI podem cair numa armadilha. A gente fica fascinado com o quanto o modelo consegue produzir e passa menos tempo definindo de maneira durável o que "bom" realmente quer dizer.

Em pequena escala, isso ainda é administrável.

Em escala maior, começa a ficar perigoso.

---

Onde Isso Me Deixa

Estou mais otimista do que nunca em relação a produtos de AI multilíngues.

A AI realmente muda a economics. Ela realmente expande o que uma pessoa sozinha ou um time pequeno consegue shipping. Ela realmente torna possíveis ambições de produto que não muito tempo atrás pareceriam irreais.

Mas ela também eleva o padrão de product judgment.

Porque, quando a expansão de idioma fica fácil, a qualidade vira o diferencial. E qualidade em produtos multilíngues não vem só da tradução. Vem de contexto, voz, interface fit, fallbacks, review loops e de uma definição muito honesta do que "nativo o suficiente" realmente quer dizer.

Foi isso que o DIALØGUE me ensinou. Quanto mais idiomas você suporta, mais product management você está realmente fazendo, chame isso assim ou não.

Se o seu produto é realmente multilíngue, o trabalho não termina quando as strings foram traduzidas. É aí que o trabalho real começa.

Se você quiser ver o resultado desse raciocínio, o DIALØGUE já está live em 7 idiomas. E eu suspeito que a camada multilíngue vai continuar me ensinando novas lições conforme mais gente usar. Normalmente do tipo humbling.

Se você também está construindo produtos multilíngues, eu adoraria saber: qual foi o momento em que você percebeu que o bug mais difícil não tinha nada a ver com tradução?

Cheers, Chandler

---

Perguntas frequentes

Qual é a parte mais difícil de construir um produto de AI multilíngue?

Não é a tradução. A AI já lida com isso muito bem hoje. A parte mais difícil é tudo em volta da tradução: formatação sensível a timezone, consistência de voz entre segmentos de TTS, UI components que quebram com comprimentos diferentes de strings e fallback behavior quando algo dá errado em um locale específico. Esses são problemas de produto, não apenas problemas de idioma.

Eu deveria adicionar mais idiomas ao meu produto de AI?

Só se você conseguir manter a qualidade. Cada idioma que você adiciona cria trabalho contínuo de produto: layout QA, voice tuning, formatação de datas e números específica por locale e fallback paths. Se o seu produto depende de nuance e generated content, como podcasts, textos longos ou conversational AI, a barra é mais alta do que em uma interface transacional simples.

Como você testa features multilíngues de AI?

Construindo uma camada explícita de evals. Para o DIALØGUE, isso significa checar datas específicas por locale, consistência de segmentos de TTS, UI overflow em todos os 7 idiomas e personality drift nos diálogos gerados dos hosts. Você não pode depender só do instinto depois que suporta mais de dois ou três idiomas. O surface area é grande demais para spot-check manual.

A AI torna a localization mais fácil ou mais difícil?

Os dois. A AI torna a tradução inicial muito mais rápida e barata. Mas também cria uma falsa sensação de conclusão. Você acerta as palavras e assume que o produto está pronto. O trabalho real, contexto, voz, UI fit e fallbacks, ainda exige julgamento humano. A AI elevou o floor da cobertura multilíngue, mas o teto ainda é product craft.