[
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:
Hi uDig developer's
Maybe I should have asked that a bit earlier already:
How does the project team suggests that the
- user guide on the web page
- the uDig help and
- their translations
are to be maintained and kept up-do-date in the future?
It is possible to export an entire space as HTML from Confluence. This
is how we will be using the help system in uDig.
I guess we should come up with a policy in regards to translations.
I've read some comments on that in this list and JIRA, but I don't think I've
gotten the overall picture yet. And I'm a bit confused, since the uDig web page
changes its layout weekly (It looks nice now!), and I constantly have to update
links.
The layout should be more or less stable now.
Especially some questions arise to me:
- The wiki user's guide is the basis for the help system, isn't it?
Correct.
- Where should contributers do changes to the user's guide: Should they edit the
wiki, the help system or both?
Contributors should edit the wiki.
- How is a consistent layout guaranteed, especially in a wiki?
This is a tough one. Given the amount of resources available, I am not
sure if this can be absolutely guaranteed. It would be the
responsibility of the contributors (and us, if we have time) to ensure
that the layout is contained. However, I also welcome changes to the
layout when it provides an improvement over the current version.
- It's probably impossible to keep several language version synchronized at all
times. So, how and how often shall the translated versions get updated.
(Usually this happens for every major release.) Should they use the English
version as basis for retranslation every time or should they "just" update
existing translations?
I guess it is time we came up with a policy. Here are my suggestions:
- 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.
- Should the language pack include every language? This is currently
what we are doing, and currently what Eclipse is doing. 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.)
- At the time of the building of the release/language pack, the help
system shall be exported from Confluence into the appropriate help plug-in.
- 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.
Once this is a little more solid, I will make a page on the main wiki
concerning it.
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. 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 :)
Thanks again, your emails have been a great help.
Richard
