Commons:Requests for comment/UniversalLanguageSelector

This page in a nutshell: A proposal to enable UniversalLanguageSelector on Wikimedia Commons

Update: ULS can be tested on the Commons beta (the test has not been setup completely yet, not all features are available for testing)

An editor had requested comment from other editors for this discussion.
The discussion is now closed, please do not modify it.

Background

This window opens when clicking a language link in the personal link area.

UniversalLanguageSelector is a Mediawiki extension for language selection. It is currently enabled on Meta, translatewiki.net and Wikidata (as well as any other Wikimedia project using the Translate extension).

“

As for ULS, it does multiple things:

Webfonts and input methods
Language selection
Language detection for anon users

Due to technical challenges we've not been able to enable all features of ULS for anonymous users yet, except in translatewiki.net.

”

—Nikerabbit, 14:44, 22 January 2013 (UTC)

Use on Wikimedia Commons

Enabling UniversalLanguageSelector on Wikimedia Commons has previously been discussed on Commons-l mailing-list and on COM:VPP.

“	As you have probably noticed, translatewiki and now also metawiki have Extension UniversalLanguageSelector enabled. I think since we are a multilingual project, there could be benefit in enabling this at Commons as well. Comments are welcome.	”
—Rillke^(q?) 15:25, 19 January 2013 (UTC) source

“	The UniversalLanguageSelector extension allows users to easily switch the interface language; it also embeds an interface to enter text in non-Latin languages even if your keyboard doesn't allow it.	”
—guillom, 13:36, 21 January 2013 (UTC) source

Questions

Don’t we already have fancy language selection?

Yes, Wikimedia Commons currently relies on MediaWiki:AnonymousI18N.js which has the following features:

Language selection (with a dropdown in the sidebar)
Language suggestion when possible (above the page title), based on « data from cookie, referal url & browser settings »
Language “uselang” persistency, regardless of the previous. Meaning, if landing on Commons from a URL with ?uselang=fr (obviously from templates on projects, but also from links), the ?uselang=fr is set for all outbound links, meaning language persistence.

ULS, in contrast, has a carefully designed selector (for discoverability and usability) and a proper persistence of language selection without the uselang hack.

We also rely on a number of language templates to show the appropriate content based on the language selection:

some which rely on the interface language set (using {{int:lang}}): {{Autotranslate}} and {{LangSwitch}};
{{Mld}}, {{En}}, … and MediaWiki:Gadget-LanguageSelect.js which does not and add another language selector above the title for everyone (hides babel tower // creates a <select> // Example).

ULS doesn't directly solve the problem of the double language selection, but will hopefully allow future development of our scripts and templates to make use of ULS rather than local, custom selectors.

What are the existing feature requests in this area?

bugzilla:1135 − Language on Commons should default to browser language preferences
bugzilla:8287 − Enable multilingual extension in Commons

Deployment plan

search for usage of the wpAvailableLanguages variable and replace it (esp. in MediaWiki:Gadget-LanguageSelect.js)
drop window.wpAvailableLanguages from MediaWiki:Common.js
wgULSLanguages can be used until bugzilla:41210 is resolved

Comments

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.

ULS was enabled as part of the Translate extension deployment. This RFC is thus deprecated. Jean-Fred (talk) 20:34, 20 May 2013 (UTC)[reply]

From my experience in translatewiki.net, I know ULS is too heavy and far stretched. ULS' ime often fails when network is slow. In these days I completely use Ibus instead of ULS input in twn. But at the same time Narayam works without a problem in both 'Commons' and 'Malayalam Wikipedia'. Worst thing about ULS is that it is not even possible to disable, even though you want to disable it badly. I know recent interface rewrite of some extensions makes ULS an indispensable extension at client side, IMO it makes people unnecessarily suffer for the things they had without ULS in past.--Praveen:talk 16:50, 24 April 2013 (UTC)[reply]

I completely agree with Praveen. --Vssun (talk) 15:43, 28 April 2013 (UTC)[reply]

Do you know whether there are bugs at bugzilla: regarding these issues? (I don't like IME-tools written in JavaScript anyway and Narayam is only fast because it ships all the JavaScript required with every page load regardless whether you're going to use it or not; IMHO system tools are the fastest ones and most reliable) -- Rillke^(q?) 14:47, 29 April 2013 (UTC)[reply]

But that is no reason to replace a working extension with a buggy one. IMO, Build of ULS is total violation of KISS principle. It combines 3 or 4 totally different things (or loosely connected things) and serves together. IMHO, Structure of ULS itself makes it bloated and cause to fail.--Praveen:talk 06:05, 30 April 2013 (UTC)[reply]

The great thing about the current script is you can set it to "all" and forget about it, and see everything from then on. I don't remember seeing that option at Wikidata... AnonMoos (talk) 04:41, 14 May 2013 (UTC)[reply]

Isn't this just a script which chooses which language to use if you're not logged in or if you haven't set a language at Special:Preferences? Would this affect your possibilities to see a page in all languages at the same time? I typically prefer to disable translations altogether as the version in the original language usually is more accurate. --Stefan4 (talk) 13:15, 14 May 2013 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.