[SSSD] [PATCH] Make manual pages translatable

Jakub Hrozek jhrozek at redhat.com
Wed Dec 1 12:06:20 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/30/2010 12:51 PM, Stephen Gallagher wrote:
> On 11/30/2010 01:42 AM, Jakub Hrozek wrote:
>> > Utilizes PO4A to extract translatable strings from Docbook XML sources
>> > and allows translators to submit ordinary .PO files. PO4A then generates
>> > translated Docbook documents that can be used to generate translated end
>> > user documentation.
>> >
>> > https://fedorahosted.org/sssd/ticket/297
>> >
>> > The second patch adds a skeleton of Czech translation I used for testing
>> > -- at least one man page is localized so the whole process is testable.
>> >
>> > The general approach is based on what some of the Debian-based projects do.
>> >
>> > I have two questions about the patch:
>> >
>> >  * the way the patch is written now, the localized manpages (and the
>> > respective xlm sources) are generated during every "make" invocation --
>> > so they are always in sync. I couldn't decide it makes more sense to add
>> > a specialized "docs" and "docsinstall" targets or something
>> > similar..which would be trivial to do, I'm just not sure whether it's
>> > better or worse than keeping things done with "make all".
>> >
> Please use the existing PO files as a guideline. We only regenerate the
> .po files during a "make dist", because we don't want them to constantly
> be cluttering our git status.
> 

OK, done

> Please make the new targets for updating the po files as a dependency on
> the update-pot target in po/Makefile if possible.

Done

> This way, they're only
> generated during "make dist". This will be behaving the same way that
> the current translatable files do.
> 

The difference is that there are actually two generated files - the
translated XML files and the actual manpages. The translated XML files
are kind of middle step, because we can for instance decide to build
translated HTML or PDF documentation. See below.

> It will be the release engineer's responsibility to build these
> translated manpages and commit them at the string freeze.
> 

I agree that this should be done for .PO files. But I think that the
translated XML files should be generated from .PO translations and the
original XML files during build. Because all information about the
structure of the documents is in the original XML files and translations
are in .PO files, the translatex .XML files are redundant and only .PO
files need to be distributed.

The attached patch does that and has a special "make
translated-manpages" target that is called in the specfile. I would
probably prefer to name it "make docs" and have the doxygen target be
called "make apidocs", but that's a detail.

> "make install" should just use whatever previously-generated PO files
> are available.
> 
> 
>> >  * the .po files are distributed, not the localized .xml sources. I
>> > think it makes more sense since the localized .xml sources are generated
>> > from the .po files and the original .xml sources anyway, but it would be
>> > easy to change the distribution to .xml and only regenerate the .xml
>> > sources when releasing a new upstream
>> > tarball.
> We need to make sure the po files are distributed, otherwise Transifex
> won't work.
> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkz2OjwACgkQHsardTLnvCW+vwCg3nX4sQbon9bq3tq/REheFeSq
kcwAnRZ//laBsVl1Ch+1zU6SaHuRzq2L
=RFfb
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-manual-pages-translatable.patch
Type: text/x-patch
Size: 9173 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20101201/65b3b4bd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-manual-pages-translatable.patch.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20101201/65b3b4bd/attachment.sig>


More information about the sssd-devel mailing list