Re: Fwd: Revisão (Revisão precisa de revisão :-))
Olá pessoal!
De fato: a lista lista de internacionalização do Debian --
debian-i18n-portuguese -- é o melhor local para esse tipo de discussão.
Quem não estiver aderido a esta lista, é convidado a fazê-lo...
Caso alguém não saiba, i18n é a forma prática e americana de dizer
"internationalization", que para o padrão deles é uma palavra imensa de
grande. Por isso, dizem: uma palavra começada por "i", seguida de 18
letras, e terminada por "n". :-)
Quanto aos elogios: KoV, penso que quem trabalha merece, pelo menos,
elogios. Pelo menos... Essa coisa de mudar o mundo é interessante e
merecia ser melhor comentada. Um dia desses.
Penso que pelo fato de ser voluntário para a maioria de nós, o trabalho
em Software Livre não deve ser considerado menos seriamente que o
trabalho remunerado. Existem softwares excelentes por aí, como
(x)emacs, vim, PostgreSQL -- sem falar no Debian, é claro --, que o
pessoal desenvolveu em base voluntária. E quem quiser trabalhar nesse
negócio tem que manter o padrão.
Contudo, a realidade do mundo está aí: vocês que são estudantes ainda
não tem isso pela frente, mas quem está formado -- principalmente se
trabalhar remuneradamente em desenvolvimento -- de vez em quando tem
umas brabeiras pela frente. Tão pesadas que não dá tempo nem de ir no
dentista. Parece engraçado, mas não é.
O pior de tudo é quando, devido a uma coisa dessas, a gente tem de
parar um trabalho voluntário. Duplamente chato: a pessoa fica com má
fama, e o trabalho não é feito.
Esse tipo de coisa é inevitável: mesmo na história do Debian, de vez
em quando alguns caras têm de dar um tempo na atividade do Debian:
somem de listas, suas atividades empacam, seus pacotes chegam a se
atrasar. Muitos voltam, pois o Debian parece algo viciante. :-)
No caso do Debian, é claro que a coisa não para porque tem mais gente
trabalhando e, acima de tudo, tem uma estrutura que pode repor (na
maioria das vezes) quase que automaticamente o trabalho dessas pessoas
que tiveram de dar um tempo. Sem que sejam necessários grandes acordos
ou negociações. Por exemplo, o NMU (Non Maintainer Upload), no qual
alguém que não o mantenedor do pacote, envia nova versão de um pacote a
seu mantenedor oficial. Que então tem apenas de revisar o pacote e
torná-lo disponível aos usuários do Debian.
É algo semelhante a isso que proponho para nossas traduções e revisões.
Não tenho muito claro, e gostaria de discutir essa estrutura. Penso
que CVS é uma ferramenta fantástica, e o Laviola um supertécnico.
Contudo, antes do CVS deve vir um tanto de conversa: nenhuma
ferramenta, por melhor que seja, pode ser usada de forma adequada se
não tivermos claro o que estamos fazendo.
Talvez o KoV, ou outra pessoa que tenha mais informações sobre o
Debian, possa comentar sobre a estrutura do Debian, para que a gente a
copie... digo, para que a gente se inspire nela. ;-)
Do meu lado, trabalhei um tanto como tradutor e revisor,
remuneradamente ou não. Por isso, posso -- modéstia às favas ;-)
--falar um pouco sobre como funciona o trabalho de tradução/revisão por
aí, e naturalmente, fazer uma proposta de como penso que este trabalho
deva funcionar. É o que faço em texto anexo, para que este email não
fique mais longo ainda.
Minha proposta é que a gente comece agora nesta lista -- com cópia para
a debian-users-portuguese -- o passo 0) da proposta em anexo: a
construção de uma tabela de equivalência, onde de um lado está o
original em inglês, e do outro o que decidimos adotar em português.
Também será interessante um glossário, principalmente de termos do
"debianês", a gíria dos projetos Debian ou GNU.
Tenho certeza de que vai ser agradável e produtivo trabalharmos todos
juntos.
[]s, Hilton
P.S.: morei três anos em Salvador, trabalhando no antigo Banco
Econômico; achei os programadores baianos muito bons. Como já trabalhei
no Brasil todo, esse elogio vale alguma coisa. :-)
Gosto também do jeitão mineiro: apesar de não ter tido colegas
programadores em MG, os clientes eram muito exigentes mas sempre
mantiveram com minha equipe uma relação pessoal muito boa e tranqüila.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
---------------------------------------------------------------------
Proposta de trabalho de tradução e revisão para o Debian-Br -- v. 0.5
---------------------------------------------------------------------
H. Fernandes
Como é feita a tradução comercial, hoje
---------------------------------------
Nas casas de tradução onde trabalhei, um texto era dividido entre
vários tradutores que em geral nem se conheciam, e eram coordenados
por um revisor.
Junto com a tradução o revisor fornece um "glossário" -- na verdade
uma tabela de equivalência: termos em lingua estrangeira vs. termos
correspondentes em português.
Todo mundo sabe que poucas palavras técnicas de informática têm
tradução bem definida em português do Brasil. Os lusos estão bem
melhor que a gente nesse ponto. Para eles, "boot" é "arranque".
Para nós, já vi "inicialização", "disparo" e até mesmo "boot". Sem
falar em "to delete", que todos nós falamos "deletar", mesmo
existindo "apagar". A tabela de equivalência, ou "glossário"
informa qual das diversas alternativas será adotada.
Tendo esse glossário em mãos, o tradutor batalha o texto.
(Quem usa GNU/Linux pode facilmente fazer um script para sed, e já
substituir a maior parte das equivalências do "glossário". Isso
porque recebemos os documentos em modo texto: SGML, LaTeX etc. Se
viessem em algum formato binário, tipo o do M$ Word, a coisa ficaria
um pouquinho mais complicada... Mas não impossível: pode-se
traduzir .doc para RTF (que é texto) sem perda de formatação.)
Depois do término da tradução, o revisor lê o texto traduzido. Sua
missão:
1) verificar se o texto original foi traduzido corretamente,
inclusive se todos parágrafos foram traduzidos -- às vezes o tradutor
"dá uma dormida" e "come" alguns parágrafos;
2) verificar se as equivalências do glossário foram respeitadas -- se
o glossário adotar "deletar" como equivalência de "to delete" e o
tradutor usar "apagar", isto é considerado erro. O revisor deve
corrigir.
Nas editoras de livros, depois da revisão gramatical, o texto vai para
um "copydesk", que é o cara que verifica se o português parece de
"gente". É que quando a gente traduz, é comum manter a estrutura
gramatical do inglês, e criar construções que ninguém fala em
português. O "copydesk" tenta reescrever o texto para que fique mais
claro e de leitura mais agradável.
Depois da revisão e do eventual "copydesk", o texto vai para um revisor
técnico, que aponta trechos onde a tradução violou conceitos técnicos,
tanto por traduzir errado, quanto por usar termos técnicos errados.
Por exemplo, as palavras em inglês "file" e "archive" podem ter o mesmo
significado no dia-a-dia, mas como termos técnicos têm significado
diferente: "archive" significa um "arquivo de arquivos", como um tar, ou
um arquivo de ZIP..
Em português de Portugual, "file" é "ficheiro", e "archive"
é "arquivo". No Brasil, "file" é "arquivo" e "archive" -- até onde eu
saiba --, não tem uma tradução padronizada. Grandes portugas...
Em casas de tradução, o revisor gramatical e o revisor técnico
trabalham por amostragem, revisando apenas alguns trechos sorteados.
É que é tudo muito rápido e não há tempo para grandes cuidados. Os
melhores revisores comerciais usam um critério de erro: para cada
erro grave encontrado em um trecho, o revisor seleciona outro trecho
para revisar.
Proposta para Debian-Br
-----------------------
0) criação da tabela de equivalência e glossário:
a tabela de equivalências deve ser padronizada para todo o Debian-Br,
e ficar disponível em uma página do site Debian-Br. Essas expressões
devem ser adotadas depois de uma discussão ampla com a comunidade.
Como nem todo mundo é especialista em tudo, é interessante juntar à
tabela de equivalências um glossário de verdade, com explicações sobre
termos técnicos menos comuns, e também sobre siglas e conceitos do
Debian: NMU, WNPP, ITP etc. Conceitos do GNU, como GPL, LGPL,
FDL etc. também devem ser considerados.
1) criação da equipe de revisão/coordenação:
a revisão/coordenação não deve, idealmente, ser feita por uma única
pessoa, mas um grupo, eventualmente pequeno, de pessoas que se
responsabilizarão pela tradução, em termos de organização. Suas
tarefas no momento inicial:
a) ler o texto, ou partes dele e identificar termos técnicos que ainda
não estejam na tabela de equivalência ou no glossário. Fazem uma
proposta de adição e colocam para a comunidade. Isto significa uma
chamada ao passo 0).
b) traduzem umas poucas páginas do documento à guisa de exemplo, e as
inserem em àrea comum (CVS?) à disposição dos possíveis tradutores;
c) dividem os textos em blocos: unidades convenientes, que contenham,
sem quebras, um único assunto. Deste modo, os tradutores vão poder
ler um texto com sentido antes de traduzir;
d) oferecem o texto nas listas para os tradutores potenciais.
Proposta: uma chamada curta na debian-users-portuguese, uma chamada
mais detalhada na debian-i18n-portuguese e as duas coisas no site.
Tipo uma página com todas chamadas para tradução, cada uma descrita
em pouco detalhe, e para cada tradução uma página específica, com
detalhes do que vai ser traduzido, divisão do documento em blocos
etc.
2) candidatura de tradução:
os tradutores se candidatam, já escolhendo um ou mais blocos. Para
evitar que os coordenadores/revisores se alienem do texto, seria
interessante que também traduzissem um ou mais blocos de texto.
DÚVIDA: Se houver um número de tradutores maior do que o número de
blocos o que fazer? Subdividir o trecho????
3) ciclo de tradução:
os tradutores começam o trabalho e vão atualizando a versão (no CVS?)
à medida que traduzem. Deste modo, os revisores podem acompanhar a
tradução. Dúvidas são comunicadas por email. É interessante que o
mesmo texto possa ser revisto por mais de uma pessoa.
Em princípio, para evitar tráfego na lista, os emails se limitam ao grupo
de tradução. Apenas dúvidas maiores vão para a lista debian-i18n-portuguese,
ou até mesmo para a lista debian-users-portuguese.
4) Estágio de RFC:
Graças ao fato da tradução ser incremental, e ao fato de que as pessoas
envolvidas são também técnicos, não deve ser necessário nem o passo de
"copydesk" ou revisão técnica. Contudo, depois de pronto, o documento
deve ficar em um passo intermediário, de RFC (Request For Comments).
Esse passo pode ser mais importante se na equipe de tradução as pessoas
não se sentirem à vontade com o assunto técnico do documento. Contudo,
dúvidas pontuais podem ser discutidas nas listas durante a tradução.
O passo 3), é onde fica a maior parte do trabalho. Nele, principalmente,
é que devem estar os maiores conflitos: de formas de tradução de um mesmo
texto ou termo, e de prazo, prazo, prazo.
Talvez em uma tradução haja termos específicos que não compense
manter na tabela global de equivalências, para evitar que ela cresça
desnecessariamente. A idéia então será ter tabelas locais.
De qualquer modo, para facilitar a manutenção das traduções, compensa
arquivar junto com o texto -- mesmo que não anexe a ele -- a tabela de
equivalência usada. Como pode ocorrer do original se perder, melhor
mantê-lo junto com o texto traduzido.
Reply to: