[
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
|
Matthias Basler wrote:
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.
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.
- 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.
I would love it if we followed this more closely for uDig.
[...] 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.
I think it might be manageable with some decent scripts that can be used
to manipulate the fragments, for example if they need a specific field
updated. I have already created a (basic) script that will make nl1
fragments that don't already exist.
Also having one monolithic language pack like Eclipse simplifies the
release process, but it is definately less flexible.
- 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.
SVN does support restricting access based on directories. I wonder if it
can do this based on file names (*.properties, etc.)? The issue can be
avoided with a web interface though.
See this website:
http://home.unilang.org/main/translations2.php?state=list&lng=de
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.
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.)
Most wikis are backed by a revision system, so your thoughts are very
close to reality :)
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.
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)
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?)
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.
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.
This would be really cool. The wiki does give us some of this
functionality though, namely refactoring.
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.)
Shall do! It currently looks like it will be three weeks from now.
Matthias Basler
c9bama@xxxxxxxxxxx
----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel