On 06/15/2010 02:13 AM, Jeff Fearn wrote:
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.
Surprisingly enough, I would give that the same score as you. ;-) It was
more an idea for a third party utility than something you (or anyone
else doing the heavy lifting) should bother with.
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.
As intriguing as it sounds, I am not convinced whether it is such a good
idea to hack this into Publican itself. You see, lightweight markup
languages such as Markdown are much less semantic than DocBook, not to
mention troublesome to parse properly and/or validate. They are great
for articles and shorter texts, but I probably wouldn't dare to write
technical book in one.
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 :(
Wouldn't it be possible to isolate it somehow, so that the FOP
dependency could be omitted on other architectures than i386 and x86_64?
Being unable to export to PDF would be a small sacrifice for having the
possibility tu use Publican everywhere, I think.
Another possibility might be to implement a TeX or LaTeX source as a
possible target format. If properly done, the typographical quality of
the produced PDF might then increase astronomically.
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.
This is certainly an impressive list, thanks for sharing those ideas.
Regards,
--
Jaromir Hradilek
Associate Content Author
Engineering Content Services
Red Hat Czech s. r. o.
Purkynova 99, 612 45 Brno
Phone: +420 532 294 326
_______________________________________________
publican-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/publican-list
Wiki: https://fedorahosted.org/publican
