• This bug has been marked as a duplicate of bug 46306 ***

This is not a duplicate of that bug - even if it can be disabled somewhere in the sea of preferences

Yes, of course, having the save button where I expect an edit like to be is very helpful, thank you, Bugzilla.

What I meant to say is that this is not a duplicate, and should be resolved - even if it can be disabled (and I couldn't find the option in the preferences), ULS shouldn't be on by default for everyone in the first place, and instead detect for the intended use cases.

Also wherever the preference is should be more apparent, but since the user preferences are kind of a mess that's probably a separate issue entirely.

I agree that this bug does not seem like a duplicate of bug 46306. The default issue in particular should be addressed.

I always feel that, the developers force users to use ULS even if they dont want to use it. In wiki user communities, some user need it and some others dont.

I dont find any reason for not giving a turn off option in the preferences section.

(In reply to comment #5)

I dont find any reason for not giving a turn off option in the preferences
section.

Well, we really want to avoid user preferences bloat. Every additional user preference has a somewhat significant cost (in terms of interface clutter, technical debt, etc.).

That said, the default behavior here seems a bit strange. For example, on Meta-Wiki, I have "en" set as my user interface language and yet I still see this somewhat annoying drop-down next to the edit summary input and the search input. As someone who has absolutely no need for a different input method (my keyboard works just fine), I don't see why I'm being presented with such a drop-down menu. Something seems amiss here.

Generally, UniversalLanguageSelector's scope and purpose is unclear to me. As someone who writes and reads in English, I have no need for this drop-down menu or the "english" link in the personal tools section. It'd be nice to not add clutter to the interface for users like me.

It also seems that UniversalLanguageSelector's scope has increased from being a universal language selector to also providing display preferences (e.g., I can select "OpenDyslexic" as my display font via ULS). It doesn't seem like a great idea to mix purposes like this.

(In reply to comment #3)

ULS shouldn't be on by default for everyone in the first place, and instead
detect for the intended use cases.

It already does. The use cases are more than you appear to know, though; have you read bug 46306?

(In reply to comment #6)

As someone who has absolutely no need for a different input method (my
keyboard works just fine), I don't see why I'm being presented with such a
drop-down menu. Something seems amiss here.

Generally, UniversalLanguageSelector's scope and purpose is unclear to me. As
someone who writes and reads in English, I have no need for this drop-down
menu
or the "english" link in the personal tools section.

Right: your keyboard, you don't see, to you, you. Not valid as general assumptions.

It'd be nice to not add
clutter to the interface for users like me.

It's quite normal for websites to have such "clutter".

It also seems that UniversalLanguageSelector's scope has increased from
being a
universal language selector to also providing display preferences (e.g., I
can
select "OpenDyslexic" as my display font via ULS). It doesn't seem like a
great
idea to mix purposes like this.

It can seem a purpose mixing only to you who have decided it can't be useful/used for English speakers; but it's just your wrong premise. It was a rather trivial extension of functionality for ULS.

In general: 1) ULS is meant to be useful for all users, including English speakers blabla, although some obviously benefit from it more than others (but think of language selection for an article, replacing interlanguage links); 2) in the current state of technology, there is no way at all to reliably mind-read the user to know what sort of language options are best in all the use cases, which is why selectors are needed in the first place.
Therefore, with the current summary, this bug is invalid.
I suggest you to read [[mw:ULS]] completely; for instance the user profile https://www.mediawiki.org/wiki/Universal_Language_Selector/Interaction_Design_Framework#Rakha directly addressed some of the questions.

As for the personal tools, it was found to be the best location for this tool; the fact that all the preferences related to ULS are available there, instead of cluttering Special:Preferences with another section of little discoverability, is something that addresses the concerns about preferences bloat you mentioned, rather than ignoring them. Anyway, this part is duplicate of bug 46306.
Of course there are separate bugs for specific tweaks like adjustment of timing for IME icon, settings from the IME icon itself, some sort of link from Special:Preferences to the ULS settings; and more tweaks are surely possible.

Please stop closing this, Nemo.

Arguing that a bug is invalid does not make it so. There is clearly at least some backing for this bug, so trying to make the discussion go away is not going to convince anyone.

Discussion can continue anyway, it's just helpful if the bug status makes it clear that the request won't be fulfilled. :)

That sort of dismissive attitude and lack of engagement are not helpful in what it otherwise a collaborative environment and I would urge you to please reconsider your standpoint.

If the reasons for having ULS the way it is are compelling, then this bug will close on its own, but otherwise the request damn well should be fulfilled, even if it isn't at a particularly high priority.

As you know very well, I'm just a random volunteer who happens to have read more on the topic; it's possible that some revolution of ULS way forward suddenly happens, but I can't do anything about it, so I only inform on the current status (which is very clear).

This request wont be fulfilled because there simply is no way to automatically detect missing fonts [1] or missing input methods.

[1] This has been explicitly prevented by browsers as a privacy measure.

Note: edited the summary because default value is unrelated to automatic detection.

This is freaking funny and pathetic!! Even after disabling it to its current possible extent, it causes performance impact while I am using translatewiki.net using GPRS. And me too also need to disable ULS completely from special:preference page. Then someone changed Summary and closed that bug using changed summery.

Reverting summary and reopening.

(In reply to comment #13)
Translate extension depends on ULS extension (see https://www.mediawiki.org/wiki/Help:Extension:Translate/Installation)

(In reply to comment #13)

Even after disabling it to its current possible extent, it causes
performance impact while I am using translatewiki.net using GPRS.

Could you elaborate please?

Even after uncheck "download font" option, Links are not clickable (mouse pointer instead of hand pointer only available) for some time (for minutes occasionally) while using poor network such as gprs.

I see it it near to impossible to automatically detect whether a user needs ULS features or not. Anyway the heading of this bug is true: ULS *is* useless for most users.

Therefore (if it can not be solved by automatic detection / different defaults as requested in this bug) it should be possible to diasable ULS on a user basis in preferences.

Therefore please reopen bug 46306. It was not clear at all why this wouldn't be an option and I think this should still be considered.

ULS can be disabled as described in [[mw:Universal_Language_Selector/FAQ#How_can_I_disable_Universal_Language_Selector]].

Sorry but this only disables the "input selector" which pops up on input fields, not the other components of ULS.

That's even written in the FAQ you linked: "Only part of the functionality can be disabled."

Again, there are no plans to fully disable ULS.
That's why this is closed as WONTFIX.