-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/02/2010 09:21 AM, Stephen Gallagher wrote:
On 12/01/2010 07:06 AM, Jakub Hrozek wrote:
> 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.
Nack. Doesn't compile. Looks like you forgot to include LINGUAS.
I take that back. I see it's supposed to be using $(srcdir)/po/LINGUAS,
however something is broken, because 'make distcheck' fails with:
(cd src/man && make top_distdir=../../sssd-1.5.0
distdir=../../sssd-1.5.0/src/man \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=:
distdir)
/bin/sed: can't read ../../../src/man/po/LINGUAS: No such file or directory
make[1]: Entering directory
`/home/bos/sgallagh/workspace/sssd/x86_64/src/man'
make[1]: *** No rule to make target `../../../src/man/po/sssd-docs.pot',
needed by `distdir'. Stop.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAkz3rF0ACgkQeiVVYja6o6O7EACfahiauUF9Ev3jM2YZTu2b1qzP
i78An3W9Nb3juA8yiSZkIwQ/VEvjBpjI
=oZ9f
-----END PGP SIGNATURE-----