On Monday 30 November 2009 15:31:48 HKairpost wrote:
Anne Wilson wrote:
As our wiki grows I become more aware that any
major re-organisation
needs doing now, before it becomes impossible. With that in mind I've
taken the first steps in categorizing the pages. I've been looking at
extensions that provide navigation aids, and see that category pages are
essential to most of those. That brings up this very thorny question of
language pages.
Unless something is done about it, the Welcome page could have 20 or more
entries on its category page, depending on how active our translators
have been. This clearly gets to the point where the page is unreadable.
I'm as well questioning multilanguage/translation support in the wiki i
maintain.
For now we are using subpages (/de, /fr, /nl, etc.) as on
mediawiki.org.
I think it is a good solution if you want to keep one language as a
reference (ie: English). That is to say that most translations are
branched off english pages and that most of the new content is added in
English.
This is exactly how the Translate extension works, and so far feedback from
our test translators has been good. We have a few issues to iron out, but
nothing that looks impossible.
I think that's close to what you are doing for
KDE. If you don't want to
use categories for languages it might work for you to use subpages.
I think we may well go down the path of having categories for translated
pages. The list of categories will be uncomfortably long, but really that
doesn't get used much. The payoff would be that a category link would only
show the pages that are in the correct language. This seems the simplest
solution.
Issue we face is: translators don't know which
english page isn't
translated yet or isn't sync anymore with the english one. Translators
have to create
http://wiki/pagename/es, copy english content, start
translating. In other words, it doesn't favor casual translation.
If you use the Translate extension pages are marked as needing updates when
something changes. However, you can't mix casual translation and the
controlled translation that the extension gives. OTOH, you can translate
single paragraphs at a time, which may be helpful to some translators.
It has been
said to me that we should be using namespaces for languages,
and that doing that would mean that in a search, for example, only pages
in your system language would be returned. I've only just started
reading the documentation, but I get the impression that this is not so.
If it is possible to cinfigure it that way that would for sure be
interesting. But it doesn't ease going back and forth between
english/other language.
No. I'm still thinking about it, but I'm not convinced that it is the
right
answer.
I should add
that we are sandbox testing the use of the translatewiki
extension and are currently considering the changes needed before
implementation.
Any feedback?
Several small things that people have asked about, but the only big thing has
been that one of our major translators remarked that with slow upload links,
the need to upload each section separately can be frustratingly slow. This is
exactly what I thought when I experimented with it, too. Against that,
though, it is thought that keeping translations up to date will be a great
deal easier, and after all, it's only when you have a complete new page to
deal with that the upload problem is big.
Apart from
http://www.mediawiki.org/wiki/Manual:Namespace and the pages
linked from there, is there any other reading that I should be
considering?
you might consider one wiki for each language + interwiki links, as
wikipeadia. But it might implies that content in different languages
goes in different directions. Maybe not the best for software
documentation.
Yes, something similar was proposed early on, and I opposed it because I felt
that it was very likely that the individual language sections would not carry
the same information. Not really what we want to achieve :-)
Anne
--
KDE Community Working Group
New to KDE4? - get help from
http://userbase.kde.org