Language specific wiki subdomains

Anne Wilson annew at kde.org
Sun Jan 4 19:32:10 UTC 2009


My gut reaction to all this is to have caution.  While I sympathise with the 
concern, I'm just not comfortable that we have the right solution here.  I've 
been talking to danimo about this, and his reponse gives some interesting 
alternative proposals, so I'm going to quote it whole for discussion:

<quote>
First of all I dislike the idea of simply putting disjoint mediawikis under 
different language domain specific URLs. opensuse has done this and it lead to 
the fact that one mediawiki doesn't know how recent the other language wikis
are. The result is that if a page is outdated relative to its english main 
page.

I would prefer if we went to make Mediawiki language aware. Yes, that means 
somebody has to sit down and write code that allows to use domain parts as 
namespaces. FWIW, it shouldn't be too hard to do. That would allow us to 
properly track the state of wiki articles and have one wiki, with one site to 
maintain and update.

The obvious alternative is not to force any binding between languages, 
something that a lot of language teams prefer. The usual argument is: "What if 
an article does not exist in english and the contributor isn't capable of 
translating it". However I think a completely disjoint like this is even 
worse, unless we implement a mandatory review for aging articles (not a bad 
idea anyway, now that I think of it).

Now for your specific questions:

Am Freitag 02 Januar 2009 schrieb Anne Wilson:
> All of you know much more about the nuts and bolts of UserBase than I do. 
> I sympathise with this idea, but my first thoughts follow - they may be
> totally irrelevant, but that's why I'm asking for opinions.
>
> If we accepted the idea of a sub-domain for fr., would that mean that we
> *have to* rather than *might choose to* move other other-language pages to
> separate domains?

Yes.

> Can fr. pages be simply re-routed through the language template, so that
> users don't need to be aware of it?

Probably, but I would hate to make exceptions just for one language. However 
the fr team is welcome to test drive (and in first place: contribute to ;) a 
proper solution.

> Frederic seems willing to take over maintenance of a fr. subdomain.  Would
> we need other volunteers for other languages, or could they simply continue
> as at present?

No, IMHO rerouting would be more of a hassle than it's worth in the current 
state of affairs. Really. let's not do this.

> My concern from the start of the discussion about inputting in native
> languages was that the information would not be passed back to other
> languages.  I think that would be a great loss.  Do you see any way around
> this?

Currently, edits can be flagged as "minor". Maybe that can be extended to 
indicate what kind of changes have been made compared to the "master article", 
i.e. "sync with master article", "additions to master article that need to be 
added there", etc. This way we could automatically visualize what state the 
article is in. For the master article (or even all language versions?), we 
could introduce ratings so if it gets poor ratings or "expires", it gets on a 
list for review to make sure it's still up to date.

> What other issues do you see?

See above.

So what I see:

1. discuss what would really help us (I really appreciate the expirience of 
the l10n teams here)
2. talk to a mediawiki dev on what's useful, sensible and would be accepted 
upstream
3. Find a guy to implement it
4. Have the French l10n team test-drive the thing

Daniel
</quote>

The technical issue are beyond me, but I'd like you to discuss these ideas.  
Hopefully I'll be able to follow and maybe even contribute something :-)

Anne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.kde.org/mailman/private/kde-www/attachments/20090104/8e4e12aa/attachment.sig>


More information about the kde-www mailing list