[Po4a-devel]Winedocs and Po4a dependencies

Martin Quinson martin.quinson@loria.fr
Thu, 26 May 2005 19:49:44 +0200


--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2005 at 05:52:39PM +0200, Francois Gouget wrote:
>=20
> For the Wine project we are trying to make it as easy as possible for=20
> Wine contributors to modify and rebuild the Wine documentation. The Po4a=
=20
> dependencies have caused some concern in this regard: for each=20
> dependency the contributor will have to track down which package to=20
> install for his distribution and this makes the initial setup=20
> significantly harder.
>=20
> Po4a being not very widespread we have checked it in the Winedocs CVS=20
> (http://cvs.sourceforge.net/viewcvs.py/wine/docs/). But Po4a has quite a=
=20
> few dependencies so this does not help very much. So now we are hoping=20
> to make it possible to reduce the number of po4a dependencies. Here is=20
> the list I came up with, together with some notes for each of them:
>=20
>=20
>  * Locale::gettext (perl module)
>    Needed by po4a for localization.
>    Provided by liblocale-gettext-perl on Debian, perl-Locale-gettext on=
=20
> Mandrake and Fedora Core(DAG), perl-gettext on SUSE.
>=20
>    Would you be open to a patch that acted as a wrapper around=20
> Locale::gettext so that po4a would continue to work untranslated if that=
=20
> module was missing?
>    The idea we would add a 'Po4aGettext' module that would export=20
> gettext() and dgettext() functions. These would try to load=20
> Locale::gettext in an eval function and use it if that succeeds.=20
> Otherwise the Po4aGettext would simply return the untranslated strings.=
=20
> The only changes to the other Po4a modules would be replacing 'use=20
> Locale::gettext' with 'use Po4aGettext'.

Ok. Great. It could even be done by default in the Common.pm module, which
would then export the d?gettext functions. Impact on other parts would be
the need to kill the explicit gettext loading.

>  * Text::WrapI18N (perl module)
>    Pure perl (so easy to check in) but depends on Text::CharWidth which=
=20
> is not pure perl.
>    Provided by libtext-wrapi18n-perl on Debian. Found no RPM packages=20
> providing it.
>=20
>    Text::WrapI18N was not used in po4a 0.16.2. I initially thought it=20
> was used to wrap the text being output to the .po and .sgml files but in=
=20
> fact it seems to only be used to print messages, warnings and errors.=20
> Why is it needed? Doesn't a simple print work fine?

This module becomes important when you want to wrap CKJ languages
(japaneese, corean), which don't have any spaces, if I understood well. So
finding where you can cut the sentence properly is not as easy as in, say,
french.

So, actually, we *ought* to use it all around the place. Maybe through a
wrapper such as the one you propose for gettext...

>  * Term::ReadKey (perl module)
>    Provided by libterm-readkey-perl on Debian, perl-Term-ReadKey on=20
> Mandrake and Fedora Core(DAG), perl-TermReadKey on SUSE.
>=20
>    This module is used to determine the size of the terminal. This=20
> information is then used by the wrap functions.

But if it's not there, things should still work, using 80 as terminal size.=
=20
=20
>  * SGMLS (perl module)
>    Needed by po4a to interface with the nsgmls parser.
>    Pure perl (so easy to check in).
>    Provided by libsgmls-perl on Debian, perl-SGMLSpm on Mandrake and=20
> Fedora Core, perl-SGMLS on SUSE.
>=20
>    This is an essential part of po4a. The easiest way to remove this=20
> dependency would be to check it into the Winedocs repository. So no=20
> action needed on the Po4a side.
>=20
>  * nsgmls (command line tool)
>    Needed by po4a to parse the Sgml files.
>    Provided by sp on Debian, sgml-tools or openjade on Mandrake and=20
> Fedora Core, opensp on SUSE.
>=20
>    This is an essential part of po4a. So it will have to remain as a=20
> dependency which is reasonable.

Actually, I'd like since a long time to kill this one, changing it to an
home-made parser such as the one used in xml or so...


Bye, Mt.

--ikeVEW9yuYc//A+q
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)

iD8DBQFClgw4IiC/MeFF8zQRAqI0AJ9LdduBGrUjvhYYVeXVKCNb3hiSawCgpBCz
/lO9eXJeHbYNSFyDpcFcSwg=
=/ygP
-----END PGP SIGNATURE-----

--ikeVEW9yuYc//A+q--