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 <[email protected]> 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 _______________________________________________ publican-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/publican-list Wiki: https://fedorahosted.org/publican
