O que é essa página
Para o pessoal que quer ajudar na tradução do Drupal 6 para o Brasil, esse é um esboço do manual para a tradução do Drupal 6. O objetivo final é ter uma espécie manual de estilo e um dicionário dos termos mais comuns. Isso tudo não é para complicar a vida de ninguém, é para que a gente possa ter uma tradução consistente com várias pessoas trabalhando nela. Não acho que valhe a pena incluir o workflow aqui, porque isso vai depender do tão esperado servidor de traduções que estão prometendo. Alguns dos comentários que eu fiz, se referem a coisas - dificuldades e alguns detalhes - que eu notei quando estava escrevendo a versão 2.0 da tradução do core do Drupal 5. Qualquer coisa, comentem aqui ou me mandem um email: jz.sanmartin@gmail.com (apresentação rápida: sou José San Martin. Conheço o Drupal faz um ano. Estou estudando lingüística na Unicamp. Fiz boa parte da versão 5.x-2.00 da tradução, a partir da versão anterior, de Bruno Massa).
Introdução: o estilo da tradução
É preciso manter um estilo consistente na tradução. É preciso, portanto, escolher um estilo para o texto da tradução. Não é, certamente, um problema muito grave. Não temos tanta liberdade como, por exemplo, teríamos em um texto literário. Além disso, a maioria dos textos (exceto os da ajuda) são muito curtos e não causam muito problema. Mesmo assim, definir, em linhas gerais, qual seria o estilo da tradução do Drupal ajuda na hora de escolher um termo ao invés de outro ou decidir que uma estrutura da frase seria mais apropriada que outra.
Para cada site Drupal, há dois grupos de pessoas usando: os administradores e os visitantes. Certas frases, como por exemplo as de ajuda, só vão ser lidas pelos administradores. Outras, como os títulos de blocos ou as frases do formulário de comentário, vão ser lidos pelos visitantes também. Quando for traduzir alguma coisa, pense em quem vai ler. Os administradores têm mais conhecimento e paciência para aprender do que os visitantes. Com os visitantes, podemos assumir apenas que eles sabem o que é um post de um blog ou um email. Com os administradores, podemos introduzir os termos mais técnicos do Drupal, como bloco, cache e peso.
Além disso, é bom lembrar que há dois tipos de administradores: aqueles que sabem bastante de informática e do Drupal (e portanto, o jargão de informática) e aqueles que não sabem. Com os usuários avançados, nem precisamos nos preocupar muito, pois - não é verdade? - eles nem vão ler a maioria dos textos, mesmo.
São três tipos diferentes de usuários do site, cada qual com suas necessidades:
- os visitantes, que precisam de frases simples, com apenas as palavras comuns do português da Internet. As frases para esse público são aquelas que aparecem em lugares como os formulários de comentário, os blocos e na página de contato.
- os administradores não-avançados, que precisam de textos bem compreensíveis e termos fáceis. As frases para esses público são aquelas que aparecem nas páginas de administração mais simples e na maioria dos textos de ajuda.
- os administradores avançados, que precisam de textos muito precisos e rápidos de ler. Eles entendem bem o jargão da informática e do Drupal e mais do que isso: entendem melhor o jargão do que o não-jargão. As frases para esse público são as de algumas páginas de administração e alguns poucos textos de ajuda.
Por isso, pense em quem vai ler antes de traduzir. As palavras usadas, podem ser diferentes em cada contexto. "Post" ou mesmo "página" podem ser usados quando apresentadas para o público não-avançado, enquanto o público avançado vai preferir "node". Ou então, "categoria" e "taxonomia". Cada termo vai ser de acordo com quem o texto se dirige. (por sinal, é exatamente como fazem no original do Drupal em inglês)
O texto final deve ser em português brasileiro, fluente e claro, com frases curtas e termos compreensíveis.
Manual de estilo
- Palavras inglesas no português: não tem porque evitar palavras do inglês se elas foram bem compreendidas pelo público brasileiro. Por exemplo, melhor usar "blog", "email", "site" e "post" ao invés de qualquer outra coisa que a gente invente. Por outro lado, é bom tomar cuidado com o jargão. Quem trabalha informática tem uma tolerância muito maior à palavras inglesas do que o público em geral, pelo simples fato de que todos na informática lêem bem inglês (e praticamente, só lêem inglês no trabalho) e o resto do público, não. É sempre bom considerar se a palavra inglesa é realmente aceita pelo público em geral ou se é aceita somente no jargão de informática. Por exemplo, "deletar" ainda que bem compreendido, é um jargão de informática, e portanto um pouco menos compreendido do que "apagar". "Overview" ou "frontpage" são outros exemplos: podem ser compreendidos por muitos, mas não por todos.
Por sorte, essa questão não é tão crítica: o Drupal em inglês é bem escrito e evita palavras pouco compreensíveis. Não tem, portanto, muitas palavras na tradução que vão causar problemas na hora de criar o dicionário.
- Expressões recorrentes: o Drupal está repleto de frases repetidas, diferentes só por uma palavra ou outra. É importante manter a consistência. Se você perceber que uma frase parece se repetir por toda a tradução, procure todo o conjunto de frases semelhantes e traduza todas de uma vez só. Além, é claro, de incluir no dicionário. Uma frase que se repetia muito na tradução do Drupal 5, por exemplo, era:
For more information please read the configuration and customization handbook Comments page. -- Para maiores informações, por favor leia o manual de configurações de comentários.
- aspas e apóstrofes: use sempre as "aspas" e não siga o que está no original. Não use 'apóstrofes' senão no caso uma citação dentro de outra, como em:
Ele disse: "clique no link 'novo menu'".
Note que esse caso não apareceu no core do Drupal 5 e provavelmente não vai aparecer em momento nenhum do Drupal 6.
- Futuro: prefira sempre a forma "vai ser" ao invés de "será". Isso dá para a tradução um tom menos formal e mais fluente.
- ter no sentido de existir: não tem problema nenhum, é perfeitamente aceitável. É o mais comum no português brasileiro. Também é perfeitamente aceitável transitar entre o uso de "ter" e de "haver".
- orações reduzidas em infinitivo: o original em inglês nos faz tender a traduzir as frases usando a seguinte estrutura:
...um menu para o visitante poder navegar
Frases desse tipo (com subordinadas reduzidas de infinitivo), especialmente se forem muito longas, podem ser difíceis de ler. É melhor escrever na forma não reduzida, como em:
... tem um menu para que o visitante possa navegar
- ou então: muitas vezes, em listas longas, onde no original se lê "or", é bom traduzir por "ou então", ao invés de simplesmente "ou". Isso porque "ou então" é mais enfático e ajuda o leitor a separar as duas alternativas quando o texto é muito longo. Por exemplo:
For more information see W3C's HTML Specifications or use your favorite search engine to find other sites that explain HTML.
Para maiores informações, consulte as especificações do HTML, da W3C, ou então use algum mecanismo de busca para achar algum outro site que fale sobre HTML.
- diferenças culturais: aproveitando a frase acima, vale mencionar: não traduza tudo literalmente. Algumas vezes, o jeito com que um americano fala com o usuário é diferente do jeito com que um brasileiro fala. (por "americano", entenda-se alguém, de qualquer nacionalidade, falando o dito "inglês internacional") Ao traduzir alguma coisa, pense se você escreveria isso em português em alguma situação qualquer. No exemplo acima, temos a expressão "favorite search engine" pode parecer muito normal na boca de um americano, mas duvido que algum brasileiro diga com naturalidade "seu mecanismo de busca favorito". Não, o que um brasileiro diria é "o que você quiser, qualquer um, de sua escolha". Esse é só um caso e listar todos os casos não é possível aqui, mas basta ficar atento.
- plural: em todo o original, se usa uma palavra no sentido genérico. Por exemplo, "administrators can" significando não "mais de um administrador", mas sim "um administrador qualquer". No português brasileiro, isso também é possível, mas resolvi dar a preferência por usar no singular com um, traduzindo "administrators can" por "um administrador pode".
- ter de / ter que:
- ênclises: (pronome -lo, -la, -lhe, como em "apagá-lo, ativá-lo") devem ser evitadas. Já caíram faz muito do português brasileiro culto falado e está em declínio até mesmo no português brasileiro culto escrito. Pronomes em ênclise dão um tom muito artificial ao texto. Alternativas (em ordem da melhor à pior): omitir o pronome oblíquo, usar uma passiva, repetir o substantivo, usar ênclise (o apagar, o ativar), usar "isso". As formas, do tipo "apagar ele" e "ativar ele", que são a norma no português brasileiro culto falado, ainda não são completamente aceitas no texto escrito. Até podemos usar "apagar ela" em alguns casos que "soar bem", mas deve se ter cautela. A decisão é caso por caso e depende do bom senso do tradutor.
- falsos cognatos e outros problemas: preste atenção se aquela palavra que parece com uma do português quer dizer aquilo mesmo. Alguns termos do inglês são traduzidas por mais de um termo em português. Outras só podem ser traduzidas por uma paráfrase (uma descrição). O caso mais radical, ao meu ver, é a palavra "unique". Não quer dizer, de modo algum, "único" e traduzir assim só causa problemas. Por exemplo, um texto diz que você precisa digitar um "unique name". Se traduzirmos por um "único nome", vai parecer que o texto diz que você está digitando dois nomes, quando na verdade está digitando um nome repitido. Por exemplo:
Filter format names need to be unique. A format named %name already exists.
é traduzido por:
Os nomes de formatos não podem ser repetidos. Um formato com o nome "%name" já existe.
As palavras, como "unique", que causam problemas de tradução devem ser incluidas no dicionário.
Dicionário de termos técnicos
- body - corpo
- cache - cache
- category - categoria
- checkbox -
checkboxcaixa de seleção - core - núcleo
(ou core? - a discutir) - cron - agendador de tarefas
- directory - pasta
engine - engine- indefinido- frontpage - página inicial / página principal
- mail - email (e não e-mail, nem mail, nem correio eletrônico)
- module - módulo
comments module, forum module, xxxxx module - módulo Comentários, módulo Fórum, módulo Xxxxx - node - node (para usuários avançados), post (para a maioria das situações) ou página (para quando não houver risco de confusão)
- outline (book) - esboço (tradução confusa, passível de revisão)
- overview - visão geral
- post - enviar, postar ou publicar
- search - buscar
- taxonomy - taxonomia / categoria
- toolkit - toolkit
- throttle - regulador/regular
- update - atualizar
- upload - na maioria dos casos, "enviar" (como em "enviar arquivos"). Quando precisar ser mais específico, use "fazer upload"
- weight - peso
*traduções discutíveis. a decidir
Dicionário de termos técnicos de informática
- add -
- administer - administrar
- administration section/screen - área de administração de ...
- administrator - administrador
- box of content - caixa de texto
- custom - palavra problemática. Embora em alguns casos pode ser traduzida como "personalizado" pode confundir o leitor. Um tema "custom" é um tema que o dono do site fez para o site dele. Um tema "personalizado", por exemplo, parece querer dizer que cada usuário do site tem um modificou o tema de acordo com suas vontades... "Customizado" não é muito corrente no português brasileiro e não quer dizer muita coisa para boa parte do público. Talvez o preferível é traduzir "custom" ora por "personalizado", ora por "próprio", ora por "adaptar" e ora por uma paráfrase como "que você mesmo criou", "como você quiser".
- delete - apagar
- enable - ativar
- enabled - ativado ou ativo
use um ou outro, dependendo do contexto. Se importa apenas o fato de estar ativo, use "ativo". Se é importante ressaltar a ação de ativar em um tempo passado recente, use "ativado". Exemplos:Quando o bloco estiver ativo, ...
Depois que o bloco for ativado...
Apenas blocos que estão ativados são exibidos.É um pouco arbitrário. A escolha final é do tradutor.
- enter - digite/digitar
- more informations - maiores informações (e nunca, mais informações)
- named - chamado/a
- note that - note que
- overview - visão geral
- read - no contexto de "read" o manual/a documentação, use "consulte"
- remove - apagar / remover
use remover apenas se for remover de algum lugar específico, como "remover do livro". Se o sentido for simplesmente o de "apagar da existência" (ou "remover do site", o que dá no mesmo), é preferível usar "apagar" - unique - Não quer dizer, de modo algum, "único" e traduzir assim só causa problemas. Por exemplo, um texto diz que você precisa digitar um "unique name". Se traduzirmos por um "único nome", vai parecer que o texto diz que você está digitando dois nomes, quando na verdade está digitando um nome repitido. Por exemplo:
Filter format names need to be unique. A format named %name already exists.
é traduzido por:
Os nomes de formatos não podem ser repetidos. Um formato com o nome "%name" já existe.
Dicionário de expressões recorrentes
(a ser preenchido quando começarmos a trabalhar com a tradução do Drupal 6)
- %username's blog - blog de %username
Comments
Sugestão de lista e discordância em algumas traduções
Olá colegas do Drupal,
Eu participo de alguns projetos de tradução e acredito que seria interessante para o grupo participar de pelo menos uma lista de discussão sobre o assunto chamada LDT-BR. Essa lista reúne pessoas que atuam em diversas traduções e tem como objetivo tentar uma padronização de termos para que as traduções pt-BR tenham mais consistência. Inclusive existe um vocabulário padrão para as traduções, que está em constante discussão lá. Maiores informações sobre a lista aqui: http://br.tldp.org/como_participar/lista.html
Em relação à tradução gostaria de discutir alguns termos. Em primeiro lugar, discordo que os termos site e post não possam ser traduzidos. Site já é traduzido como sítio em vários locais e o termo não causa nenhuma confusão, além de se evitar de usar um termo estrangeiro. E post pode ser traduzido de várias maneira, dependendo do contexto. Pode ser mensagem, artigo, colaboração e por aí afora. Vai depender de onde se encontra no Drupal. Indico abaixo outras sugestões para o vocabulário, algumas já consolidadas em discussões na LDP-BR:
checkbox - caixa de seleção.
core - núcleo.
engine - mecanismo (engine é um termo muito técnico que não faz o menor sentido para o usuário que não é da área).
mail - mensagem (não faz sentido "traduzir" como email, mesmo porque não existe o termo email, o correto é e-mail, uma vez que é a contração de "eletronic mail").
node - esse é um dos termos mais complicados do Drupal, uma vez que é um termo do programa. A tradução literal é nó, que não faz muito sentido. Só acho que não deva ser "traduzida" como post, pois aí não é uma tradução. Estamos trocando um termo em inglês por outro, o que, pra mim, não se justifica.
outline (book) - esboço é interessante pois passa o sentido. Mas talvez seja melhor rascunho. Que tal?
post - eu acho que publica passa melhor a idéia. Mas isso quando for verbo. Quando for substantivo, vai depender do contexto, mensagem, artigo ou publicação (talvez para manter coerência com o verbo, publicação seja melhor).
search - sei que "buscar" é amplamente difundido, mas será que "procurar" não ficaria melhor? Buscar me passa a idéia de a coisa já existe e você vai lá pegar. Já "procurar" indica, pra mim o sentido mais direto, que é o de encontrar algo que não se sabe se existe ou não.
taxonomy - eu acho que podemos manter taxonomia, porque é um termo do Drupal e cuja tradução passa bem a idéia.
toolkit - conjunto de ferramentas ou kit de ferramentas mesmo, tem que ver no contexto como fica melhor.
upload - na maioria dos casos, "enviar" (como em "enviar arquivos"). Quando precisar ser mais específico, ao invés de "fazer upload", acredito que seja melhor "transferir". É mais simples, e todo mundo entende (upload é mais técnico e não tão popular quanto download).
add - adicionar
box of content - caixa de conteúdo
custom - personalizado passa exatamente a idéia. Afinal, mesmo se considerarmos no contexto do tema, um "custom theme" é exatamente isso, um tema que pode ser selecionado pelo usuário (quando lhe for permitido) para modificar seu Drupal de acordo e deixá-lo diferente do padrão.
delete - apagar ou excluir. Vai depender do contexto.
enable - habilitar fica uma tradução mais coesa com o original. "Ativar" seria a tradução de "activate".
enabled - habilitado
more informations - não vejo problema em utilizar "mais informações". Inclusive, me soa melhor do que "maiores informações". Qual o senão ao "mais informações"?
named - acredito que "denominado" fica melhor.
Bom, acho que é isso. Se vamos mesmo manter um vocabulário, poderíamos pensar em uma estrutura para tal. Que tal uma página wiki? Ela permitiria uma edição mais ágil por parte dos interessados.
Retrucando...
Oi, bom dia!
Ótimo ver sua resposta.
Antes de tudo, quero deixar bem claro qual é a minha posição. Quero um texto em português brasileiro corrente, esse que a gente usa todo dia. A maior dificuldade da tradução é fazer com que o texto se acomode bem no português brasileiro e não fique com um jeito de coisa artificial. A clareza vem disso: do texto parecer natural.
Obrigado pela sugestão da LDT-BR, já me cadastrei lá. Só um pequeno comentário: se tivermos uma padronização dos termos técnicos em português, tanto melhor. Por outro lado, acredito que prevalece o bom senso: se decidirmos aqui que um certo termo fica melhor no Drupal, não temos que seguir religiosamente o padronizado.
Discordo quando você diz "evitar de usar um termo estrangeiro". Para que evitar? Me dê um bom motivo para isso. Não estamos redigindo um manifesto ufanista, estamos fazendo uma tradução de um software. "Site", por exemplo, é muito mais usado do que "sítio". Pense agora no usuário comum: ele usa todo dia "site" ou com "sítio"? "Site" é que é português corrente. Palavras como "site", "post", "marketing", "show" - quer a gente goste quer não - são palavras do português brasileiro. Não importa se foram importadas recentemente ou se tem origem estrangeira: elas são usadas e isso nos basta para que sejam aceitas nesta tradução.
"Post"/"Node", que são no Drupal a mesma coisa, é a tradução mais difícil de todas. Em cada contexto é preciso tomar uma decisão, porque cada termo que vai bem em uma situação, pode cair mal em outra. (a maior prova disso é que nem mesmo o original em inglês faz uso de um termo único) O melhor é listar alguns termos possíveis e decidir caso por caso, de acordo com, principalmente, o bom senso. Nessa lista, tudo bem incluir "página", "artigo", "contribuição", mas "post" e "node" também devem entrar, cada qual por um motivo. "Post" é uma palavra extremamente usada no meio dos blogs. Além disso tem um significado muito claro: você pode contar facilmente "1 post, 2 posts, 3 posts..." ao passo que "1 contribuição, 2 contribuições, 3 contribuições" fica muito mais forçado. "Contribuição" (ou "colaboração") é útil em algumas situações, mas é uma palavra muito mais abstrata (é derivada de um verbo, oras), enquanto "post" é uma coisa concreta, contável - e, principalmente, um termo comum para usuários e leitores de blogs. "Node", por outro lado, ainda que totalmente hermético para a maioria dos usuários, é um termo técnico bem aceito pelos usuários mais avançados e deveria ser usado, restrito, em alguns contextos, principalmente na página de configurações, quando o mais importante for a exatidão do termo. Vou adicionar "contribuição" ao dicionário como uma tradução possível, mas com uma ressalva: não é muito adequado quando se quer destacar o caráter "unidade" que um node tem. "Mensagem" é um termo extremamente pouco preciso e não me parece adequado para descrever um "node" (dá mais a idéia de uma frase curta avisando alguma coisa do que de um texto grande; me lembra mais um comentário do que um node). Por fim, "artigo" é uma idéia boa, mas me surgiu outra idéia: não seria melhor reservar esse termo para traduzir "story", que hoje é traduzido pelo termo "matéria", que é no mínimo discutível. Em suma, é uma discussão longa e acho que o melhor seria simplesmente traduzir com o que temos (e ser criativos, também) e resolver cada caso em que houver prejuizos à clareza. Só não vejo porque riscar "post" e "node" da lista de possibilidades, que são extremamente úteis em alguns contextos.
Agora uns comentários sobre as palavras que você sugeriu alterações:
<select>? Não consegui achar nenhuma tradução satisfatória em português.É isso que eu tinha para comentar. Apesar de ter argumentado tanto quanto argumentei aí em cima, não queria que a gente desse por decidido tudo antes de traduzir. É preciso ver o que tem para traduzir para poder saber como traduzir. Proponho um manual de estilo de linhas gerais, com algumas regras bem claras, mas que não sejam feitas para serem obedecidas, mas sim para ajudar o tradutor, simplesmente. Por isso, podemos colocar várias traduções possíveis para cada termo. Não vamos brigar muito agora, vamos ter um bom tempo para brigar por cada tradução em particular. :)
Por fim: talvez pudessemos fazer um grande site para esse manual de estilo/dicionário mais tarde. Por agora, essa "story" aqui no Groups está bom e qualquer coisa que a gente discutir aqui nos comentários eu atualizo lá em cima. Tudo bem assim?
Até mais,
José San Martin
Mais discussões
Olá José San Martin e demais colegas do Drupal,
Em primeiro lugar, desculpe-me pela demora na resposta, mas tive alguns problemas de ordem pessoal que me impediram de acessar a rede. Mas vamos lá, vou fazer alguns comentários por blocos.
Bom justamente por estarmos fazendo uma TRADUÇÃO, devemos evitar os termos em inglês. Senão não seria tradução, não é mesmo? ;-)
Veja bem, temos que tomar cuidado com os termos porque geralmente temos uma visão muito restrita ao universo onde estamos imersos. Palavras que, para nós, são comuns, para outras pessoas, fora do meio técnico, podem não ter significado nenhum. Além do mais, ao fazermos uma tradução temos uma responsabilidade com o que escrevemos. O que constar ali irá definir a forma como as pessoas usam o programa e estaremos criando uma cultura ao redor daquilo. Portanto, não é ufanismo, mas responsabilidade com o nosso idioma. Além do mais, não digo que não PODEMOS usar, mas sim que DEVEMOS EVITAR, quando existir um termo com tradução equivalente e que transmita bem o significado.
Depende do seu conceito de usuário comum. O termo sítio já está bastante difundido em nosso meio. Inclusive existe uma orientação para que sítios governamentais e ligados à educação utilizem o termo em português. E só porque uma palavra é muito usada, não quer dizer que ela seja "português corrente".
Discordo. Post, por exemplo, é uma palavra conhecida somente entre as pessoas que alimentam blogs ou outros sítios de envio de mensagens/notícias. E a tradução para o português, além de ser mais inteligível, não perde em nada em matéria de significado para o termo em inglês. Marketing tudo bem, porque é um termo que, por si, tem um significado, e cuja tradução é pouco viável. Show só faz sentido enquanto apresentação, o que não é o caso da tradução aqui no Drupal.
E, de novo, o fato de ser usada não deveria ser o único critério para ser incluída como TRADUÇÃO.
Não entendi muito bem o que você está chamando de "forçado". Quer dizer que é mais difícil de falar? Mais complicado? Além disso, você reforçou o que eu falei acima, ao afirmar que "post" é muito usado em blogs. Mas e os outros usuários? Como ficam? E se for para usar "post", então pelo menos utilizemos a forma aportuguesada, já encontrada em alguns locais, que é "postagem".
Aqui também não entendi. O que torna "post" como algo concreto e confiável (???) em detrimento de "contribuição". Post também é um verbo em inglês, portanto o argumento de "contribuição" ser abstrato porque deriva de verbo não faz sentido. E, mais uma vez, post faz sentido para quem está habituado com a palavra. Para as outras pessoas, é absolutamente vazia de significado.
Não acho que "matéria" seja discutível no que se refere ao sentido da "story", que é justamente esse.
Bom, o node eu concordo que é terrível para traduzir, mas o post eu continuo defendendo a tradução, pelos argumentos acima... :-)
Salvo engano, o combobox não é aquela caixa de seleção que aceita mais de uma opção? Se for (e pelas traduções que eu já encontrei aqui), fica "caixa de seleção" mesmo, pois não tem diferença entre elas.
Eu uso e a inspiração para "rascunho" vem justamente daí... :-) Porque é justamente isso: um rascunho produzido antes de publicar a versão final.
Apesar de achar que "procurar" passa melhor a idéia, concordo com você que buscar é esteticamente mais indicado, inclusive nas conjugações verbais e na hora de gerar os derivados.
Faz sentido. Apesar de "Adicionar bloco" funcionar, "Novo bloco" é bem melhor.
Tudo bem. Pensei em "denominado" porque, além de ser a tradução mais precisa, pra mim soa mais "profissional"... :-)
Sem problemas. Minha opção foi mais estética mesmo...
Nesse exemplo que você citou, acredito que traduzir "custom" como "personalizado" funcionaria bem, pois o "custom logo" é um logo diferente do padrão, por isso, é uma personalização.
hehehehehehe Concordo com você. ;-)
Só gostaria de destacar que muito da minha argumentação vem de discussões (algumas vezes, briga feia) que rolam nas listas de tradução que eu participo, especialmente a LDP-BR.
Por mim tudo bem. Mas gostaria de informar que eu tenho um domínio (teia.bio.br) que está hospedado em um host. Lá é possível colocar sub-domínios e tenho uma banda mensal razoável. Se o grupo quiser, podemos criar um site lá (pode ser um Wiki ou mesmo um Drupal) para organizar esses trabalhos. Como eu já pago a mensalidade para o meu site, e esse "site extra" não representaria nenhum custo a mais, isso não teria custo nenhum. Portanto, fica a oferta. O espaço está à disposição... :-)
Um abraço a todos e até mais.
parte um da resposta - conceitos
Claro que é! Sejamos pragmáticos: qual o objetivo da tradução? É fazer um texto legível na língua-alvo (ou melhor, para o público-alvo). Remover o texto da língua-original é um mero meio, não é o fim - apenas parte do processo, não é o objetivo. Não vamos confundir as coisas; o que faz o quadro não é a tinta, é o pintor. Do mesmo modo, o que faz a tradução é a compreensão do leitor, não a quantidade de palavras do original eliminadas.
Não tenho responsabilidade com o idioma, o idioma é que deve ter responsabilidade comigo, pois eu tenho responsabilidade é com o leitor. Pouco me importa se o texto está "responsável". Me importa se o texto é eficaz, se atinge do melhor jeito o seu leitor. Isso não quer dizer de modo algum - por favor não me entenda mal - escrever "de qualquer jeito". Muito pelo contrário, significa um trabalho cuidadoso com a linguagem, mas não pensando em "regras do bem falar", mas sim pensando no que estamos querendo dizer, e para quem.
Eu concordo absolutamente com você nesse ponto. É justamente esse o ponto da minha argumentação: devemos pensar o que as pessoas vão entender melhor, não apenas seguir uma regra qualquer (por exemplo a regra de que todo nome estrangeiro é ruim).
Você está se contradizendo... :-)
Essa é a questão central. Todo meu raciocínio se baseia na divisão dos três tipos de usuários, que eu descrevi mais acima:
(i) os visitantes, que não sabem nada além do básico da Internet;
(ii) os administradores não-avançados, que não querem uma parede de termos técnicos entre eles e o Drupal
(iii) os administradores avançados, que até se sentem mais confortáveis com termos técnicos, por mais precisos.
Cada texto ("string") da tradução é direcionado para um desses três grupos. Alguns textos vão aparecer na página de administração, outros para os visitantes, etc. Na hora de traduzir, a gente tem que pensar qual é o caso. Por isso que acho que "post" é péssimo para o grupo (i), para o qual apenas o termo "página" seria aceitável. Por outro lado, é bastante razoável para o grupo (ii), porque imagino que quem vai produzir um site já teve um contato prévio com blogs e outras ferramentas de publicação e está mais familiarizado com esse tipo de vocabulário. Tudo depende de para quem estamos escrevendo, então vamos seguir o bom-senso e não um punhado de regras.
parte dois da resposta - discussão dos termos
Isso é verdade, mas essa não é justamente grande parte do público do Drupal? Acho justo considerar isso e se permitir usar o termo post quando estivermos falando para esse tipo de gente.
(aliás, diria que leitores de blogs, mesmo que não escrevam, também sabem o que são posts. Não é tão jargão assim)
Certamente. Foi só um exemplo. Traduzir o verbo "show" por "show" não faria mesmo o menor sentido, estava falando mesmo do "show-espetáculo".
Ok, qual delas, oras? Se há muitas traduções possíveis é justamente porque perde significado...
Eu escrevi contável e não confiável. Por contável eu quero dizer que dá para falar, naturalmente, "1 post, 2 posts, 3 posts", assim como se fala "1 cadeira, 2 cadeiras, 3 cadeiras". Em oposição a "1 institucionalização, 2 institucionalizações, 3 institucionalizações".
O que eu quero dizer é que "contribuição" não é geralmente contável, por ser, geralmente, um substantivo abstrato. Contribuição é o ato de contribuir, não é uma coisa. Se por exemplo, fulano cria muitas páginas num site por dia, poderíamos dizer que "fulano contribui muito", ou então que "sua contribuição é muito grande". Eu nunca diria que "fulano tem muitas contribuições" - isso não existe, pelo menos na minha língua, e é isso que eu chamo de "forçado". "Contribuição" é um ato, não é uma coisa concreta e muito menos uma página de Internet.
Sou totalmente contra o uso do termo "contribuição" por esses motivos:
1) é jargão, e pior ainda, um jargão usado só pela tradução do Drupal. Explico. O sentido corrente da palavra contribuição é do "ato de contribuir". Esse sentido de "contribuição" como uma "página de um site" é completamente inventado.
2) é restrito a apenas um tipo de público: vale para sites colaborativos, do tipo "wiki". Não vale por exemplo, para um blog - o autor do blog não "contribui" para o seu próprio blog (assim como não doa dinheiro a si mesmo :-) ). Também não vale para um site corporativo - os funcionários não "contribuem" para o site corporativo - eles são pagos, não são voluntários.
"Post", justamente por ser uma palavra de origem estrangeira, é muito mais específico e se refere não a um ato, uma ação, mas a uma coisa bem definida. Concordo que post deve ser usado em apenas alguns momentos, mas não vejo razão nenhuma - sejamos pragmáticos - para descartar ele da tradução. Se não gosta, acho que usar "página" ou "artigo" está muito bom para muitos casos.
Estou falando do combobox, do "drop-down", daquela coisinha criada pelo <select>, quando ele tem uma linha só.
A metáfora vale... Mas é meio estranho para mim. Não é um rascunho, é a própria versão final, não? O.o
Quem sabe "estrutura do livro" não é uma tradução decente?
E no caso de "custom theme"? O "tema personalizado" pode parecer que cada usuário (cada pessoa) escolhe seu próprio tema. Custom é uma dessas palavrinhas chatas que não têm tradução. Melhor omitir ou usar uma paráfrase. Traduzir por personalizado dá algumas vezes, algumas vezes não dá. (e claro, traduzir por "customizado" é muita forçação de barra. :-) )
Onde organizaremos a traducao
Obrigado Frederico,
Mas em breve (espero que antes do Drupal 6.x sair) teremos um jeito bem bonitinho para irmos traduzindo o drupal e nos organizarmos, muito provavelmente ele será integrado ao groups.drupal.org, entao acho que é melhor irmos nos organizando por aqui pois assim poupamos o trabalho de migrar o conteúdo :)
Concordo com o "wundo". Não
Concordo com o "wundo". Não é por falta de lugar que eu deixei aqui, que eu também tenho um site pessoal, mas por que é melhor dar ao Drupal (.org) o que é do Drupal.
Comunicação
Venho dar minha contribuição.
Acredito que o maior objetivo de uma tradução seja conseguir comunicação com quem lê.
Minha posição em relação a isso é parecida com a do José San Martin: a tradução deve dar nosso recado, deve ser clara o suficiente para o usuário entender o que traduzirmos.
De que adianta uma tradução usando um português corretíssimo, nenhuma palavra em inglês, usando português extremamente culto, falado e lido apenas por poucas pessoas? De que adianta isso se a grande maioria não irá entender. Já assistiu o discurso de um jurista que não quer se fazer entender? De um economista, de um médico?
Bem, acho que me fiz entender, não devemos seguir padrões (a não ser que ajudem), não devemos obedecer a regras (só às que melhorem a tradução) mas devemos ser capazes de traduzir e qualquer pessoa, com um mínimo de conhecimentos sobre a nossa língua, seja capaz de enteder o que traduzimos. Mesmo que não consigamos isso, mas esse objetivo deve ser perseguido.
Ribamar FS - http://ribafs.net
Ribamar FS - http://ribafs.net
Meus dois centavos
"Outline"
Na minha modesta opinião, a dificuldade em traduzir esta palavra advém do fato de que ela já foi uma escolha infeliz desde o inglês original. "Outline", no contexto do módulo Book, tem muito pouco a ver com o conceito de rascunho ou esboço, que seriam traduções adequadas em outros contextos.> Mas no Drupal, "outline" não é nada mais que organizar a seqüência em que os nodes vão aparecer num Livro. Portanto, minha sugestão é simplesmente Ordenar.
"Contribuição"
Como já foi dito, contribuição é o ato de contribuir, colaborar, ajudar. Tem pouco a ver com o conceito de "post". Prefiro muito mais usar Publicação, que deixa menos margem a confusão, até porque é uma das que fazem parte do grupo de palavras que serão lidas pelos visitantes comuns. E Publicação abrange mensagem, artigo, página, livro, foto etc, que é justamente o que precisamos.
"Transferir"
A gente pode "transferir" algo em duas direções, de cá para lá e de lá para cá. Portanto, usar "transferir" para traduzir "upload" é perigoso, pois a rigor pode significar tanto "upload" quanto "download", que são conceitos que precisam estar muito bem diferenciados no Drupal. Minha sugestão é Carregar, pois – além de ser uma tradução mais próxima da literal – parece já estar amplamente difundida e de uso corrente em sites brasileiros e portugueses.
No mais, não nos deixemos cair em preciosismos contraproducentes. Tanto faz e-mail ou email, maiores informações ou mais informações (embora eu prefira a segunda, pois é mais curta e cabe melhor nos diferentes layouts), procurar ou buscar (apesar de eu preferir novamente a segunda, pelos mesmos motivos), vai ser ou será (idem), ...
post, postar, enviar, publicar?
Olá,
No passado eu traduzi a expressão "post" dependendo do contexto. Por exemplo:
Post a new message -> Publicar uma nova mensagem
Your message has been posted -> Sua mensagem foi enviada
New posts -> Novas mensagens
Agora, "postar"... JAMAIS. Odeio jargões do tipo deletar, postar, logar, etc. Também tive intolerância no passado com "fazer login". Mas vejo que hoje em dia tudo que é site utiliza o jargão login... e acho que "efetuar login" não soa tal mal assim.
2 centavos, quem dá mais?
Enquanto estava lendo o manual estava pensando em fazer um comentário parecido ao do Aracnus.
Mas enfim, aqui vão mais dois centavos: (essa é a típica frase americana que passamos a utilizar em informática e que não faz o menor sentido para nenhum outro grupo)
Sou velho participante também da LDP-BR e da Gnome-BR, mas não pensem que eu vim aqui para defender o Aracnus ... :)
A minha primeira contribuição é a disponibilização de um atalho (link) para um sítio (site) interessante: http://pt-br.open-tran.eu/
Neste podemos acompanhar quais as traduções são comumente utilizadas em vários aplicativos, como exemplo o drop-box:
Lista, Lista visível, Lista suspensa, Lista dobrável, Lista de seleção.
O que é mais interessante notar é que cada uma é utilizada em determinada situação mesmo em softwares que tentam seguir os mesmos padrões entre si. Aí é que está o grande diferencial: Não existe tradução única para praticamente nenhum termo, tudo depende do contexto. Então ficarmos aqui discutindo uma única palavra para sabermos se ela fica melhor de uma forma ou de outra é perca de tempo e esforço.
Outro site interessante para ser visto é o do Vocabulário padrão da LDP-BR, este segue um princípio um pouco diferente mas também pode ajudar bastante.
O que eu proponho é: Vamos deixar para discutir quando olharmos um determinado termo em seu contexto, então poderíamos assim resolver melhor essas situações dispares de "público alvo" para a tradução.
E só para não dizerem que vim aqui tentar esfriar a discussão, vou colocar um pouco de lenha na fogueira.
O grupo 1 não é o grupo de seletos leitores de blogs e afins, pensem também nos paraquedistas (esse só funciona com bloqueiros) e também nos recém usuários de informática. Estamos em um país que está enfrentando uma massiva inclusão digital, o número de novos usuários de internet no brasil está constantemente crescendo, e acho que se pudermos contribuir para que esses recém chegados possam se sentir mais cômodos com os termos que encontram na internet, devemos também pensar em fazer com que os textos traduzidos sejam de simples associação com o cotidiano.
Nesse caso relatado se encontra a palavra "Post", por mais comum e simples que ela possa parecer a nós e aos usuários acostumados com blogs, ela não é nada comum no cotidiano de qualquer pessoa. Na minha opinião usar post para grupo 2 ou 3 é mais do que sensato, mas usar para o grupo 1 não seria tão adequado assim.
O post no gnome-blog, que é o software que mais se assemelha ao drupal do meu convívio vem de Publicar (Post an entry to a web log - Publique artigos em um blog).
Publicar entra no problema da contagem (2 publicações, 3 publicações), mas não é tão feio e é um termo comum o suficiente. E também Publicar não incorre no problema com a informação, como ocorre com o termo contribuição.
Nota final: eu discordo da utilização de atalho como link, mas sítio como site pode ser usado com ressalvas.
Pessoal · Comunidade
Post: reduzir, talvez sim; eliminar, melhor não
O Grupo 1 inclui leitores e escritores de blogs, mas eles não são seletos coisa nenhuma. Não estou pensando nos grandes blogs, daquele mundo de jornalistas e dinheiro adsense. Estou pensando naquelas pessoas que chegam na internet e uma das primeira coisas que fazer é montar um blog ou um fotolog pessoal. Não é um grupo seleto, não é um grupo elitista, não é um grupo fechado, não é um grupo pequeno.
Acredito também que mesmo que a pessoa não saiba o que é um "post", vai ser muito mais fácil perguntar por aí e descobrir o que é um "post" do que descobrir o que é uma "publicação" ou uma "contribuição". Metáforas são muito boas, mas nem sempre elas são tão óbvias quanto a gente quer que elas sejam.
Post é um termo comum, mesmo entre os paraquedistas. Não adianta só eu falar isso, certo? Veja só:
O tal "grupo seleto de blogueiros famosos" não é o mesmo grupo que usa o Blogger da Globo.com. No entanto, as pessoas do blogger.com.br sabem o que é um "post", e imagino que os seus leitores também:
http://www.google.com/search?q=site%3Ablogger.com.br+post
O Fotolog do Terra também usa "post" sem se incomodar ou temer que seus usuários não saibam o que seja a palavra:
http://fotolog.terra.com.br/
E o Flogão:
http://www.google.com/search?q=site%3Aflogao.com.br+post
dava para continuar por mais um bocado. Não é um meio técnico, das pessoas que sabem muito de informática. Acho que isso mostra que "post" não é mais uma palavra do jargão mais fechado e já está bem aceita pelo público.
(tenho a impressão que as pessoas preferem aprender uma palavra nova do que aprender um sentido novo para uma palavra que elas já conhecem)
Isso não quer dizer que acho que "post" precisa estar em todas as traduções de "node". Em muitos casos, há uma ou outra palavra que cai melhor. Mas não estamos em condições de prescindir de "post".
José San Martin
Mais informações
ok, desdigo o que disse sobre maiores informações.
Que fique então "mais informações", se a maioria está preferindo assim.
Usando o cliente de tradução
Olá,
Podemos configurar o cliente de tradução nos nossos sites Drupal para enviar sugestões para o http://l10n.drupaleiros.com?
Eu tentei fornecer o endereço http://l10n.drupaleiros.com/ como URL do servidor de tradução, porém o Drupal diz que o endereço é inválido... Alguma sugestão?
Grato,
P.