Manpages

NOME

po4a - quadro para traduzir a documentação e outros materiais

Introdução

O objetivo do projeto po4a ( PO para tudo) é facilitar traduções (e mais interessante, a manutenção das traduções) usando ferramentas gettext em áreas onde eles não eram esperados como documentação.

Tabela de conteúdo

Este documento está organizado da seguinte forma:
1 Porque deveria eu usar po4a? É bom para quê?

Este capítulo de introdução explica a motivação do projeto e sua filosofia. Você deve lê-lo primeiro, se você está no processo de avaliação do po4a para suas próprias traduções.

2 Como usar po4a?

Este capítulo é uma espécie de manual de referência, tentando responder às perguntas dos utilizadores e dar-lhes uma melhor compreensão de todo o processo. Este introduz o modo de fazer as coisas com po4a e serve como uma apresentação à documentação das ferramentas específicas.
COMO começar uma nova tradução?
COMO mudar a tradução de volta para um ficheiro de documentação?
COMO atualizar uma tradução po4a?
COMO converter uma tradução pré-existente para po4a?
COMO adicionar texto extra para traduções (como o nome do
tradutor)?
COMO fazer tudo numa invocação de programa?
COMO personalizar po4a?

3 Como é que funciona?

Este capítulo dá-nos uma visão geral interna do po4a, de modo a que você se possa sentir mais confiante para nos ajudar a manter e a melhorar. Pode também ajudá-lo a entender por que ele não faz o que você esperava, e como resolver os seus problemas.

4 FAQ

Este capítulo agrupa as perguntas frequentes ( FAQ ). Na verdade, a maioria das perguntas até agora puderam ser formuladas dessa forma: "Porque ele é projetado dessa forma e não dessa outra?" Se você pensa que po4a não é a resposta correta para tradução de documentação, você deveria considerar ler esta seção. Se ele não responder suas perguntas, por favor entre em contato conosco na lista de discussão <devel [AT] lists.org>. Nós adoramos feedback.

5 Notas específicas sobre módulos

Este capítulo apresenta as especificidades de cada módulo a partir do ponto vista do tradutor e do autor original. Leia este capítulo para aprender a sintaxe que você irá encontrar ao traduzir coisas neste módulo, ou as regras que deve seguir no seu documento original para tornar a vida dos tradutores mais fácil.

Na verdade, esta secção não é realmente parte deste documento. Ao invés disso, é colocada na documentação de cada módulo. Isto ajuda a garantir que a informação é atualizada, mantendo a documentação e o código juntos.

Porque deveria eu usar po4a? Para que é bom?

Eu gosto da idéia de software de código aberto, tornando possível para todos o acesso ao software e seu código fonte. Mas, sendo francês, eu estou bem ciente que O licenciamento não é a única restrição à abertura do software: software livre não traduzido é inútil para quem não fala inglês, e nós ainda temos algum trabalho para realmente torná-lo disponível para todo o mundo.

A percepção desta situação por parte dos atores do código aberto melhorou drasticamente recentemente. Nós, como tradutores, ganhamos a primeira batalha e convencemos todo mundo da importância das traduções. Mas infelizmente, foi a parte fácil. Agora, temos que fazer o trabalho e realmente traduzir todas estas coisas.

Atualmente, o software de código aberto beneficia de um nível decente de tradução, graças ao conjunto maravilhoso de ferramentas gettext. Ele é capaz de extrair as sequências a traduzir do programa, apresentar um formato uniforme aos tradutores, e depois usar o resultado de seus trabalhos em tempo de execução para exibir mensagens traduzidas para o utilizador.

Mas a situação é um pouco diferente quando se trata de documentação. Com muita frequência, a documentação traduzida não é visível o suficiente (não distribuída como uma parte do programa), apenas parcialmente, ou não atualizada. Esta última situação é de longe a pior possível. Tradução desatualizada pode se tornar pior do que nenhuma tradução para os usuários ao descrever comportamento antigo do programa, que não é mais usado.

O problema para resolver
Traduzindo documentação não é muito difícil em si mesmo. Os textos são muito mais longos do que as mensagens do programa e assim, levar mais tempo a ser alcançado, mas nenhuma habilidade técnica é realmente necessária para fazê-lo. A parte difícil vem quando você tem que manter o seu trabalho. Detectar em quais partes fez a mudança e precisam ser atualizadas é muito difícil, propenso a erros e altamente desagradável. Eu acho que isso explica por que é que há tanta documentação traduzida ultrapassada.

As respostas po4a
Então, todo o ponto de po4a é fazer a tradução da documentação maintainable. A ideia é reutilizar a metodologia gettext para esse novo campo. Como em gettext, os textos são extraídos dos seus locais originais em ordem a serem apresentado num formato uniforme para os tradutores. As ferramentas clássicas gettext ajuda-os a atualizar as suas obras quando uma nova versão do original sai. Mas com a diferença do modelo clássico gettext, as traduções são re-injetadas na estrutura do documento original de modo que podem ser processadas ​​e distribuídas como a verão inglesa.

Graças a isso, descobrir quais partes do documento foram alteradas e precisam de uma atualização torna-se muito fácil. Outro ponto positivo é que as ferramentas fazem quase todo o trabalho quando a estrutura do documento original fica fundamentalmente reorganizado e quando alguns capítulos são movimentados, fundidos ou divididos. Ao extrair o texto para traduzir de uma estrutura do documento, você mantém-se longe da complexidade de formatação de texto e reduz as suas chances de obter um documento partido (mesmo se não o impedir completamente de o fazer).

Por favor, consulte também o FAQ abaixo neste documento para uma lista mais completa das vantagens e desvantagens desta abordagem.

Formatos Suportados
Atualmente, esta abordagem tem sido implementada com sucesso para vários tipos de formatos de formatação de texto:

manual

O bom e velho formato de páginas de manual, usado por muitos programas por aí. O suporte po4a é muito bem-vindo aqui, pois este formato é um pouco difícil de usar e não é muito amigável para os novatos. O módulo Locale::Po4a::Man(3pm) também suporta o formato mdoc, usado por aspáginas de manual BSD (também elas são bastante comuns no Linux).

pod

Este é o formato de Documentação Perl Online. A linguagem e as extensões em si são documentados desta maneira, assim como a maior parte dos scripts Perl existentes. Isso torna-se fácil de manter a documentação junto ao código atual por incorporação de ambos no mesmo ficheiro. Isso torna mais fácil a vida mais fácil ao programador, mas infelizmente, não ao tradutor.

sgml

Mesmo que um pouco substituído por XML hoje em dia, este formato é ainda com frequência bastante usado para documentos que são mais do que alguns ecrans de comprimento. Ele permite-lhe fazer livros completos. Atualizando assim a tradução de documentos longos pode revelar-se um verdadeiro pesadelo. diff revela-se muitas vezes inútil, quando o texto original foi recortado após a atualização. Felizmente, po4a pode ajudá-lo nesse processo.

Atualmente, são suportados apenas o DebianDoc e DocBook, mas acrescentando suporte para um novo, é muito simples. É até possível usar po4a num SGML DTD desconhecido sem alterar o código, fornecendo as necessárias informações sobre a linha de comando. Veja Locale::Po4a::Sgml(3pm) para obter mais detalhes.

TeX / LaTeX

O formato LaTeX é o principal formato de documentação usado nas publicações de Software Livre mundiais. O módulo Locale::Po4a::LaTeX(3pm) foi testado com documentação Python, um livro e algumas apresentações.

texinfo

Toda a documentação GNU está escrita neste formato (que é ainda um dosrequisito para um projeto GNU se tornar oficial). O apoio para Locale::Po4a::Texinfo(3pm) em po4a ainda está no início.Por favor, reporte erros e solicitações de recursos.

xml

O formato XML é um formato de base para muitos formatos de documentação

Atualmente, o DocBook DTD é suportado por po4a. VejaLocale::Po4a::Docbook(3pm) para obter mais detalhes.

outros

Po4a também pode lidar com alguns formatos mais raros ou especializados, como a documentação de opções de compilação para os kernels 2.4+ ou os diagramas produzidos pela ferramenta Dia. Adicionar um novo é muitas vezes bastante fácil e a tarefa principal é chegar com um analisador de seu formato de destino. Consulte Locale::Po4a::TransTractor(3pm) para obter mais informações sobre isso.

Formatos não suportados
Infelizmente, po4a ainda carece de suporte para diversos formatos de documentação.

Há um monte de outros formatos que gostaríamos que fossem suportados em po4a e não só os de documentação. De fato, pretendemos ligar todos os "market holes" deixados pelas ferramentas clássicas gettext. Abranger descrições de pacotes (deb e rpm), scripts de perguntas de pacotes de instalação, pacotes com registos das modificações (changelogs), e todos os formatos de ficheiros especializados utilizados pelos programas como cenários de jogos ou ficheiros de recursos do Wine.

Como usar po4a?

Este capítulo é uma espécie de manual de referência, tentando responder às perguntas dos utilizadores e dar-lhes uma melhor compreensão de todo o processo. Este introduz o modo de fazer as coisas com po4a e serve como uma apresentação à documentação das ferramentas específicas.

Visão geral gráfica
O esquema a seguir dá uma visão geral do processo de tradução de documentação usando po4a. Não tenha medo da sua aparente complexidade, vem do fato de que o processo whole é representado aqui. Uma vez que você converteu seu projeto para po4a, apenas a parte direita do gráfico é relevante.

Note que mestre.doc é tido como um exemplo de documentação a ser traduzida e tradução.doc é o texto tradução correspondente. O sufixo poderia ser .pod, .xml ou .sgml, dependendo do seu formato. Cada parte da imagem será detalhada nas próximas seções.

                                   original.doc
                                       |
                                       V
     +<-----<----+<-----<-----<--------+------->-------->-------+
     :           |                     |                        :
 {tradução}      |         { actualização do original.doc }     :
     :           |                     |                        :
   XX.doc        |                     V                        V
(opcional)       |               original.doc ->-------->------>+
     :           |                  (novo)                      |
     V           V                     |                        |
  [po4a-gettextize]    doc.XX.po--->+  |                        |
          |             (antigo)    |  |                        |
          |              ^          V  V                        |
          |              |     [po4a-atualizar po]              |
          V              |             |                        V
     tradução.pot        ^             V                        |
          |              |         doc.XX.po                    |
          |              |         (impreciso)                  |
     {tradução}          |           |                          |
          |              ^           V                          V
          |              |     {edição manual}                  |
          |              |           |                          |
          V              |           V                          V
      doc.XX.po --->---->+<---<---- doc.XX.po   adenda     original.doc
      (inicial)                   (atualizado) (optional)   (atualizado)
          :                          |            |             |
          :                          V            |             |
          +----->----->----->------> +            |             |
                                     |            |             |
                                     V            V             V
                                     +------>-----+------<------+
                                                  |
                                                  V
                                           [po4a-traduzido]
                                                  |
                                                  V
                                                XX.doc
                                            (atualizado)

Na parte da esquerda, a conversão de uma tradução não usando po4a para esse sistema é mostrada. No topo da parte da direita, a ação do autor original está descrita (atualização da documentação). O meio da parte da direita é onde as ações automáticas do po4a estão descritas. Os novos materiais são extraídos e comparados com a tradução existente. Partes que não foram alteradas são encontradas e a tradução anterior é usada. Partes que foram parcialmente modificadas também são conectadas à tradução anterior, mas com uma marcação indicando que a tradução deve ser atualizada. A parte inferior da figura mostra como um documento formatado é compilado.

Na verdade, como um tradutor, a única operação manual que você tem que fazer é a parte marcada {edição manual}. Sim, me desculpe, mas o po4a ajuda você a traduzir. Ele não traduz para você…

COMO começar uma nova tradução?
Esta secção apresenta os passos necessários requeridos para começar uma nova tradução com po4a. os refinamentos envolvidos na conversão de um projeto existente para este sistema estão detalhados na secção relevante.

Para começar uma nova tradução usando po4a, você tem que fazer os seguintes passos:

  $ po4a-gettextize -f <format> -m <master.doc> -p <translation.pot>

<formato> é naturalmente o formato usado no documento master.doc. Como esperado, a saída vai para translation.pot. Por favor referir para po4a-gettextize(1) para obter mais detalhes sobre as opções existentes.

A tradução real pode ser feita utilizando-se os modos Emacs ou Vi PO, Lokalize (baseado em KDE ), gTranslator (baseado em GNOME ) ou qualquer programa que você prefira usar em vez destes (por exemplo Virtaal).

Se você quiser saber mais sobre isto, definitivamente precisa de consultar a documentação gettext, disponível no pacote gettext-doc.

COMO mudar a tradução de volta para um ficheiro de documentação?
Uma vez que você acabou a sua tradução, deseja obter a documentação traduzida e distribuí-la aos utilizadores, juntamente com o original. Para isso, use o programa po4a-translate(1) assim (onde xx é o código de linguagem):

  $ po4a-translate -f <format> -m <master.doc> -p <doc.XX.po> -l <XX.doc>

Como antes, <formato> é o formato usado no documento mestre.doc. Mas dessa vez, o ficheiro PO fornecido com a opção -p é parte da entrada. Essa é a sua tradução. A saída vai para XX .doc.

Por favor, consulte po4a-translate(1) para mais detalhes.

COMO atualizar uma tradução po4a?
Para atualizar a sua tradução quando o ficheiro original master.doc mudou, use o programa po4a-updatepo(1) assim:

  $ po4a-updatepo -f <format> -m <new_master.doc> -p <old_doc.XX.po>

(Por favor, consulte po4a-updatepo(1) para mais detalhes)

Naturalmente, o novo parágrafo no documento não será magicamente traduzido no ficheiro PO com esta operação, e você precisa atualizar o ficheiro PO manualmente. Da mesma forma, pode ter que refazer a tradução de parágrafos que foram um pouco modificados. Para se certificar de que não vai perder nenhum deles, eles são marcados como "fuzzy" durante o processo e tem que remover esse marcador antes da tradução poder ser usada por po4a-translate. Quanto à tradução inicial, o melhor é usar o seu editor favorito PO aqui.

Depois que o ficheiro PO é atualizado de novo, sem qualquer falta de sequência não traduzida ou imprecisa (fuzzy), você pode gerar um ficheiro de documentação traduzida, como explicado na secção anterior.

COMO converter uma tradução pré-existente para po4a?
Muitas vezes, você alegremente traduziu manualmente o documento até uma grande reorganização do documento original master.doc aconteceu. Então, depois algumas tentativas desagradáveis ​​com diff ou ferramentas similares, você deseja converter em po4a. Mas, claro, você não quer perder sua tradução existente no processo. não se preocupe, neste caso, também é tratado por ferramentas po4a e é chamado gettextization.

O importante aqui é para ter a mesma estrutura no documento traduzido e no original, de modo que as ferramentas possam combinar o conteúdo adequadamente.

Se você tiver sorte (ou seja, se as estruturas de ambos os documentos se adequarem perfeitamente), vai funcionar perfeitamente e vai ser definido em poucos segundos. Caso contrário, você pode entender porque este processo tem um nome feio, e é melhor estar preparado para algum trabalho duro aqui. Em qualquer caso, lembre-se que é o preço a pagar para ter o conforto de po4a depois. E o bom é que tem que fazer isso apenas uma vez.

Não posso enfatizar demasiado. A fim de facilitar o processo, é assim importante que você encontre a versão exata onde foram utilizados para fazer a tradução. A melhor situação é quando anotou a revisão do VCS usado para a tradução e não o modificou no processo de tradução, por isso pode usá-lo.

Isso não vai funcionar bem quando você usa o texto original atualizado com a tradução antiga. Continua a ser possível, mas é mais difícil e realmente deve ser evitado se possível. Na verdade, eu acho que se não encontrar o texto original novamente, a melhor solução é encontrar alguém para lhe fazer a gettextization (mas, por favor, eu não ;).

Talvez seja muito dramático aqui. Mesmo quando as coisas estão erradas, restam maneiras mais rápidas do que traduzir tudo de novo. Eu era capaz de gettextizar a tradução francesa existente da documentação Perl num dia, até mesmo quando as coisas did estão erradas. Isso foi há mais de dois megabytes de texto, e uma nova tradução teria durado meses ou mais.

Deixe-me explicar a base do primeiro procedimento e vou voltar com dicas para o alcançar quando o processo dá errado. Para facilitar a compreensão, Vamos usar o exemplo acima, mais uma vez.

Uma vez que você tem o antigo master.doc outra vez que coincide com a tradução XX .doc, a gettextização pode ser feita diretamente para o ficheiro PO doc.XX.po sem a tradução manual do ficheiro translation.pot:

 $ po4a-gettextize -f <format> -m <old_master.doc> -l <XX.doc> -p <doc.XX.po>

Quando você tiver sorte, é isso. Converteu sua antiga tradução para po4a e pode começar com a tarefa de atualização imediatamente. Basta seguir o procedimento explicado uma secção um pouco atrás para sincronizar seus ficheiros PO com o mais novo documento original e, atualizar a tradução em conformidade.

Por favor note que, mesmo quando as coisas parecem funcionar corretamente, ainda há espaço para erros neste processo. A questão é que po4a é incapaz de compreender o texto para se certificar de que a tradução coincidir com o original. É por isso que todas as sequências são marcadas como "fuzzy" no processo. Você deve verificar cada um cuidadosamente antes de retirar os marcadores.

Muitas vezes, as estruturas dos documentos não correspondem exatamente, evitando po4a-gettextize de fazer seu trabalho corretamente. Neste ponto, o jogo total é sobre a edição dos ficheiros para obter a harmonia entre as malditas estruturas.

Pode ajudar a ler a secção Gettextization: como é que funciona? abaixo. Compreender o processo interno vai ajudá-lo a fazer este trabalho. O bom ponto é que po4a-gettextize é bastante detalhado sobre o que deu errado, quando isso acontece. Primeiro, ele aponta nas estruturas dos documentos onde são as discrepâncias. Vai aprender que as sequências não correspondem, a suas posições no texto e, o tipo de cada uma delas. Além disso, o ficheiro PO gerado até agora, vai ser despejado para gettextization.failed.po.

Da mesma forma, dois parágrafos podem ser mesclados no POD quando a linha separadora contém alguns espaços ou quando não há linha vazia entre a linha =item e o conteúdo do item.

Esta situação infeliz acontece quando o mesmo parágrafo é repetido sobre odocumento. Neste caso, não é criada uma nova entrada no ficheiro de PO, mas uma nova referência é adicionada ao já existente em seu lugar.

Então, quando o mesmo parágrafo aparece duas vezes no original, mas ambos não estão traduzidos da mesma forma cada vez, você terá a sensação de que um parágrafo do original desapareceu. Basta matar a nova tradução. Se, ao invés disso, você preferir matar a primeira tradução quando a segunda estiver melhor, substitua a primeira pela segunda.

No contrário, se dois parágrafos semelhantes, mas diferentes foram traduzidos exatamente da mesma maneira, você terá a sensação de que um parágrafo da tradução desapareceu. Uma solução é adicionar uma sequência estúpida ao parágrafo original (como "Eu sou diferente"). Não tenha medo, essas coisas vão desaparecer durante a sincronização, e quando o texto adicionado é suficiente curto, gettext irá corresponder a sua tradução para o texto existente (marcando-o como impreciso (fuzzy), mas você realmente não se importa uma vez que todas as sequências são fuzzy depois da gettextization).

Esperamos que estas dicas o irão ajudar a fazer o seu trabalho de gettextization e obter o precioso ficheiro PO. Agora você está pronto para sincronizar o seu ficheiro e começar a tradução. Note que no texto grande, pode acontecer que a primeira sincronização demore um longo tempo.

Por exemplo, o primeiro po4a-updatepo da tradução de documentação Perl em francês (ficheiro PO 5,5 Mb) demorou cerca de dois dias num computador G5 1Ghz. Sim, 48 horas. Mas as subsequentes levam apenas uma dúzia de segundos no meu velho portátil. É assim porque na primeira vez, a maioria das ’msgid’ do ficheiro PO não correspondem a nenhum dos ficheiros POT existentes. Isto força o gettext a procurar o mais próximo, utilizando um caro algoritmo de proximidade de sequências.

COMO adicionar texto extra para traduções (como o nome do tradutor)?
Por causa da abordagem ao gettext, fazendo isto torna-se mais difícil em po4a do que era quando a simples edição de um novo ficheiro ao longo do original. Mas continua a ser possível, graças ao chamado addenda.

Pode ajudar a compreensão de considerar adendas como uma espécie de remendos aplicados ao documento localizado após o processamento. Eles são bastante diferentes dos habituais ’patches’ (têm apenas uma linha de contexto, que pode incorporar expressão regular Perl, e só podem adicionar novo texto sem remover nenhum), mas as funcionalidades são as mesmas.

O seu objetivo é permitir que o tradutor possa adicionar conteúdo extra para o documento que não é traduzido a partir do documento original. O uso mais comum é adicionar uma secção sobre a sua própria tradução, lista de colaboradores e explicando como reportar uma erro contra a tradução.

Uma adenda deve ser fornecida como um ficheiro separado. A primeira linha constitui um cabeçalho que indica onde o documento produzido deve ser colocado. O resto do ficheiro adenda será adicionado textualmente em determinada posição do documento resultante.

O linha de cabeçalho que especifica o contexto possui uma sintaxe bem rígida: ele deve começar com a string PO4A-HEADER: , seguida por um uma lista separada por ponto-e-vírgula (;) de campos chave=valor. Espaços em branco SÃO importantes. Note que se você não puder usar o caractere ponto-e-vírgula (;) no valor e colocar entre aspas não vai ajudar. Opcionalmente, espaços ( ) podem ser inseridos antes de chave para legibilidade.

Embora essa pesquisa de contexto possa ser considerada como operando aproximadamente em cada linha do documento traduzido, ela realmente opera na cadeia de dados interna do documento traduzido. Essa cadeia de dados interna pode ser um texto abrangendo um parágrafo contendo várias linhas ou pode ser uma tag XML sozinha. O exato ponto de inserção do adendo deve ser anterior ou posterior à sequência de dados interna e não pode estar dentro da cadeia de dados interna.

A cadeia de dados interna real do documento traduzido pode ser visualizada executando po4a no modo de depuração.

Mais uma vez, parece assustador, mas os exemplos dados a seguir devem ajudá-lo a encontrar como escrever a linha de cabeçalho que precisa. Para ilustrar a discussão, assuma que queremos adicionar uma secção chamada "Sobre esta tradução" depois uma "Sobre este documento".

Aqui estão as chaves do cabeçalho possíveis:
mode (obrigatório)

Pode ser a string before ou after.

Se mode=before, o ponto de inserção é determinado pela correspondência de regex de um passo especificada pelo argumento de regex position. O ponto de inserção está imediatamente antes da cadeia de dados interna unicamente correspondida do documento traduzido.

Se mode=after, o ponto de inserção é determinado por correspondências de regex de dois passos especificados pelo argumento regex position; e pelo argumento beginboundary ou endboundary.

Como pode haver várias seções para o caso assumido, vamos usar a abordagem de 2 etapas.

     mode=after

position (obrigatório)

Uma regexp Perl para especificar o contexto.

Se mais de uma cadeia de dados interna corresponder a essa expressão (ou nenhuma), a pesquisa pelo ponto de inserção e adição do adendo falhará. Na verdade, é melhor relatar um erro do que inserir o adendo no local errado.

Se mode=before, o ponto de inserção é especificado para ser imediatamente antes da sequência de dados interna que corresponde exclusivamente ao argumento regex position.

Se mode=after, a procura pelo ponto de inserção é reduzida aos dados após a sequência de dados interna correspondendo exclusivamente ao argumento regex position. O ponto de inserção exato é especificado mais adiante por beginboundary ou endboundary.

Em nosso caso, precisamos pular várias seções anteriores restringindo a pesquisa usando a string de título da seção.

     position=Sobre esse documento

(Na verdade, você precisa usar a string do título da seção traduzida aqui, em vez disso.)

beginboundary (usado somente quando mode=after, e obrigatório neste
caso)
endboundary (idem)

Um segundo regexp de Perl é requerido somente quando mode=after. O adendo será colocado imediatamente antes ou depois da primeira cadeia de dados interna correspondente ao argumento de registro beginboundary ou endboundary, respectivamente.

No nosso caso, podemos escolher para indicar o final da secção, nós combinamos por acrescentando:

   endboundary=</section>

ou para indicar o início da próxima secção, indicando:

   beginboundary=<section>

Em ambos casos, nosso adendo vai ser localizado após </section> e antes de <section>. O primeiro é melhor já que ele vai funcionar mesmo se o documento for reorganizado.

Ambas as formas existem porque os formatos de documentação são diferentes. Em alguns deles, existe uma forma de marcar o fim duma secção (tal como o </section>, que utilizamos), enquanto alguns outros não marcam explicitamente o fim da secção (como no manual). No primeiro caso, você quer fazer um boundary correspondente a end de um section, de modo que insertion point vem depois. Neste último caso, você quer fazer um boundary correspondente ao beginning of the next section seguinte, de modo que a insertion point vem pouco antes.

Isto pode parecer obscuro, mas espero que os próximos exemplos vão esclarecer.
Para resumir o exemplo que usamos até agora, a fim de adicionar uma
secção chamada"Sobre esta tradução" depois uma "Sobre este documento"
num documento SGML, você pode usar qualquer uma destas linhas de
cabeçalho:

 PO4A-HEADER: mode=after; position=Acerca deste documento; endboundary=</section>
 PO4A-HEADER: mode=after; position=Acerca deste documento; beginboundary=<section>

Se você quiser acrescentar algo depois na secção seguinte nroff:

  .SH "AUTORES"

Você deve selecionar a abordagem em duas etapas configurando mode=after. Em seguida, você deve restringir a pesquisa à linha após AUTHORS com a regex de argumento position. Então, você deve combinar o início da próxima seção (isto é, ^ \. SH ) com a regex de argumento beginboundary. Isso é para dizer:

 PO4A-HEADER:mode=after;position=AUTORES;beginboundary=\.SH

Se você quiser adicionar algo numa secção (como depois "Copyright Big
Dude") em vez de adicionar uma secção inteira, dê um position
correspondente a essa linha, e dê um beginboundary combinando qualquer
linha.

 PO4A-HEADER:mode=after;position=Copyright Big Dude, 2004;beginboundary=^

Se você quiser adicionar alguma coisa no final do documento, dê uma
position correspondente a qualquer linha do seu documento (mas apenas
uma linha, po4a não continuará se não é única), e dê uma endboundary
sem corresponder a nada. Aqui não use sequências simples como " EOF" ,
mas prefira as que têm menos chance estar no seu documento.

 PO4A-HEADER:mode=after;position=Sobre este documento;beginboundary=FakePo4aBoundary

Em todo caso, lembre-se que estas são expressões regulares. Por exemplo, se você quiser corresponder à extremidade de uma secção nroff terminando com a linha

  .fi

Não use .fi como endboundary, porque vai coincidir com "the[ fi]le", que obviamente não é o que você espera. O endboundary correto nesse caso é: .^\fi$.

Se a adenda não for para onde você esperava, tenta passar o argumento -vv para as ferramentas, para que elas expliquem o que fazem ao colocar a adenda.

Exemplo mais detalhado

Documento original ( POD formatado):

 |=head1 NOME
 |
 |fictício - um programa fictício
 |
 |=head1 AUTOR
 |
 |eu

Então, a adenda a seguir irá garantir que uma secção (em francês) sobre o tradutor é adicionado no final do processo (em francês, " TRADUCTEUR" significa "tradutor" e, "moi" significa "eu").

 |PO4A-HEADER:mode=after;position=AUTOR;beginboundary=^=head
 |
 |=head1 TRADUTOR
 |
 |eu
 |

A fim de colocar a seu adenda antes do AUTOR, use o seguinte cabeçalho:

 PO4A-HEADER:mode=after;position=NOM;beginboundary=^=head1

Isso funciona porque a próxima linha correspondendo ao beginboundary /^=head1/ após a seção " NAME" (traduzido para " NOM" em Francês) é aquela declarando os autores. Então, o adendo será colocado entre as duas seções. Note que se outra seção for adicionada entre as seções NAME e AUTHOR posteriormente, po4a colocará o adendo equivocadamente antes da nova seção.

Para evitar isto, você pode realizar o mesmo usando mode=before:

 PO4A-HEADER:mode=before;position=^=head1 AUTEUR

COMO fazer tudo numa invocação de programa?
O uso de po4a provou ser um erro de pouco propenso para os utilizadores, desde que têm que invocar dois programas diferentes na ordem correta (po4a-updatepo e depois po4a-translate), cada um deles necessitando de mais de 3 argumentos. Além disso, foi difícil com este sistema utilizar apenas um ficheiro PO para todos os seus documentos quando foi usado mais do que um formato.

O programa po4a(1) foi projetado para resolver estas dificuldades. Uma vez que seu projeto é convertido para o sistema, você escreve um ficheiro de configuração simples a explicar onde estão seus ficheiros de tradução ( PO e POT ), onde estão os documentos originais, os seus formatos e onde as suas traduções devem ser colocadas.

Então, ao chamar po4a(1) com este ficheiro assegura que os ficheiros PO são sincronizados com o documento original e que os documentos traduzidos sejam gerados adequadamente. É claro que você vai querer chamar este programa duas vezes: uma antes da edição dos ficheiros PO para atualizá-los e mais uma vez em seguida para obter um documento traduzido completamente atualizado. Mas você só precisa se lembrar de uma linha de comando.

COMO personalizar po4a?
Os módulos po4a têm opções (especificado com a opção -o) que podem ser usadas para alterar o comportamento do módulo.

Você também pode editar o código fonte dos módulos existentes ou até mesmo escrever seus próprios módulos. Para torná-los visíveis ao po4a, copie seus módulos para o caminho "/bli/blah/blu/lib/Locale/Po4a/" e adicione o caminho "/bli/blah/blu" na variável de ambiente "PERLIB" ou "PERL5LIB". Por exemplo:

   PERLLIB=$PWD/lib po4a --previous po4a/po4a.cfg

Nota: o atual nome do diretório lib não é importante

Como é que funciona?

Este capítulo dá-nos uma visão geral interna do po4a, de modo a que você se possa sentir mais confiante para nos ajudar a manter e a melhorar. Pode também ajudá-lo a entender por que ele não faz o que você esperava, e como resolver os seus problemas.

Qual é a grande imagem aqui?
A arquitetura po4a é orientada a objetos (em Perl. Isso não é de bom gosto?). A ancestral e comum a todas as classes de analisadores é chamada TransTractor. Este estranho nome vem do facto de ter a responsabilidade de traduzir documentos e extrair sequências ao mesmo tempo.

Mais formalmente, é preciso um documento para traduzir mais um ficheiro PO contendo as traduções para usar como entrada, enquanto produz duas saídas separadas: Outro ficheiro PO (resultante da extração das sequências traduzíveis no documento de entrada) e um documento traduzido (com a mesma estrutura do que a entrada, mas com todas as sequências de carateres traduzíveis substituídos com o conteúdo de entrada PO ). Aqui é uma representação gráfica deste:

   entrada documento --\                             /---> saída documento
                       \      TransTractor::       /       (traduzido)
                        +-->--  analise()  --------+
                      /                             \
   entrada PO --------/                               \---> saída PO
                                                           (extraido)

Esse pequeno osso é o núcleo de toda arquitetura do po4a. Se você omitir o PO de entrada e o documento de saída, você obtém po4a-gettextize. Se você fornecer ambos ficheiros de entrada e desconsiderar o PO de saída, você obtém po4a-translate. O po4a chama o TransTractor duas vezes e chama msgmerge -U entre essas chamadas do TransTractor para fornecer uma solução completa com um único ficheiro de configuração.

TransTractor::analise() é uma função virtual implementada por cada módulo. Aqui está um pequeno exemplo para mostrar como funciona. Ele analisa uma lista de parágrafos, cada um deles começando com <p>.

  1 sub parse {
  2   PARAGRAPH: while (1) {
  3     $my ($paragraph,$pararef,$line,$lref)=("","","","");
  4     $my $first=1;
  5     while (($line,$lref)=$document->shiftline() && defined($line)) {
  6       if ($line =~ m/<p>/ && !$first--; ) {
  7         $document->unshiftline($line,$lref);
  8
  9         $paragraph =~ s/^<p>//s;
 10         $document->pushline("<p>".$document->translate($paragraph,$pararef));
 11
 12         next PARAGRAPH;
 13       } else {
 14         $paragraph .= $line;
 15         $pararef = $lref unless(length($pararef));
 16       }
 17     }
 18     return; # Did not got a defined line? End of input file.
 19   }
 20 }

Na linha 6 e 7, encontramos "shiftline ()" e "unshiftline ()". Isso ajuda você a ler e não ler o cabeçalho do fluxo interno de dados de entrada do documento mestre na string de linha e sua referência. Aqui, a referência é fornecida por uma string "$ filename:$linenum". Por favor, lembre-se Perl só tem uma estrutura de dados de matriz dimensional. Portanto, os códigos que manipulam a linha de fluxo de dados de entrada interna são um pouco crípticos.

Na linha 6, encontramos <p> para o segundo tempo. Isso é o sinal do próximo parágrafo. Devemos, portanto, colocar a linha que obtemos de volta no documento original (linha 7) e empurrar o parágrafo construído até agora nas saídas. Depois de retirar o líder <p> da linha 9, vamos empurrar a concatenação desta etiqueta com a tradução do resto doparágrafo.

Esta função ’translate’() é muito fixe. Ela empurra o seu argumento para a saída do ficheiro PO (extração) e retorna a sua tradução como a encontra no ficheiro PO de entrada (tradução). Uma vez que é usada como parte do argumento de ’pushline’(), estas regiões de tradução para o documento de saída.

Isso não é legal? É possível compilar um módulo po4a completo em menos de 20 segundos quando o formato é simples o suficiente…

Você pode aprender mais sobre isso em Locale::Po4a::TransTractor(3pm).

Gettextization: como é que funciona?
A ideia aqui é levar o documento original e a sua tradução, e dizer que a enésima sequência extraída da tradução é a tradução da enésima sequência extraída do original. Para isto funcionar, os dois ficheiros devem partilhar exatamente a mesma estrutura. Por exemplo, se os ficheiros têm a seguinte estrutura, é muito pouco provável que a 4ª sequência na tradução (do tipo ’capítulo’) seja a tradução da 4ª sequência no original (do tipo ’parágrafo’).

    Original          Tradução
  capítulo            capítulo
    parágrafo           parágrafo
    parágrafo           parágrafo
    parágrafo         capítulo
  capítulo              parágrafo
    parágrafo           parágrafo

Para isso, os analisadores po4a são usados ​​em ambos os ficheiros, original e a tradução, para extrair ficheiros PO e, em seguida um terceiro ficheiro PO é construído a partir deles tomando as sequências do segundo como a tradução de sequências do primeiro. A fim de verificar que as sequências que são colocadas juntas são realmente as traduções de cada um dos ficheiros, documentos analisados em po4a devem colocar informações sobre o tipo sintático das sequências extraídas do documento (todos os existentes o fazem, o seu também deve). Então, esta informação é usada para certificar que ambos os documentos têm a mesma sintaxe. No exemplo anterior, que nos permitia num caso detetar que a sequência 4 é um parágrafo , e noutro caso um título do capítulo e relatar o problema.

Em teoria, seria possível detetar o problema, e voltar a sincronizar os ficheiros depois (como faz diff). Mas o que devemos fazer das poucas sequências antes da dessincronização não é clara, e iria produzir maus resultados algumas vezes. É por isso que a implementação atual não tenta voltar a sincronizar tudo e falhar com os detalhes quando algo dá errado, exigindo modificação manual dos ficheiros para corrigir o problema.

Mesmo com essas precauções, as coisas aqui podem muito facilmente dar errado. É por isso que todas as traduções supostas desta forma são marcadas como imprecisas (fuzzy) para se certificar de que o tradutor as revê e verifica.

Adenda: Como isso funciona?
Bem, isso é muito fácil aqui. O documento traduzido não é escrito diretamente para o disco, mas mantido na memória até que todas as adendas sejam aplicadas. Os algoritmos envolvidos aqui são bastante simples. Nós olhamos para uma linha que correspondente na posição da expressão regular (regexp), e inserimos a adenda antes, se estamos emmode=before. Se não, vamos procurar a próxima linha correspondente ao limite e inserimos a adenda após esta linha se é um endboundary ou antes se esta linha é um beginboundary.

PERGUNTAS MAIS FREQUENTES

Este capítulo agrupa as perguntas frequentes ( FAQ ). Na verdade, a maioria das perguntas até agora puderam ser formuladas dessa forma: "Porque ele é projetado dessa forma e não dessa outra?" Se você pensa que po4a não é a resposta correta para tradução de documentação, você deveria considerar ler esta seção. Se ele não responder suas perguntas, por favor entre em contato conosco na lista de discussão <devel [AT] lists.org>. Nós adoramos feedback.

Porque se traduz cada parágrafo separadamente?
Sim, em po4a, cada parágrafo é traduzido separadamente (na verdade, cada módulo decide isso, mas todos os módulos existentes o fazem, e o vossos também devem). Existem são duas vantagens principais para essa abordagem:

Mesmo com essas vantagens, algumas pessoas não gostam da ideia de traduzir cada parágrafo separadamente. Aqui estão algumas das respostas que eu posso dar vosso receio:

Porque não dividir em nível da frase (ou menor)?
As ferramentas de tradutor profissional, por vezes, dividem o documento nível da frase, a fim de maximizar a capacidade de reutilização das traduções anteriores e acelerar o seu processo. O problema é que a mesma frase pode ter traduções diversas, dependendo do contexto.

Os parágrafos são, por definição, mais longos do que frases. Esperemos garantir que tendo o mesmo número em dois documentos irá ter o mesmo significado (e tradução), independentemente do contexto em cada caso.

Dividindo em partes menores do que a frase seria very bad. Seria um pouco longo para explicar porquê aqui, mas o leitor interessado pode consultar a página do manual Locale::Maketext::TPJ13(3pm) (que vem com a documentação Perl), por exemplo. Para ser curto, cada idioma tem as suas regras de sintaxe específicas, e não há maneira de construir frases agregando partes de frases trabalhando para todos os idiomas existentes (ou mesmo para 5 dos 10 mais falados, ou até menos).

Porque não colocar o original como comentário, juntamente com a tradução (ou vice-versa)?
À primeira vista, gettext não parece ser adaptado a todos os tipos de traduções. Por exemplo, não parecia adaptado para debconf, o interface que todos os pacotes do Debian usam para sua interação com o utilizador durante instalação. Nesse caso, os textos para traduzir eram muito curtos (uma dúzia de linhas para cada pacote), e foi difícil colocar a tradução num ficheiro especializado uma vez que tem de estar disponível antes do pacote instalação.

É por isso que o developer debconf decidiu implementar outra solução, onde as traduções são colocados no mesmo ficheiro que o original. Isto é bastante atraente. Alguém poderia até querer fazer isso para XML, por exemplo. Ficaria assim:

 <section>
  <title lang="en">My title</title>
  <title lang="fr">Mon titre</title>
  <para>
   <text lang="en">My text.</text>
   <text lang="fr">Mon texte.</text>
  </para>
 </section>

Mas foi tão problemático que uma abordagem baseada em PO é usada agora. Apenas o original pode ser editado no ficheiro, e as traduções devem ter lugar em ficheiros PO extraídos do modelo principal (e colocado de volta no pacote de compilação na hora). O sistema antigo foi substituído por causa de várias questões:

Se vários tradutores fornecerem um fragmento ao mesmo tempo, fica difícil fundi-los.

Como você vai detectar alterações ao original, que precisam ser aplicadas àstraduções? Se usar ’diff’, você tem que anotar que versão do original você traduziu. Ou seja, você precisa de um ficheiro PO em seu ficheiro ;)

Esta solução é viável quando são envolvidos apenas os idiomas europeus, mas a introdução de coreano, russo e/ou árabe realmente complicaram o quadro. UTF poderia ser uma solução, mas ainda há alguns problemas com ele.

Além disso, esses problemas são difíceis de detetar (ou seja, apenas os leitores coreanos irão detetar que a codificação de coreano está partida [por causa do tradutor russo]).

Gettext resolve todos os problemas em conjunto.

Mas gettext não foi projetado para esse uso!
Isso é verdade, mas até agora ninguém apareceu com uma solução melhor. A única alternativa conhecida é a tradução manual, com todos os problemas de manutenção.

E sobre as outras ferramentas de tradução para documentação usando gettext?
Tanto quanto eu sei, existem apenas duas delas:
poxml

Esta é a ferramenta desenvolvida por pessoas do KDE para lidar com DocBook XML. AFAIK, ele foi o primeiro programa para extrair sequências para traduzir de documentação para ficheiros PO, e injetá-las de volta depois de tradução.

Só pode lidar com XML, e apenas um DTD particular. Estou muito descontente com a manipulação de listas, que terminam com um identificador de mensagem (msgid) grande. Quando a lista se torna enorme, o bloco torna-se mais difícil de absorver.

po-debiandoc

Este programa feito por Denis Barbier é uma espécie de precursor do módulo po4a SGML, que mais ou menos o despreza. Como o nome diz, ele trata apenas o DebianDoc DTD, que é mais ou menos um DTD obsoleto.

As principais vantagens de po4a sobre eles, são a facilidade de adição de conteúdos extra (que é pior ainda lá) e a capacidade de atingir gettextization.

Educar os developers sobre tradução
Quando você tenta traduzir a documentação ou programas, você enfrenta três tipos de problemas; Linguística (nem toda a gente fala duas línguas), técnicas (é por isso que existe po4a) e relacional/humano. Nem todos os developers entendem a necessidade de traduzir o material. Mesmo quando de boa vontade, eles podem ignorar como facilitar o trabalho dos tradutores. Para ajudar com isso, po4a vem em muita documentação que pode ser referida.

Outro ponto importante é que cada ficheiro traduzido começa com um curto comentário indicando o que o ficheiro é e como usá-lo. Isso deve ajudar a os pobres developers inundados com toneladas de ficheiros em diferentes idiomas que eles dificilmente falam e, ajudá-los a lidar corretamente com ele.

No projeto po4a, os documentos traduzidos não são mais ficheiros fontes, no sentido que estes ficheiros não são da forma preferencial de trabalho para fazer modificações. Já que isto não é convencional, é uma fonte de erro fácil. É por isso que todos os ficheiros possuem esse cabeçalho:

 |      *****************************************************
|      *          FICHEIRO GERADO, NÃO EDITE               *
|      *   NÃO É UM FICHEIRO FONTE, MAS UMA COMPILAÇÃO     *
|      *****************************************************
|
| Este ficheiro foi gerado por po4a-translate(1). Não o guarde (em VCS,
| por exemplo), mas armazene o ficheiro PO usado como ficheiro de origem por po4a-translate.
|
| De fato, considere isso como um binário, e o ficheiro PO como um ficheiro fonte regular:
| Se o PO se perde, manter esta tradução atualizada será mais difícil ;)

Da mesma forma, os ficheiros PO regulares do gettext só precisam ser copiados para o diretório po/. Mas este não é um dos casos manipulados por po4a. O grande risco aqui é que um developer apaga a tradução existente do seu programa com a tradução de sua documentação. (Ambos não podem ser armazenados no mesmo ficheiro PO, porque o programa precisa para instalar o sua tradução como um ficheiro mo enquanto a documentação só usa a sua tradução na hora de compilação). É por isso que os ficheiros PO produzidos pelo módulo po-debiandoc contêm o seguinte cabeçalho:

 #
 #  AVISO PARA developers:
 #    - não precisam de editar manualmente os ficheiros POT e PO.
 #    - este ficheiro contém a tradução do seu modelo debconf.
 #      Não substitua a tradução do seu programa com isto !!
 #       (ou os seus tradutores irão ficar muito chateados)
 #
 #  AVISO PARA TRADUTORES:
 #    Se não está familiarizado com o formato PO, é melhor ler documentação
 #         gettext, especialmente secções dedicadas a este formato.
 #    Por exemplo, corra:
 #         info -n '(gettext)Ficheiros PO'
 #         info -n '(gettext)Cabeçalho de Entrada'
 #
 #    Alguma informação específica para po-debconf está disponível em
 #            /usr/share/doc/po-debconf/README-trans
 #         ou http://www.debian.org/intl/l10n/po-debconf/README-trans
 #

SUMÁRIO de vantagens da aproximação de base ao gettext

 - https://docs.kde.org/stable5/pt_BR/kdesdk/lokalize/project-view.html
 - http://www.debian.org/intl/l10n/

Mas não é tudo verde e, esta aproximação tem também algumas desvantagens com que temos de lidar.

Um dos meus sonhos seria integrar de alguma forma po4a ao Gtranslator ou Lokalize. Quando um ficheiro de documento fosse aberto, as strings seriam automaticamente extraídas e um ficheiro traduzido + ficheiro po poderia ser gravado no disco. Se nós conseguirmos fazer um módulo para MS Word ( TM ) (ou pelo menos RTF ), tradutores profissionais podem até mesmo usá-lo.

AUTORES

 Denis Barbier <barbier,linuxfr.org>
 Martin Quinson (mquinson#debian.org)