[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] User guide's and help system's future
|
Wow guys, lots of good ideas. (I am snipping the occasionaly paragraph
to try and keep the email shorter)
- One week is imho far to less for a new translation. This would work
only if
For a new translation, I agree. However, as you have shown yourself,
it doesn't take that long to translate uDig almost entirely. (The help
system is a little slower) Our French translation took less than a
week as well. But I agree that more warning would be needed.
How much time would be needed? I am really trying to get uDig 1.0 out
the door, it would be okay if some language packs followed the formal
release.
- 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 am afraid we are much smaller project the Open Office. The release
time table was set sometime ago, development has fallen
behind in a few areas as outlined in Milestone 4, and Final Report.
Unfortantly the website was the area hardest hit, with a ripple through
effect on the translations.
- 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.
We can also prioritise translation effort, for example the Getting
Started tutorial is much more important then the introduction to
"concepts".
They use a lot of open source on that website, so their code to
translate their properties might even be available. All that would
need to be done is get it working in SVN.
I would hope that the existing idea of different wiki spaces will prove
sufficient (I would really like to get on to bug fixes, rather than
replace the existing setup for the third time in four weeks).
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.
Right now we do have access controls that can be placed on the wiki.
Right now just signing up is enough to create and edit content (but not
to remove pages). I would be happy to set up separate permissions for
udig-translators or something if this would somehow help?
That is a good idea. Or perhaps just have the translations reviewed
and approved before the release. (Any vandalism that is noticed at
that point can then be reverted)
The process where we export the wiki contents into the eclipse help
system (and check all the table of contents links) should be a good
opertunity to check for vandalism.
.properties files a LOT easier than in Eclipse. (Maybe there's an
eqivalent and
I've just not yet found it?)
There are several translation support plugins for eclipse, I keep asking
Richard to write up a page on them. Sounds like I will need to do this
myself.
Here is one: http://resourcebundleeditor.com/ess/rbe/home.do
That is cool. I will check that out at some point. What I would really
like to see is a closer linking between Java source code and
properties files. For example if you hold control and click on a field
or method in Eclipse, it will take you to that field or method
declaration. It would be nice if you could do this for property keys.
This is done for Eclipse 3.1 M6, I think you hold down option or
something, and you can often see the value from the property file as a
tooltip.
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.
There are a number of interesting things out there, check out this book
(http://www.eclipsefaq.org/chris/faq/) it was written as an eclipse help
system. They made a couple of plugins to support there work. It does not
cover all your requirements but it does a bit.
Somethings on your list, like the system wide CSS are already provide by
the eclipse help system.
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.)
Of course, when we get really close we start making SC (for sanity check
releases),
and we keep making them as every "fix" comes in. But we are in the
danger zone, where
uDig does so much people want it to do more before version 1.0. We will
do our best to
stick to the origional requirements list.
For reference I intend to have a release 1.1 in June for the Mapserver
Users Meeting.
Thanks again for all your help,
Jody Garnett
