[Foundation-l] Re: Rethinking Meta (was- Wikiquote now has subdomains)

[Erik Moeller]

Daniel-
> If there is a problem with naming conflicts, then that is a very good reason
> to have separate wikis.

The distinction between "separate wikis" and "one wiki" is a lot blurrier  
than you describe it. Having proper multilanguage support within a single  
installation would lead to a setup very similar to our current one from  
the user POV, but with a lot of advantages which come with having a single  
database (e.g. it becomes very easy to have combined RC, watchlists,  
single sign-on etc.).

> That problem does not really exist for meta, wikisource, and wikibooks.

Naming conflicts are largely independent of the purpose of the wiki; the  
larger a wiki gets the more likely they will become. Right now you could  
have a "Merchandising (German)" and a "Merchandising (English)" page, for  
example, but that is really just a workaround for a proper design and it's  
going to bite us in the ass sooner or later (e.g. template names are  
usually short and likely to cause conflicts).

The current MediaWiki design - separate installation for each language -  
was flawed from the start. It has served us reasonably well, but if we  
redesign it, we should do it properly.

> In short, I think we should only divide things up
> if there is a compelling reason. Meta in *particular* is there for
> multiproject and multilingual coordination. How is that coordination going
> to happen on separate wikis?

The only compelling reason for having separate wiki installations is that  
it is the only way for the current setup to achieve
- see only the language you care about
- different language user interfaces (including MediaWiki: namespace)
- standard interlanguage links
- no naming conflicts

These things would be important on Meta as well to encourage international  
cooperation and reduce English dominance, hence my support for subdomains.  
With a properly designed system, we don't need to use separate installs  
for Meta, Wikipedia or any other wiki - they are all going to behave the  
same; you only see the languages you care about. (Emphasis on plural  
here.)

So, for example, when you would go to www.wikimedia.org, it would take the  
preferred language from your browser and show you, e.g.,  
www.wikimedia.org/de/, but prominently show the other languages as well.  
You could set the order in your user prefs if you want. If you create a  
regular link from under de/, it would point to a German page. If you  
create a link from under en/, it would point to an English page. In your  
recent changes view, you would see only the RC for the languages which you  
have set in your browser or MediaWiki prefs.

The only thing that would change about the effective user experience on  
Meta is that it would become a lot more convenient, and that you could  
easily move only in your local language if you want (this is already  
possible in a half-assed way through the localized Main Pages). The  
balkanization you speak of does not exist here. And if you're afraid of  
too much language separation, there's no reason not to allow languages to  
be used liberally, e.g. on discussion pages, even in the subspace which is  
technically French, German or English.

Now, with a separate install, you lose certain functionality, which I  
agree is important, such as having multiple languages in one RC view, and  
having a single login. As Angela pointed out, the current interlanguage  
link system is also needlessly redundant. I can agree that this creates  
more trouble in the short term than it is worth, and that it leads to a  
certain amount of balkanization, although I think that this is being  
exaggerated for dramatic effect.

But then, if you agree that doing a proper multilingual setup for all  
wikis is a good and necessary thing, we should set a sizable bounty on it  
ASAP and do it the right way rather than have ever larger inconsistencies.  
This can be combined with single sign-on at least on a project level,  
something which a lot of people have been waiting for. I would be willing  
to write up a bounty proposal which specifies the necessary functionality  
if there is general agreement that this is what we should do.

Regards,

Erik