O Respondo foi construído em Dubai, e esse fato moldou o produto mais do que qualquer decisão de roadmap que tomamos. Uma única fila de suporte aqui pode conter um cliente escrevendo em árabe, outro em inglês, um terceiro em hindi e um quarto em urdu — muitas vezes na mesma hora. Nunca existiu uma versão deste produto que tratasse um idioma como padrão e o resto como traduções. Mais de trinta idiomas, incluindo os que se escrevem da direita para a esquerda, tinham que ser a fundação, e não uma camada que acrescentaríamos depois.

Essa restrição acabou sendo esclarecedora. Quando o multilíngue não é opcional, muitos atalhos que parecem razoáveis em um produto que nasce em inglês se revelam becos sem saída. Foi isto que aprendemos ao construir para essa realidade, tanto na IA quanto na interface.

Traduzir não é entender

A arquitetura tentadora é um pipeline: pegar a mensagem que chega, passá-la por uma API de tradução para o inglês, processá-la com seus modelos em inglês, gerar uma resposta em inglês e traduzi-la de volta. É barato, é rápido de construir, e falha exatamente nas situações de que o atendimento ao cliente é feito.

As conversas com clientes são densas de contexto, que a tradução genérica achata. Gírias, expressões idiomáticas, registros de polidez e terminologia específica do domínio são todos lixados nessa ida e volta. O exemplo clássico é uma única palavra com uma bifurcação de sentido: um cliente perguntando sobre um "retorno" no contexto do varejo quer saber sobre devolver um produto; a mesma palavra num contexto financeiro diz respeito ao rendimento de um investimento. O ciclo traduzir-processar-traduzir perde o fio, porque, quando o modelo em inglês a vê, o contexto que desfazia a ambiguidade já foi destroçado.

O Respondo usa, em vez disso, modelos específicos por idioma. Uma mensagem em árabe é entendida e respondida em árabe, nativamente, sem nunca passar pelo inglês como representação intermediária. As distinções que importam — tom, registro, o sentido certo de uma palavra ambígua — são captadas no idioma em que de fato vivem. Essa é a diferença entre uma resposta que é tecnicamente correta e uma que um falante nativo reconhece como fluente.

Quando a interface se inverte

Lidar com os idiomas no modelo é metade do problema. A outra metade é a interface, e os idiomas escritos da direita para a esquerda são onde a maioria dos design systems discretamente se desfaz.

Dar suporte ao árabe e ao hebraico não é uma questão de traduzir strings. O layout inteiro se inverte. O texto se alinha à direita. A ordem de leitura corre da direita para a esquerda, o que significa que o fluxo visual de uma conversa, a posição de um botão de voltar, a direção para a qual uma seta deve apontar — tudo isso é espelhado. Um design construído com pressupostos da esquerda para a direita fixados em posições absolutas não se adapta ao RTL; ele quebra.

A parte sutil é que nem tudo se inverte. É a armadilha em que as equipes caem quando descobrem a propriedade direction do CSS e acham que o trabalho está feito.

  • Layout, alinhamento de texto e ordem de leitura são espelhados. Uma barra lateral à esquerda em inglês pertence à direita em árabe.
  • Ícones com direção herdam a inversão. Uma seta de "responder" ou um chevron de "próximo" tem que apontar para o outro lado, porque seu significado é direcional.
  • Conteúdo que é inerentemente LTR não se inverte. Números de telefone, nomes de marca em alfabeto latino, trechos de código e URLs são lidos da esquerda para a direita, independentemente do idioma ao redor. Espelhe-os e você terá criado algo sem sentido.

Acertar isso à mão, componente por componente, ao longo de um produto inteiro é exatamente o tipo de tarefa impossível de manter consistente à medida que o produto cresce. Então não fizemos à mão.

Baseado em restrições, não em posições

A decisão que tornou o RTL sustentável foi parar de descrever nossos componentes em termos de posições absolutas e passar a descrevê-los em termos de relações.

Um componente baseado em posição diz "este rótulo fica a 16 pixels da borda esquerda". Essa instrução está errada no instante em que o layout se inverte. Um componente baseado em restrições diz "este rótulo fica no início da linha, com 16 pixels de espaço antes de o conteúdo começar". Agora, "início" resolve para a esquerda em inglês e para a direita em árabe automaticamente, e a mesma definição de componente é renderizada corretamente nas duas direções sem um único condicional.

Nos apoiamos nas próprias propriedades lógicas do navegador para expressar isso — o CSS moderno que pensa em *start* e *end* em vez de *left* e *right*, e em *inline* e *block* em vez de horizontal e vertical. Um componente escrito dessa forma não sabe nem se importa em qual direção está sendo renderizado. A direção é definida uma vez, na raiz, e cada componente abaixo dela se adapta.

O retorno se acumula. Adicionar o próximo idioma RTL custa quase nada, porque a lógica de layout nunca esteve atrelada a uma direção específica, para começar. Um componente novo, construído sobre as primitivas compartilhadas, é correto nas duas direções por padrão — um engenheiro teria que se esforçar para quebrá-lo.

Espaço para o texto respirar

A última lição é a menos glamorosa e a mais frequentemente ignorada: o comprimento do texto varia enormemente entre os idiomas, e um layout que só viu inglês vai rachar sob aqueles que não cabem.

A mesma frase pode ficar 30% mais longa em alemão, chegar num conjunto de caracteres completamente diferente em chinês, onde alguns poucos glifos carregam o que o inglês precisa de uma frase inteira para dizer, ou exigir mais espaço vertical para os diacríticos que ficam acima e abaixo da escrita árabe. Um botão dimensionado para a palavra inglesa "Send" corta ou transborda o texto no instante em que uma tradução mais longa cai dentro dele.

Nossos componentes assumem desde o início que não sabem qual será o comprimento do texto deles. Eles crescem com o conteúdo, quebram a linha com elegância, e nunca dependem de uma string ter um comprimento específico. É uma pequena disciplina que poupa mil correções pontuais de layout mais tarde — e, assim como o tratamento da direção, é o tipo de coisa que é quase de graça se você já constrói assim desde o primeiro dia, e enormemente cara de adaptar depois.

O fio condutor

Cada uma dessas decisões rima com a mesma ideia: o multilíngue não pode ser um recurso que você acrescenta, porque os pressupostos de um produto de idioma único se estendem ao modelo, ao layout e a cada componente individual. Construa priorizando o inglês e você passará o resto da vida do produto remendando os lugares onde esses pressupostos vazam. Construa para trinta idiomas desde o começo e o trigésimo primeiro sai quase de graça. Estar sediados onde nossos clientes falam uma dúzia de idiomas por dia não tornou isso mais difícil — tornou impossível errar silenciosamente, que é o melhor tipo de restrição sob a qual projetar.