[publican-list] --lang vs --langs

[Mike Hideo]

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