-
Notifications
You must be signed in to change notification settings - Fork 11
Guia de tradução e estilo
*** texto prévio / primeira escrita ***
Sintam-se a vontade para discutir e alterar o texto.
A tradução de um manual envolve bem mais que a mera transformação. É preciso um tanto de sensibilidade estética para produzir um bom texto, ainda que o texto produzido seja parte de uma tradução que guarda grande sincronia com o texto original, que é o caso do Manual do PHP.
Abaixo algumas indicações de como lidar com o texto de uma forma consistente.
Nomes de parâmetros não devem ser traduzidos no <methodsynopsis>. A razões para isso são eminentemente técnicas:
-
Mensagens de erro vão mencionar os parâmetros com o nome original, o que causa confusão quando consultando o manual aquele parâmetro não se encontra presente.
-
Está em discussão a possibilidade do PHP aceitar parâmetros nomeados, ou seja, a habilidade de passar parâmetros através de seus nomes em vez de sua posição. Novamente será utilizado nesse caso o nome original, não importa o que diga o manual traduzido.
Porém o texto que explica os parâmetros podem traduzi-los, ou até mesmo os explicar longamente, mesmo que não exista tal texto no original.
Em informática há muitos termos que, embora tenham tradução para Português do Brasil, são comumente utilizados na forma original. Principalmente siglas, mas também conceitos e produtos. Termos que tenham uso comum em Inglês (ou outra língua) podem ser mantidos no original, talvez recebendo uma rápida e informal tradução entre parenteses.
Há o caso oposto no entanto, em que termos não tem tradução em Português por serem pouco utilizados. Esses termos merecem uma tradução (ou uma explicação curta) que substitua uma palavra potencialmente desconhecida do público iniciante em informática.
Na parte final do guia há uma lista de expressões dos casos que geraram discussões em momentos anteriores, com suas respectivas argumentações e sugestões de tratamento.
Termos ou conceitos comuns, que tenham palavras normalmente utilizadas em português aparecerão bastante no manual. Tanto no texto livre, tanto em código ou referenciando código. Preferir traduzir os termos quando no meio de texto livre, mas manter os termos no original quando se tratando de código ou referência de código.
Isso ajuda o texto livre manter o poder explanatório, mas também cria uma distinção bem clara entre texto e código, que ajuda o leitor a diferenciar o que é conceito de código.
O manual é rico de exemplos em código, e isso traz uma questão: traduzir ou não o código?
Via de regra é indicado que comentários do código sejam traduzidos, mas a tradução do código em si vai depender. Sendo um código curto, localizado, é até possível de traduzir o código (nomes de classes, variáveis e valores). No entanto, isso obriga o tradutor a testar o código. Nada de mexer em código e subir sem testar!
Código longo, que seja utilizado ou referenciado ao longo de um texto, a sugestão é de não traduzir. O esforço de manter um longo trecho de código "funcionando" é tão grande ou maior que o esforço de traduzir o texto. Com a diferença que texto não "quebra". Mas pequenas alterações que pareçam cosméticas tem grande potencial de inserir bugs no código traduzido, que sejam muito difíceis de detectar. E um código grande no manual tem tanta probabilidade de ser revisado quanto o texto do manual, dificultando a manutenção da corretude-consistência do código e seus resultados.
-
haystack - Geralmente aparece no contexto de funções que fazem busca. Se traduz literalmente como palheiro (como em "buscando uma agulha em um palheiro"). Não há tradução simples para esse termo. Dependendo do contexto pode ser utilizado expressões que denotem conjunto, coleção. Uma solução alternativa é traduzir, dando a função:
haystack (palheiro, onde pesquisar), desde que tal explicação já não ocorra em algum frase subjacente ao termo. -
needle - Agulha, valor, item, o que pesquisar. Ver haystack.
-
threaded MPM - Manter no original. Termo muito específico/sem uso/outros materiais não traduzem.
-
user-land - Termo muito específico/sem uso/outros materiais não traduzem. Porém tem um sentido mais comum, diferenciando "espaço do kernel" do "espaço do usuário", esse último a tradução mais próxima de user-land. Porém no PHP tem um sentido diferente, geralmente significando "fora do espaço do interpretador do PHP". A sugestão é usar a expressão ao invés do termo. Ainda que mais comprido, transmite o sentido original. Se o termo aparecer muitas vezes num texto, use a expressão maior, seguida do termo original entre parênteses e aspas, para depois usar o termo explicado pelo resto do arquivo.
Ficou com dúvida em algum termo? Põe ele em discussão na lista/chat, para assim incrementar o dicionário padronizado.
Tente manter o número de linhas igual, entre arquivo original e traduzido, assim como a "proximidade" das tags utilizadas em cada arquivo.
Isso vai parecer ir contra os conselhos acima, de fazer uma tradução mais semântica que literal. Mas é um conselho que economiza muito esforço, principalmente em arquivos grandes.
Arquivos grandes são mexidos com grande frequência, mas quase sempre com alterações pontuais. Se o arquivo traduzido guardar grande semelhança de número de linhas e de disposição do texto nas linhas, o esforço de atualização será muito reduzido.
Mas o maior valor de manter essa "compatibilidade binária" é a possibilidade de fazer a tradução com os dois textos, original e tradução, lado a lado. É muito mais simples traduzir textos que tenham a mesma estrutura e a mesma altura. Novamente isso não significa fazer tradução literal, dado que as línguas usam construções diferentes, e portanto o texto traduzido deve ficar diferente.
O resultado mais provável de manter as quantidade de linhas iguais é que a tradução terá linhas mais compridas que o texto em inglês, violando o limite normal de 78 colunas, utilizado em todo o manual. É tecnicamente feito, mas compensa em muito o esforço de sincronizar o manual, depois.