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
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,
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
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.,
, 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.