Testes podem ser meio polêmicos no mundo da tradução por diversos motivos, frequentemente dividindo os tradutores entre aqueles que apoiam e aqueles que são contra. Eu, confesso, sou do tipo que apoia o uso de testes, e espero esclarecer o motivo disso ao longo desse artigo. Para mim, testes medem mais do que apenas "conhecimento", ajudando a descobrir as aptidões de cada tradutor e como melhor aproveitar elas. Por outro lado, testes também podem ser muito mal utilizados para a seleção de profissionais, exigindo cuidado tanto no preparo como na avaliação.

Convém dizer que minha experiência nesse aspecto vem tanto por realizar como por corrigir testes ao longo dos anos. Falar sobre isso talvez ajude a elucidar os aspectos mais obscuros sobre preparo e avaliação, e como cada aspecto costuma ser medido.

Bom, vamos lá.

Por que testes?

Um dos aspectos meio polêmicos de se tratar em tradução de videogame — e que me causa certa ansiedade, não nego — é que tempo de experiência não se traduz (rá) necessariamente em qualidade de serviço. Isso não é exclusivo de tradução: acontece com médicos, engenheiros, profissionais de TI, gerentes, pedreiros, e por aí vai. A diferença primordial entre um tradutor e esses outros profissionais é que "qualidade", em uma área tão humanística como a nossa, tem uma boa dose de subjetividade. Como é impossível ser completamente imparcial, é importante reconhecer aonde suas preferências subjetivam levam, tanto para se adaptar às expectativas de um teste como para não se deixar influenciar por opiniões pessoais ao corrigir testes — uma habilidade também importante na revisão, diga-se de passagem.

Testes, quando bem elaborados e devolvidos com feedback, devem ser informativos, explicando o motivo da rejeição e, potencialmente, indicando quais aspectos melhorar. Caso o tradutor tenha sido aprovado, os testes devem servir para indicar quais aspectos precisam ser melhor trabalhados e acompanhados mais de perto — algo que, idealmente, fica a cargo do gerente de projeto, embora revisores confiáveis dando feedback sobre os primeiros trabalhos também ajude.

Dito isso, é preciso saber reconhecer a própria qualidade dos testes para ajustar as expectativas de acordo, já que que nem todos os testes são feitos iguais. Prazos curtos — 24 horas ou menos, por exemplo — ou falta de espaço (ou liberdade) para deixar comentários já são indicadores de que o teste é de "baixa qualidade", por assim dizer, frequentemente esperando uma abordagem mais simples e direta. Por outro lado, testes que dão prazos de alguns dias para entrega, possuem área de comentários, e nos quais alguém se disponibiliza a tirar dúvidas, prezam mais pelo trabalho "puro" da tradução e por soluções criativas. A abordagem para cada teste deve sempre ser fluida, e vou falar sobre isso mais adiante.

É importante lembrar que, independente do resultado, testes se passam em ambientes profissionais, então rejeições não devem ser levadas para o lado pessoal. Elas não medem o valor do tradutor como profissional, apenas indicam que, por um motivo ou outro, o perfil (ou a abordagem) do tradutor não se encaixa no que a empresa busca. Mesmo este que vos escreve, apesar de toda experiência, já recebeu má avaliação em testes, sendo considerado "passable" em um apesar de, poucos meses antes, ter colaborado com o lançamento de um projeto amplamente bem recebido pelo público. É difícil separar o ego da percepção de si como profissional, especialmente para quem está começando, mas é algo que se faz necessário. Bola pra frente e tenta de novo na próxima oportunidade que tiver.

Outro aspecto menos conhecido nos quais testes são utilizados é para seleção de prestação de serviço, ou seja: uma empresa querendo saber se certa agência ou equipe está à altura do que esperam. Frequentemente, quanto os clientes são grandes empresas, agências realizam testes para ganhar contratos. É menos comum, mas ainda assim relativamente corriqueiro, especialmente quando o cliente possui algum linguista interno capaz de avaliar o resultado e ver se atende às expectativas do projeto. Não posso dar exemplos aqui (NDAs e tal), mas já realizei diversos testes, ao longo da carreira, para ganhar projetos para agências com as quais trabalhava. Talvez sirva de consolo saber que agências também são testadas — e nem sempre aprovadas. Ter um histórico longo de lançamentos não significa muita coisa se há alta rotatividade de tradutores, por exemplo.

Testes como tradutor

Diversos colegas de profissão, especialmente no LinkedIn, já escreveram sobre quais aspectos se deve ter atenção ao fazer um teste, então talvez o que eu vá dizer aqui soe familiar ou repetitivo, mas são coisas que valem a pena sempre ter em mente.

A primeira coisa para se ter cuidado são... typos. É extremamente desestimulante começar a corrigir um teste e ele estar cheio não só de erros de pontuação, como erros de ortografia também. Já cria uma imagem negativa imediata, querendo ou não, porque faz parecer que o teste foi feito sem atenção ou às pressas. A parte mais triste é que isso acontece tanto com novatos — o que é mais ou menos esperado, apesar de ainda ser ruim — como com pessoas com experiência. Alguns typos são esperados, não existe tradução perfeita, e todo mundo comete erros — e às vezes o corretor gramatical falha também — mas aqui eu falo de testes inteiros, com centenas de palavras, contendo erros em praticamente toda linha.

Outro aspecto para se ter atenção é formatação. Tradutor não é designer ou diagramador, mas se alguma palavra ou frase está em negrito, itálico, caixa alta, ou o que quer seja, é por algum motivo, então a tradução deve refletir isso. Em certos casos, quando destaques são usados para dar ênfase, a posição não precisa ser exatamente a mesma, mas isso é algo que vou abordar em uma newsletter diferente. Por ora, basta saber que a formatação de texto na fonte não é arbritrária, então não pode ser ignorada.

Eu diria que estes são os dois aspectos mais "objetivos" que vão ser avaliados em um teste por serem "erros binários", significando que algo ou está certo, ou está errado. Dificilmente vai existir uma terceira interpretação possível para um typo ou formatação incorreta, por exemplo. Embora outros aspectos de um teste também tenham abordagens objetivamente errôneas, já se torna menos comum haver um único tipo de solução "correta". A alternância entre gramática formal e escrita coloquial, por exemplo, vai ser medida de acordo com o contexto — uma conversa entre amigos no mundo moderno usando gramática formal estaria objetivamente errada, mas ao mesmo tempo não há como definir a estrutura ideal para abordar o coloquialismo na escrita.

Enfim, terminologia é o terceiro aspecto para ter atenção. Embora muitos termos usados em videogames não tenham tradução "oficialmente reconhecida", há um consenso no público sobre como algo deve ser chamado. O gênero "RPG" (role-playing game), por exemplo, nunca é traduzido, apesar de ser uma sigla estrangeira. "RTS" (real-time strategy) já possui uma abordagem variável, às vezes mantendo a sigla, às vezes sendo traduzido como "estratégia em tempo real". "Turn-based strategy", por outro lado, pode ter variação na preposição ao ser traduzido — estratégia por/de/em turno(s) — e a preferência de cada pessoa vai ser diferente. Quando se trata de gêneros mais difíceis de traduzir, como "side scroller", a situação começa a ficar complicada. Ou seja: a abordagem indica tanto o nível de familiaridade do tradutor com a área como a capacidade criativa ao lidar com os termos mais complexos. Apesar de ter usado gênero de jogos aqui, isso vale para qualquer coisa: nomes de armas, habilidades, lugares fictícios, etc.

Porém, há um subconjunto de termos que volta a se encaixar em "erros binários": terminologia de plataforma. Cada console possui um conjunto próprio de termos que devem ser seguidos à risca. Caso o jogo esteja utilizando terminologia errada, há perigo dele falhar na certificação da plataforma, potencialmente atrasando o lançamento do jogo ou da tradução. Os termos para os mesmos botões podem ser diferentes para cada plataforma, e esses termos frequentemente não condizem com o uso popular — "analógico direito/esquerdo", por exemplo, não fazia parte do glossário da Sony até pouco tempo atrás, apesar do termo ter se popularizado durante a transição entre o PlayStation 1 e 2. Nesse tipo de caso, o tradutor deve saber a plataforma e utilizar o termo adequado, sem espaço para variação ou adaptação. Lembro de já corrigir testes para agências que enviavam glossários junto, deixavam claro que o glossário era obrigatório, mas os tradutores tratavam apenas como sugestão, às vezes até dizendo que preferiam usar outros termos. Em projetos oficiais, isso é impensável.

Já começa a ficar claro que os testes também avaliam a capacidade de seguir instruções. Sendo um campo complexo e trabalhoso, é extremamente necessário que o tradutor saiba reconhecer quando há abertura criativa e quando não há. Muitas vezes, as ordens vêm de cima, e não há o que fazer além de seguir, mesmo não gostando do resultado.

Alguns testes também gostam de colocar uma seção com uso de tags, que são pequenos pedaços de código indicando variáveis, quebras de texto e coisas assim. Um uso comum para elas, como variáveis, é fazer concordância gramatical de gênero entre palavras ou contextos diferentes, como garantir que um personagem da classe "warrior" vá ser chamado de "guerreiro" ou de "guerreira" em um diálogo ou na interface, seguindo o gênero que o jogador escolheu. Tradutores novatos frequentemente têm dificuldade nessa parte por falta de prática, já que muitas vezes é necessário torcer um pouco a gramática do português ou a construção da frase para criar uma leitura fluida quando a variável for substituída por uma palavra, já dentro do jogo.

Outro uso de tags é para inserir ícones no texto, como os de botões em um menu de configuração ou ícones de recursos em um jogo de estratégia. O problema que as tags causam para novatos é que não existe um formato unificado para elas: cada projeto tem um código-fonte próprio, então é algo que só se aprende ao lidar na prática, após encontrar várias situações diferentes. Particularmente, ao corrigir testes, costumo pegar leve na parte de tags com quem é novato ou iniciante, e peso muito mais a mão quando a pessoa diz ter 7 ou mais anos de experiência com tradução de videogames — nessa altura, lidar com variáveis já deveria ser algo corriqueiro.

Nota: pretendo abordar com mais detalhes em outra newsletter o uso das tags. Vejo muita confusão sobre elas para quem está chegando na área e tem pouca experiência com o aspecto técnico de software/computadores. É algo que vale um mergulho mais cuidadoso e com exemplos.

Eu diria que lidar com terminologia e uso de tags faz parte do conhecimento técnico básico do tradutor. São coisas que exigem um nível de atenção maior aos detalhes e que raramente têm soluções prontas — mesmo a terminologia específica de plataformas exige conferir qual a plataforma, e não dá para memorizar tudo — então um tradutor experiente vai ter maior facilidade ao tomar decisões comparado a um iniciante, mas é uma parte indissociável da tradução de videogame.

A última questão que o tradutor deve ter atenção ao fazer um teste é "estilo". Eu sei que essa palavra é muito utilizada como desculpa genérica e, frequentemente, é má vista, mas é um aspecto importantíssimo porque engloba tanto qualidade de escrita — algo que desenvolvemos escrevendo na língua materna — como expectativas ou adequabilidade do texto ao contexto. Citei alguns parágrafos acima, por exemplo, a questão de usar coloquialismo ao escrever diálogos, e que se eles fossem escritos utilizando a gramática formal do português, estaria errado. Isso é uma questão de estilo, porque a abordagem linguística — português formal — não se encaixa com a que é esperada do contexto — dois amigos, nos dias atuais, conversando. É algo para o qual não existem regras oficiais, propriamente, mas dependem do entendimento sobre o consenso social no uso da linguagem. Por isso, é importante desenvolver o domínio da escrita no português como tradutor, já que apenas ser falante nativo não garante conhecimento crítico adequado sobre o uso de palavras.

Saber disso não ajuda de maneira imediata nos testes, mas indica a importância de ter atenção — e engajar criticamente — textos que vemos no dia a dia, de pensar o motivo de certas coisas serem usadas como são. É importante se perguntar, por exemplo: como são os textos de interface de software? Por que são assim? Como diálogos são escritos? Por qual motivo soam naturais? Quando algo gera estranhamento, por quê? Qual tipo de linguagem difere uma explicação acadêmica e uma explicação popular sobre o mesmo evento? Qual conjugação verbal costuma ser usada em objetivos e missões de videogame? E qual é usada em conquistas? E por aí vai.

Esses tipos de perguntas são relevantes para um tradutor não por darem a resposta do que fazer, mas porque obriga a destrinchar o texto e analisar as partes que compõem o todo. Quando se tem um bom domínio da gramática formal e boa capacidade de interpretar os aspectos que um texto exige em seu contexto, aprendemos a "destruir" a gramática de forma intencional. Durante um teste, pode haver diálogos, pode haver descrições, pode haver menus, e pode haver uma infinidade de misturas de elementos. Saber identificar cada tipo de texto e a linguagem adequada necessária aumenta as chances de acertar o "estilo" esperado por quem preparou o teste.

Digo mais: isso é algo de "alto nível" porque é dependente de todos os elementos anteriores. Usar terminologia incorreta, errar pontuação, não encaixar tags de maneira fluida, escolher substantivos inadequados para termos ou conjugação verbal incomum para a interface, tudo isso afeta o "estilo" de certa forma porque quebra a leitura, tira a imersão do jogador e, muitas vezes, faz a leitura parecer uma "tradução" em vez de um texto nativo — que é o objetivo máximo do trabalho.

Porém, o Brasil é um país gigante, há diversos regionalismos e, dentro da mesma cidade, as pessoas de bairros diferentes podem falar de maneiras diferentes. Por isso, também é importante deixar comentários. Ao comentar sua tradução, convém avaliar se há variações comuns para a solução que você tomou e contextualizar o motivo da escolha como, por exemplo, o motivo de usar "senhora" em vez de "madame" para uma personagem que é chamada de "madam". Caso tenha desviado demais do source, mas conseguido manter o sentido original — tipo traduzir "she's got a lot of heart" como "ela é muito carinhosa" — vale a pena apontar isso e dizer "tomei essa decisão por causa de <motivo X>". Não é preciso escrever um livro justificando o que fez, mas pequenas sinalizações de que "saiu do padrão" por algum motivo, e que é capaz de justificar esse motivo, fazem muita diferença e dão um grande insight no processo lógico que o tradutor seguiu.

Exemplificando o que falei, basta olhar a palavra "vâmo": essa palavra, com essa grafia, é frequentemente usada quando algum personagem tem um sotaque muito carregado. Nesse caso, há a escolha de fazer referência ao sotaque caipira removendo o marcador de plural -s, um aspecto regional muito comum. Porém, apenas escrever "vamo" faz parecer que houve um typo e a letra "s" não saiu. Fora isso, acentuar a primeira sílaba é gramaticalmente incorreto, mas serve para sinalizar que a falta do -s é intencional. Ainda assim, nem todo mundo pode ligar os pontos, então colocar um comentário dizendo algo tipo "estou referenciando o sotaque caipira, o acento circunflexo errado é para indicar que não é typo e para dar ênfase, a palavra foi escrita assim de propósito" não só explica a tomada de decisão, como já remove a necessidade de justificar outras palavras modificadas para manter o sotaque consistente.

Dito isso, estes elementos só carregam todo esse peso quando os testes são de "alta qualidade", ou seja, testes em que o tradutor tem alguns dias para fazer, pode deixar comentários, tem glossário e, idealmente, pode tirar dúvidas. Isso não é indicador de qualidade propriamente, mas sim que o teste foi feito com cuidado e pensando nas necessidades que o tradutor vai ter durante o processo. O teste em si não vai medir a qualidade do tradutor, mas sim o quão próximo ele chega do que a empresa espera. Como não existe padronização de avaliação — algo impossível de existir, na verdade — é importante o tradutor saber reconhecer, ao ver o teste, o que é esperado dele.

Já falei no passado que todo projeto é único, não existe solução generalizada para problemas tradutórios, e o mesmo vale aqui: testes também são únicos, e cabe ao tradutor se adaptar ao que é exigido, mesmo sem ter todas as informações em mãos. Por exemplo, em testes de "baixa qualidade" — aqueles em que temos apenas algumas horas para fazer e entregar, e que não há espaço para comentar ou tirar dúvidas — a criatividade frequentemente é punida, não recompensada, então a abordagem mais adequada é seguir a tradução mais "padrão" e sem sal possível, algo comum em empresas com um toque mais "corporativo", mais rígido.

Falar assim parece contradizer toda a parede de texto que escrevi anteriormente, mas se encaixa na questão de "reconhecer contexto e tomar a atitude adequada para ele". Tradução é trabalho, e nem todo trabalho vai ter cliente com grande toque artístico e que admira criatividade — há clientes que não se importam com isso e apenas querem o texto de volta no prazo, esperando que não desvie demais do que é "padronizado" (com aspas bem fortes).

Adaptação é uma habilidade essencial para um tradutor. De certa forma, saber como abordar um teste já coloca ela à prova.

Testes como avaliador

O lado do avaliador é um tanto complicado, eu diria, mas mais por motivos éticos do que práticos. Para mim, pelo menos, é uma responsabilidade muito grande definir se alguém está apto ou não para receber trabalho. Em todo teste que corrigi ao longo da carreira, sempre fiz o possível para deixar feedbacks extensos (e sei que não sou o único avaliador fazendo isso) justamente porque, em caso de rejeição, eu quero que a pessoa saiba o que precisa melhorar para quando for tentar de novo.

Em um mundo ideal, quero que mais tradutores tenham trabalho, mas aprovar alguém que não sabe exatamente o que está fazendo, ou que não consegue se adaptar à demanda, pode descarrilhar um projeto inteiro ou sobrecarregar o resto da equipe, e nem sempre vai haver tempo de explicar e ensinar. Isso não significa que apenas pessoas com experiência prévia são aprovadas — como falei, há muitos casos de pessoas com experiência que cometem erros básicos — mas sim que é necessário ter as habilidades adequadas para se tornar um bom tradutor. Ao longo dos anos, já vi muita gente sem experiência alguma — muitas vezes, sem sequer ter curso de tradução — sendo aprovada e, em pouco tempo, sendo alocada para projetos de maior demanda, onde há menos tempo para supervisão e feedback. É por isso que, ao corrigir um teste, é importante não só conferir os erros, mas avaliar "potencial".

Potencial é outra palavra com carga altamente subjetiva, mas aqui eu trato de ela de uma maneira mais direta: averiguar os tipos de erros que acontecem, a frequência deles, conferir as justificativas ou a lógica que o tradutor seguiu em aspectos criativos e, caso esteja repetindo o teste, ver se aplicou o feedback que recebeu no passado. Só saber o idioma-fonte não basta, só saber usar o glossário bem não basta, só dominar estilo para certos tipos de conteúdo não basta: é preciso ver se o tradutor consegue mesclar bem todas essas habilidades, mesmo que falhe às vezes em atingir o patamar adequado. É preciso saber avaliar os motivos de uma tradução não ter ficado boa e, a partir daí, tentar concluir se isso é apenas falta de conhecimento, ou se é uma habilidade não relacionada à tradução que ainda não foi desenvolvida o suficiente.

Falando assim, parece muito abstrato, então vou tentar ser direto: muitas rejeições são resultado de tradutores que escrevem mal. Dá para notar que entendem o sentido das frases no idioma-fonte, que conhecem a terminologia, às vezes até sabem usar bem as tags, mas o texto traduzido é muito literal, ou muito truncado, ou a abordagem não se adequa ao contexto, ou o estilo varia entre sentenças dentro da mesma frase. São problemas de alta complexidade, que exigiria um longo período de treinamento para compensar.

Por outro lado, muitas das aprovações, mesmo de novatos, são pessoas que escrevem bem. Mesmo que não saibam usar tags corretamente, ou que se enganem com a terminologia às vezes, ou até mesmo errem termos não oficiais já sedimentados, se as frases fluem bem, se são agradáveis de ler, se o estilo é adequado, nota-se que é possível trabalhar mais facilmente os aspectos mais fracos, que são "técnicos".

Acho que foi Mark Ferrari, um artista que trabalhou em diversos jogos clássicos da LucasArts, que falou (parafraseando): "Fui contratado porque consideraram que era mais fácil ensinar um artista a programar do que ensinar um programador a desenhar". É a mesma situação aqui: é muito mais fácil ensinar os aspectos técnicos para alguém que já é bom escritor do que ensinar um mau escritor, mas que conhece bem a parte técnica, a escrever melhor. Não é que uma pessoa tem potencial e outra não — tem gente que escreve bem e acaba nunca desenvolvendo o lado técnico, por exemplo — mas é que o potencial de uma pessoa pode ser atingido mais rápido do que de outra, algo importante em um mundo de prazos curtos onde estão todos correndo contra o tempo.

Sei que falar dessa forma faz parecer um jogo de apostas, mas por isso é essencial dar feedback nos testes, especialmente para quem foi rejeitado: é impossível esperar que alguém melhore ou evolua profissionalmente se ninguém diz o quê melhorar ou como melhorar. Apenas assim é possível tentar equilibrar a balança para que todo mundo tenha uma chance. É cruel responder alguém apenas com as palavras "rejeitado" e acho que, no papel de avaliador, as pessoas merecem um pouco mais de dignidade que isso.

Outra questão importante, como avaliador, é tentar ser imparcial. Nunca vai ser completamente possível evitar viéses, mas há passos que podemos tomar para reduzir isso, o mais comum sendo anonimizar testes, garantindo que até o gênero da pessoa não influencie o rigor da correção. Em casos onde os testes não são anônimos, o ideal é evitar corrigir aqueles de pessoas que conhece ou de quem já tem alguma opinião formada, mesmo que mal tenha interagido com ela. Eu já rejeitei corrigir testes de pessoas que reconheci os nomes de breves interações em grupos de Facebook, por exemplo. E mesmo durante a correção, é importante o avaliador questionar se está formando alguma imagem ou opinião sobre o tradutor, e então verificar se a forma que está abordando algum tipo de erro está sendo consistente com a forma que abordou os mesmos problemas em outros testes.

Agora, um ponto que acho problemático é a inclusão de "pegadinhas". Embora seja comum haver erros em projetos do "mundo real", inserir um erro proposital é um tanto... manipulativo, eu diria. O tradutor já está tendo sua capacidade testada, testar ele de novo dentro do teste é como procurar justificativas para rejeitar alguém. Ninguém faz uma prova na escola ou na faculdade esperando que o professor tenha colocado erros de propósito só para ver quais alunos caem, e isso não deveria acontecer em ambiente profissional também. Em um teste realizado para conseguir trabalho, isso não só pode gerar confusão, como quebra um possível elo de confiança que o tradutor formaria com a empresa e o avaliador. Afinal, como confiar em alguém que preparou um teste esperando que falhasse nele?

No mais, acho que o último aspecto que o avaliador deve levar em consideração — se indicado — é tempo de experiência. Geralmente, novatos e pessoas entrando na área são muito mais rígidos na tradução, muito mais travados, porque ainda não possuem a experiência para lidar com as expectativas do empregador e a confiança para defender as próprias decisões. Não sabem ainda quanta liberdade podem tomar com o texto, e onde devem restringir esse aspecto. Em suma: falta conhecimento prático. Nestes casos, mesmo que haja uma rejeição, acho que é de bom gosto pegar leve no feedback, sendo menos ríspido e mais detalhado — pelo menos, é assim que eu gostaria de ser tratado no meu início de carreira. Caso seja uma aprovação, convém ainda informar quais áreas a pessoa pode melhorar, além do que vai ser esperado dela em projetos sérios, já que ela pode não fazer ideia do que vem pela frente.

Conclusão

Testes são chatos e estão longe de serem a forma ideal avaliar um tradutor, mas cumprem um trabalho decente em conferir as aptidões de cada um, além de nivelar a entrada no mercado e permitir que, em vários casos, novatos compitam em pé de igualdade com pessoas mais experientes. Fora isso, permitem que empresas diferentes avaliem habilidades diferentes de acordo com o que buscam.

Outro lado menos comentado é a dificuldade em definir aspectos autorais em projetos já lançados para avaliar habilidades. Mesmo se tornando mais frequente os tradutores aparecerem nos créditos, qualquer projeto sempre vai envolver, no mínimo, de 2 a 4 pessoas — tradutor, revisor, especialista em LQA e gerente de projeto — que podem influenciar a qualidade. Há casos em que o tradutor faz um bom trabalho e o revisor mal precisa mexer no texto; há casos em que o revisor precisa ajustar várias coisas porque o tradutor não trabalhou muito bem; há casos em que o LQA reescreve muito da tradução; e há casos em que o gerente de projeto mal toca no projeto em si, e o bom resultado é devido apenas ao esforço dos tradutores em conjunto. Não dá para quantificar a participação de cada um e, simplesmente olhando no portfólio, saber se alguém se encaixa bem no que está sendo procurado.

Para explicar o ponto acima, vou dar um exemplo: até onde eu sei, fui o primeiro tradutor a pegar a música da Priscilla, em The Witcher 3, para traduzir. Porém, sei que a música dela passou pelas mãos de mais dois tradutores em momentos diferentes, e depois pela revisão, dublagem e LQA. Eu não sei dizer o quanto do meu trabalho original ainda está ali, ou se alguma possível modificação foi inspirada pelo que eu traduzi ou se foi obra original de outro tradutor. Fora isso, a vida que as linhas ganharam na voz da dubladora também não estavam sob meu controle. E, apesar de tudo, se for para trabalhar com rimas e ritmo, consigo pensar em umas duas pessoas que dominam essa arte melhor que eu. Não significa que sou ruim mas, sem um teste com poema, por exemplo, essas duas pessoas teriam chances menores do que eu pelo simples fato de que eu tenho um projeto de peso no portfólio e elas, não, apesar de serem tão competentes quanto eu.

Não me entendam mal, não significa que portfólio é inútil, mas ao avaliar a competência em áreas diferentes de pessoas que você não conhece, ele não indica muita coisa. Não é como um livro, uma música, ou uma obra de arte, onde é refinada pelo próprio criador antes de chegar aos passos seguintes, onde dá para apontar e dizer "eu que fiz". Tradução de videogame é, querendo ou não, um trabalho altamente colaborativo, com todos os positivos e negativos que isso traz.

O maior problema, porém, continua sendo a inerente subjetividade da área e o possível viés que sofremos ao avaliar. Boas explicações sobre as decisões tomadas e feedbacks detalhados ajudam a reduzir estes efeitos ou, pelo menos, tornar eles menos injustos. Quanto menos "caixa-preta" forem as expectativas de um teste, melhor é o resultado para todos os envolvidos.

Novatos e iniciantes também têm mais chances de conseguir trabalho graças aos testes. Uma das formas que considero mais "fáceis" de começar é justamente enviando currículo para agências e fazendo testes. Vale dizer que existem muitas agências abusivas ou que pagam pouco por aí, então embora sejam experiências válidas para dar os primeiros passos na área, é importante saber quando partir em busca de pastos mais verdes.

E por fim, vale repetir algo que já falei: testes não definem o valor do tradutor como profissional. Eles servem como métodos avaliadores, sim, mas eles não indicam quem é o "melhor". Não existe ranking de tradução, não existe competição com parâmetros oficiais e objetivos, só existe "é isso aqui que eu tô procurando e aquele tradutor se encaixa". Sofrer rejeição não significa que é um mau profissional, e ser aceito não significa que não tenha nada a melhorar.

Post scriptum

Acredito que minha posição tenha ficado clara. Tentei destacar quais aspectos costumam ser importantes em um teste, tanto na posição de tradutor como de avaliador, mas muita coisa sempre vai depender de quem está envolvido e do comprometimento de cada parte. Espero, pelo menos, ter desmistificado um pouco o funcionamento e o motivo de testes existirem. Como sempre falo, essa é a perspectiva de uma pessoa só, e meu objetivo não foi fazer ninguém mudar de opinião, mas só comentar sobre como lidar com essa realidade da área.

A próxima newsletter sai dia 2 de novembro. Ainda estou incerto sobre o tema, mas penso em talvez algo mais prático, relacionado ao ato de traduzir, para quebrar a monotonia de falar só teorias e questões organizacionais. Vou ver quais ideias surgem ao longo do mês.

Até lá.