po4av0.69

PO4A

Section: Herramientas de po4a (7)
Updated: 2023-01-01
Index Return to Main Contents
 

NOMBRE

po4a - Un marco de trabajo para traducir documentación y otro material  

Introducción

po4a (PO para todo) facilita el mantenimiento de traducción de documentación utilizando las clásicas herramientas gettext. La característica de po4a principal es que desacopla la traducción del contenido desde su estructura documental.

Este documento sirve como una introducción para el proyecto po4a con un enfoque en usuarios potenciales considerando si utiliza esta herramienta y en la curioso deseo de entender por qué las cosas son de la manera que son.  

¿Por qué po4a?

La filosofía de Free Software , es hacer que la tecnología está disponible a cada uno. Pero la licencia no es la única consideración: el software libre no traducido es inútil para los hablantes no ingleses. Por lo tanto, aún hay tarea que hacer para crear software disponible para todos.

Esta situación es bien entendida por muchos proyectos y cada uno ahora está convencido de la necesidad de traducir todo. Aún, las traducciones actuales representan un enorme esfuerzo de muchos individuales, heridos por pequeñas dificultades técnicas.

Agradecidamente, el software libre se beneficia de un nivel decente de traducción gracias al maravilloso conjunto de herramientas gettext. Éste puede extraer las cadenas a traducir de un programa, presentarlas en un formato uniforme a los traductores, y luego usar el resultado de su trabajo durante la ejecución para mostrar los mensajes traducidos al usuario.

Regarding documentation, however, the situation still somewhat disappointing. At first translating documentation may seem to be easier than translating a program as it would seem that you just have to copy the documentation source file and start translating the content. However, when the original documentation is modified, keeping track of the modifications quickly turns into a nightmare for the translators. If done manually, this task is unpleasant and error prone.

Outdated translations are often worse than no translation at all. End-users can be tricked by documentation describing an old behavior of the program. Furthermore, they cannot interact directly with the maintainers since they don't speak English. Additionally, the maintainer cannot fix the problem as they don't know every language in which their documentation is translated. These difficulties, often caused by poor tooling, can undermine the motivation of volunteer translators, further aggravating the problem.

La ambición del proyecto po4a es facilitar el trabajo de los traductores de la documentación. En particular, crea traducciones de documentación mantenibles.

The idea is to reuse and adapt the gettext approach to this field. As with gettext, texts are extracted from their original locations and presented to translators as PO translation catalogs. The translators can leverage the classical gettext tools to monitor the work to do, collaborate and organize as teams. po4a then injects the translations directly into the documentation structure to produce translated source files that can be processed and distributed just like the English files. Any paragraph that is not translated is left in English in the resulting document, ensuring that the end users never see an outdated translation in the documentation.

This automates most of the grunt work of the translation maintenance. Discovering the paragraphs needing an update becomes very easy, and the process is completely automated when elements are reordered without further modification. Specific verification can also be used to reduce the chance of formatting errors that would result in a broken document.

Por favor, lea también las Preguntas frecuentes, más abajo en éste documento, para una lista más completa de las ventajas y desventajas de este enfoque al problema.  

Formatos compatibles

Actualmente se han implementado satisfactoriamente algunos tipos de formato de texto:
man (intérprete maduro)
El clásico formato de las páginas de manual, usado por muchos programas fuera de allí. La compatibilidad con po4a es bienvenida ya que el formato es algo difícil de usar, y no muy amistoso para los principiantes.

El módulo Locale::Po4a::Man(3pm) además admite el formato mdoc, utilizado por las páginas man BSD (no son muy comunes en Linux).

AsciiDoc (intérprete maduro)
Este formato es un formato de margen ligero entendido para facilitar la autoría de documentación. Es utilizado por ejemplo para documentación del sistema git. Esas páginas man son traducidas utilizando po4a.

Vea Locale::Po4a::AsciiDoc para detalles.

pod (intérprete maduro)
Este es el formato «Perl Online Documentation» (Documentación en línea de Perl). El lenguaje y sus mismas extensiones están documentados utilizando este formato junto la suma de muchos guiones Perl existentes. Hace muy fácil mantener la documentación cerca del código al integrarlos en el mismo fichero. Facilita la vida del programador, pero por desgracia, no la del traductor, hasta que utilice po4a.

Vea Locale::Po4a::Pod para detalles.

sgml (intérprete maduro)
Even if superseded by XML nowadays, this format is still used for documents which are more than a few screens long. It can even be used for complete books. Documents of this length can be very challenging to update. diff often reveals useless when the original text was re-indented after update. Fortunately, po4a can help you after that process.

Actualmente, sólo son compatibles los DTD de DebianDoc y de DocBook, pero añadir compatibilidad con uno nuevo es realmente fácil. Incluso es posible usar po4a con un DTD desconocido de SGML sin cambiar el código introduciendo la información necesaria en la línea de órdenes. Consulte Locale::Po4a::Sgml(3pm) para más detalles.

TeX / LaTeX (intérprete maduro)
El formato LaTeX es un formato de documentación usado principalmente en el mundo del Software Libre y para publicaciones.

Se probó el módulo Locale::Po4a::LaTeX(3pm) con la documentación de Python, un libro y algunas presentaciones.

texto (intérprete maduro)
El formato Texto es el formato base para muchos formatos que incluyen bloques grandes de texto, incluyendo Markdown, fortunes, sección matter de frente YAML, debian/changelog, y debian/control.

Esto admite el formato común utilizado en Generadores de Sitio Estático, README, y otros sistemas de documentación. Vea Locale::Po4a::Text(3pm) para detalles.

xml y XHML (intérprete probablemente maduro)
El formato XML sirve de base para muchos formatos de documentación.

Actualmente, el formato DTD de DocBook (vea L>Locale::Po4a::DocBook(3pm)> para detalles) y XHTML están admitidos por po4a.

BibTex (intérprete probablemente maduro)
El formato BibTex es utilizado a lo largo de LaTeX para listados de formato de referencias (bibliográficos).

Vea Locale::Po4a::BibTex para detalles.

Docbook (intérprete probablemente maduro)
Un lenguaje añadido basado en XML que utiliza etiquetados semánticos para describir documentos.

Vea Locale::Po4a:Docbook para detalles mayores.

Guide XML (intérprete probablemente maduro)
Un formato de documentación XML. Este módulo fue desarrollado específicamente para ayudar con apoyo y mantenimiento de traducciones de documentación de Linux Gentoo hasta al menos en marzo de 2016 (basado en la Máquina Wayback). Gentoo desde entonces se ha migrado al formato XML DevBook.

Vea Locale::Po4a:Guide para detalles mayores.

Wml (probablemente intérprete maduro)
El XML (Web Markup Language), no mezcla WML con la materia WAP utilizada en celdas de teléfonos. Este módulo depende del módulo XHTML, el mismo que dependo del módulo XML.

Vea Locale::Po4a::Wml para detalles mayores.

Yaml (probablemente intérprete maduro)
A strict superset of JSON. YAML is often used as systems or configuration projects. YAML is at the core of Red Hat's Ansible.

Vea Locale::Po4a::Yaml para más detalles.

RubyDoc (probably mature parser)
The Ruby Document (RD) format, originally the default documentation format for Ruby and Ruby projects before converted to RDoc in 2002. Though apparently the Japanese version of the Ruby Reference Manual still use RD.

Vea Locale::Po4a::RubyDoc para detalles mayores.

Halibut (probably experimental parser)
Un sistema de producción de documentación, con elementos similares a TeX, debiandoc-sgml, TeXinfo, y otros, desarrollados por Simon Tatham, el desarrollador de PuTTY.

Vea Locale::Po4a:Halibut para detalles mayores.

Ini (probablemente intérprete experimental)
Formado del archivo de configuración popularizado por MS-DOS.

Vea Locale::Po4a::Ini para detalles más grandes.

texinfo (intérprete altamente experimental)
Toda la documentación de GNU está escrita en este formato (es incluso un requisito para ser un proyecto oficial de GNU). La compatibilidad de Locale::Po4a::Texinfo(3pm) en po4a está en sus inicios. Por favor, remita informes de fallo y peticiones de funcionalidades.
Otros formatos admitidos
Po4a también puede tratar algunos formatos raros o específicos, tales como la documentación de las opciones de compilación de núcleos 2.4+ (Locale::Po4a::KernelHelp) o los diagramas producidos por la herramienta (Locale::Po4a:Dia). Añadir un formato nuevo es a menudo una tarea muy sencilla, y la tarea principal es conseguir un intérprete para el formato escogido. Consulte Locale::Po4a::TransTractor(3pm) para más información.
Formatos no compatibles
Desafortunadamente, po4a aún le falta compatibilidad para formatos de documentación. Muchos de ellos serían sencillos de mantener en po4a. Esto incluye formatos no tan solo utilizados para documentación, como descripciones de paquetes (deb y rpm), guiones de instalación de paquetes , boletines del paquete, y todos los formatos de archivos especializados utilizados por los programas tales como escenarios de juegos o los archivos de recursos de wine.
 

Cómo utilizar po4a

Historically, po4a was built around four scripts, each fulfilling a specific task. po4a-gettextize(1) helps bootstrapping translations and optionally converting existing translation projects to po4a. po4a-updatepo(1) reflects the changes to the original documentation into the corresponding po files. po4a-translate(1) builds translated source file from the original file and the corresponding PO file. In addition, po4a-normalize(1) is mostly useful to debug the po4a parsers, as it produces an untranslated document from the original one. It makes it easier to spot the glitches introduced by the parsing process.

Most projects only require the features of po4a-updatepo(1) and po4a-translate(1), but these scripts proved to be cumbersome and error prone to use. If the documentation to translate is split over several source files, it is difficult to keep the PO files up to date and build the documentation files correctly. As an answer, a all-in-one tool was provided: po4a(1). This tool takes a configuration file describing the structure of the translation project: the location of the PO files, the list of files to translate, and the options to use, and it fully automates the process. When you invoke po4a(1), it both updates the PO files and regenerate the translation files that need to. If everything is already up to date, po4a(1) does not change any file.

The rest of this section gives an overview of how use the scripts' interface of po4a. Most users will probably prefer to use the all-in-one tool, that is described in the documentation of po4a(1).  

Visión gráfica esquemática de los script po4a

The following schema gives an overview of how each po4a script can be used. Here, master.doc is an example name for the documentation to be translated; XX.doc is the same document translated in the language XX while doc.XX.po is the translation catalog for that document in the XX language. Documentation authors will mostly be concerned with master.doc (which can be a manpage, an XML document, an asciidoc file or similar); the translators will be mostly concerned with the PO file, while the end users will only see the XX.doc file.

                                   maestro.doc
                                               |
                                               V
     +<-----<----+<-----<-----<--------+------->-------->-------+
     :                                 |                        |                                         :
{traducción}              |    { actualizar maestro.doc }         :
     :                   |                     |                                                          :
   XX.doc        |                     V                                     V
 (opcional)   |                 maestro.doc ->------->----->+
     :                   |                   (nuevo)                                      |
     V                 V                           |                                            |
  [po4a-gettextize]          doc.XX.po-->+   |                   |
      |  (antiguo)                      |                            |                  |
      |                 ^                       V                          V                  |
          |              |                        [po4a-updatepo]             |
          V             |               |                          V
    traducción.pot       ^                         V                            |
          |                               |                 doc.XX.po                   |
          |              |               («fuzzy» (difusa))                        |
   { traducción }                      |               |                              |
          |          ^                         V             V                                 |
          |          |                    {edición manual}                      |
          |          |                             |                            |                  |
          V         |                            V                          V                  |
      doc.XX.po -------->---->+<---<---- doc.XX.po  apéndice    maestro.doc
      (inicial)                                               (actualizado) (opcional)  (actualizado) 
          :                                        |                         |                        |
          :                                       V                        |                         |
          +----->----->--->------ +                        |                         |
                                                   |                         |                         |
                                                   V                      V                         V
                                                   +------>------+------<---------+
                                                                           |
                                                                          V
                                                            [po4a-translate]
                                                                          |
                                                                          V
                                                                  XX.doc
                                                               (actualizado)

Este esquema es complicado, pero en la práctica solo la parte derecha (relacionando po4a-updatepo(1) y po4a-transalte(1)) es utilizado una vez que el proyecto está instalado y configurado.

The left part depicts how po4a-gettextize(1) can be used to convert an existing translation project to the po4a infrastructure. This script takes an original document and its translated counterpart, and tries to build the corresponding PO file. Such manual conversion is rather cumbersome (see the po4a-gettextize(1) documentation for more details), but it is only needed once to convert your existing translations. If you don't have any translation to convert, you can forget about this and focus on the right part of the schema.

On the top right part, the action of the original author is depicted, updating the documentation. The middle right part depicts the automatic actions of po4a-updatepo(1). The new material is extracted and compared against the exiting translation. The previous translation is used for the parts that didn't change, while partially modified parts are connected to the previous translation with a ``fuzzy'' marker indicating that the translation must be updated. New or heavily modified material is left untranslated.

Then, the manual editing reported depicts the action of the translators, that modify the PO files to provide translations to every original string and paragraph. This can be done using either a specific editor such as the GNOME Translation Editor, KDE's Lokalize or poedit, or using an online localization platform such as weblate or pootle. The translation result is a set of PO files, one per language. Please refer to the gettext documentation for more details.

The bottom part of the figure shows how po4a-translate(1) creates a translated source document from the master.doc original document and the doc.XX.po translation catalog that was updated by the translators. The structure of the document is reused, while the original content is replaced by its translated counterpart. Optionally, an addendum can be used to add some extra text to the translation. This is often used to add the name of the translator to the final document. See below for details.

Como notificado antes, el programa po4a(1) combina los resultados de los script separados, actualizando los archivos PO y el documento traducido en una invocación. La lógica por la que se trata permanece igual.  

Iniciar una nueva traducción

If you use po4a(1), there is no specific step to start a translation. You just have to list the languages in the configuration file, and the missing PO files are automatically created. Naturally, the translator then have to provide translations for every content used in your documents. po4a(1) also creates a POT file, that is a PO template file. Potential translators can translate your project into a new language by renaming this file and providing the translations in their language.

If you prefer to use the individual scripts separately, you should use po4a-gettextize(1) as follows to create the POT file. This file can then be copied into XX.po to initiate a new translation.

  $ po4a-gettextize --format <formato> --master <maestro.doc> --po <traducción.pot>

El documento maestro es utilizado en la entrada, mientras que el fichero POT es la salida de este proceso.  

Integrando cambios al documento original

El guion a utilizar para que es po4a-upgradepo(1) (refiera a su documentación para detalles):

  $ po4a-updatepo --format <formato> --master <nuevo_original.doc> --po <doc_antiguo.XX.po>

El documento maestro es utilizado en la entrada, mientras que el archivo PO está actualizado: es utilizado en entrada y salida.  

Generando un documento traducido

Una vez que ha terminado la traducción, querrá obtener la documentación traducida para distribuirla a los usuarios junto con el original. Para ello, utilice el programa po4a-translate(1) tal como sigue:

  $ po4a-translate --format <formato> --master <maestro.doc> --po <doc.XX.po> --localized <XX.doc>

Ambos el maestro y los archivos PO son utilizados en entrada, mientras que el fichero localizado es la salida de este proceso.  

Al utilizar adenda para agregar texto adicional para traducciones

Agregando texto nuevo para la traducción es probablemente la única cosa que es más fácil en la dirección larga cuando traduzca archivos manualmente :). Esto ocurre cuando desea añadir una sección adicional para el documento traducido, no correspondiente a ningún contenido dentro del documento original. La utilización clásica de caso es dar reconocimientos al equipo de traducción, y para indicar como informar problemas específicos de traducción.

With po4a, you have to specify addendum files, that can be conceptually viewed as patches applied to the localized document after processing. Each addendum must be provided as a separate file, which format is however very different from the classical patches. The first line is a header line, defining the insertion point of the addendum (with an unfortunately cryptic syntax --- see below) while the rest of the file is added verbatim at the determined position.

The header line must begin with the string PO4A-HEADER:, followed by a semi-colon separated list of key=value fields.

For example, the following header declares an addendum that must be placed at the very end of the translation.

 PO4A-HEADER: mode=eof

Things are more complex when you want to add your extra content in the middle of the document. The following header declares an addendum that must be placed after the XML section containing the string "About this document" in translation.

 PO4A-HEADER: position=About this document; mode=after; endboundary=</section>

In practice, when trying to apply an addendum, po4a searches for the first line matching the "position" argument (this can be a regexp). Do not forget that po4a considers the translated document here. This documentation is in English, but your line should probably read as follows if you intend your addendum to apply to the French translation of the document.

 PO4A-HEADER: position=À propos de ce document; mode=after; endboundary=</section>

Once the "position" is found in the target document, po4a searches for the next line after the "position" that matches the provided "endboundary". The addendum is added right after that line (because we provided an endboundary, i.e. a boundary ending the current section).

The exact same effect could be obtained with the following header, that is equivalent:

 PO4A-HEADER: position=About this document; mode=after; beginboundary=<section>

Here, po4a searches for the first line matching "<section"> after the line matching "About this document" in the translation, and add the addendum before that line since we provided a beginboundary, i.e. a boundary marking the beginning of the next section. So this header line requires to place the addendum after the section containing "About this document", and instruct po4a that a section starts with a line containing the "<section"> tag. This is equivalent to the previous example because what you really want is to add this addendum either after "/section"> or before "<section">.

You can also set the insertion mode to the value "before", with a similar semantic: combining "mode=before" with an "endboundary" will put the addendum just after the matched boundary, that the last potential boundary line before the "position". Combining "mode=before" with an "beginboundary" will put the addendum just before the matched boundary, that the last potential boundary line before the "position".

  Mode   | Boundary kind |     Used boundary      | Insertion point compared to the boundary
 ========|===============|========================|=========================================
 'before'| 'endboundary' | last before 'position' | Right after the selected boundary
 'before'|'beginboundary'| last before 'position' | Right before the selected boundary
 'after' | 'endboundary' | first after 'position' | Right after the selected boundary
 'after' |'beginboundary'| first after 'position' | Right before the selected boundary
 'eof'   |   (none)      |  n/a                   | End of file

Hint and tricks about addenda

Remember that these are regexp. For example, if you want to match the end of a nroff section ending with the line ".fi", do not use ".fi" as endboundary, because it will match with "the[ fi]le", which is obviously not what you expect. The correct endboundary in that case is: "^\.fi$".
White spaces ARE important in the content of the "position" and boundaries. So the two following lines are different. The second one will only be found if there is enough trailing spaces in the translated document.

 PO4A-HEADER: position=About this document; mode=after; beginboundary=<section>
 PO4A-HEADER: position=About this document ; mode=after; beginboundary=<section>

Aunque se puede considerar que esta búsqueda de contexto funciona básicamente en cada línea del documento traducido, en realidad funcionan a partir de la cadena de datos interna del documento traducido. Esta cadena de datos interna puede ser un texto que comprende un párrafo de varias líneas, o una etiqueta XML individual. El punto de inserción preciso del apéndice se debe encontrar antes o después de la cadena de datos interna, y no puede encontrarse dentro de la cadena de datos interna.
Pass the -vv argument to po4a to understand how the addenda are added to the translation. It may also help to run po4a in debug mode to see the actual internal data string when your addendum does not apply.

Addenda examples

Si desea añadir algo después de la siguiente sección de nroff:

  .SH "AUTORES"

Debería seleccionar un método de dos pasos definiendo mode=after. A continuación debe reducir la búsqueda a la línea posterior a AUTHORS con la expresión regular de argumento de position. Después, debe hacer coincidir el principio de la sección a continuación (esto es, ^\.SH) con la expresión regular de argumento beginboundary. Esto es:

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

If you want to add something right after a given line (e.g. after the line ``Copyright Big Dude''), use a position matching this line, mode=after and give a beginboundary matching any line.

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

Si desea añadir algo al final del documento, especifique un position que encaje con cualquier linea del documento (pero sólo una línea. po4a no procederá si no es única), y ponga un endboundary que no encaje con nada. No utilice cadenas simples como ``EOF'', sino las que tengan menos probabilidad de salir en el documento.

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

Ejemplo más detallado

Documento original (en formato POD):

 |=head1 NOMBRE
 |
 |relleno - un programa de relleno
 |
 |=head1 AUTOR
 |
 |yo

Luego, el siguiente apéndice asegurará que se añade una sección (en español) sobre el traductor al final del fichero.

 |PO4A-HEADER:mode=after;position=AUTOR;beginboundary=^=head
 |
 |=head1 TRADUCTOR
 |
 |yo
 |

To put your addendum before the AUTHOR, use the following header:

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

Esto funciona porque la siguiente linea que encaja con beginboundary «/^=head1/» después de la sección «NOMBRE», es la que declara los autores. Por lo tanto, se colocará el apéndice entre ambas secciones. Tenga en cuenta que si se añade posteriormente otra sección entre NAME y AUTHOR, po4a ubicará de forma indebida el apéndice antes de la sección nueva.

Para evitarlo, puede lograr el mismo efecto utilizando mode=before:

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

 

¿Cómo funciona?

Este capítulo ofrece una breve explicación del funcionamiento interno de po4a, de forma que se pueda sentir más seguro para ayudarnos a desarrollar y mejorar el programa. También le puede ayudar a entender porqué no hace lo que esperaba, y cómo solucionar sus problemas.

The po4a architecture is object oriented. The Locale::Po4a::TransTractor(3pm) class is the common ancestor to all po4a parsers. This strange name comes from the fact that it is at the same time in charge of translating document and extracting strings.

Más formalmente, toma un documento a traducir, además del fichero PO que contiene las traducciones a usar como entrada mientras produce dos salidas separadas: Otro fichero PO (resultado de la extracción de las cadenas traducibles del documento de entrada), y un documento traducido (con la misma estructura que el de entrada, pero con las cadenas traducibles reemplazadas por el contenido del PO de entrada). Esta es una representación gráfica de este proceso:

   Documento de entrada -\                        /---> Documento de salida
                          \    TransTractor::    /         (traducido)
                           +-->-- parse()  ------+
                          /                       \ 
   PO de entrada --------/                         \---> PO de salida
                                                           (extraído)

This little bone is the core of all the po4a architecture. If you omit the input PO and the output document, you get po4a-gettextize. If you provide both input and disregard the output PO, you get po4a-translate. The po4a calls TransTractor twice and calls msgmerge -U between these TransTractor invocations to provide one-stop solution with a single configuration file. Please see Locale::Po4a::TransTractor(3pm) for more details.  

Open-source projects using po4a

Here is a very partial list of projects that use po4a in production for their documentation. If you want to add your project to the list, just drop us an email (or a Merge Request).
adduser (man): users and groups management tool.
apt (man, docbook): Debian package manager.
aptitude (docbook, svg): terminal-based package manager for Debian
F-Droid website <https://gitlab.com/fdroid/fdroid-website> (markdown): installable catalogue of FOSS (Free and Open Source Software) applications for the Android platform.
git <https://github.com/jnavila/git-manpages-l10n> (asciidoc): distributed version-control system for tracking changes in source code.
Linux manpages <https://salsa.debian.org/manpages-l10n-team/manpages-l10n> (man)

This project provides an infrastructure for translating many manpages to different languages, ready for integration into several major distributions (Arch Linux, Debian and derivatives, Fedora).

Stellarium <https://github.com/Stellarium/stellarium> (HTML): a free open source planetarium for your computer. po4a is used to translate the sky culture descriptions.
Other item to sort out: <https://gitlab.com/fdroid/fdroid-website/> <https://github.com/fsfe/reuse-docs/pull/61>
 

Preguntas frecuentes

 

How do you pronounce po4a?

I personally vocalize it as pouah <https://en.wiktionary.org/wiki/pouah>, which is a French onomatopoetic that we use in place of yuck :) I may have a strange sense of humor :)  

¿Qué hay de las otras herramientas de traducción de documentación que usan gettext?

There are a few of them. Here is a possibly incomplete list, and more tools are coming at the horizon.
poxml
Esta es la herramienta desarrollada por la gente de KDE para tratar DocBook XML. Me parece que este fue el primer programa que extrajo cadenas de texto a traducir desde la documentación a ficheros PO, e inyectarlas de vuelta después de la traducción.

Únicamente puede tratar XML, y solo un DTD en particular. Estoy bastante insatisfecho con el tratamiento que hacen de las listas, que terminan en un único msgid. Cuando la lista crece, el bloque se hace difícil de tratar.

po-debiandoc
Este programa hecho por Denis Barbier es un tipo de precursor del módulo SGML de po4a, que más o menos lo deja obsoleto. Como su nombre indica, únicamente trata el DTD de DebianDoc, que es más o menos un DTD anticuado.
xml2po.py
Used by the GIMP Documentation Team since 2004, works quite well even if, as the name suggests, only with XML files and needs specially configured makefiles.
Sphinx
The Sphinx Documentation Project also uses gettext extensively to manage its translations. Unfortunately, it works only for a few text formats, rest and markdown, although it is perhaps the only tool that does this managing the whole translation process.

Las principales ventajas de po4a sobre ellos son la facilidad de adición de contenidos extra (que es aún peor ahí) y la habilidad de realizar la gettextización.  

RESUMEN de las ventajas de la metodología basada en gettext

Las traducciones no se guardan junto con el original, lo que hace posible la detección de traducciones anticuadas.
Las traducciones se guardan en ficheros separados unos de otros, lo que impide que traductores de diferentes idiomas interfieran en su trabajo tanto al enviar parches, como a nivel de codificación de ficheros.
Está basado internamente en gettext (pero po4a ofrece una interfaz muy simple de forma que no necesita entender el funcionamiento interno para usarlo). De esa forma no tenemos que reinventar la rueda, y debido a su uso extendido podemos imaginar que estas herramientas están más o menos libres de fallos.
Para el usuario final nada ha cambiado (aparte de que, probablemente, las traducciones estarían mejor actualizadas :). El fichero de documentación resultante es exactamente el mismo.
No hace falta que los traductores aprendan una nueva sintaxis de fichero, y sus editores favoritos de ficheros PO (como el modo PO de Emacs, Lokalize o Gtranslator) servirán a la perfección.
gettext ofrece una manera simple de conseguir estadísticas sobre qué está hecho, qué se debería repasar y actualizar, y lo que queda por hacer. Puede encontrar algunos ejemplos en estas direcciones:

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

Pero no todo es bonito, y este enfoque también tiene algunas desventajas con las que debemos lidiar.

Los apéndices son… extraños a primera vista.
No puede adaptar el texto traducido a su gusto, como dividir párrafos por aquí, y juntar esos dos allí. Pero por supuesto, si hay algún problema con el original debería remitir un informe de fallo.
Incluso con una interfaz fácil, sigue siendo una nueva herramienta que la gente debe aprender.

Uno de mis sueños es integrar de alguna forma po4a con Gtranslator o Lokalize. Cuando se abra un fichero, se extraen las cadenas automáticamente, y se puede escribir en el disco un fichero traducido y un fichero PO. Si consiguiéramos hacer un módulo para MS Word (TM) (o al menos RTF) incluso podrían usarlo traductores profesionales.

 

VÉASE TAMBIÉN

The documentation of the all-in-one tool that you should use: po4a(1).
La documentación del script individual po4a: po4a-gettextize(1), po4a-updatepo(1), po4a-translate(1), po4a-normalize(1).
The additional helping scripts: msguntypot(1), po4a-display-man(1), po4a-display-pod(1).
Loa analizadores de cada formato, en particular para ver las opciones aceptadas por cada uno de ellos: Locale::Po4a::AsciiDoc(3pm) Locale::Po4a::Dia(3pm), Locale::Po4a::Guide(3pm), Locale::Po4a::Ini(3pm), Locale::Po4a::KernelHelp(3pm), Locale::Po4a::Man(3pm), Locale::Po4a::RubyDoc(3pm), Locale::Po4a::Texinfo(3pm), Locale::Po4a::Text(3pm), Locale::Po4a::Xhtml(3pm), Locale::Po4a::Yaml(3pm), Locale::Po4a::BibTeX(3pm), Locale::Po4a::Docbook(3pm), Locale::Po4a::Halibut(3pm), Locale::Po4a::LaTeX(3pm), Locale::Po4a::Pod(3pm), Locale::Po4a::Sgml(3pm), Locale::Po4a::TeX(3pm), Locale::Po4a::Wml(3pm), Locale::Po4a::Xml(3pm).
The implementation of the core infrastructure: Locale::Po4a::TransTractor(3pm) (particularly important to understand the code organization), Locale::Po4a::Chooser(3pm), Locale::Po4a::Po(3pm), Locale::Po4a::Common(3pm). Please also check the CONTRIBUTING.md file in the source tree.
 

AUTORES

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

 

TRADUCCION

 Jordi Vilalta <jvprat@gmail.com>
 Omar Campagne <ocampagne@gmail.com>


 

Index

NOMBRE
Introducción
¿Por qué po4a?
Formatos compatibles
Cómo utilizar po4a
Visión gráfica esquemática de los script po4a
Iniciar una nueva traducción
Integrando cambios al documento original
Generando un documento traducido
Al utilizar adenda para agregar texto adicional para traducciones
¿Cómo funciona?
Open-source projects using po4a
Preguntas frecuentes
How do you pronounce po4a?
¿Qué hay de las otras herramientas de traducción de documentación que usan gettext?
RESUMEN de las ventajas de la metodología basada en gettext
VÉASE TAMBIÉN
AUTORES
TRADUCCION

This document was created by using the manual pages.
Time: 01:12:36 GMT, January 01, 2023
català Deutsch English Esperanto español français hrvatski Magyar Italiano 日本語 Bokmål Nederlands polski Português Português (Brasil) Русский српски језик український 简体中文 简体中文 (how to set the default document language)