Topic on Talk:Universal Language Selector

Hi all,

is there a way to disable ULS as a user setting? I never use it and – since it's JavaScript – is distracting me on page load since it's displayed with a noticeable delay.

Regards

Yes. See Universal_Language_Selector/FAQ#How_can_I_disable_Universal_Language_Selector.

Thanks, but this only allows to disable "input methods", not ULS completely. I hope there is more I can do?

No.

Thank you for you replies so far. Sadly this wasn't the answer I had hoped for.

Anyway I discovered two Bugzilla bugs regarding the issue:

• bugzilla:46306 is about adding an option to user preferences to diable ULS completely
• bugzilla:46744 is about finding better default settings or automatically detecting useful settings for ULS so it's not shown for people that probably don't need it.

@Nemo: Can you elaborate on why ULS can't be completely disabled on a user basis in your opinion? You said something about API functions used by other extensions in bug 46306? Anyway the user front end with all it's options is probably independent from the core of the extension anyway, so I don't see a problem here, even if your statement is true.

I was directed here from Bugzilla:46306 by Erik Moeller. I dont have much technical knowledge and I dont know why a user cannot be given the option to diable ULS completely. If the users request that they should be given an option to swith ULS off completely, that must be provided unless there is some sound technical reasons which makes it impossible. Is there any such reason?

There was given no reason at all so far (at least none of which I would be aware of and I searched a lot, on Bugzilla as well as on Wiki pages).

I even wrote an e-mail to Siebrand who is the project manager responsible for ULS (and who closed the bug as "WONTFIX") and asked him for a statement on why this wasn't considered. However he didn't respond to my mail sent on Monday yet (neither directly nor by a comment in Bugzilla nor on a Wiki page)

This is highly disappointing in my opinion! There is notable request by the community for such a feature. The WMF declines to fix it however and (which is worst) doesn't even care do give a reason for it.

• If there are good technical reasons, that make such an option hard to implement, that would be acceptable (although unsatisfactory).
• If this is another move - like in the VisualEditor case - to force established editors to have a look at it to find bugs, that would at least be a comprehensible motive (although questionable action).

Any way I highly suggest somebody at WMF to elaborate on the issue, otherwise this discussion will go on forever with us not knowing anything and you being bugged by us because of this!

I see disabling ULS entirely as akin to disabling the preferences section. ULS simply surfaces options and features related to languages in a location of the user interface where they are likely to be sought. From what I've seen in the ml.wp and ta.wp discussions, the desire to disable seems to mostly stem from identifying ULS with overriding the default font. That is, however, not inherently something that ULS does -- the default font can be configured on a per-language level, and completely disabled (both by communities in Common.js and in the ULS config itself) if needed.

What other reasons or motivations are there to completely disable it? If ULS loads more JavaScript than strictly needed, for example, that seems like an area of optimization but surely solvable in its own right. Is it causing any problems or interference?

I gave several reasons in many places already, but I'll elaborate on it again in the hope that you will consider those issues.

First of all I think many users don't need ULS at all:

• The "default" user which is writing in a Latin language on a Wikipedia that is using a Latin language has absolutely no need for input methods or different fonts, therefore two unnecessary features added, nothing gained.
• The third main feature of ULS, changing interface language, is redundant to the setting in user preferences. It is a great feature for not logged in-users, I don't want to deny that, but its totally useless for logged-in users. Setting the interface language is normally a one time Job one does on account creation or shortly after. Afterwards the setting is not needed anymore (and surely not directly in ones face on every page). And this setting is normally sought in a central place – the user's preferences, where all settings should be made. What makes this single setting so much more important than others, that it needs to be presented separately in the UI? I often change my skin to check compatibility – maybe add a button for that one, too?

Besides those nobody was able to tell me if ULS offers any further features, that may not be directly visible. But if there are no such "hidden" features ULS is totally useless for me (and probably many others) and only clutters the UI.

Now to the problems this is actually producing besides being redundant or even useless:

• ULS is loaded by JavaScript. That means it's slow as hell by default (whatever you are going to do to optimize it). And it adds overhead to every page load.
• Since it's loaded by JavaScript the buttons are added to the UI with some delay. This causes "flickering" which looks totally unprofessional and is distracting the eye.
• Currently it even renders some pages with many language links useless (the loading of the script takes ages, blocking everything). There are bug reports already and I'm sure it will be fixed eventually, but it is a good example why I would have preferred to be able to disable ULS in the first place. It would have saved my needless hassle with a feature I never used and will never use.

On choosing the default font and consensus (bugzilla:46306#c43), I'm a bit concerned because it enables a paradox: if a font is supported very bad by normal systems, wikis will have users coming only from uncommon systems/setups, hence consensus will be skewed; the more a webfont is needed, the more likely it is to be disabled based on consensus...

Of course, as Churchill would say, it's the worst except that the alternatives available so far would be worse.

I fully agree with your concern. I do not agree with you that the Churchill invocation is applicable.

After more than a month there is still no satisfactory answer why an option to disable ULS is not considered at all.

Meanwhile

• ULS keeps jumping in my face with needless messages (e.g. "Language changed from Deutsch") when I come to Commons (where I set my UI language to English) from a file description page on German Wikipedia (where I have set my UI language to German).
• Produces needless flicker on page load due to the delayed loading of webfonts of languages I don't speak or even can read anyway.
• Slows down the already slow page load of JavaScript-overloaded Wikipedia pages even more (I did some performance measurements and often around one third of the used time "could be ULS" according to devs. But hey, who cares, its "only" one third – why should anybody care to optimize ULS further or at least offer an option to turn it off, if it does not lock the browser for most of Wikipedia users?).

I'm deeply disappointed by you guys! This is not how great software is designed. It's ragged, ignorant and unfinished. If you don't have the manpower to develop such extensions to the end then delay deployment or please offer an off-switch for those who are not dependent on the offered functionality!