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

[Jacob Wisor]

On 09/19/2014 at 10: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. Typos shouldn't be a worry since we should in theory never accept things with typos.

Right. Besides, HTML_DOCS_TARGET_DIR, PLAIN_DOCS_TARGET_DIR, and/or 
MAN_DOCS_TARGET_DIR may have been defined before make is invoked, or at make's 
invocation.

> 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

Yes please. Message.properties is full grammar mistakes which sometimes even 
cause semantic mistakes. Of course, you are free to fix /all/ or /any/ of the 
grammar mistakes, regardless of their origin or connection to any specific 
changeset. ;-) Thank you for taking care of this.

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

The simplest and possibly most consistent approach to get rid of those awful 
@TAG@ tags is just to allow man page formatting in message strings and have them 
removed by the lately introduced Translator. Now, I am unaware whether the text 
providers depend on the Translator too. If they do the Translator's kind of 
getText() method could be overloaded with one that has an additional boolean 
parameter which causes the man formatting to be preserved or ignored. Then the 
text providers could set this parameter to true when generating documentation. I 
do not know, it is just an idea.

Jacob