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

[Jeff Fearn]

On Sat, 2010-06-12 at 21:23 +0200, Jaromir Hradilek wrote:
> On 06/12/2010 04:07 AM, Joshua Wulf wrote:
> >
> >>> What about a warning message, something like ``A single language
> >>> expected, using --lang instead''?
> >> I think the generic "that parameter can't be used with this action" is
> >> pretty clear. Again, to harp on, if you say --langs is a valid
> >> parameter, then you have to support people supplying a list of
> >> languages. Generating an error for a valid parameter that has a valid
> >> format is a bug.
> >>
> > Can we make it prompt for the parameter if it is not supplied? That way
> > I don't have to think about lang or langs, I just type the thing in when
> > it asks for it.
> >
> > Publican create would also be great with a wizard-like interface.
> 
> Personally, I don't think this is something Publican should ever do, as 
> applications with interactive prompt are harder to use from scripts, not 
> to mention counter-intuitive if they do not do so consistently. This is 
> an ideal task for a wrapper, though.
> 
> By the way, I am starting to think that implementing a full featured 
> interactive prompt in the best spirit of git-sh [1] would be cool. 
> Having all defaults set and current language displayed as a part of the 
> prompt, you could just type ``test'', ``build'', ``package'', and so on, 
> or even use configurable aliases like ``te'', ``bu'', or ``pk'' 
> respectively.
> 
> [1] http://github.com/rtomayko/git-sh
> 
> Regards,

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.

Cheers, Jeff.

-- 
Jeff Fearn <jfearn at redhat.com>
Software Engineer
Engineering Operations
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY

Sure our competitors can rebuild the source but can they engage the customer the same way? -wmealing