Re: [udig-devel] User guide's and help system's future

[Matthias Basler <Matthias.Basler@xxxxxxxxxxx>]

Richard wrote:

The suggestions you made are a good start. Let me add my thought to this. As a
loose contributor to OpenOffice I will give some reference how this is or seems
 to be handled there.

> - At some point, a call is made out for translations. Presently this
> could be done at the actual time of release, and that probably works
> best for us at Refractions. Ideally, the call would be made about a week
> before the release,  but this would require a code/ui freeze. The
> advantage of having the translations ready at release time is that they
> can be included in the release. Otherwise, an additional language pack
> would have to be created.

- One week is imho far to less for a new translation. This would work only if
(a) it can be assured that translators with time are at hand for all languages
or (b) that the current one only needs some update.

- Code freeze: yes. Actually I'm a bit surprised that uDig RC's are out already
at this state, but developements and new features are still added. I got used
to the fact (e.g. from OpenOffice) that Betas (and especially Release
candidates) mean that
  (a) no new features will be added till the release
  (b) The release is considered to be free of major problems
  (c) The api is stable
  (d) Bug tracking gets priority and
  (e) Translation work can start and will not be hindred by code changes.
In a project as big as OOo this means two months or so from the beta to the
final version - enough time for translations.

> [...] But this means we cannot ship the language pack until every
> language has been translated.
> My vote here is for separate language packs, one per
> language. This could be done through use of fragments.
> (udig/trunk/fragments/de/, udig/trunk/fragments/fr/, etc.)

There are pros and cons for both.
- separate language packs mean a lot (!) more fragments to maintain and to
synchronize - too much for my liking if I were the one to maintain the SVN.
- separate language packs mean smaller downloads - one just downloads the
language of choice.
- I would'n consider it a problem if language packs get released with a higher
frequency than the main program. For example. uDig could oringially come with
EN and FR when they are ready. When, lets say, German is ready and some errors
in the EN and FR translations are fixed a new language pack release comes out.
- Given the above there is no general problem in putting all languages in one
release and re-releasing it whenever a new language is added.

Personally I prefer to do it like Eclipse, because I consider it impossible to
maintain 100+ translation fragments at a time.

> - Whether to use the English as basis for retranslation should be left
> up to the individual contributor, I believe. Updating existing
> translations should be sufficient, as long as they are still accurate.

Agree.

> What I would really like to see is a web interface (like a wiki) sitting
> on top of SVN that would allow someone to come along and add to the
> translations, without requiring SVN access.

Yes, I already thought about this SVN problem as well.
I wouln't like to have access to the main program - especially as a newby to
CVS. But it would be comfortable to have access to the translation fragments.
I believe it should in principle be possible to restrict access to different
directories with different passwords .. or create two repositories, one for the
program and one for the translations.
Actually I think of a CVS (as SVN) of being close to a wiki where everybody can
contribute, but errors or even deliberate damages can be undone (... though I
might misjudge the SVN security features.)

If someone monitored the "translation part" of the SVN to correct potential
misuse, it could maybe get opened for contributors that demand access to it by
sending an "applying email" to the developer news group.
It's just an idea ... that's how getting privileges works at OpenOffice.org.

> Also, I would really like to see better support in Eclipse's JDT for
> internationalization. Some tools could easily eliminate many of the
> problems you have highlighted (such as duplication of values). Maybe
> I will get some free time at some point and implement these :)

YES!

Netbeans has an own editor for .properties files, where the keys can f.e. get
sorted by names and double keys cannot get entered. This makes maintaining the
.properties files a LOT easier than in Eclipse. (Maybe there's an eqivalent and
I've just not yet found it?)

For the help files I am dreaming of a "help editor" plugin for Eclipse that
works as good as JavaDoc. Features I would like to see:
- Graphical "overview page" that shows representations of the pages and the
links between and allows easy reordering (UML diagram-like).
- Refactoring. If a page gets deleted/remaned all references to it get
removed/renamed too.
- Help-wide style settings, e.g. using CSS or whatever.
- Graphical GUI for editing the help texts, similar to a graphical web page
editor or a word processor.
- Automatic Table of contents generation
- Possibility to set up "TODO"s, e.g. if help pages are still missing for a
feature.

If I were a computer scientist I would try to find some sponsor and do this as a
project. Unfortunately I'm geographer, and building help editors does not quite
match this field...

-----

P.S. Could you please notify me 2-3 days before uDig 1.0 final goes out, so I
can clean up the German translation (e.g. remove unnecessary files) and send
you an updated version? (This obviously applies only if you consider shipping
uDig 1.0 already together with the German translation.)

Matthias Basler
c9bama@xxxxxxxxxxx


----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de