[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-www
Subject:    Re: translation extension? (was: Re: techbase wiki question)
From:       Dominik Haumann <dhdev () gmx ! de>
Date:       2007-04-07 22:28:38
Message-ID: 200704080028.40001.dhdev () gmx ! de
[Download RAW message or body]

On Thursday 05 April 2007, Stefan Monov wrote:
[...]
> > So we have two approaches:
> > 1. Use templates
> > The <translate...> will go into a template to be reuable, but that is
> > what we have now.
>
> Hmm, doesn't this _still_ have the same disadvantage of keeping things in
> sync?

Yes. that's what I meant with 'that is what we have now' ;)

> > 2. Hard code the number of languages in the <translate/> template.
> > Example: You translate the MainPage, thus you add <translate/> to the
> > MainPage and MainPage_(de). Say we have 20 languages, then the MainPage
> > and MainPage_(de) will have a bar with those 20 languages, all but de
> > and en links to non-existant pages. This is a bit fuzzy imo.
>
> Not sure what you mean by fuzzy, but it would certainly irritate
> visitors.

I'm thinking of something like this: The translation bar shows all available 
languages, along with a "More..." link. Clicking on the link will 
unfold/show all other languages. I'd grab a list of all available languages 
from http://websvn.kde.org/trunk/l10n-kde4/subdirs?view=markup
That are ~50 languages. I'm not sure whether this really makes sense. To 
reduce this we also could add languages on request only.

The usage will look like this: add <i18n />
That's everything. Redlinks (nonexistant pages) are hidden by default. This 
will work well with the slight disadvantage that you have to update/purge 
the cache manually. But that's not that bad, as the pages are edited anyway 
over time.

Btw, there is a disadvantage with our current naming scheme. Take the 
following example:
(1) Development
(2) Development/Tutorials
Translated they would look like this:
(3) Development_(de)
(4) Development/Tutorials_(de)

(4) generates backlinks from the german to the english page 'Development'. 
That does not really matter (we can hack mediawiki to generate correct 
backlinks if translations exist, I guess ;) ). The problematic part is (3) 
imo, as adding a mediawiki link like [[/Subpage]] will result in
(5) Development_(de)/Subpage
and that's not what we want, right? (*) ;) It's not that bad, but it means 
people will do that and we have to fix it manually everytime.

(*) Development_(de)/Tutorials_(de) and
    Development/Tutorials_(de) will probably both be created, ugh...

Thoughts? :)

Dominik
PS: I already have something working, let's call it a prototype ;)
_______________________________________________
kde-www mailing list
kde-www@kde.org
https://mail.kde.org/mailman/listinfo/kde-www
[prev in list] [next in list] [prev in thread] [next in thread]