Os programas do PostgreSQL (servidor e cliente) podem emitir as mensagens em seu idioma preferido — se as mensagens tiverem sido traduzidas. Criar e manter um conjunto de mensagens traduzidas requer ajuda de pessoas que falem bem seu próprio idioma, e que desejem contribuir para o trabalho do PostgreSQL. De forma alguma é necessário ser um programador para realizar esta tarefa. Esta seção explica como ajudar.
Aqui não será julgado seu conhecimento do idioma — esta seção é sobre ferramentas de software. Teoricamente só é necessário um editor de textos. Mas isto se aplica somente ao caso improvável de não se desejar testar as mensagens traduzidas. Ao configurar a árvore de fontes certifique-se que a opção --enable-nls está sendo utilizada. Esta opção também verifica a biblioteca libintl e o programa msgfmt, que todo usuário final vai necessitar de todo jeito. Para testar a tradução realizada, devem ser seguidas as partes aplicáveis das instruções de instalação.
Se for desejado iniciar um novo trabalho de tradução, ou se for desejado fazer uma mesclagem do catálogo de mensagens (descrita posteriormente), serão necessários os programas xgettext e msgmerge, respectivamente, em uma implementação compatível com o GNU. Posteriormente isto será arrumado de tal forma que, se for utilizado um pacote de distribuição do código fonte, não será necessário utilizar xgettext (A partir do CVS ainda é necessário). É recomendado o GNU Gettext 0.10.36 ou mais recente.
A implementação local do gettext vem com a sua própria documentação. Provavelmente parte desta documentação está duplicada no que se segue, mas para obter detalhes adicionais deve ser vista esta documentação local.
Os pares de mensagens original em inglês e equivalente traduzida são mantidos nos catálogos de mensagens. Cada programa possui seu próprio catálogo (embora programas relacionados possam compartilhar catálogos de mensagem), sendo um catálogo por idioma. Existem dois formatos para os catálogos de mensagens: O primeiro é o arquivo "PO", significando "Objeto Portável" (Portable Object), que é um arquivo texto puro com sintaxe especial editado pelos tradutores. O segundo é o arquivo "MO", significando "Objeto de Máquina" (Machine Object), que é um arquivo binário gerado a partir do respectivo arquivo PO, usado quando o programa internacionalizado é executado. Os tradutores não lidam com arquivos MO; na verdade quase ninguém lida.
As extensões dos arquivos de catálogos de mensagens são, sem surpresa alguma, .po ou .mo. O nome base é o nome do programa que o arquivo acompanha, ou o idioma a que se destina, dependendo da situação. Isto confunde um pouco. Por exemplo, psql.mo (o arquivo MO do psql) ou pt_BR.po (arquivo PO em português).
O formato dos arquivos PO está exemplificado abaixo:
# comentário msgid "cadeia de caracteres original" msgstr "cadeia de caracteres traduzida" msgid "outra cadeia de caracteres original" msgstr "outra cadeia de caracteres traduzida" "as cadeias de caracteres podem ser quebradas desta forma" ...
As linhas msgid são extraídas do código fonte do programa (Não é necessário, mas esta é a forma mais usada). As linhas msgstr são inicialmente vazias, e depois preenchidas com cadeias de caracteres úteis pelo tradutor. As cadeias de caracteres podem conter caracteres de escape no estilo C, e podem ter várias linhas de continuação conforme mostrado acima (A linha de continuação deve começar no início da linha).
O caractere # inicia um comentário. Se o caractere # for seguido imediatamente por um espaço em branco, então este é um comentário mantido pelo tradutor. Podem haver comentários automáticos, que possuem um caractere diferente de espaço em branco logo após o caractere #. Estes comentários são mantidos por várias ferramentas que operam em arquivos PO, e têm por objetivo ajudar o tradutor.
#. comentário automático #: nome_do_arquivo.c:1023 #, sinalizador, sinalizador
Os comentários no estilo #. são extraídos do código fonte em que a mensagem é utilizada. Possivelmente o programador inseriu informações para o tradutor, tal como o alinhamento esperado. O comentário #: indica o local exato onde a mensagem é utilizada no código fonte. O tradutor não precisa olhar o código fonte, mas pode olhar se houver dúvidas sobre a tradução correta. Os comentários #, contém sinalizadores que descrevem de alguma forma a mensagem. Atualmente existem dois sinalizadores: fuzzy é definido se a mensagem está possivelmente desatualizada devido a alterações no fonte do programa. O tradutor pode verificar e talvez remover o sinalizador fuzzy. Deve ser observado que as mensagens sinalizadas como fuzzy não se tornam disponíveis para os usuários finais. O outro sinalizador é c-format, que indica que a mensagem é um modelo de formato no estilo printf. Isto significa que a tradução deve ser capaz de formatar a cadeia de caracteres com o mesmo número e tipo de argumentos. Existem ferramentas que podem fazer a validação.
[1]
[2]
Como fazer para criar um catálogo de mensagens "em branco"? Primeiro, o diretório que contém o programa cujas mensagens se deseja traduzir deve ser tornado o diretório corrente. Se existir o arquivo nls.mk, então este programa está preparado para ser traduzido.
Se já existirem alguns arquivos .po, então já foi feito algum trabalho de tradução. Os arquivos se chamam idioma.po, onde idioma é o código de duas letras (minúsculas) especificado em ISO 639-1 como, por exemplo, fr.po para Francês. Havendo necessidade de mais de um trabalho de tradução para o idioma, então os arquivos podem se chamar idioma_região.po, onde região é o código de duas letra (maiúsculas) do país especificado em ISO 3166-1 como, por exemplo, pt_BR.po para o português do Brasil. Se for encontrado o idioma desejado, pode-se simplesmente começar o trabalho a partir deste arquivo.
Se for necessário começar um novo trabalho de tradução, então primeiro deve ser executado o comando
gmake init-po
para criar o arquivo progname.pot. (.pot para diferenciar dos arquivos PO que estão "em produção". O T significa "template" (modelo)). Este arquivo deve ser copiado para idioma.po e editado. Para ficar conhecido que existe um novo idioma disponível, deve ser editado o arquivo nls.mk e adicionado o código do idioma (ou do idioma e do país), em uma linha parecida com a seguinte:
AVAIL_LANGUAGES := cs de es fa fr hu it ko nb pt_BR ro ru sk sl sv tr zh_CN zh_TW
(Obviamente, podem estar presentes outros idiomas)
À medida que os programas e bibliotecas subjacentes são modificados, as mensagens podem ser modificadas ou alteradas pelos programadores. Neste caso não é necessário começar do zero. Em vez disso, deve ser executado o comando
gmake update-po
para criar um novo arquivo de catálogo de mensagens em branco (o arquivo pot usado no começo), e mesclá-lo com os arquivos PO existentes. Se o algoritmo de mesclagem não tiver certeza sobre uma determinada mensagem, esta é marcada como"fuzzy" conforme explicado acima. No caso de alguma coisa ter dado realmente errado, o arquivo PO antigo é salvo com a extensão .po.old.
Os arquivos PO podem ser editados usando um editor de textos comum. O tradutor pode apenas mudar o texto entre as aspas após a diretiva msgstr, adicionar comentários e alterar o sinalizador fuzzy. Existe um modo PO para o Emacs (o que não é surpresa), bastante útil.
Os arquivos PO não precisam ser totalmente preenchidos. O software retorna, automaticamente, a cadeia de caracteres original se não houver nenhuma tradução disponível (ou se a tradução estiver vazia). Não há problema em submeter uma tradução incompleta para ser incluída na árvore de fontes; isto abre espaço para outras pessoas darem continuidade ao trabalho. Entretanto, estimulamos que seja dada prioridade à remoção das entradas fuzzy após realizar a mesclagem. Lembre-se que as entradas fuzzy não serão instaladas; servem apenas como referência do que seria a tradução correta.
Abaixo seguem recomendações que devem ser lembradas ao editar as traduções:
printf, a tradução também deve ser. A tradução também deve ter os mesmos especificadores de formato e na mesma ordem. Algumas vezes as regras ortográficas tornam isto impossível ou esquisito. Neste caso podem ser mudados os especificadores de formato como mostrado abaixo:
msgstr "Die Datei %2$s hat %1$u Zeichen."Desta maneira o primeiro argumento vai, na verdade, utilizar o segundo especificador de formato da lista. A seqüência dígitos$ deve vir imediatamente após sinal de %, antes de qualquer outro manipulador de formato (Esta funcionalidade existe na família de funções
printf. Não é muito conhecida porque tem pouca utilidade fora da internacionalização de mensagens).
Nota: Seção escrita pelo tradutor, não fazendo parte do manual original.
Exemplo 46-1. Personalização das mensagens traduzidas do psql
Neste exemplo é mostrado como editar o arquivo pt_BR.po que contém as mensagens do psql traduzidas por Euler Taveira de Oliveira (<
euler@ufgnet.ufg.br
>), fazer alguma personalização porventura desejada e, por fim, gerar e colocar o arquivo binário psql.mo em produção no Fedora Core 3.
$ psql --version psql (PostgreSQL) 7.4.8 contém suporte a edição em linha de comando
$ cd /tmp $ tar xzvf /download/postgresql-7.4.8.tar.gz
$ cd /tmp/postgresql-7.4.8/src/bin/psql/po/ $ cp pt_BR.po pt_BR.po.original
$ kbabel pt_BR.po
$ cp /usr/share/locale/pt_BR/LC_MESSAGES/psql.mo /usr/share/locale/pt_BR/LC_MESSAGES/psql.mo.original
$ msgfmt --statistics -v -c -o psql.mo pt_BR.po $ mv psql.mo /usr/share/locale/pt_BR/LC_MESSAGES/psql.mo
| [1] |
O KBabel faz a validação de catálogos PO verificando, inclusive, os argumentos das mensagens com sinalizador c-format. (N. do T.) |
| [2] |
O poEdit é um editor de catálogos PO que funciona tanto no Linux quando no Windows. (N. do T.) |