[Kde-i18n-pt_br] Atividades do Lakademy

Quinta Maio 26 21:07:51 UTC 2016

Em quinta-feira, 26 de maio de 2016, às 16:58:50 BRT, Frederico Goncalves Guimaraes escreveu:
> Olá André e demais,

Olá Fred.

Estava escrevendo uma resposta para a Aracele, mas vou aproveitar a sua para também comentar o que você disse.
> 
> Em Thu, 26 May 2016 16:16:20 -0300
> André Marcelo Alvarenga <andrealvarenga em gmx.net> escreveu:
> 
> > Quanto à revisão do glossário, sem possível, apresentem uma relação
> > com as mudanças que forem feitas. Isso facilitará bastante, pelo
> > menos para mim, pois dificilmente faço consultas ao glossário. Depois
> > de tanto tempo traduzindo, a maioria dos termos já estão na memória :)
> 
> Esse é o problema. As coisas estão na SUA memória.  :-) E só você tem
> acesso à ela.  ;-)
Concordo que não é a melhor forma de armazenamento, até porque minha memória falha às vezes. :)
O motivo de eu não consultar periodicamente um glossário é porque já estou há muito tempo fazendo traduções para o KDE. A maioria dos termos eu já sei qual é a tradução, sem necessidade de consulta. Quando faço traduções de outros projetos, preciso me familiarizar com as características desse projeto antes de fazer alterações.

Quanto ao vocabulário único, entendo que é relevante e necessário, mas o mais importante é que coisas/funções/ações, enfim, qualquer coisa que seja única, deverá ter a mesma tradução, independentemente se usam um termo definido no vocabulário ou não.

Isso não se consegue de uma hora para outra. Uma pessoa por mais que conheça o idioma original e possa fazer uma boa tradução, precisa estar ambientado com o contexto em que está fazendo, ou seja, deve se familiarizar com os termos que está usando em determinado programa ou até mesmo no ambiente completo. Não que isso vá impedir o entendimento, mas com certeza ficará algo inconsistente.
> 
> A ideia é criarmos uma "memória coletiva", de forma que possamos ter
> uma consistência de termos entre todos os programas. Citando um exemplo
> hipotético, imagine o termo "delete". Alguns traduzem como "apagar"
> outros como "excluir". A ideia é padronizarmos isso e todos traduzirem
> como, por exemplo, "excluir".
Esse era o termo que eu justamente ia usar como exemplo.
É comum ver traduções como "remover", "excluir" ou "apagar".
Qual critério eu uso (não estou falando aqui em MINHA memória, mas no que um tradutor deveria ter em mente)?
Bom... Depende do contexto: Para operações com arquivos, sempre uso "excluir" (normalmente a string original é "delete"). Mas porque não "remover" ou "apagar"? Simples, por consistência e padronização.  A maioria do sistemas operacionais, programas e ambientes de trabalho já usam esta tradução. Mesmo que a string original seja "remove", a tradução será "excluir". O ideal, neste caso, seria a solicitação de alteração da string original, mas este processo pode ser muito demorado e nem sempre tem a atenção devida dos desenvolvedores, o que não impede o cadastramento do bug, claro. Mesmo assim, a correção desse problema da string original pode e deve ser corrigida no processo de tradução e marcada com uma nota. A nota é necessária porque nem sempre o contexto fica explícito na string.
Pode parecer estranho mas a string original pode estar errada! E assim ela estará se não atender a um contexto global e específico do programa/ambiente.
Então a pergunta. Se o programador não se convencer disso, devemos manter uma tradução inconsistente? Entendo que não, porque o processo de tradução, embora deva manter as características originais da string, deverá também atender a outras questões, como tamanho da string traduzida (que as vezes é necessário suprimir termos ou abreviar para que caiba na interface) ou até mesmo a modificação na própria tradução. E isso só será alcançado com a revisão das traduções, não em relação a um vocabulário, mas na própria interface. 

Uma outra questão é que devemos ter certeza que coisas/funções/ações que sejam iguais em sua funcionalidade devam ter uma mesma tradução, independentemente se usam a tradução diferente do vocabulário ou até mesmo em relação à string original. Exemplo: a Lixeira do Plasma. Esse termo já foi objeto de discussão nesta lista e também no desenvolvimento dos programas. Naquela época era usado "trash", "trash bin", entre outros, para se referir a mesma coisa. A Lixeira. Então devemos usar "Lixeira" para todos os casos. Hoje isso já foi mais padronizado nas strings originais.

Mais uma questão é a tradução dos manuais. Ler manuais já é algo cansativo por si só, mas alguns deles é realmente um exercício mental. Até cansa. Isso porque a tradução foi feita "em função do vocabulário". Para traduzir um manual adequadamente, às vezes, incluir/remover palavras ou explicações, de forma que a leitura fique fluida, mas que mantenha a ideia original da string.

> 
> Pra isso, estamos pensando em usar o glossário que já está disponível
> no subversion do KDE. Ele já possui uma série de termos, mas é um
> glossário e não uma memória de tradução. Isso significa que ele possui
> a tradução, mas também uma contextualização. Por exemplo, lá existe o
> termo "100BaseT", que ao invés de simplesmente estar traduzido do mesmo
> jeito (pois é um termo técnico), tem a explicação disso, que é "Fast
> Ethernet 100 Mbps". A ideia é termos a tradução lá, mas manter os
> contextos, caso ele exista. Mas vamos amadurecer essa ideia e publicar
> mais detalhes ao final do evento.
Para um manual ou explicação eu concordo com isso, mas nem sempre pode ser usada por causa do tamanho.
Até pode ser usada por extenso, mas devemos nos certificar de que isso não vai comprometer sua legibilidade na interface. Às vezes também há uma "tooltip" explicando mais detalhadamente uma sigla ou termo técnico. Acredito que este seja o local mais adequado.

> 
> > Uma área que está merecendo atenção é a revisão dos manuais. De vez
> > em quando eu pego um ou outro para revisar, normalmente dos
> > principais programas, mas ainda há muita coisa a fazer.
> 
> Sim, concordo. É algo que precisamos cuidar com mais carinho.
> 
> > Antes de alterar a tradução existente, verifiquem se não existe uma
> > "nota" explicando porque a tradução está diferente do que normalmente
> > seria. Durante as revisões, eu costumo fazer essas notas para evitar
> > que sejam alteradas novamente para a forma incorreta ou menos
> > adequada. Essas notas podem ser vistas no campo "Metadados da
> > unidade" no Lokalize.
> 
> Eu tenho uma certa restrição a usar os metadados para "conversas", mas
> concordo que acrescentar notas de contexto ou justificativa de tradução
> é uma boa ideia. Só acho que devemos evitar esse lugar para discutir a
> tradução. Por exemplo, alguém coloca uma explicação e outra pessoa que
> não concorda com aquela explicação altera ou acrescenta uma outra nota.
> Acho que devemos colocar lá somente os consensos e fazer as discussões
> das notas aqui na lista de discussão.
Entendo que lá é o local adequado para explicações de uma string em particular, porque trata do caso pontual.
Se há uma nota e a explicação estiver adequada, e mesmo assim achar que deva alterar, acho que seria uma situação de entrar em contato com quem fez a nota ou aqui na lista. Nos demais casos, não vejo necessidade.
Um dos processos de trabalho de um tradutor é revisar as alterações feitas. Se não concordar, é o caso de mandar uma mensagem diretamente para quem fez a alteração e, caso não entrem em consenso, trazer a discussão para a lista. Isso evitaria exposição desnecessária.
As notas eu cadastro da seguinte forma: "Nota (Alvarenga)". Isso facilita a identificação de quem fez a nota.

> 
>   Estou a disposição caso queiram compartilhar alguma discussão. Pode
> > ser aqui na lista mesmo ou através do meu e-mail.
> 
> Vamos por aqui mesmo, pois assim socializamos com todo mundo.
> 
> Um abraço e até mais.
> 
> 
> Fred
> 

-- 
André Marcelo Alvarenga