[rfc][icedtea-web]Localized Man Page Script

Jiri Vanek jvanek at redhat.com
Wed May 21 07:56:15 UTC 2014


On 05/20/2014 09:53 PM, Andrew Azores wrote:
> On 05/20/2014 03:52 PM, Jie Kang wrote:
>> Hello,
>>
>> I've made all the suggested fixes and am working on the makefile at the moment.
>>
>> Thanks,
>>
>>
>
> Looks good to me. Please post the new patch when you have your script integrated and tested working
> in the Makefile.
>
> Thanks,
>


hi!

The creepy voice from behind the sea have nasty words to say :(

I'm afraid we ca not use this approach. And as it is it must not be pushed.

The original idea of this feature was to *reuse* already existing, localized properties files.
Also it was intended to share output between manpages *and* applications (javaws, policieditor, 
itw-settngs) --help option. Also maybe add icedtea-web manpage, and (probably) also have an 
possibility to generate more then man pages - eg html "man pages" or whatever.

You can see that -help swihhc already  provides eg full list of programs switches, or some about 
sntences....

Well your approach do not  implement any of this.  Well, as opposite it  file new file to localize 
and even more fiels to maintain.

My original idea on this to have java based generator, included in netx itself.
Its "main" class will be able to :
  - be called during the build (just put $CLASSES to CLASSPATH and invoke main)
    - generate man pages in reqested language
    - genreate html man pages (well I think there is some man2html, so maybe this is waste of 
everything)
   - the html files may save as base for help in gui modes
  - be called from javaws/itwsettings/policieditor and so
    - generate -help output
  - implementation detail - do not add "language swithc" generate files baed of currently set LOCALE
  - much more :)

As benefit you will get
  - all the messages will come form properties
   - only properties to maintain!
  - parsing of properties in free - unicode support, and insertion of parametres from JDK itself
  - improved -help output (from man pages)
  - improved manpages form -help outputs
  - list of all switches
  - all default file locations!
  - get rid of about/help code from main classes of itw
  - much more;)

If some messages are in man pages, but not in properties, you can add them into proeprties, but 
please verify that there is no similar in properties. And of course vice versa.

Well most of http://icedtea.classpath.org/wiki/IcedTea-Web#Release_Plans since 1.3 are mostly 
somehow inserted by me. Sometime from need, sometimes from wish (feel free to add yours, or suggest 
modifications!)  But pelase, always consult a bit before first patch. Mostly IRCis enough :)

Sorry for this email:( But this is really stop show for this approach).

Please try to post the patch ins small hunks, but it can be harder  then write patch itself, andnot 
always possible, or meaningful.
I hope I havenot forget something :( But we can tune it during the process. But I'm afraid nowyou 
are dammed to wait with final push on this topic to me  returned from PTO :o)

All the best!
  J


Few notes to code itself just "education purposes":
  - changelog - the first line of changes should be caption. Eg "Added generator of man pages" for 
this particualr setthsi

date-name-email
[emtyline]
[tab]caption
[tab]* file:changes


In changelog - always clearly say that it is new file. like
[tab[ * file: new file, its purpose


I'm not sure how good templates for man pages will be suitable in java based solution.. Well then 
may be. We will see. I hoped to have some class like "Content provider" which will use some class 
"markup" and together they will provide
  - context of desired verbosity
  - marked in markup you wont

You can think about it as execise from some "system architecture"  because it is isolated system in 
netx :) (whch you are designing from ground)

In case of template - I would suggest %{key} rather then simple @KEY (although for your sh based 
solution @KEY is most correct)

Otherwise splendid work on code, and sorry for wasting it:(



More information about the distro-pkg-dev mailing list