Last modified: 2014-02-25 14:11:17 UTC
As part of bug 46306, an option was implemented to disable UniversalLanguageSelector (ULS) on a per-user basis. I believe the addition of this user preference is a temporary measure that should eventually be reverted. Adding a user preference contributes to (very visible) user interface clutter and should only be done as a last resort.
I doubt it's appropriate to add more and more bugs in contrasting directions in a moment when the confusion is such, that you call the preference the opposite of what it is. Anyway, yes, the preference will need to be removed at some point. Probably this report will have to be duplicated to some report outlining the future path, which AFAIK is still bug 56433 comment 22, though in the last 24h the confusion has been great.
(In reply to comment #0) > Adding a user preference contributes to (very visible) user interface clutter > and should only be done as a last resort. This statement feels a bit ironic given the fact that the setting actually removes a whole lot of user interface clutter (ULS) that is not at all needed by most people in western countries. Also I think it's better to have one simple setting "hidden away" in user preferences than to have a whole bunch of ULS UI elements scattered across the whole UI. All in all the gain of this option is much larger than the minimal "clutter" that is criticized in this bug.
What percentage of the USA, UK or AU population does it take to insist on the fallacy that ULS is clutter and not needed ?
The preference was simply a means of disabling the extension by default for all users but allowing users who depend on it to turn it back on. It was not a product or design decision. It may or may not go away in the future; it is not my call.
(In reply to comment #3) > What percentage of the USA, UK or AU population does it take to insist on the > fallacy that ULS is clutter and not needed ? It may surprise you, but some people don't use the ULS system and ultimately would prefer it to not add any additional {clutter|un-used features} to the user interface. That doesn't mean we want it disabled for every one or don't see the usability features and benefits for other users that it's designed to help. Personally, I would just prefer to have a proper user preference to control it, rather than some hacky personal js or css code.
When "some people" remove functionality for everyone, functionality that enables people to read Wikipedia in the first place, I would qualify them as egocentric. When someone comes new to our projects we do not know them, we do not know their need. So far we have done a poor job at appreciating the differences in need. The ULS is disabled for technical reasons but it is not because the performance deteriorated drastically. Seven to ten percent of our public are negatively affected by this.
Gerard, you are still saying that people have to suffer ugly coding to compensate those who need ULS, right?
say 93 to 90 percentage. ;-)
This whole discussion is silly. ULS is not removed so it's still available for everybody. Nobody wants to take this feature away from others. The only logic solution is to make the ULS setting to be enabled by default which will make everybody happy in the end: - People who don't need ULS or have problems with it can disable it and be happy - Everybody else gets ULS by default and can be happy, too. The whole "removing options" kamikaze trips some devs are pushing lately will only make those people angry wo depended on this option, will not improving the situation at all for anybody else.
The WMF is to share in the sum of all knowledge. When a majority prevents this sharing of knowledge to a minority, it is NOT about ugly coding, it is about lack of consideration for the consequences to others.
(In reply to comment #10) > The WMF is to share in the sum of all knowledge. When a majority prevents > this > sharing of knowledge to a minority, it is NOT about ugly coding, it is about > lack of consideration for the consequences to others. When the local transit authority pulls a city bus from circulation to the depot for repairs, it is not an attack on the value of public transportation or a slight to the people who use it. It's just a bus that needs to be repaired. I understand you have some strong, urgent feelings about this, but I think your gusto is misspent. There's some engineering work to do and that's that. Shouting about it won't make it go faster.
The option will go away again and is temporary (as disabling ULS is temporary). Also see bug 46306 comment 115. Gerard: Please take high-level abstract "what WMF does" discussions somewhere else ( https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum#toc etc.). This bug report is about removing the option to disable ULS. See topic.
(In reply to comment #12) > The option will go away again and is temporary (as disabling ULS is > temporary). > Also see bug 46306 comment 115. Why do we actually have to remove this option again? What's wrong with simply keeping it and making it default to enabled (therefore enabling ULS by default) while still giving people the possibility to disable it at their own desire? The only thing the whole back and forth with repeatedly enabling / disabling features and adding / removing options achieves is to annoy *every* user group at some point and in the end leaves all users behind dissatisfied.
So I disagree with this bug. I think the option should be there. I also disagree that having it enabled or disabled should be a global all or nothing thing. Different projects have different use cases - one that serves primarily users without compatibility issues, for instance, probably should have it off by default. On the other hand, ones that serve areas full of users who often have trouble with the exact things it's trying to address should have it on by default - but we can't assume that the defaults will ever suit everyone, or that there won't be overlap. We can, however, try to have sane defaults so that the most people will be happy just in general. But that requires an option.
Apparently Erik has a problem with what I said here (?), so I'd like to clarify that this is according to how it currently appears to stand; there could be several different potential resolutions depending on what is ultimately done with ULS, such as having the options at an effective load point within ULS itself (from what I understand this is/was the intent, but I haven't exactly been much in the loop).
There's a patch for this pending, covertly not linked for some reason: https://gerrit.wikimedia.org/r/#/c/108988/
Ah, neat. Nevermind, then.
Change 108988 had a related patch set uploaded by Ori.livneh: Restore enableWebfonts pref and remove uls-enable https://gerrit.wikimedia.org/r/108988
Does this mean that the global preference to toggle the default for webfonts is removed ? If so why, where was this discussed and has it been considered what this does for the utility of MediaWiki for many Wikipedias, Wiktionaries and what not.. Eh do not forget Wikidata in this.. Thanks, GerardM
(In reply to comment #20) > Does this mean that the global preference to toggle the default for webfonts > is > removed ? No, the current direction is to remove the preference that enables or disables all of ULS, so that ULS will always be on if installed, and to introduce a preference that enables or disables webfonts. The idea is to enable all of the other ULS features as they were before January 21, but with webfonts disabled by default on Wikimedia sites, and with the possibility of enabling webfonts by default after careful examination of the performance impact.
There is still no comment on *why* we need to remove the preference to disable all of ULS! Comment 13 was not answered yet. The solution proposed there would still enable ULS by default (therefore the status quo we had before disabling ULS for performance reasons) while maintaining the option to opt-out. I don't see any downsides of this and probably nobody else? Otherwise I assume there would have been some sort of answer? Why do we remove the option then?
The backlog in bug 46306 should cover that request (before the report turned its meaning).
(In reply to comment #21) > (In reply to comment #20) > > Does this mean that the global preference to toggle the default for webfonts > > is > > removed ? > > No, the current direction is to remove the preference that enables or > disables > all of ULS, so that ULS will always be on if installed, and to introduce a > preference that enables or disables webfonts. > > The idea is to enable all of the other ULS features as they were before > January > 21, but with webfonts disabled by default on Wikimedia sites, and with the > possibility of enabling webfonts by default after careful examination of the > performance impact. Will there be a global switch to enable web fonts for a specific Wiki? (maybe with the possibility to toggle this on a personal level ? Thanks, Gerard
(In reply to comment #24) > Will there be a global switch to enable web fonts for a specific Wiki? > (maybe with the possibility to toggle this on a personal level ? Both possibilities are part of the patch that is being reviewed ( https://gerrit.wikimedia.org/r/#/c/108988/ ) A user will be able to enable it using a checkbox, both logged in and anon (for anons the preferences will be saved as a cookie, as it is with other ULS preferences). There will also be an option that enables webfonts by default for all users of a given wiki. It will be disabled by default, but may be enabled by default in the future.
(In reply to comment #23) > The backlog in bug 46306 should cover that request (before the report turned > its meaning). If this was a reply to my comment 22 I don't see how bug 46306 should be helping? It was closed (because for a very short period of time the option actually was there) but actually you'd have to reopen it now (since the option is gone again by resolving this bug). Also bug 46306 doesn't contain any reasoning why we should *not* have that option to disable ULS.
(In reply to comment #13) > Why do we actually have to remove this option again? What's wrong with simply > keeping it and making it default to enabled (therefore enabling ULS by > default) while still giving people the possibility to disable it at their own > desire? User preferences are a last resort; they're a way of giving up. The vast majority of site visitors can't set user preferences because they don't log in. The vast majority of logged-in users don't change the default setting (or even know that they have settings). And, of course, we still don't have global user preferences (i.e., the ability to set a user preference across Wikimedia wikis). In the conversations about ULS, I think some important points are getting lost. For example, ULS is not actually universal. It only applies to Wikimedia wikis, not to the rest of the Internet. Perhaps usage statistics would help here, but it's beginning to seem as though the entire approach being taken here needs a reevaluation. Users interested in decent font support should be solving the issue at an operating system or browser level. Solving the issue on a particular set of sites, at great cost, is beginning to look like the wrong approach to take.
(In reply to comment #27) > (In reply to comment #13) > > Why do we actually have to remove this option again? What's wrong with simply > > keeping it and making it default to enabled (therefore enabling ULS by > > default) while still giving people the possibility to disable it at their own > > desire? > > User preferences are a last resort; they're a way of giving up. The vast > majority of site visitors can't set user preferences because they don't log > in. > The vast majority of logged-in users don't change the default setting (or > even > know that they have settings). And, of course, we still don't have global > user > preferences (i.e., the ability to set a user preference across Wikimedia > wikis). > > In the conversations about ULS, I think some important points are getting > lost. > For example, ULS is not actually universal. It only applies to Wikimedia > wikis, > not to the rest of the Internet. Perhaps usage statistics would help here, > but > it's beginning to seem as though the entire approach being taken here needs a > reevaluation. Users interested in decent font support should be solving the > issue at an operating system or browser level. Solving the issue on a > particular set of sites, at great cost, is beginning to look like the wrong > approach to take. I am sad because of your remarks. They clearly assume that people have the power to install the fonts on the systems they use. Not necessarily true. They assume that ULS is not universal ... it exists as an extension to Chrome and Firefox. That makes it as close as we can make it to the kind of universal you suggest ULS is not. You are clearly under the impression that YOUR experience is a valid point of reference.. It is not.. When you go to FOSDEM the PC's that you can use have a French keyboard. Having ULS available to you makes them usable when you know how to type blindly (this is a first world experience). All in all ULS is successful in what it aims to do. It may be improved upon but that does not negate its accomplishments. Thanks, GerardM
(In reply to comment #28) > I am sad because of your remarks. They clearly assume that people have the > power to install the fonts on the systems they use. Not necessarily true. Sure. > They assume that ULS is not universal ... it exists as an extension to Chrome > and Firefox. That makes it as close as we can make it to the kind of universal > you suggest ULS is not. The fact that browser extensions exist is part of my point... fixing this at the browser level is saner and should likely be more encouraged on our sites. That said, the comments at bug 60327 were helpful to me in better understanding some of the issues here. Apparently people rely on Wikimedia wikis to write on other sites. If we can provide such a service, there's certainly value in that. > All in all ULS is successful in what it aims to do. It may be improved upon > but that does not negate its accomplishments. Sure, but there's also a question of what value to users is provided given the implementation costs (whether that's coding, designing the user interface, making small tweaks, performance debugging, etc.). I personally think better ULS usage statistics, and overall better messaging about the virtues of ULS, would significantly help here.
Implementation costs are secondary when they stand in the way of our mission. You acknowledge that people often do not have the power to manage the systems they are using. You acknowledge that people need our software to write in their language and the associated script. What do you not understand about "sharing in the sum of all knowledge" because that is exactly what the consequences of this whole fracas is preventing. It is what our Wikis are about, it is what all the engeneering that is done is about. Thanks, GerardM
Gerard: Please take a high-level discussion of Wikimedia's mission to private email. Technically offtopic here. Thanks.
Change 108988 merged by jenkins-bot: Restore enableWebfonts pref and remove uls-enable https://gerrit.wikimedia.org/r/108988
(In reply to comment #32) > Change 108988 merged by jenkins-bot: > Restore enableWebfonts pref and remove uls-enable > > https://gerrit.wikimedia.org/r/108988 + https://gerrit.wikimedia.org/r/111176 + https://gerrit.wikimedia.org/r/111778 = fixed in master absent surprises. Current plan: https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=98833&oldid=98832
All Wikipedias done on the 20th, no surprises.
*** Bug 60323 has been marked as a duplicate of this bug. ***
