Como uma agência de conteúdo de uma pessoa entrega sites multilíngues sem tradutor
By Robert M
Como uma agência de conteúdo de uma pessoa entrega sites multilíngues sem um tradutor
Um cliente pergunta se você pode entregar o novo site dele em inglês, francês, alemão, espanhol e holandês. Você administra uma agência de uma pessoa só. Não tem um orçamento para tradução incluído no seu contrato, e não tem uma rede de tradutores freelancers disponíveis. Mas também não quer dizer não para um bom projeto.
Essa é uma situação em que muitas pequenas agências e freelancers acabam. A demanda por sites multilíngues cresceu constantemente à medida que mais empresas tentam alcançar públicos fora do seu mercado local, mas as conversas sobre orçamento não acompanharam. Os clientes frequentemente tratam a tradução como um item que pode ser reduzido ou cortado, sem realmente entender o custo de fazer isso corretamente.
Este post é sobre como lidar com essa lacuna na prática, sem comprometer a qualidade ou ter prejuízo no projeto.
As opções antigas, e por que elas não funcionam
Os caminhos tradicionais são familiares.
Você poderia contratar um tradutor freelancer para cada idioma. Para um site de cinco idiomas com trinta páginas de conteúdo, você está olhando para um custo significativo antes de considerar as rodadas de revisão, o tempo de entrega e o trabalho de orientar cinco pessoas diferentes sobre o tom e a terminologia do cliente. Esse custo ou consome sua margem ou vai para a fatura do cliente e, de repente, o projeto fica em risco.
Você poderia usar uma ferramenta de tradução para consumidores e corrigir manualmente. Isso funciona para frases simples, mas no momento em que seu conteúdo tem alguma estrutura (um arquivo JSON de localização, um post de blog em Markdown, uma página HTML com atributos e tags) a saída se torna imprevisível. As chaves são traduzidas. A sintaxe Markdown quebra. Os atributos HTML ficam bagunçados. Você acaba gastando mais tempo corrigindo a saída do que economizou por não contratar um tradutor.
Você poderia dizer ao cliente que multilíngue está fora do escopo e fazer um site em um único idioma. Às vezes essa é a resposta certa. Mas nem sempre é uma conversa que você quer ter.
O que realmente mudou
O que tornou esse fluxo de trabalho viável não foi a tradução por IA em si. Foi a preservação do formato especificamente.
O problema de alimentar conteúdo estruturado em uma ferramenta de tradução de uso geral nunca foi realmente a qualidade da tradução. A tradução automática moderna é boa. O problema era que as ferramentas não entendiam a diferença entre conteúdo e estrutura. Tratavam tudo como texto a ser traduzido, incluindo as partes que deveriam ser deixadas intactas.
Um arquivo de localização assim:
{
"nav": {
"home": "Home",
"about": "About us",
"contact": "Get in touch"
}
}
Voltaria com as chaves traduzidas, a hierarquia colapsada ou tudo convertido em prosa. Qualquer um desses resultados significa limpeza manual antes que o arquivo seja utilizável, e é aí que a economia de tempo desaparece.
Uma API que trata a estrutura como fora dos limites muda a economia. Você envia o arquivo, recebe de volta uma estrutura idêntica com apenas os valores das strings alterados. Coloque o arquivo de saída direto no projeto. Nenhuma limpeza necessária.
O fluxo de trabalho na prática
Veja como o processo funciona em um projeto real.
Na fase de conteúdo, tudo vai para arquivos de texto simples ou Markdown em vez de strings codificadas diretamente. Isso é uma boa prática para manutenção, mas também significa que o conteúdo está em um formato que pode ser traduzido de forma limpa.
Na fase de build, um script curto lê o arquivo do idioma fonte, envia para a API PolyLingo com a lista de idiomas alvo e escreve um arquivo de saída por localidade. Para um site que precisa de cinco idiomas, isso é uma chamada de API. O script leva alguns segundos para rodar. Os arquivos de saída vão direto para a estrutura do projeto.
Na fase de revisão, o cliente revisa o conteúdo traduzido. Essa é uma etapa que vale a pena manter. A tradução automática lida bem com a maior parte do conteúdo, mas os clientes às vezes têm terminologia preferida, frases de marca ou convenções regionais que precisam de um olhar humano. A revisão é mais rápida do que traduzir do zero porque a estrutura já está correta e a maior parte do conteúdo é precisa. Você está revisando, não produzindo.
Na fase de entrega, o site é lançado com todos os arquivos de localização no lugar. O seletor de idioma funciona no primeiro dia. Não há nada para acompanhar.
O custo disso versus contratar tradutores
Os números dependem do tamanho do projeto, mas a estrutura da comparação é consistente.
Um site típico de pequena empresa pode ter cerca de 2.000 palavras de texto de interface e conteúdo de página. Traduzido para cinco idiomas, isso dá cerca de 10.000 palavras de saída. Com uma taxa média de tradutor freelancer, você está olhando para várias centenas de libras ou dólares antes das revisões.
Com PolyLingo, 2.000 palavras de conteúdo em cinco idiomas alvo cabem confortavelmente no plano Starter pago de $9 por mês, incluindo capacidade para múltiplos projetos no mesmo período de cobrança. O nível gratuito (50.000 tokens por mês) cobre projetos menores sem custo algum.
O cliente ainda faz uma revisão, o que significa que ele está envolvido na qualidade da saída em vez de apenas receber uma fatura. Isso tende a ser melhor aceito nas conversas de projeto.
A conversa sobre escopo com os clientes
Uma mudança que esse fluxo de trabalho permite é mudar como você fala sobre escopo multilíngue com os clientes.
Antes, "multilíngue" significava "mais caro, prazo mais longo, dependência de terceiros." Agora é mais uma decisão de configuração. Você define o escopo, executa o script, o cliente revisa. A parte difícil é a estratégia de conteúdo e a arquitetura do site, não a logística da tradução.
Isso muda o que você pode oferecer. Um cliente que ia lançar em um idioma só com um plano vago de adicionar idiomas depois pode fazer os cinco no lançamento sem o custo do projeto dobrar. Um cliente que continua adicionando páginas pode reexecutar o script sempre que o conteúdo mudar, em vez de voltar a um tradutor com um novo briefing.
Também muda a conversa sobre o que multilíngue realmente envolve. O trabalho da agência é construir um site com uma arquitetura i18n adequada, bom texto no idioma fonte e um processo de revisão para as traduções. Essa é uma conversa de maior valor do que "vamos resolver as traduções quando a versão em inglês estiver pronta."
Onde ainda faz sentido usar tradutores humanos
Vale ser honesto sobre isso.
Para textos de marketing que precisam carregar peso emocional genuíno no idioma alvo, um tradutor humano qualificado produzirá uma saída melhor. A diferença importa mais para campanhas, declarações de posicionamento de marca e qualquer coisa onde a própria frase seja o produto.
Para conteúdo altamente regulado (jurídico, médico, financeiro) um tradutor humano com expertise no domínio é a escolha certa, e muitas vezes uma exigência de conformidade.
Para conteúdo editorial longo onde a voz precisa parecer nativa e não traduzida, a revisão humana é mais que uma passagem leve.
O fluxo de trabalho descrito aqui é mais adequado para textos de interface, conteúdo de página, descrições de produtos, documentação e sites de marketing onde a precisão e a integridade estrutural importam mais que nuances estilísticas. Isso cobre uma grande parte do que uma pequena agência realmente entrega.
Começando
O nível gratuito do PolyLingo inclui 50.000 tokens por mês sem necessidade de cartão de crédito. Para uma pequena agência, isso cobre uma quantidade significativa de conteúdo antes de precisar pensar em um plano pago.
A API aceita texto simples, Markdown, JSON e HTML. O tradutor sem código no painel lida com trabalhos pontuais sem tocar na API, o que é útil para sessões de revisão com clientes onde você quer mostrar a saída traduzida sem construir nada primeiro.