enable setting language preference without requiring login
Closed, ResolvedPublic

Description

Why can't MediaWiki do like all major sites' software, and allow setting
the interface language without requiring the user to establish an account?

Observe the bottom of e.g.,
http://www.facebook.com/
http://www.flickr.com/
http://www.youtube.com/
Each has a language selector that doesn't require login.
http://www.couchsurfing.org/
even puts it right at top.

Yes, patient users can set their language preference in Preferences.
But what about read-only sites? I.e., What should one suggest on
http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation
to say to users who wish to view in a different language?
Painfully suffix "?uselang=..." to the end of each URL they browse?

One might argue "users will confuse MediaWiki uselang= with
XX.wikipedia.org languages" ... well they haven't yet with the language
choice in Preferences.

I'm not saying rip it out of Preferences. I'm saying add an additional
way to set it for even non-logged in users, just like the aforementioned
"real websites" do.

Also consider the current accessibility up until the point the user has
managed to register an account and finally set his/her language
preference... all of which has to be somehow accomplished in the "dark"
of the default language, unless he/she knows to add the magic
uselang=... to MediaWiki URLs every step of the way.

Please don't suggest an add-on for such basic functionality.


Version: 1.20.x
Severity: enhancement
Whiteboard: UniversalLanguageSelector-fixed
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20151
https://bugzilla.wikimedia.org/show_bug.cgi?id=56464

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz33677.
Jidanni created this task.Via LegacyJan 12 2012, 12:56 AM
Jidanni added a comment.Via ConduitJan 12 2012, 1:03 AM

There remains the question of how to exactly design a language
selector that everybody can understand. All I can say is the
aforementioned "real websites" offer very good examples there on the
footers of their pages!

Jidanni added a comment.Via ConduitJan 12 2012, 1:05 AM

http://www.google.com/ 's approach is somewhat different... but still usually there at the bottom of the page.

Peachey88 added a comment.Via ConduitJan 12 2012, 1:12 AM

We currently have 380 languages, So you would need to store a cache for each
one of those languages (depending on your setup), You would need a nice
language selector.

Although I don't see the need in most cases, Since in most wikis I have come
access, The user language is usually the same as the content language.

brion added a comment.Via ConduitJan 12 2012, 1:27 AM

This would be absolutely trivial to do in a cache-friendly way... in a sufficiently redone JavaScript application UI. But I don't think jidanni would find it to work in lynx. :)

Jidanni added a comment.Via ConduitJan 12 2012, 1:51 AM

(In reply to comment #4)
No worry, I'm with the 99% on this issue. What's good for the real sites is good for me!

liangent added a comment.Via ConduitJan 12 2012, 4:17 AM

There's a major difference between Wikipedia and those sites you listed: Wikipedia has different sites for contents in different languages, and those websites have an only global site with contents in mixed language.

So on those websites, people using completely different language use the same site, so it's important to provide a language selector. While on Wikipedia, normally (I mean, except for those people doing crosswiki work) only people who know the content language come to the site and since the interface language defaults to the content language, it's safe to assume that people can understand the default interface language.

However it can be useful for wikis with mixed contents, eg, http://wikimediafoundation.org/wiki/Home .

Peachey88 added a comment.Via ConduitJan 12 2012, 4:27 AM

just a slight note from the IRC channel, for anyone that may want to attempt this:

[11:31] <p858snake|l> brion: I believe commons tried to do it a cache friendly way and couldn't get it to work properly for anons (although we have a slightly more complicated cache setup than normal)
[11:33] <brion> p858snake|l, yeah the "right" way is to make the frontend a javascript app that uses the api, and only has to fetch UI messages once etc ;)

Jidanni added a comment.Via ConduitJan 12 2012, 4:31 AM

(In reply to comment #6)

There's a major difference between Wikipedia and those sites you listed

So how would you suggest owners of read-only databases who would like
their database to be accessible in more than one language proceed? Hack
up some xx.example.com massive redirect nightmare? One can't always
assume "well the content has that problem too" so there is no need to
make the interface accessible. I mean I keep reading about the efforts
to make things internationally accessible, e.g.,
http://blog.wikimedia.org/2012/01/09/end-of-sprint-6-translate-and-other-goodies/
but at the same time there is no path in ones language from a MediaWiki
Main Page through the many steps to set up the correct preference... if
indeed a given MediaWiki allows logging in in the first place.

Jidanni added a comment.Via ConduitJan 12 2012, 4:35 AM

By database I mean e.g., a ham radio frequency database or a database of Latin names for plants, etc. that the owner has chosen to use MediaWiki as the platform.
I.e., the content is just numbers or other language neutral items, so why can't the interface (MediaWiki) be language neutral from click 1?

santhosh added a comment.Via ConduitJan 12 2012, 4:45 AM

There are some efforts going on designing a language selector UI by integrating language tools to it. See https://www.mediawiki.org/wiki/Universal_Language_Selector for a draft specification.

Nikerabbit added a comment.Via ConduitNov 1 2013, 7:44 AM

I'm just going to mark this as fixed. ULS provides this functionality, and there is no mention about WMF where this functionality cannot currently be enabled.

Nemo_bis added a comment.Via ConduitNov 1 2013, 8:02 AM

(In reply to comment #11)

I'm just going to mark this as fixed. ULS provides this functionality, and
there is no mention about WMF where this functionality cannot currently be
enabled.

Fixing dependencies and component then.

Add Comment