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

[Jeffrey Fearn]

Jaromir Hradilek wrote:
> 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.

If you are going to allow people to pass in --langs as a valid parameter 
then you have to support supplying multiple languages, not just cater 
for people providing a single language with --langs.

You can't just pass in multiple languages to a function expecting a 
single language, you need to either flag it as an error before you get 
to the function, or split them up and loop around the call, or modify 
the function to handle multiple languages.

I expect if you pass multiple languages in to some functions that expect 
a single language you will get odd message, maybe like:

en-US,fr-FR is not a valid language

or it may work, and you will have one fancy language code!

Simply copying langs to lang isn't robust, at the least it will lead to 
people asking "if I can use --langs why can't I supply more than one 
language?"

Cheers, Jeff.

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