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

[Jiri Vanek]

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

Not sure how much is Jie native speaker .. . But good to have an volunteer O:)

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

This is refreshing idea, but have several drawbacks. The Translator is responsible  for delivering 
message from proeperties to target, according to language.
It should have  nothing to do formating.  We breake this principle on places, where the output 
should be html. It is saving a lot of work, so afiak it is ok. But translator itself have nothing to 
do with formatting.

So although current doc provider is using translator to get sentences or titles, it is responsible 
for collecting sentences to  paragraphs, adding headers, headlines and footers and adding, based on 
formatter, add correct formatting.

J.