[rfc][icedtea-web] localizable Plugin+settings+fix+cleanup

[Andrew Azores]

On 09/19/2014 04:52 PM, Jie Kang wrote:
> ----- Original Message -----
>> ...
>>>> +    mkdir -p $(DOCS_DIR) ; \
>>>> +    HTML_DOCS_TARGET_DIR=$(DOCS_DIR)/html  ; \
>>>> +    PLAIN_DOCS_TARGET_DIR=$(DOCS_DIR)/plain ; \
>>>> +    MAN_DOCS_TARGET_DIR=$(DOCS_DIR)/man/  ; \
>>>
>>> Drop the trailing slash.
>>
>> fixed
>>>
>>>>       mkdir $$HTML_DOCS_TARGET_DIR ; \
>>>>       mkdir $$PLAIN_DOCS_TARGET_DIR ; \
>>>> -    mkdir -p $$MAN_DOCS_TARGET_DIR ; \
>>>> +    mkdir $$MAN_DOCS_TARGET_DIR ; \
>>>
>>> Why did you remove the "-p" switch? It is probably best to have this switch
>>> almost always on in
>>> scripts to avoid running into errors just because of non-existing parent
>>> directories.
>>
>> I prefer opposite. To not use -p. If some typo seek in, then it can create
>> whole branch in some
>> really strange lcoation...
> Hello,
>
> I would also prefer a consistency in the makefile for mkdir using -p. When you use it in one place and not in another, it leads viewer to wonder why it's needed in one place and not in another. This means extra work to figure out the reason. Maybe some comments in-file here could help? If the only reason to not use '-p' is because typos would cause weird things to happen, then I would keep the -p.

Generally agreed here. I'd also lean on the side of consistency, 
although I do also think Jiri's motivation for removing it does make 
sense. As "risky" as the -p switch may be in case of the arguments to 
mkdir being incorrect, I think it's still acceptable if you're always 
essentially in direct control of those arguments. If the directory path 
was coming from a user then yea definitely don't put a -p there, but if 
it's just given a default value from the Makefile, or some non-default 
from configure because a developer wants it somewhere else... then I 
think it's reasonable to assume that the input is relatively "sanitized" 
already.

>Typos shouldn't be a worry since we should in theory never accept things with typos.

Really not agreed here. How exactly are we supposed to detect, let alone 
even decide on accepting, what is a typo when attempting to create a 
directory given only its name? To me this is a ludicrous proposition. 
It's completely context dependent. You can try to deem a location as 
being a "typo" if its parents don't yet exist and the -p switch isn't in 
use, but this is not actually equivalent to being a typo. It's just a 
weak-ish heuristic for it.

It's one thing to simply assume that there aren't typos but that isn't 
the same as asserting that typos will be rejected.

>
> I think some of the strings in Message.properties can be reworded to fix grammar mistakes and help formatting but that can be done in another patch. I will probably submit some changes to the strings myself :D
>
> Apart from that it seems okay. I haven't thought of any good solutions to the issue with @BOLD_OPEN, etc. but I will keep thinking.
>


Thanks,
-- 
Andrew Azores