[Pkg-shadow-devel] Solution to translate shadow documentation

[Martin Quinson]

--pY3vCvL1qV+PayAL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 23, 2005 at 11:56:30AM +0100, Tomasz K?oczko wrote:
> On Mon, 21 Mar 2005, Christian Perrier wrote:
>=20
> >=20
> > > I plan convert all shadow man pages documentation to XML (this is much
> > > more commont format for documentation) and prepare translation framew=
ork
> > > basing on this source form. Probably will be used gnome-doc-utils (or
> >=20
> > ....which does not prevent using PO format for documentation
> > translation. The PO format is *designed* for translation handling,
> > with good handling of "upstream" changes and impact on
> > translations. All free software translation teams use PO tools for
> > handling translation work because of the wide availability of tools
> > and utilities (compendium, dictionaries, automation tools, web
> > translation projects such as Pootle....)
>=20
> You are wrong.
> You can use:
> - XML (refentry) as source format,
> - gnome-doc-utils for sucking .po file for translators and for track all=
=20
>   changes on this level for keep in synced form man pages in all=20
>   avalaible translations,
> - use .po files with translations for generate non-english XML files,
> - use XSLT for generate roff files.

Sure, that's just what Christian proposed. Why is he wrong?
=20
> This guarangis *one common man pages stilistics*. Also allow use XML
> format as installabe form in future when like in Solaris man program will=
=20
> handle man pages also in SGML.

I see this as somehow unrelated, but I may be wrong (see below).

> I'm not perform yet some experiments but probably for generate .po files
> from XML rerfentry can be used plain gettext because xgettext can handle
> XLM files (I don't know now is it can handle refentry).

Were did you get this information from? From the info xgettext, the list of
supported format are:=20
-L NAME'
--language=3DNAME'
     Specifies the language of the input files.  The supported languages
     are `C', `C++', `ObjectiveC', `PO', `Python', `Lisp', `EmacsLisp',
     `librep', `Smalltalk', `Java', `JavaProperties', `C#', `awk',
     `YCP', `Tcl', `Perl', `PHP', `GCC-source', `NXStringTable', `RST',
     `Glade'.

(xgettext (GNU gettext-tools) 0.14.1)

> If it will work now po4a will be redundant. If not probaly it will require
> some additional work on gettext level (which will be very good invesment
> also for other projects).

I guess it won't work because if it did, it would indeed make po4a redundant
with gettext regular tools and I did check before investing so much time
into this project ;) I guess that the authors of poxml did the same, too. As
well as the gnome-doc-utils authors, which you plan to use.


I must confess that I'm a bit lost here. You say at the same time that po4a
is redundant with regular gettext tools and that you plan to use a concurent
solution (xml2po, from gnome-doc-utils).=20

I'm perfectly ok with po4a not getting used in shadow, but could you please
explain why (so that we get a chance to improve po4a, if needed/possible)?


Thanks for your time,
Mt.

--pY3vCvL1qV+PayAL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCQVKrIiC/MeFF8zQRAgQPAKDVWf0aYayrlvqeYGekkuviSX5F0QCglox5
OLRY1iKGL9SV0tyKcNhoceM=
=7gl6
-----END PGP SIGNATURE-----

--pY3vCvL1qV+PayAL--