[Po4a-devel]Encoding stuff breaks po4a(1)

Martin Quinson mquinson@ens-lyon.fr
Mon, 16 Aug 2004 17:01:55 -0700


--0lnxQi9hkpPO77W3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 16, 2004 at 02:53:06AM +0200, Jordi Vilalta wrote:
> On Sat, 14 Aug 2004, Martin Quinson wrote:
>=20
> >We need a way to pass the charsets values on the command line or within =
the
> >config file (or boths).
> >
> >The command line approach is trivial if we're ok to have the same encodi=
ng
> >for all files. The config file is not very difficult under the same
> >assumtion.
>=20
> This can be an easy solution for a near release.

done.

> >If we remove this assumption, it becomes more difficult. Very difficult
> >indeed, check the code of po4a.
>=20
> For future releases we should go through this approach.

Yup, the current situation is crude. Enough for now, but hackish.

> As I said some days ago:
>=20
> >This would also take to a redesign of the po4a config files, since we ne=
ed=20
> >to specify more information there. This could be done together with the=
=20
> >TransTractor redesign explained in the "Future directions" section. Well,

This redesign is not really related. It would allow to deal with formats we=
re
all translations end in the same generated document. It implies a
modification for the Transtractor structure, but not really to the
configuration file, I guess.

> >we should leave all this for a future release... but we should begin=20
> >thinking about it ;)
>=20
> When dealing with... say 10 languages, and for each file of each language=
=20
> you need to specify the output file, the output encoding and one or more=
=20
> addendums (maybe something more in the future), this makes long lines in=
=20
> the config file, very hard to deal with.
>=20
> I think we should separate all this in lang-file blocks to make it more=
=20
> clear, and together with this, think on how to pack all this information=
=20
> to pass it to the "new" transtractor.

Maybe. The content of this file is not very difficult, but what we want to
express is a matrix of setting (masterfile x language), which is not trivial
in a linear file. It would be cool to be able to give defaults values, too.
Such as "use this addendum for all files of this language".

A tree based vision, such as xml (yurk) or apt config files may help or make
things even worse. I dunno.=20

apt-like would be:

potfile =3D po/perl-doc.pot;
pofile =3D {
  fr =3D po/perl-doc.fr.po;
};

addendum::fr::* =3D po/fr/addendum.generic;
addendum::fr::"perl.pod" =3D po/fr/addendum.generic po/fr/addendum.perl.pod;

master =3D {
  perl.pod =3D {
    format =3D pod;
    encoding =3D isolatin-1;
}; };
master::"perltoc.pod"::format =3D pod;
master::"perltoc.pod"::encoding =3D ascii;

fr::*::encoding =3D utf8;

This one seems powerfull enough, but harder to implement...

As I said before implementing po4a(1), the most difficult task here is to
come up with a config file format people can understand.

> By now, use the first approach and document the current limitation (we=20
> have to release this week ;)

Yeah, you are right.

--=20
Le sens commun n'est pas si commun.
  -- Voltaire
[Common sense is not so common]

--0lnxQi9hkpPO77W3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFBIUrzSJAMsfOxudIRAqg7AJ0Qh7C2PqBIoaRkPi9NSRSQH7qaCACfYSbB
fpHNt6GYK1+3x4eYMZI5tdw=
=XZKX
-----END PGP SIGNATURE-----

--0lnxQi9hkpPO77W3--