On 06/11/2010 12:33 AM, Jeffrey Fearn wrote:
Jaromir Hradilek wrote:
On 06/10/2010 05:49 PM, Jaromir Hradilek wrote:
On 06/10/2010 03:35 PM, [email protected] wrote:
On 10/06/2010, at 10:42 PM, Jaromir Hradilek <[email protected]>
wrote:
On 06/10/2010 12:56 AM, Jeffrey Fearn wrote:
Joshua Wulf wrote:
Another thing I notice is that publican build takes --langs as an
argument, while publican package takes --lang.
Is this because "package" can only do one language at a time, while
"build" can do multiple?
This is correct.
Cheers, Jeff.
That makes sense to me. However, did you consider allowing both --lang
and --langs interchangeably? I mean, it is perfectly OK to document
only one of them where appropriate, but it will definitely spare us
all some otherwise easily avoidable errors.
Feel free to submit a patch :-)
See the attachment! ;-) (Created by typing `diff publican/bin/publican
publican/bin/publican.orig > publican.diff' in the root directory of the
publican's latest SVN snapshot.)
However, I didn't have much time to really familiarize myself with the
source code, so there is probably a smarter way to do this.
Well, the smarter way would be to add the alias directly to the
Getopt::Long options, and then make all functions use the same form,
but I did not want to disturb the semantic distinction between the
singular and plural forms in the code.
Since they parameters do not actually do the same thing ATM, your patch
needs to include:
A: Changes to the Publican::* modules to handle the option they don't
currently support, either lang or langs, they only handle one ATM.
>
> A involves either adding an extra parameter to the functions and making
> sure one of them is supplied, or modifying bin/publican to convert from
> between lang and langs as required.
I believe I already did the latter as you can see near the very end of
my patch. I avoided making any changes in Publican::*, because I am
convinced this is purely a matter of the option parsing and should be
handled by bin/publican itself. Furthermore, making these changes in
Builder.pm would with no doubt worsen its readability.
B: Test cases to prove your changes work.
> B involves adding new parameter combinations to publican/t/900.publican.t
I will take care of that, thanks.
C: Update the documentation
C: Update the POD and maketexts in bin/publican and the User Guide.
Well, as Rudi pointed out somewhere below, I completely agree that the
distinction between plural and singular form is not only important for
the user, but that it should stay the way it is as I suggested in my
initial response.
You see, the trouble with plural and singular forms is that they are
just too much alike, especially when they have basically the same
meaning, and even if you are well aware of the difference between them,
as a human being that uses publican routinely every single day, you are
bound to mistype now and then. What I wanted to accomplish with this was
to avoid these unnecessary errors that don't really help you, but slow
you down a lot. No worries, publican will still complain whenever you
supply multiple languages where only one is allowed.
Anyway, thanks for your fast reply, Jeff.
--
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
