On Tue, 20 Jul 2004, Martin Quinson wrote:
> > > > But if I had to redo the man module now, I'd
go for docbook-like tag intead
> > > > of pod notation. But I don't plan to change that for now...
> > >
> > > I think this isn't necessary by now.
> >
> > It could be made an option, but the issue is that if the author makes its
> > pot with one notation and the translator with another, you'll get fuzzies.
>
> I think we should take an arbitrary decision and don't include this
> option, to avoid this issue about the fuzzies (and to reuse translations
> between projects, where each one could use a different option).
>
> Then, we should decide between one of these:
> 1) we use the same tag syntax for all the modules: this makes po4a more
> consistent (now that it's easy to mix more than one document format
> with po4a(1)), and maybe some translations could be reused between
> formats
> 2) each module can use its own format tagging: it makes modules easier to
> write
>
> In my personal opinion, I also like the docbook tagging more than the pod
> one. I'd like to follow the 1) option, although it's a lot of work for
> reworking the current man/pod modules.
>
> > Unless you implement also a on the fly convertion, but I'm not sure it
> > worths the work.
>
> It's an unnecesary complication.
I agree that 1) is the best, at the first glance.
It wouldn't be that difficult to do in the Man module. There is already a
conversion between the native representationS from/to the pod one. Changing
it would be rather easy.
Borrowing this into the pod module wouldn't be that hard either.
And since po4a is getting used outthere, I'd say that we do have to
implement this as an option, with the on-the-fly conversion. That's not very
difficult either.
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...)
But, you'll get ugly results if you have to mix between native formatting
and common formatting. I mean, let's say we use the pod formating. How to
deal with the (sg|x)ml "<a href=toto><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)
I know that we would not take pod as common format, and that all marker of
pod/man can be formated to ml ones, but it will change when another module
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?
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 ;)
- 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.
- get ride of nsgml
This should be easy using the Xml module when it gets mature :)
- 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, for
example, you can have almost the whole document in one line, and you
should put the addendum there in the middle.
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...
Just my opinion ;)
Regards,
Jordi Vilalta