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

[Jaromir Hradilek]

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, mhideo at redhat.com wrote:
>>>> On 10/06/2010, at 10:42 PM, Jaromir Hradilek <jhradile at redhat.com>
>>>> 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