On 06/15/2010 10:13 AM, Jeff Fearn wrote:
I'd give that a very low score on "useful things I could do for
Publican". I'd give it even a lower score on "listening to the users",
there are other requests that have been discussed by a much wider range
of users. I certainly wouldn't stop you from doing it, but there are
many more useful things to do IMHO.
Here are a few ideas I don't have time to implement, all of which I
think are much more useful.
1: Different formatting for article based on class
2: DocBook 5 support
3: Ground work for supporting different XML DTDs, e.g. DITA
4: Ground work for supporting non-XML input, e.g. markdown
5: Ground work for supporting non-PO translations, e.g. XLIFF
6: Replace gettext fuzzy merge with Perl implementation.
7: More ports, e.g. FreeBSD, Mac
8: Replace FOP
Number 1 has been discussed on the list, it's an extremely useful
feature that would benefit many users. There is an experimental brand in
the repo with a very basic attempt at a new article layout, very raw.
This is by far the most requested feature ... well aside from the web
stuff perhaps, but that only started generating feedback after I'd done
most of the work ;)
Number 2 is going to hit us sooner or later, we really need to rethink
how we override the templates, particularly sorting what changes we can
get upstream and separating them from changes that upstream don't want.
This affects all users in the long run.
Number 3 can probably be done by sub classing Builder.pm. Lots of work
required on deciding which bits to split in to the sub classes. Could be
handy, might not be used.
Number 4 could probably take the same approach as number 3, but is
probably somewhat more invasive. Could be handy, might not be used.
Number 5 can probably be done by sub classing, again. We do have some
old code to handle XLIFF, but it needs to be reworked to fit the current
code structure. Could be handy, might not be used.
Number 6 is the only part of gettext we actually use, merging updated
POT files with existing PO files. Replacing this would allow us to drop
the gettext dependency and make supporting other translation formats
easier. Definitely be used, transparent to users though.
Number 7 means a wider user base, FreeBSD for instance uses DocBook for
their docs, but they aren't as pretty as ours. Should be easy to whip up
a brand once the port is done.
Number 8 PLEASE! I've looked on and off ever since we started using it
and I haven't found anything that can replace it, but it's the number
one source of configuration issues and weird behavior, so either
supporting another FO processor, or simply replacing it, would be a God
send. FYI on RHEL 6 Publican is locked to i386 and x86_64 arches because
of the FOP dependency :(
There are a few other things that are crying out to be done, but off the
top of my head this is what came to me. They are all much more worthy of
your time than catering to people who are challenged by typing --lang,
IMHO.
Thanks, Jeff,
Good list.
I guess we should start on #1 and work our way down the list.
- Mike
_______________________________________________
publican-list mailing list
publican-list@redhat.com
https://www.redhat.com/mailman/listinfo/publican-list
Wiki: https://fedorahosted.org/publican
