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

[Jie Kang]

----- Original Message -----
> 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.

You misunderstood me. I meant we ourselves shouldn't write typos and push them into the repo. Since we're in direct control of the directory name we shouldn't be making typos and so the -p issue shouldn't be a worry. I didn't mean the code should check for typos.


Regards,

> 
> >
> > 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
> 

-- 

Jie Kang