[Po4a-devel]Sharing bold/emphasis marker between modules

martin.quinson@free.fr martin.quinson@free.fr
Sun, 25 Jul 2004 13:52:36 -0700


Quoting Jordi Vilalta <jvprat@wanadoo.es>:

> On Tue, 20 Jul 2004, Martin Quinson wrote:
>
> Ok, then we should define a common option for all the modules like
> "sgmlize", and every module make his conversion. Just choose a name and
> document it (and put the implementation on the TODO list :P)
>
> We also should define some common tags (like <b> for bold, etc...)

I'd prefer to keep po4a format agnostic. The Right Format(tm) is very muc=
h like
a religion question. It's impossible to make everybody happy.

> > But, you'll get ugly results if you have to mix between native format=
ting
> > and common formatting. I mean, let's say we use the pod formating. Ho=
w to
> > deal with the (sg|x)ml "<a href=3Dtoto><b>bla</b></a>"
>
> We won't be able to manage these things, just leave them as they are
> (consider the string with <a> different than another that doesn't have =
the
> <a>, don't have the same meaning)

That's not an option here. Either we convert everything, or we convert no=
thing.
That was the point of my previous mail, sorry for being so elusive.

Since we cannot come up with a format which will make everybody happy, an=
d not
even with a format which may contain all the weirdness of all existing fo=
rmats
out there, I would prefer to keep those convertions to the very strict mi=
nimum.

Read: I don't want to do any such conversion beside of the the Man format=
, where
the native format is soo counter intuitive, user unfriendly and dying any=
way.

> > I know that we would not take pod as common format, and that all mark=
er of
> > pod/man can be formated to ml ones, but it will change when another m=
odule
> > for a more complete format gets finally implemented (texinfo comes to
> > mind)...
>
> I haven't used it. Would it be so difficult to "convert" it from/to ml?

Pretty damn complex, indeed. texinfo share caracteristics with [La]TeX. T=
here is
a complete math formating stuff, complex table formating, cross-reference
support, and even the possibility to program macro in order to extend it.

XML does all this, but just with a completely different syntax/philosophy=
.
That's not a surprise that no good converter for those system exist. It m=
ay be
doable, but that's at least a 2 month work. I don't have that amount of t=
ime.

> > Moreover, my current concern with po4a are:
> >  - getting new blood here. New users, new contributor, new feedback.
>
> Yes, I don't know why there's so few people around po4a, in the near
> future EVERY project should use it ;)

I hack around po4a since a very long time, but it's usable by others only=
 since
recently. One of the showstopper was also the fact that it was debian onl=
y
until you fixed the build mecanism.

> >  - put the file inclusion into the main modules
> >  - encoding
>
> I think it's a basic issue in translation. I haven't worked with
> cyrilic/asian/etc. languages, but I think this is basic for them.

Yeah, exactly. As long as this is not addressed, those guys cannot use po=
4a.

another issue seems to be that gettext expect the text to translate to be=
 ASCII
formated. It seems to choke on UTF encoded strings (such as when the text
contain the name of a guy with strange chars in it).

> >  - get ride of nsgml
>
> This should be easy using the Xml module when it gets mature :)

I'm hopping so !

> >  - texinfo module
> >  ...
>
> I think it also would be interesting to change the addendum format and
> make each format module to handle them. I haven't used them yet, but it
> seems it's applied after/before a line found by regexes. In (sg|x)ml, f=
or
> example, you can have almost the whole document in one line, and you
> should put the addendum there in the middle.

But Sgml.pm will "normalize" the file, ie, put <section> alone on its lin=
e and
so on... Of course you can write your whole document on one line, but you=
 don't
have to. And if you do so anyway, you won't be able to use po4a addendums=
.

It looks like a fair deal to me. Likewise, groff allows you to switch dir=
ectly
from bold to emphasis without coming back to roman. Something like:
  \fBbold\fEemphasis, but not bold\fR roman again.
And if you do so, po4a yiel at you. You should write:
  \fBbold\fR\fEemphasis, but not bold\fR roman again.
ie, close the bold before opening the emphasis.


I want to keep po4a modular, and make sure that adding a new format remai=
ns as
easy as possible. I'm not speaking about adding a new xml dtd, W but a br=
and
new format such as Debian and RPM package description, Debian changelogs =
(there
is a big need for this one), debconf templates (in order to merge po-debc=
onf
and po4a), kernel 2.6 options (they changed it again), python documentati=
on and
so on.

So the trend is to move more stuff from the modules to the core (file inc=
lusion,
for example. groff allows file inclusion, but Man.pm doesn't). What you p=
ropose
whould go in the other direction. And after the po4aization of the Perl
documentation, I'm ok with the addendums again. They do their job rather =
well,
and I cannot think about an easier way to express what they have to expre=
ss.

If you have better ideas, of course, I'd be glad to hear about.

> This issue about the addendums, the encoding one and the "sgmlization"
> should be kept in mind before the crowd begins using po4a, so we don't
> fuzzy all their translations after a hard work...

Agreed.

> Just my opinion ;)

Thanks for expressing it. I'm glad to hear about it. Even if I don't agre=
e with
everything, the discussion is always good.

Thanks for your time,
Mt.