Last modified: 2014-11-17 10:34:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T6125, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4125 - Preserve ?uselang=xx / &uselang=xx during sessions
Preserve ?uselang=xx / &uselang=xx during sessions
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal enhancement with 11 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-01 00:43 UTC by lɛʁi לערי ריינהארט
Modified: 2014-11-17 10:34 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description lɛʁi לערי ריינהארט 2005-12-01 00:43:05 UTC
Hallo!

?uselang=xx / &uselang=xx is a great help also to revert vandalism and to
provide testlinks.

battle against vandalism: For a project you may take a look at a project using
special:RecentRecentchanges?uselang=en .

Then it would be great if uselang=xx could be preserved for all links you click
afterwards (unless you change to uselang=yy). You would neither need to sign not
to add ?uselang=xx to every url.

best regards reinhardt [[user:gangleri]]
Comment 1 Raimond Spekking 2006-10-18 08:51:35 UTC
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.
Comment 2 Daniel Kinzler 2007-04-05 13:09:31 UTC
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.
Comment 3 Mike.lifeguard 2009-04-01 19:15:42 UTC
Wouldn't it be enough to set uselang to cascade such that links you're clicking have that param?
Comment 4 Platonides 2010-03-12 23:23:10 UTC
(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.
Comment 5 Chad H. 2010-03-12 23:26:12 UTC
(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.
Comment 6 Platonides 2010-03-12 23:41:42 UTC
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...
Comment 7 Thana 2010-03-20 04:38:19 UTC
> 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.
Comment 8 Krinkle 2011-01-31 15:25:28 UTC
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
Comment 9 dohnp5a1 2011-05-21 09:43:01 UTC
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).
Comment 10 Platonides 2011-05-21 13:00:48 UTC
What language is your browser *interface* in?

WikiSkripta.eu is not considered. But links fronm cz.wikipedia.org should be taken into account.
Comment 11 dohnp5a1 2011-05-21 13:35:21 UTC
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.
Comment 12 Krinkle 2011-05-21 14:51:26 UTC
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
Comment 13 dohnp5a1 2011-05-21 15:34:41 UTC
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.
Comment 14 Platonides 2011-05-23 21:35:54 UTC
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
Comment 15 Chad H. 2011-05-23 21:47:59 UTC
How is this fixed? The solution in question seems to only apply to commons.
Comment 16 Platonides 2011-05-24 13:53:42 UTC
Soved as in "there's a gadget for this". It could be converted into a extension, if you prefer.
Comment 17 Chad H. 2011-05-24 14:08:56 UTC
uselang is in core, there's no reason this shouldn't be there as well IMO.
Comment 18 Platonides 2011-05-24 14:32:45 UTC
I don't think it's good for core. Perhaps it can get a place inside Extension:LanguageSelector though.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links