This would also be a great help while linking to Commons from other projects. At
the moment the language is lost after clicking e.g. to "login/create user
account". The user has to choose there his language again.

Maybe the solution from r14901 (Introduce optional (off by default) language
selector bar for user login and registration. Customisable via the
"loginlanguagelinks" message, the links will preserve "returnto" values) can be
extended to all kind of uselang-usages.

The "LanguageSelector" extension could be used to achive this -
http://www.mediawiki.org/wiki/Extension:LanguageSelector. You can choos a
language with a setlang parameter in the URL, and it uses a cookie to remember
the interface language for anonymous users (for logged in users, it would change
the language in the user's preferences - which may not be desirable when using
this in links).

This would not be possible on Wikimedia projects though, be cause it doesn't
work right with squid caches. I'm not sure if that's even possible.

mike.lifeguard+bugs wrote:

Wouldn't it be enough to set uselang to cascade such that links you're clicking have that param?

(In reply to comment #3)

Wouldn't it be enough to set uselang to cascade such that links you're clicking
have that param?

That means reparsing the whole contents just to add that parameter. Although you could always use an ugly regex to do that.

(In reply to comment #4)

(In reply to comment #3)

Wouldn't it be enough to set uselang to cascade such that links you're clicking
have that param?

That means reparsing the whole contents just to add that parameter. Although
you could always use an ugly regex to do that.

You could at least handle everything that goes through Linker::link() in one place. Doesn't help for raw <a> though.

You want to fetch the page from memcached, and maybe also the sidebar.
A regex would be able to set the proper uselangs without having to reparse everything. But so ugly resorting to that...

M8R-cyc3n3 wrote:

Wouldn't it be enough to set uselang to cascade such that links you're clicking
have that param?

While waiting for a "real" solution that behavior would be very easy to mimic using javascript, except for a previously unvisited site it would have to come through greasemonkey or wikibits.js.

Preserving &useskin= in the same way(s) would be good too, as long as we're messing with it.

Global prefs for things like this would be ideal.

Since last december a javascript solution[1] has been implemented at Wikimedia Commons.

Short summary:

• puts a dropdown menu in the Sidebar with all supported languages
• Auto-guesses from: cookie (not available on initial visit), then referalwiki, then browser language and finally a fallback to the content language (English in commons' case).
• When current language is different from the one guessed it presents an (internationalized) message on top of the site asking the user if he or she would like to view (Sitename) in the guessed language.
• When coming from a wikimedia wiki the language of that wiki is automatically appended.
• When clicking (not onload) an internal link or external link within WMF it preserves the uselang-setting
• The setting is preserved by a cookie.

[1] http://commons.wikimedia.org/wiki/MediaWiki:AnonymousI18N.js

dohnp5a1 wrote:

I do not think it really works in that way, because:

The only thing improved regarding this is that uselang in links is permanent now during the session.

I have Commons always in English if unlogged, although my browser language setting is cs-sk-eo-de-en.

If I link to WC from a Czech wikiproject (Wikipedia or WikiSkripta.eu) unlogged, I got the interface always in English (if uselang not used).

What language is your browser *interface* in?

WikiSkripta.eu is not considered. But links fronm cz.wikipedia.org should be taken into account.

dohnp5a1 wrote:

My browser interface is in Czech (cs).

If I click (unlogged) on "file description page" in the sentence "This file is from Wikimedia Commons and may be used by other projects. The description on its file description page there is shown below." on a local image page (for instance "http://cs.wikipedia.org/wiki/Soubor:Symbol_kept_vote.svg"), I get Commons in English.

If the language is preserved automatically among Wikimedia project (which doesn't work now), there could be an option of the MediaWiki setting, useful for external wikiprojects, to add uselang to the links from local image pages to Commons. E.g. WikiSkripta.eu, using InstantCommons, need it, because many users there refuse working at Commons, if the interface is in English.

When I browser from http://cs.wikipedia.org/wiki/Soubor:Symbol_kept_vote.svg to http://commons.wikimedia.org/wiki/File:Symbol_kept_vote.svg, AnonymousI18N redirects me to suggestlang (which was set to 'cz', based on the referring wikimedia domain).

Due to a script error this didn't happen in some cases, that is fixed [1] now.

Krinkle

[1] http://commons.wikimedia.org/w/index.php?title=MediaWiki%3AAnonymousI18N.js&diff=54608039&oldid=54460611

dohnp5a1 wrote:

When I browser from http://www.wikiskripta.eu/index.php/Soubor:Symbol_kept_vote.svg to http://commons.wikimedia.org/wiki/File:Symbol_kept_vote.svg, I get the English interface, nevertheless there is a panel above the picture, writing "Wikimedia Commons je dostupné v češtině." (Wikimedia Commons are available in Czech.) and I can click on it to have the Czech version of Commons.

So, the language information is transferred in some way already now – couldn't it be transformed to the interface language directly?

Resumed, there are two parts to sort out, both for unlogged users:

• Commons interface after linking from external wikiprojects.
• Default Commons language neglecting the browser settings.

Links from cs.wikipedia.org are not being translated.

Given your insistence, I have also instructed it about treating www.wikiskripta.eu as Czech.

http://commons.wikimedia.org/w/index.php?title=MediaWiki%3AAnonymousI18N.js&action=historysubmit&diff=54699986&oldid=54699044

How is this fixed? The solution in question seems to only apply to commons.

Soved as in "there's a gadget for this". It could be converted into a extension, if you prefer.

uselang is in core, there's no reason this shouldn't be there as well IMO.

I don't think it's good for core. Perhaps it can get a place inside Extension:LanguageSelector though.