Pela experiência que tive ao longo dos anos, noto com certa frequência que grande parte dos tradutores não têm muita ideia de como as coisas acontecem nos bastidores, tanto na organização como no preparo e manejo dos arquivos que vão ser traduzidos. Acho, então, que vale a pena comentar sobre isso e levantar alguns pontos, exemplificando um pouco do que rola.

Vale dizer que essa falta de informação/conhecimento não tem um culpado direto. Os passos que existem no processo de localização são muito segmentados e, frequentemente, realizados por empresas diferentes, entre pessoas que têm pouco contato direto umas com as outras. Como tudo mais que acontece nessa indústria, isso não é regra: cada caso é um caso, cada agência é uma agência e cada empresa é uma empresa. Ainda assim, vale a pena tocar em umas generalidades e, espero, ajudar a sanar algumas questões que as pessoas possam ter — ou, talvez, até responder dúvidas que não sabiam que tinham.

O texto

Como deve ser esperado, tudo começa com os roteiristas e escritores que vão trabalhar em um determinado jogo. A questão que mais afeta a tradução aqui, no entanto, é quando tudo começa.

Concepção

No início da fase de produção do jogo, supondo que tudo já esteja decidido pelo diretor e/ou produtor, a galera que escreve começa a colocar a mão na massa enquanto o resto da equipe inicia o processo de desenvolver aspectos do jogo em si. Dependendo do cronograma que o estúdio for seguir, eles podem iniciar o processo de localização imediatamente ou esperar ter um volume considerável de texto antes de contatar os tradutores. Cada estúdio vai ter seu próprio fluxo de trabalho, mas aqui entra o primeiro aspecto que pode afetar nós, tradutores, indiretamente: é muito mais fácil e rápido produzir, editar, e reescrever texto do que fazer qualquer outra coisa durante o desenvolvimento de um jogo, o que significa que roteiristas e escritores trabalham com material altamente volátil, propenso a ser modificado diversas vezes ao longo do tempo.

Dependendo da abordagem da empresa, eles podem preferir esperar até terem pedaços maiores do jogo preparado antes de enviar à tradução, garantindo que o texto vá sofrer pouca modificação posteriormente, ou podem enviar imediatamente o que já vão escrevendo para, depois, reenviar texto editado que a equipe de tradução vai precisar atualizar. Independente de como seguem com o processo, isso já levanta alguns problemas, tipo:

• A tradução frequentemente começa antes mesmo do jogo ser anunciado, então há zero contexto para o tradutor trabalhar caso não receba algum tipo de instrução ou briefing como, por exemplo, material de referência que o resto da equipe de desenvolvimento tem acesso. Se não há anúncios na mídia e nenhuma documentação de suporte, o tradutor não sabe qual a visão para o jogo e trabalha às cegas.
• Como o jogo está em início da fase de produção, não há referências sólidas para serem consultadas, porque os assets e o jogo em si ainda não existem. Em diversos casos, quando existem referências, elas podem ser alteradas durante o período mais ativo do desenvolvimento e se tornarem defasadas sem os tradutores saberem, algo comum (e acidental) quando há centenas de profissionais multidisciplinares trabalhando juntos sem alguém dedicado a fazer ponte de contato com a equipe de localização.
• Nem todo estúdio ou distribuidora mantém comunicação frequente com equipes de tradução. A causa costuma ser falta de informação mesmo, tanto sobre o processo, como sobre o que é necessário para que se tenha um bom resultado.

Devido a esses fatores, a equipe de tradução raramente recebe um pacote completo de texto — algo com o conteúdo do jogo todo — para traduzir. A grande maioria dos casos envolve um planejamento tenebroso de recebe-e-devolve diversos pacotes de palavras (comumente chamados de batches) que são escritos e traduzidos em intervalos irregulares. Quando se fala na mídia que "o jogo X teve 1 milhão de palavras e levou 2 anos para ser traduzido", o comum seria pensar que a equipe de tradução recebeu o pacote de 1 milhão de palavras e teve 2 anos para realizar o processo todo, mas raramente é assim.

O que acontece, na grande maioria dos casos, é o envio de batches menores, conforme vão sendo escritos, e a devolução deles traduzidos. Seria um sonho poder ter um cronograma fixo de entregas e devoluções, mas como a própria produção de jogos é uma área caótica — aspecto inerente de um campo criativo que precisa gerar lucro como produto — todos trabalhamos com um calendário em que não há previsão exata de prazos e volumes. O jogo X de 1 milhão de palavras, por exemplo, pode passar por meses em que exige a tradução de 40 ou 50 mil palavras, e pode passar por meses de hiato em que não há nada para fazer — tudo depende de como os escritores e roteiristas estão trabalhando e avançando, e eles próprios podem não ter um cronograma redondinho para entregas devido a outros aspectos da produção.

Aliás, esse é um dos motivos de, em jogos grandes assim, estúdios e distribuidoras preferirem trabalhar com agências em vez de diretamente com tradutores: agências já possuem uma estrutura organizacional pronta para lidar com a inconsistência de cronogramas, portanto a empresa desenvolvendo o jogo não precisa se preocupar em:

1. Gerenciar uma equipe de freelas, que vão fazer um serviço o qual os desenvolvedores não são capacitados para avaliar.
2. Se responsabilizar pelo bem estar financeiro de pessoas que podem passar grandes intervalos de tempo sem receber serviço.

Claro, a realidade nem sempre é assim, agência não é algo que vai automaticamente garantir qualidade, ou que vai ter gente capacitada na gerência e que seja capaz de amenizar os problemas enquanto mantém o fluxo de trabalho. Porém, do ponto de vista externo, é serviço terceirizado valioso com existência justificada. Ou seja: você, tradutor freela e sozinho, que tenta contato com gigantes dos jogos, possivelmente está sendo ignorado por esse motivo, e vai ser muito difícil conseguir algum contrato sem estar envolvido com alguma agência, especialmente porque quando algum jogo é anunciado para o público, há grandes chances dele já estar com o processo de tradução em andamento. Mas, se você oferecer um serviço completo, com uma equipe pronta, a situação já muda.

Fora isso, sempre ressalto o quão importante é o tradutor ter um alto desconfiômetro, e um grande repertório crítico sobre o universo dos videogames, justamente porque vai precisar lidar com situações que estão bem longe do ideal enquanto ainda é capaz de entregar um trabalho com qualidade profissional. Se ter conhecimentos literários ajuda na hora de escrever uma tradução bonita e fluida, ter conhecimentos especificamente sobre videogames ajuda em todo o resto, porque a consequência da falta de um cronograma fixo é a falta de acesso à informação sobre o jogo de maneira atempada. Mesmo que um desenvolvedor tenha passado todas as referências possíveis no início do projeto, há uma chance acima de zero de que, em algum momento, algo vai ser alterado no jogo e a equipe de tradução não vai ser informada – não por malícia ou desprezo, mas porque os próprios desenvolvedores podem estar com dificuldade em documentar e rastrear tudo o que acontece e informar todas as partes envolvidas.

Como tradução é uma parte à parte do desenvolvimento (somos freelas que trabalham para empresas prestando serviço terceirizado, afinal), há chances maiores de algo se perder na cadeia de comunicação. Embora existam agências que detestam manter linhas de comunicação abertas, convém sempre aproveitar a chance quando trabalhar para alguma que permita não só que os tradutores se reúnam e conversem, como também tenham acesso direto ao gerente de projeto para tirar dúvidas.

Nota: essa costuma ser a abordagem de empresas trabalhando com AAA, pois têm logística mais complexa para a produção de jogos, então precisam ter todos os passos bem definidos com certa antecedência, mesmo que o calendário seja inconsistente. Jogos menores ou independentes costumam passar por outros tipos de desafios e problemas.

Preparo

Para a tradução realmente começar, o texto tem que sair do jogo e ir para um arquivo que o tradutor possa acessar e mexer, e é aqui que entra um cargo pouco conhecido, mas importante: o engenheiro de localização. Essa é a pessoa que vai extrair o texto relevante, converter para um formato acessível e inserir na CAT Tool que vai ser usada.

Frequentemente, porém, o trabalho do engenheiro acaba sendo dividido entre alguém da equipe de desenvolvimento e o gerente de projeto, porque é algo que pode ser separado em múltiplas etapas: extração do texto (desenvolvedor) e inserção na ferramenta de tradução (gerente de projeto) — embora empresas maiores costumem ter alguém dedicado só para isso, especialmente se há múltiplos projetos correndo ao mesmo tempo. Outra utilidade dessa função é ter alguém para resolver problemas técnicos que podem vir a surgir da manipulação do texto, como erro ao alinhar colunas, caracteres de certos idiomas que não aparecem, problemas de importação com variáveis ou pedaços de código que bugam o jogo, e coisas assim.

Quando o texto é exraído de um jogo, o formato dele pode variar de acordo com a engine ou escolha da equipe de desenvolvimento. Meu formato favorito é o .xls porque não só separa de maneira fácil de visualizar todas as informações relevantes em uma tabela — enquanto preserva o texto original — como também permite editar rapidamente qualquer coisa que for preciso direto no arquivo, sem usar a CAT Tool ou navegar em meio a linhas de código, caso algo precise de algum ajuste urgente (obs: não recomendo traduzir direto no Excel, nunca, isso é só para situações rápidas e urgentes). Outros formatos que já usei foram .txt, .xml e .po, mas não gosto deles justamente porque não têm uma visualização limpa do texto, ou dificultam organizar e filtrar informações extras.

Em outros casos, quando a função é segmentada entre desenvolvedor e gerente de projeto, quem faz o preparo é o gerente em si. Caso o texto esteja em .xls, é muito fácil filtrar as linhas a serem trabalhadas, ou adicionar colunas extras para serem usadas como filtros a mais ao importar na CAT Tool — como, por exemplo, definindo linhas que estarão trancadas e destrancadas — entre outras coisas que podem exigir um trabalho mais "manual" sem o risco de quebrar algum código.

Nesse tipo de cenário, as traduções em .xls costumam ser organizadas em colunas, onde cada uma é usada para uma função específica. A coluna "A", por exemplo, pode ser a ID da linha; a "B" pode ser o nome do personagem que está falando; a "C" pode ser alguma orientação de cena, indicação de gênero dos personagens, coisas assim; a "D" seriam as falas no idioma original; a "E" seria onde a tradução para o português vai ficar; e assim vai indo. Não só as informações nas colunas A-C podem ser inseridas como contexto dentro do MemoQ como, ao exportar o arquivo depois de pronto, é possível fazer uma inspeção visual do resultado com grande facilidade.

Já com outros formatos, tenho muita pouca experiência, mas dentre o que já vi, eles costumam ter muitos resquícios de código ao redor do texto, exigindo mais cuidado ao manusear e sendo extremamente desaconselhável editar qualquer coisa fora da CAT Tool. Também é impossível filtrar linhas, até onde eu sei, para ver apenas aquelas que interessam — como todas as falas de um personagem específico, por exemplo — sem arriscar quebrar alguma coisa ou sem depender de um outro software externo. É possível que eu apenas não tenha conhecimentos suficientes para "data wrangle" o que importa nesses formatos, mas depender de um script ou visualizador extra me soa contraintuitivo.

No fim, o preparo do arquivo acaba sendo uma etapa importante, com capacidade de influenciar ou quão trabalhosa vai ser a função do tradutor — que deve ser apenas traduzir — e quanto contexto ele vai ter acesso dentro da CAT Tool.

A tradução

Depois do texto ser criado e preparado, ele finalmente chega aos tradutores para fazer o serviço esperado. Aqui não há muito o que falar porque é o passo que todo mundo conhece: abrir o arquivo, traduzir e entregar. O padrão é sempre haver um tradutor e um revisor — desconsiderando a existência de projetos que usam MT ou LLM, claro — e, idealmente, eles devem ter comunicação fácil entre si. Em outros casos, dependendo do prazo ou urgência, pode haver múltiplos tradutores para um revisor, ou ainda mais tradutores para múltiplos revisores. O ideal é que todos sempre tenham contato uns com os outros, seja em uma sala de chat do projeto em algum programa de mensagens, seja por troca de e-mails.

A minha abordagem pessoal, na gerência de um projeto, é dar o maior prazo que conseguir aos tradutores para que eles possam trabalhar a criatividade enquanto sentem o mínimo possível a pressão do relógio. Também encorajo a conversarem entre si sobre abordagens da terminologia, se for necessário, e sempre adicionarem os termos no glossário — mesmo que seja uma tradução temporária — para, assim, reduzir ou evitar inconsistências em equipes com múltiplos tradutores.

O motivo de dar o maior prazo possível para os tradutores é para que, ao chegar no passo da revisão, os revisores possam se concentrar em fazer só isso mesmo: revisar. Idealmente, o revisor vai corrigir pontuação, typos, ou ajustar alguma terminologia que foi atualizada após o fim da etapa de tradução, evitando o máximo possível ter que reescrever frases, preservando a voz do tradutor. Porém, às vezes, há necessidade de fazer alterações mais profundas, especialmente quando guias de estilo não foram seguidos, orientações foram ignoradas, ou a qualidade está abaixo do esperado.

Nota: pretendo abordar a questão de qualidade, edição e feedback com mais detalhes uma newsletter futura.

Revisores devem evitar alterações estilísticas ou preferenciais, embora eu confesso que, quando sou o lead, costumo meter a mão nessa parte para harmonizar o texto. Porém, nesse tipo de contexto, sempre deixo claro para o tradutor que não são correções e que a tradução em si não estava errada. Em projetos onde outra pessoa é a lead, evito o máximo possível mexer no texto sem necessidade.

Caso existam problemas recorrentes na tradução, convém o revisor avisar o gerente de projeto para que ele possa verificar o que ocorre e, depois, elaborar um feedback e conversar com o tradutor sobre os problemas. Nem sempre há tempo para isso, mas acho positivo quando um gerente de projeto está envolvido mais profundamente com o processo e, no caso de problemas que persistem, conversa em particular com o tradutor em questão para ver o que está acontecendo. Somos todos humanos, afinal, e ninguém vai estar 100% o tempo todo.

Quando um problema é corriqueiro demais, ou não é possível descobrir a origem ou de onde propagou, sempre solto um aviso para a equipe toda — tradutores e revisores — ficar atenta àquilo. Nos casos de ser possível rastrear de onde os erros estão saindo, chamar a atenção de uma pessoa em público é desaconselhável, cria um clima ruim para a equipe toda e pode gerar um sentimento de humilhação. Da mesma forma, se qualquer outra pessoa da equipe notar problemas na tradução, o ideal é avisar o gerente de projeto — expor o problema diretamente no chat geral só é recomendado se todos os participantes já têm intimidade entre si.

Como sempre, isso não é regra, cada agência ou cliente pode funcionar de uma maneira diferente — e certas agências sequer permitem que o gerente se envolva tanto no projeto, ou não dão tempo suficiente para isso. Cada gerente de projeto pode ter uma abordagem própria também — tem gente que prefere que os revisores, e não os tradutores, adicionem termos ao glossário, por exemplo. Toda a dinâmica entre tradutor, revisor e gerente exige um aspecto muito "humano" dos envolvidos, dependendo também do ambiente de trabalho, então não há como definir uma fórmula que funcione para todos os casos.

A organização

Além do acesso e preparo dos arquivos, e da dinâmica entre tradutor, revisor e gerente de projeto, a organização geral do projeto — e não só no sentido de cronograma, mas de tudo — tem grande influência na tomada de decisões e nas limitações e desafios que a equipe de tradução vai enfrentar.

Problemas comuns

É importante lembrar que as "fases" que separei acima — concepção, preparo e tradução — podem acontecer simultaneamente. Não há uma delimitação clara entre elas que indique quando uma acaba e outra começa, principalmente em projetos grandes onde há múltiplas pessoas envolvidas. Por conta disso, métodos "lineares" de gerenciamento e repetição, como o Agile, não são aplicáveis. Algo como kanban é mais indicado por ser mais flexível, permitindo definir o ritmo de trabalho através de passos separados e prazos. O Trello é uma ferramenta bem popular de kanban, por exemplo.

(Só um aviso de que, apesar de conhecer o método Agile, nunca estudei ele formalmente e nunca trabalhei para uma empresa que seguisse ele. Talvez alguém que tenha experiência prática possa discordar de mim. Laura Michet, uma roteirista de jogos, fala da experiência dela com Agile aqui, e eu tenho a mesma opinião, mas voltada para tradução.)

Uma grande armadilha que costumava acontecer no passado, mas tem se tornado cada vez mais rara, é pensar na localização apenas após o início do desenvolvimento de um jogo, ignorando todas as particularidades — e complexidades — envolvidas em idiomas diferentes do nosso. Isso é um problema porque muitos dos aspectos técnicos se tornam extremamente penosos de alterar ou reverter, e muitas vezes é impossível ajustar ou adaptar o projeto quando já está tudo seguindo a pleno vapor. Para dar alguns exemplos de situações que já passei:

• Mais de 10 anos atrás, houve um projeto em que o jogo não comportava diferenciação de gênero gramatical. Sem gênero gramatical, era impossível marcar no texto o gênero dos personagens, fossem NPCs ou o jogador. Para implementar diferenciação de gênero, seria preciso reescrever toda a engine, e os desenvolvedores não tinham tempo/dinheiro para isso. No fim, a tradução teve que ser escrita de maneira a evitar marcar gênero. A qualidade ficou abaixo da esperada, mas não havia o que fazer.
• Em um projeto indie, o texto estava hard coded no código-fonte, então os desenvolvedores precisaram encontrar um jeito de extrair ele automaticamente, senão teriam que fazer isso manualmente. O processo todo levou algumas semanas e não foi perfeito — respostas contextuais, tipo "I do", eram formadas por uma linha só, repetida em pontos diferentes do jogo — e também não havia informação contextual sobre o que estava acontecendo, como descrição de ações que o personagem estava executando.
• Jogos japoneses são famosos no meio da localização por, frequentemente, não terem quebra automática de linha, exigindo contar caracteres "manualmente" para garantir que o texto não vá estourar o limite da interface. Implementar uma quebra automática envolveria, possivelmente, reprogramar muitos aspectos da interface para que funcionasse melhor sob as mais diversas circunstâncias, algo que é mais complexo do que parece, especialmente envolvendo múltiplos idiomas.
• Um jogo "live service" que traduzi no lançamento teve uma atualização de interface alguns anos depois. Nela, o limite de caracteres no nome dos itens foi reduzido e, como essa alteração de interface não considerou o impacto na localização, tivemos que abreviar manualmente centenas de termos já existentes, uma vez que não era viável reprogramarem a interface para exibir palavras mais longas.

Um caso interessante de se analisar é o do jogo Brigador, onde os desenvolvedores publicaram um texto contando como foi o processo de localização do ponto de vista técnico. É notável como a falta de preparo prévio dificultou alguns aspectos e exigiu que muita coisa fosse resolvida na mão. É um bom exemplo de como a localização deve ser pensada desde o começo e ser implementada de maneira estrutural no desenvolvimento.

Diferenças entre indies e AAA

Geralmente, jogos AAA possuem uma estruturação mais rígida e um cronograma menos flexível, onde dependem muito da tradução de batches a intervalos que podem ou não ser regulares — e na minha experiência, raramente são. Isso adiciona um certo nível de stress e acaba exigindo uma equipe com tradutores de "backup", pois a irregularidade não garante que os tradutores principais estarão sempre disponíveis.

Indies, por outro lado, costumam entregar o texto completo do jogo para tradução, de uma só vez mesmo. Os projetos tendem a ter bem menos palavras que jogos AAA e seguem para tradução após o jogo já ter alguma demo interna funcional, muitas vezes permitindo que o tradutor jogue uma versão alfa para ter mais contexto. Nos casos em que a tradução é segmentada durante o processo de escrita do jogo, a quantidade de pacotes é muito menor que um AAA — não é incomum um título indie ter 5 ou 10 batches, enquanto um AAA é capaz de chegar até, ou ultrapassar, 50. Por conta disso, a maior diferença prática, para um tradutor, é que projetos indie costumam ser traduzidos em questão de poucos meses, enquanto produções maiores levam anos e podem ter grandes momentos de hiato.

Quem vê um projeto de 100 mil ou 200 mil palavras pode pensar "opa, os próximos meses já estão garantidos" mas, devido à inconsistência em cronogramas e necessidade de mais pessoas no mesmo projeto para dar conta dos prazos, pode acabar trabalhando em 10 ou 20 mil palavras apenas, espalhadas ao longo de alguns meses. Como todo o processo de desenvolvimento é muito dinâmico e caótico (uso excessivamente essa palavra em conversas, mas é o melhor adjetivo que existe para descrever o ambiente), o texto de AAA frequentemente sofre alterações, então é muito improvável que alguma equipe vá receber o volume completo, na íntegra, com apenas um prazo final. Não digo que é impossível, já me aconteceu, mas foram apenas duas vezes ao longo dos meus 13 anos de serviço, e eram casos bem específicos: um projeto que era AAA, mas tinha cerca de 40 mil palavras com prazo de entrega de 3 semanas; e um relançamento que estava sendo traduzido pela primeira vez em português do Brasil, então o texto já estava todo pronto e havia amplo contexto para consulta.

Apesar disso, é bem mais comum, também, que estúdios criando um AAA tenham maior experiência em localização — e, às vezes, até profissionais internos para organizar esse aspecto — o que pode levar a um processo mais suave no aspecto técnico em troca de uma distância maior entre o tradutor e o produto ou os criadores. Por outro lado, indies permitem uma conexão mais íntima com o criador, o que muitas vezes abre a possibilidade de um toque mais pessoal no trabalho feito.

O lado da gerência

Em um mundo ideal, o papel do gerente de projeto é:

1. Manter o cliente informado sobre questões relevantes para o processo de tradução e auxiliar no que for necessário para implementar ou sugerir mudanças que sejam benéficas (conseguir mais referências, mais contexto, alterar a forma de organizar os arquivos, ajudar a elaborar cronogramas que funcionem para todos, etc).
2. Blindar os tradutores contra problemas técnicos e burocráticos, permitindo que eles foquem apenas na tradução. "Apagar focos de incêndio" é uma boa expressão para essa função também, onde se tenta prever problemas que podem surgir e evitar que se concretizem — ou trabalhar para resolver o mais rápido possível caso algum venha a acontecer.

Já li na internet certas opiniões sobre não ser necessário ter experiência de tradução para ser gerente de projeto de localização. Eu discordo porque, sem experiência prática de como o processo tradutório decorre, é difícil reconhecer e prever problemas típicas da área e como eles podem ser abrandados ou resolvidos. Aposto que você, tradutor ou tradutora ou tradutore, com certeza lida com certas questões que acontecem em quase todo projeto e pensa "ugh, seria mais fácil se a organização fosse assim em vez de assado". Mesmo que seja algo impraticável, esse tipo de insight é muito útil para notar certos elementos que geram dificuldade na hora do serviço. Duas situações bem comuns de acontecer, por exemplo, são:

• Projetos novos, geralmente anglófonos ou japoneses, sem indicação de gênero na fala dos personagens, ou em que a estrutura do texto não permite inserir variação de gênero quando a mesma resposta é usada para personagens diferentes. Notar isso logo de início já abre caminho para conversar com o cliente, permitindo buscar alguma solução possa ser aplicada para informar o tipo de concordância necessária nos diálogos.
• Jogos em que há muitas variáveis compondo estruturas sintáticas complexas, dificultando a concordância entre gênero e número de quase todas as classes de palavras. Aqui, muitas vezes, é preciso ver se existe alguma forma de implementar uma solução na engine, ou se vai caber ao tradutor tentar contornar esse problema enquanto minimiza a estranheza que essas estruturas podem gerar.

Nota: o problema de variáveis sendo usadas excessivamente é bem emblemático, resultado do aspecto mais "técnico" do desenvolvimento, onde uma tentativa de solução para um problema típico de combinação de palavras acaba mais atrapalhando do que ajudando. É algo que vou abordar com mais detalhes em uma newsletter futura.

Um gerente de projeto que já foi tradutor — e já passou por esses problemas — tem grandes chances de reconhecer imediatamente abordagens que possam funcionar para cada situação específica e que atendam ao que o projeto exige, antes mesmo da tradução começar; já um gerente de projeto sem essa experiência vai precisar, primeiro, entender o porquê dessas coisas gerarem problemas, para só então fazer um toró de ideias com possíveis soluções.

Sobre o tema

Falei um monte de coisas, e ainda assim mal saímos da ponta do iceberg. É muito difícil se aprofundar mais sem poder trazer exemplos práticos (por causa dos NDAs e tudo mais), mas pretendo continuar expandindo certos tópicos e subtópicos ao longo das newsletters. Hoje, o objetivo foi mesmo dar uma introdução e comentar casos que ou são comuns, ou que eu presenciei. No futuro, vou trazer um exemplo hipotético e "linear" da rota que a tradução de um jogo segue, do início ao fim, e isso talvez ajude a conectar melhor os pontos comentados acima. Não gosto de manter as coisas no nível "teórico" mas, colocar esse exemplo aqui, hoje, iria triplicar o tamanho dessa newsletter que já está um tanto longa.

Fora isso, ainda estou apresentando as generalidades da área e certos conceitos e questões que são recorrentes, embora nem sempre universalmente conhecidos. Quando tivermos atravessado esse matagal não desbravado, vou começar a entrar em pontos mais específicos sobre tradução, envolvendo formas de lidar com o texto em si e certos casos comuns que afetam a qualidade do serviço. Tenho uma listinha de questões linguísticas e problemas práticos que vale muito a pena abordar em detalhes, e tenho feito o possível para coletar exemplos ilustrativos (sem quebrar NDAs) para quando chegar a hora. A coleta é lenta mas, até lá, espero ter o suficiente.

Enfim, a próxima newsletter chega em outubro e vai ser sobre testes de tradução — um assunto em que é preciso desconstruir certos mitos, ao meu ver, principalmente no que diz respeito à "qualidade". Vou falar um pouco sobre os aspectos negativos da falta de feedback e direito de resposta, a importância de comentários e a minha abordagem em correções de testes.

Post scriptum

O Ghost decidiu, de uma hora para a outra, praticamente dobrar o custo do serviço deles. Os níveis de contribuição que existiam nessa newsletter eram para ajudar a custear a plataforma quando houvesse uma quantidade maior de artigos para consulta. Porém, considerei que mais do que 5 reais por mês é muito dinheiro para uma newsletter mensal, principalmente em uma área constantemente precarizada, onde nem todo mundo tem uns trocados sobrando. Por conta disso, aboli os níveis de contribuição e desbloqueei os comentários, então todas as pessoas inscritas podem comentar à vontade, em todos os artigos, sem pagar nada.

Quanto ao Ghost em si, paguei 1 ano de serviço adiantado, então o aumento de preço não me afetou ainda. Quando esse ano pago acabar, a newsletter vai ser transferida para uma plataforma diferente, com um valor mais acessível para quem não busca crescimento financeiro infinito (que é o meu caso) e que traz formas de contribuição melhores. Quem está inscrito não vai precisar fazer nada nessa mudança, mas quem acompanha por RSS vai precisar atualizar o link. Temos cerca de 9 meses até lá, então não é nada para se preocupar agora. Quando o momento chegar, vou avisar com antecedência.

Agora bora trabalhar que as contas não dão trégua. Nos vemos em um mês.