Last modified: 2014-01-23 16:16:59 UTC
An option in Settings section required to disable ULS completely.
Click on the ULS icon in the user portlets -> Input Settings to disable. As already discussed in the IRC channel previously, As a user preference to disable this, It shouldn't be anywhere other than under User Preferences.
(In reply to comment #0) > An option in Settings section required to disable ULS completely. What problem do you see with ULS if this option is not there?
(In reply to comment #1) > Click on the ULS icon in the user portlets -> Input Settings to disable. Bug is not about disabling input methods, it is about disabling the ULS completely. And reason for adding this option in ULS rather than at User Preferences is, we allow anonymous users also to have language related preferences(UI language, fonts, input and any language related settings in future)
(In reply to comment #3) > And reason for adding this option in ULS rather than at User Preferences is, > we > allow anonymous users also to have language related preferences(UI language, > fonts, input and any language related settings in future) I've assisted more long term users than I can count on one hand to disable the input methods, How many anon users have actually disabled it?
(In reply to comment #2) > (In reply to comment #0) > > An option in Settings section required to disable ULS completely. > > What problem do you see with ULS if this option is not there? Users must have choice to decide whether they use ULS offered features or local settings. If the user has local input methods and local fonts, it is unnecessary to load ULS. A Disable ULS checkbox in the User Preferences section is the best way to implement this.
(In reply to comment #5) > Users must have choice to decide whether they use ULS offered features or > local > settings. If the user has local input methods and local fonts, it is > unnecessary to load ULS. Input and fonts are just 2 features of ULS. Both can be disabled in the current interface. Why you want to disable other features? Your bug is about disabling ULS *completely*
(In reply to comment #6) > (In reply to comment #5) > > Users must have choice to decide whether they use ULS offered features or > > local > > settings. If the user has local input methods and local fonts, it is > > unnecessary to load ULS. > > Input and fonts are just 2 features of ULS. Both can be disabled in the > current > interface. Why you want to disable other features? Your bug is about > disabling > ULS *completely* I think, those 2 are the major features of ULS. Please excuse me if not. Is there any other feature which ULS offers and it is not possible to implement at local level?
(In reply to comment #7) > I think, those 2 are the major features of ULS. Please excuse me if not. Not at all. There are language selection features(many scenarios), APIs being used by extensions(for script, language code, text directionality, autonyms etc). Please read the ULS documentation at MediaWiki.
One of my question is still unanswered. Is there any feature which ULS offers and it is not possible to implement that at local level? If all the features ULS offer, are able to implement at local level, disable UCS should be there at preferences.
(In reply to comment #9) > Is there any feature which ULS offers and it is not possible to implement > that > at local level? Yes: all those mentioned in comment 8.
Thank you
If an extension has some dependency on other extensions, then it should be handled at server side, not at user level. Certainly not WFM. Reopening.
(In reply to comment #12) > If an extension has some dependency on other extensions [...] Wrong premise: (interface) language selection [mentioned in comment 8] is not about that. Also, the general premise in comment 0 that preferences should all be in Special:Preferences is invalid (and would probably go against bug 31882), hence I'm closing this INVALID. You may be looking for bug 46044 or bug 45964 (this bug could also be considered a duplicate of the latter).
*** Bug 46744 has been marked as a duplicate of this bug. ***
Sorry, but why was this bug closed? From what I read in this bug and on [[:mw:Universal Language Selector]], ULS offers three features: 1) Switching interface language 2) Font selection 3) Input methods (including the pop-up near HTML inputs) 1) is done via preferences for logged in users, 2) and 3) are useless for many people. I'm from Germany for example - active on dewiki, enwiki and commons - and I've never actively used any of the features of ULS (besides turning of input methods after being annoyed by the keyboard symbol always popping up near HTML inputs). So for my use case (which is not so uncommon after all) ULS doesn't seem to bring any needed functionality? The only thing I stumbled across so far was Nemo mentioning "APIs being used by extensions" in comment 8. But I didn't find information according to this statement anywhere? What type of API and what extensions are you talking about? Therefore (if there is no hidden functionality somewhere) I see no reason to close this bug as invalid. I think the request is perfectly reasonable and I can add two downsides of ULS which are why I want it disabled: a) It's JavaScript and therefore loaded with delay. I always see the ULS link on the top "flickering" in after the page is already loaded, therefore distracting my eyes. b) It's JavaScript and therefore slow. It certainly delays page load itself (as does every unnecessary JavaScript, but this is a different bug I suppose).
Hello All, This is my first time entering the hightec world of Bugzilla.wikimedia.org. Nevertheless, I have been a Wikimedia (WM) user, preacher and evangelist for long many years with significant contributions to both the content as well as idea of WM ventures. Hence a brief self-intro may be befitting. One of my major efforts towards the propagation of WM has been to educate new users at scenarios completely unexpected such as non-standard hardware/OS/input methods, accessibility compromised users, network-restricted systems etc. I have had quite an extensive experience in encountering such situations. Besides, I often work in a completely multi-language situation with editing in at least 5 different language wikis and reading in a dozen or more. Also, I have been instrumentally active on the web in helping and guiding people to work with Unicode web pages ever since Unicode became a standard for multi-lingual computing. With this intro, let me express my annoyance I am facing with the ULS in some such situations as a user and user-trainer. 1. As for my own use, I DO NOT NEED ANY ULS! I am using several tools, as appropriate as the situation calls for, completely at the system or browser level with no dependence on the Wikimedia pages. In other words, as long as Mediawiki can serve its pages and take back my inputs in the right character encoding as specified, I DO NOT WANT MEDIAWIKI OR THE WIKIMEDIA SERVERS TO BOTHER about my input/render issues! I would rather want a much faster transfer of real knowledge content than some javascript and webfonts loading my often pitifully sluggish and broken internet service. A similar situation to me is Hotcat, WikiEd and such other gadgets. Often, if I am in a tight situation (due to hardware/bandwidth issues) I just disable them so that my real intended work can get done. Please note that they are also indispensable tools to me at some other time when their utility is required. The bug mentioned here is exactly the kind of feature that I require! Instead of only able to disable the substructure features, (in addition to that), a carpet-blank toggle to switch the ULS completely OFF is much desired. Certain other issues too call for this. 2. I have been living in a locale (ar) where my day-to-day life, contacts and Wikimedia circles have no connection with that local language. ULS tries to pick-up (AND DECIDE!) a locale and set the user(!) preferences according to its own dictated terms! Unacceptable for a non-local) (say expatriate) user in a foreign country where he is living temporarily or permanently for his own personal reasons. 3. Introduction of ULS tends to bind a user to the OS/browser in peculiar ways. Ideally, MW should be just streaming out and taking out content. And the user reciprocating the same. Any features and tools be only interconnecting these two nodes without forcing them to abide by any conditions. Features (not just ULS but any!) provided by MW by means of client-side scripts and web fonts, may facilitate general comfort and efficiency to a user. But there is a down-side. It also makes both the user and MW stream more dependent on the kinds and versions of OS and browser. By default, Wikipedia must be supplying knowledge to users of every unthinkable kind in every unthinkable client situation. The very purpose of ULS may thus be killed by itself! 4. Language dependent issues may cause ULS to actually deteriorate user experience. It is possible that the particular web fonts or input methods forced as initial defaults or even provided as additional options by the server may not be technically or aesthetically best suited for a user. Then he should be able to disable the whole feature and select his own preferred local tools. Right now, such a situation has arisen at http://ml.wikipedia.org . Please see this rather unusual voting being taken place there: http://ml.wikipedia.org/wiki/Wiki_Panchayath_Technical#English_translation_of_the_proposal_being_voted_here . You may also see how the number of edits and user activity has suddenly come down after the introduction of ULS there. The Mediawiki sofware should be more bothered about the concept of 'universal freedom to choose'. The people there should know that 'every human being' has a right to deny a facility that he is not interested in.
The IME portion of ULS can be disabled, see [[mw:Universal_Language_Selector/FAQ#How_can_I_disable_Universal_Language_Selector]].
Sorry but this bug was not about the "IME portion". It was about all functionality of ULS (including the link on the top and especially everything that might load unnecessarily in the background)
Yeah, an option in Preferences for everything would be nice.
Except for input methods, all other ULS functionalities will have no user interface that allows it to be disabled.
*sigh* The reasoning remains untold I assume? Additionally - as I pointed out before - there's more than user interface. We're stuffing more and more JavaScript into MediaWiki so it becomes slower and slower on page load. And close to unusable for the folks keeping it disabled for speed, security reasons or whatever their motives might be (actually the increasing slowness of Wikipedia might be a good motive after all).
Perhaps, the testing of all new features should be done from a dial up connection in a third-world rural school or a primitive GPRS link through a villager's barebone mobile phone, first. The Wikipedia experience from that point will make the developers know a difference!
Priority changed to critical since in ml.wiki we are observing a fallout of experienced contributors who feel their opinion on a key request is not at all cared for
Please refer here for the discussion http://ml.wikipedia.org/wiki/Wiki_Panchayath_Technical#English_translation_of_the_proposal_being_voted_here
Changed title since that has been the primary limitation due to which users wanted ULS disabled
I find the problem mentioned by Eduard Braun very annoying. The flickering ULS link is a major irritant. The entire process of editing has become more time consuming as well. I want to be able to switch ULS off completely.
(In reply to comment #26) > The flickering > ULS > link is a major irritant. The entire process of editing has become more time > consuming as well. > > I want to be able to switch ULS off completely. In your case, why isn't it enough to disable the input methods and choose system font? That basically disables everything, except the presence of the gear/settings icon.
As mentioned earlier, I am quite unfamiliar with the decision-making/democratic culture of bugzilla. The only thing now I sincerely know is that this bug has been dictatorially decided to be closed with a "Resolved" or "Wontfix" label repeatedly without even a simple satisfactory explanation! Is this the way bugzilla blatantly deals with serious issues raised by Wikipedia users who are more into content editing than technical know-how? The issue raised in this bug IS SERIOUS! We are losing editors in an unprecedented way in ml.wikipedia.org and its sister projects, the most vibrantly active and most promising community among Indian languages! I have also received complaints and issues from my fellow-editors in Sanskrit (sa) projects regarding ULS implementation.
(In reply to comment #27) > (In reply to comment #26) > > The flickering > > ULS > > link is a major irritant. The entire process of editing has become more time > > consuming as well. > > > > I want to be able to switch ULS off completely. > > In your case, why isn't it enough to disable the input methods and choose > system font? That basically disables everything, except the presence of the > gear/settings icon. We are not expecting MIT graduates as new Wikipedia editors in Malayalam Wikipedia. Even the seemingly simple task of "finding" and "disabling" some gadgets can be disastrously discouraging and technically challenging for new visitors (readers and editors) in projects such as ours. As for Malayalam, we have enough and unique language and font issues already in place at the OS/browser level itself. Since almost 10 years, we have been trying to bring the horse to the water. And now when the horse is ready to drink the water, it seems polluted! Seemingly completely out of control and misbehaving from an early user's point of view. ULS should be an opt-in. Not opt-out. And even either way, at least ULS should be treated like HotCat or WikiEd that the user can choose to COMPLETELY get rid off.
(In reply to comment #28) > As mentioned earlier, I am quite unfamiliar with the > decision-making/democratic > culture of bugzilla. Bugzilla is just a tool which reflects the status of things (and a place where people work together who care care about that). ULS is developed and enabled on Wikimedia projects by the Wikimedia Foundation (which hosts the wikis), i.e. by the [[mw:Wikimedia Language engineering]] team, overseen by Erik Möller over it etc. So, there isn't a document explaining the decision-making process (AFAIK), but in short it's like in any corporation, hence hierarchical not democratic. (In reply to comment #29) > We are not expecting MIT graduates as new Wikipedia editors in Malayalam > Wikipedia. [...] Comment 27 began with "In your case": I asked about Ajay's experience, the rest I personally leave to experts and oracles.
[offtopic] Jacob: http://www.mediawiki.org/wiki/Bugzilla/Fields explains the meaning of priority and severity. Please do not reset them and please do not change summaries to ask for something totally different. If you have questions, please drop me a private email.
I have been contributing to various Malayalam ventures of Wikimedia for many years. I used to introduce wikipedia to new users and train them to contribute contents. Most of them are fascinated by the idea of collaboratively generating free content for the benefit of their fellow beings. Recently many of such users started raising complaint on some distractions they are facing while editing. I noticed these problems are induced by the forcefully enabled of ULS in their interface. Many of them have recently stopped their editing. So this bug has to be taken very seriously and appropriate action has to be taken at the earliest. If users of other language ventures does not find it as an issue, It would be nice to disable ULS by default at least in Malayalam ventures. Many users of Malayalam wikipedia are demanded it. The link of voting in this regard was already given in earlier comment $16 and comment #24 by others.
Anilkumar: Specific issues with ULS should be filed as specific bugs with clear instructions how to reproduce the issue: https://www.mediawiki.org/wiki/How_to_report_a_bug High-level discussions about ULS are better suited on the mailing list at https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n and are offtopic for any specific bug report. For your interest, reasons for ULS user interface design decisions can be found in http://www.mediawiki.org/wiki/File:ULS_Usability_testing_summary.pdf As written before, disabling ULS completely is not planned and will not happen, instead specific and actionable requests for improvements are very welcome.
(In reply to comment #27) > In your case, why isn't it enough to disable the input methods and choose > system font? That basically disables everything, except the presence of the > gear/settings icon. This does disable everything, and the flickering keyboard is gone too. Now, if I get to see the window in yellow when the input language is malayalam, it would be perfect.
(In reply to comment #22) > Perhaps, the testing of all new features should be done from a dial up > connection in a third-world rural school or a primitive GPRS link through a > villager's barebone mobile phone, first. The Wikipedia experience from that > point will make the developers know a difference! I know nothing of the ULS, except that it's one more thing slowing down my access to a page, and I'm in North America on a fast computer and a high speed internet connection. However, Vishwaprabha has hit the nail on the head. Wikimedia projects are becoming increasingly inaccessible to users, including readers, who are in our largest target audiences. This is at least in part because the primary developers of unavoidable MediaWiki extensions are *not* testing in less than ideal circumstances. This is a systemic problem, of which ULS is only one example. But when technology is driving away editors, then "Wikimedia the Tech company" is failing its mission.
Comment 33 explained already: High-level discussions about ULS are better suited on the mailing list at https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n If you would like to discuss what "Wikimedia the Tech company" is doing wrong, please do it but at https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum Can we now please stay ontopic? Bugzilla is not a forum.
If there is question about whether a bug is an issue or not, should the discussion not go on the bug? If this is off-topic, then please point to somewhere specific where it would be on-topic and appropriate, because it is a discussion that needs to be had both with regard to this specific bug as well as with regard to practices in general.
Is it impossible to add an option to disable ULS? Does WONTFIX mean that? Such an option will FIX this issue. As far as this issue is concerned, I dont understand what is meant by WONTFIX.
(In reply to comment #38 by Ajay) If you click the "Status" link next to "Status: RESOLVED WONTFIX", it explains that WONTFIX means "The problem described is a bug which will never be fixed." Comment 33 said "disabling ULS completely is not planned and will not happen". Comment 20 said "Except for input methods, all other ULS functionalities will have no user interface that allows it to be disabled." (In reply to comment #37 by Isarra) > If this is off-topic, then please point to somewhere specific where > it would be on-topic and appropriate Done that already, see comment 33 (though not sure what your "this" is - I refered to high-level "Wikimedia is doing something wrong" debates).
(In reply to comment #36) > Comment 33 explained already: High-level discussions about ULS are better > suited on the mailing list at > https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n > If you would like to discuss what "Wikimedia the Tech company" is doing > wrong, > please do it but at > https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum > > Can we now please stay ontopic? Bugzilla is not a forum. There's no right place, Andre, and we all know that. We ask for something to be fixed anywhere, and we're told to write a bugzilla, even for "high level" matters. And then if we write a bugzilla about an issue that nobody wants to address, we're told to join some mailing list that has no authority to address the issue, or post on some noticeboard that also has no authority to address the issue and probably isn't even being watched by anyone who *can* address the issue. Or we can post on MediaWikiWiki, where non-techs are pretty routinely ignored. Please keep this in mind: I've been told to join the tech-ambassadors mailing list in order to follow upcoming technical changes, but the two recent really major technical changes (VE and ULS) haven't been mentioned on that list at all.
So, actually, what is bugzilla? A place to play ping-pong? Or where we play "ON TOPIC" laurel & Hardy? Sorry for asking, but I am still very Wikipedian and still very a man on the "King's side". Only just confused too much about this non-"Forum" being part of the 'free' Wikimedia! Please do not pinch me or strangle.
You may want to talk about this on IRC, since there will be an office hour about ULS next week: https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
The discussion on ml.wikipedia.org seems to be about defaulting to the system font, rather than setting a font that doesn't work well for many users. That's a change that was already made for Tamil Wikipedia. Unfortunately it's impossible to reliably detect what fonts are present on a user's system, so we're often faced with the choice of initializing a freely licensed font, which may override a locally present font, or having some users not be able to view the page _at all_. That said, if the overwhelming consensus in the Malayalam community is that the provided font is inferior to the system font installed on many users' systems, it seems sensible to default to the system font instead, like we did for Tamil.
(In reply to comment #43) > The discussion on ml.wikipedia.org seems to be about defaulting to the system > font, rather than setting a font that doesn't work well for many users. > That's > a change that was already made for Tamil Wikipedia. > > Unfortunately it's impossible to reliably detect what fonts are present on a > user's system, so we're often faced with the choice of initializing a freely > licensed font, which may override a locally present font, or having some > users > not be able to view the page _at all_. > > That said, if the overwhelming consensus in the Malayalam community is that > the > provided font is inferior to the system font installed on many users' > systems, > it seems sensible to default to the system font instead, like we did for > Tamil. This bug was filed to provide an option to disable ULS to all those who want it disabled. This is not limited to Malayalam Wikipedia. In Malayalam Wikipedia, we are currently having poll to build a community consensus to decide whether or not the ULS extension should "initially present.. as disabled". As soon as we reach a consensus, we will file another bug regarding that.
Sorry for adding to the meta-discussion... (In reply to comment #40) > Please keep this in mind: I've been told to join the > tech-ambassadors > mailing list in order to follow upcoming technical changes, but the two > recent > really major technical changes (VE and ULS) haven't been mentioned on that > list > at all. Risker, ULS was announced with http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-June/000271.html As regards last minute notifications, it's true that Greg's Deployment Highlights missed a couple of cc in the last two rounds, that should be easy to fix (cc'ed him in case you didn't tell him already).
(In reply to comment #44) > In Malayalam Wikipedia, we are currently having poll to build a community > consensus to decide whether or not the ULS extension should "initially > present.. as disabled". As soon as we reach a consensus, we will file another > bug regarding that. Hi Ajay, it would help (and we can take it to https://www.mediawiki.org/wiki/Talk:Universal_Language_Selector if folks would prefer that) if you could explain what the issues are. The issue I can infer from the discussion concerns fonts. If the default font is really not a good choice, then it can be changed separately to the system font without disabling ULS, just like it is on Tamil Wikipedia.
It's possible to add the following to [[MediaWiki:Common.js]] to override the ULS default configuration: $.webfonts.repository.languages.ml = ["system", "Meera", "AnjaliOldLipi"]; This will change the default font to text tagged "ml" from the current default to no default (i.e. a user's system font), and will make subsequent array members available as options in the font choice dialog. We advise against adding font names there that are not in the MediaWiki UniversalLanguageSelector font repo [1]. [1] https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FUniversalLanguageSelector.git/HEAD/data%2Ffontrepo%2Ffonts
(In reply to comment #43) > Unfortunately it's impossible to reliably detect what fonts are present on a > user's system, so we're often faced with the choice of initializing a freely > licensed font, which may override a locally present font, or having some > users not be able to view the page _at all_. It is possible, just hard to implement well. But it's a solved problem these days. http://www.lalit.org/lab/javascript-css-font-detect/
AFAIK, A well implemented DOM model can even detect the rendering dimensions, not just the kind of available fonts, on the output screen.
Oh, the comment#48 above is a very good demonstration of what I mentioned in comment#49!
I presume the only needed change in code for one of the issues mentioned in our community page, is to simple remove a * from the line shown here: https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FUniversalLanguageSelector/20033e4fbf0c4743df5162f10c67c0751c414608/data%2Ffontrepo%2Ffonts%2FMeera%2Ffont.ini#L2 This will keep Meera being self-initiated as the preferred default font during the Webpage loading. The required change is similar to https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FUniversalLanguageSelector/e726f016153727d82ef1652dbe7bb4fd426035e5
This user claims to have successfully disabled ULS by using Adblock, with three rules: <https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&diff=562972847&oldid=562970770>
https://en.wikipedia.org/w/index.php?title=Wikipedia%3AHelp_desk&oldid=562961777#Odd_lag
It is a shame that some third party site adblock has to come to the rescue of veteran Wikipedians!
(In reply to comment #54) > It is a shame that some third party site adblock has to come to the rescue of > veteran Wikipedians! Well, that was a Firefox extension fixing a problem for a Firefox user, it doesn't sound so inconceivable (surely better than a reformat, ouch).
Viswaprabha, that is probably caused by bug 49935.
Adblock does deactivate ULS. The correct incantatio is the rule: wikipedia.org/w/api.php?action=ulslocalization&language= To disable downloading WMF webfonts, use this rule: bits.wikimedia.org/*/extensions/UniversalLanguageSelector/data/fontrepo To disable all webfonts 1) Mozilla Firefox Open about:config Set "gfx.downloadable_fonts.enabled" to false. 2) Google Chrome Right Click Chrome's launcher icon, click "Properties". At the end of the launcher string add the following: " --disable-remote-fonts" (without quotes).
Reopening; no reason that I could find was given for closing this bug as it currently stands, and this is indeed an issue given the nature of the extension. Useful as it may be for some folks, it can be just as problematic for others for all manner of reasons. Neither group should be ignored.
(In reply to comment #58) > Reopening; no reason that I could find was given for closing this bug as it > currently stands, and this is indeed an issue given the nature of the > extension. I'm not sure what you mean by "this is an indeed an issue." Can you elaborate? > Useful as it may be for some folks, it can be just as problematic for others > for all manner of reasons. Problematic how? --- At 59 comments, this bug is pretty complex and difficult to follow. I'd strongly recommend filing a new bug that can answer the above questions. :-)
(In reply to comment #59) > (In reply to comment #58) > > Reopening; no reason that I could find was given for closing this bug as it > > currently stands, and this is indeed an issue given the nature of the > > extension. > > I'm not sure what you mean by "this is an indeed an issue." Can you > elaborate? > > > Useful as it may be for some folks, it can be just as problematic for others > > for all manner of reasons. > > Problematic how? > > --- > > At 59 comments, this bug is pretty complex and difficult to follow. I'd > strongly recommend filing a new bug that can answer the above questions. :-) As I understand it, any new bug for the exact same topic would just be closed as a duplicate. Which is stupid; I agree that a new bug to try to focus the discussion is probably be in order, since most of this doesn't really go anywhere. I filed Bug 56292 for basically the same reasons (and it might answer some of those questions), but it's a slightly different, slightly more general issue.
*** Bug 56292 has been marked as a duplicate of this bug. ***
Siebrand, Please don't close bugs like this, which is requested by many communities repeatedly, just because you don't support it.
There have been no new arguments provided to reopen this ticket. Comment 46 and comment 47 have not been answered. In general, maintainers of projects are free to decide what functionality they implement and what not. Hence please keep this ticket as WONTFIX for the time being. Bugzilla also allows to add comments without changing the status.
But you people are getting paid for solving bugs not WONTFIX it ignoring communities.
But you people are getting paid for solving bugs, instead of WONTFIX it ignoring communities.
You want a very good reason (in addition to the many reasons that were already given before but which are seemingly ignored by the devs)? Lately I had to rely on a very slow and unstable wireless connection. The HTML part of pages was usually loaded. CSS and especially JS parts often timed out, though (and as far as I know ULS is a huge piece of JS adding substantial amounts of CSS). As a result Wikipedia got totally unusable for me, while many other pages being more lightweight did still work without problem. So get off your high horse - not everybody has access to a 100 MBit cable connection nowadays. It's a shame Wikipedia is not suitable for low bandwith connections because of nice-to-have but not necessary extensions like ULS. If I had the possibility to disable all the unnecessary cruft which ULS is only a part of I could have possibly continued to use Wikipedia. Since there currently is no such possibility I had to do my research somewhere else.
(In reply to comment #63) > In general, maintainers of projects are free to decide what functionality > they implement and what not. This is not completely true. Siebrand can certainly decide how to spend his own time, but he cannot dictate to others how to spend theirs. This does not seem like a situation in which patches won't be accepted. In fact, it seems to be exactly the opposite: patches are desperately needed to make ULS less of a burden to users. This issue has been split out to bug 56292.
(In reply to comment #65) > But you people are getting paid for solving bugs, instead of WONTFIX it > ignoring communities. This is a fallacy; sometimes, a WONTFIX is the appropriate solution, and project managers are also paid for making hard decisions and WONTFIXing bugs. (I've already expressed my opinion on whether it is appropriate here.) Alas, this is clearly not going to happen for Wikimedia wikis for reasons which are unconvincing to me; but unless somebody convinces the Board of Trustees or someone with comparable decisive power, we can't do anything about it. *However*, that doesn't stop the option itself from being implemented – even if it's not made available for Wikimedia wikis – so maintainers of third-party wikis who have a different set of priorities than WMF can make this extension available as opt-in or opt-out, not mandatory. I am CC-ing Mark Hershberger (hexmode), MediaWiki release manager, and asking for his input. I would suggest reopening the bug again, making it clear that this would be third-party only, and setting it to lowest priority to indicate that WMF teams are not going to spend any resources on it. I'm also imploring Siebrand to actually reply one more time instead of just closing the bug with no explanation, as it seems to me that Isarra's intention was exactly what I said above.
Change 92562 had a related patch set uploaded by Legoktm: Add user preference to enable ULS https://gerrit.wikimedia.org/r/92562
It wasn't my intention to re-open the bug, sorry. I agree with most of what the people above (Bartosz, Isarra, etc) have said, and am willing to work on the patch to get this bug resolved.
(In reply to comment #66) > CSS and especially JS parts often timed > out, though (and as far as I know ULS is a huge piece of JS adding substantial > amounts of CSS) If that's the real issue, the answer here is further optimizing ULS load and performance characteristics and eliminating the need for a preference. Are there other reasons to want a preference beyond performance?
Comment #65 is a succinct expression of the frustratione that users sometimes end up feeling when the Foundation changes Wikipedia and its sister sites in unexpected ways. If other sites use ULS, then it makes sense to keep track of this issue. As far as testing on low bandwidth connections, there is Bug #55842 for this issue.
The performance was an issue, but also the font issue. If it really is causing editors to leave mlwiki, then it should be addressed.
(In reply to comment #71) > (In reply to comment #66) > > CSS and especially JS parts often timed > > out, though (and as far as I know ULS is a huge piece of JS adding substantial > > amounts of CSS) > > If that's the real issue, the answer here is further optimizing ULS load and > performance characteristics and eliminating the need for a preference. Are > there other reasons to want a preference beyond performance? It's a real issue. Another, more general, issue is that it adds an extra interface and fonts that for many users simply serves no purpose, or even makes things worse. There is enough clutter as is; when it comes to added features with specific use cases, folks should be able to remove what they don't use. Essentially this is a gadget in extension form, and follows, or should follow, many of the same principles. (It's true that if the first issue is resolved, it would then be more feasible for users to just hide that interface and such if desired, but such an approach is rather poor practice in the long run especially with relatively large objects such as this.)
There are several separate issues here: 1) Does ULS have an unacceptable performance impact on some users which needs to be mitigated; 2) Does ULS include functionality that is simply irrelevant for some users while cluttering UI; 3) Is there a specific "third party" vs. "WMF" issue here. I think the third point is a red herring. If we agree that there are real issues to be solved, then we should solve them for everyone, not just hypothetical third party ULS users who have a hypothetical interest in offering users ULS while also offering them the option to disable it on a per-user basis. The first point, performance, has been an ongoing issue with ULS. The initial release of ULS caused insane amount of font-loading to occur on pageviews with language links. That issue was unfortunately unresolved far too late, which probably caused a lot of users to identify ULS with negative performance impact. Loading of fonts for sidebar links has been disabled since late September, and the new autonym font should offer a solution for this issue once and for all: https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/ This is by far the biggest performance issue with ULS -- we're talking about megabytes of payload on some pages. I suspect, though, that even with the autonym font, we need to continue to improve font-loading behavior. It's possible to force use of system fonts; however, I don't see an option to disable font-loading altogether. Having that be an option within ULS itself may be useful for users of slow connections. Has that been discussed? The JS/CSS payload is less of an issue, and the team has already made some optimizations, though there's probably still room to do more lazy-loading so that ULS truly only adds payload to page requests when actually used. I've CC'd Ori on this bug from his perspective as Performance Engineer, though there are probably other relevant bugs where this discussion is occurring/should occur. Regarding the question if ULS should be "disable-able" for some users altogether, the reason I'd argue against it is that ULS is basically a core site feature: changing the UI language and language settings. It's like hiding a part of the preferences section. It's where ULS has impact that goes _beyond_ what you'd expect from a preferences/selection feature that preferences or changes to the default behavior are more appropriate. In addition to the font issue, the only other aspect of ULS where that's true is arguably the input method selection. This is really the only part of ULS that adds true clutter to the page, because it pops up in every edit field, taunting you with a feature that may be completely irrelevant to you. It _can_ be disabled and hidden with a single click from the menu. I know the UX folks have thought about a way to make the selection control itself less annoying, e.g. embedding it into form fields rather than having it come up on focus below the field. IMO we should be focusing on improvements like this. Improving the user experience in this fashion also makes sure we reach all users, and not just the small percentage who are annoyed enough to change a preference. Preferences are a form of clutter, too, and we should be very thoughtful and intentional when we add them.
Erik and others: bug 56292 focuses on making ULS more lightweight and more performant. I think adding a user preference is a last resort. We should try to figure out why people hate ULS so much that they want to actively disable it. I'd also encourage you to look at mw.loader.inspect(). :-) Just run it from a developer console and look at the output.
(In reply to comment #75) > There are several separate issues here: > > 1) Does ULS have an unacceptable performance impact on some users which needs > to be mitigated; Yes. > > 2) Does ULS include functionality that is simply irrelevant for some users > while cluttering UI; Irrelevant for some users, yes. I don't personally think it is cluttering the UI. > > 3) Is there a specific "third party" vs. "WMF" issue here. > > I think the third point is a red herring. If we agree that there are real > issues to be solved, then we should solve them for everyone, not just > hypothetical third party ULS users who have a hypothetical interest in > offering > users ULS while also offering them the option to disable it on a per-user > basis. Okay. > > The first point, performance, has been an ongoing issue with ULS. The initial > release of ULS caused insane amount of font-loading to occur on pageviews > with > language links. That issue was unfortunately unresolved far too late, which > probably caused a lot of users to identify ULS with negative performance > impact. Loading of fonts for sidebar links has been disabled since late > September, and the new autonym font should offer a solution for this issue > once > and for all: > https://blog.wikimedia.org/2013/10/28/the-autonym-font-for-language-names/ > > This is by far the biggest performance issue with ULS -- we're talking about > megabytes of payload on some pages. I suspect, though, that even with the > autonym font, we need to continue to improve font-loading behavior. It's > possible to force use of system fonts; however, I don't see an option to > disable font-loading altogether. Having that be an option within ULS itself > may > be useful for users of slow connections. Has that been discussed? I don't think so. While webfonts are pretty large, ULS itself is also large. > > The JS/CSS payload is less of an issue, and the team has already made some > optimizations, though there's probably still room to do more lazy-loading so > that ULS truly only adds payload to page requests when actually used. I've > CC'd > Ori on this bug from his perspective as Performance Engineer, though there > are > probably other relevant bugs where this discussion is occurring/should occur. I disagree that JS/CSS payload is less of an issue. On the latest master of ULS + MediaWiki master, the top 4 entries in mw.loader.inspect() are from ULS: 'jquery.uls', 'jquery.uls.data', 'ext.uls.init', and 'ext.uls.webfonts.repository' (118.67KB total). The next extension on the list that I have installed is Echo, which has a total of 14.79KB (not including common dependencies like mediawiki.jQueryMsg). On enwiki's main page the results are similar, except for jquery.ui being loaded from somewhere, but I understand that's already on its way out (bug 47145). > > Regarding the question if ULS should be "disable-able" for some users > altogether, the reason I'd argue against it is that ULS is basically a core > site feature: changing the UI language and language settings. It's like > hiding > a part of the preferences section. It's where ULS has impact that goes > _beyond_ > what you'd expect from a preferences/selection feature that preferences or > changes to the default behavior are more appropriate. I disagree. You can go to Special:Preferences and change your language settings there. ULS even conveniently adds a link in that section to open the ULS language selection pane. For people who don't change their language settings every few minutes or ever, that feature isn't needed. > > In addition to the font issue, the only other aspect of ULS where that's true > is arguably the input method selection. This is really the only part of ULS > that adds true clutter to the page, because it pops up in every edit field, > taunting you with a feature that may be completely irrelevant to you. It > _can_ > be disabled and hidden with a single click from the menu. I know the UX folks > have thought about a way to make the selection control itself less annoying, > e.g. embedding it into form fields rather than having it come up on focus > below > the field. IMO we should be focusing on improvements like this. I like that option because there's a way to turn it off. For people who find it useful, they can keep it enabled, but for people who don't, they can turn it off. The rest of ULS needs an option like this too, simply because not everyone needs/uses/wants it. Right now wikis are resorting to ugly hacks like https://en.wiktionary.org/w/index.php?title=MediaWiki:Common.js&oldid=23352360 to disable ULS. Providing a sane off switch is an improvement.
Adding a user preference should be considered a last resort. The reality is that most site visitors can't set user preferences at all and most logged-in users will never know about or set this user preference. We must focus on having sane default behavior.
(In reply to comment #76) > We should try to figure out why people hate ULS so much that they want to > actively disable it. I think that this is a useful frame (though 'hate' is a bit extreme). There is a marked discrepancy between our (the developer community, broadly defined) understanding of ULS performance and user's reports of their experiences. The explanation that I think is most convincing is this one: - There are still serious performance issues with ULS. - Users can sense that something is wrong, but they don't always have the means to express it in a technically precise way. - Developers want to fix problems, but we're not measuring anything that shows the problems clearly. - The point of reference for input tools and font rendering is the native capabilities implemented in the OS. - Anything implemented in JavaScript and interpreted at page load is going to be several orders of magnitude slower. There is a wide band of performance degradation that leaves you irritated and aware that something is not as it should, but unable to pinpoint the source of irritation. I've been able to identify one example: the language input selection interface. Something is causing the browser to repeatedly recalculate styles while the interface is active, which makes the browser appear sluggish and unresponsive. This is especially noticeable when scrolling. I recorded a short screencast showing how one might go about diagnosing this issue: <http://www.youtube.com/watch?feature=player_detailpage&v=JprXNc9Ei2A> (YouTube; sorry.) I suspect that this is not an isolated issue, and that there's a lot that we need to investigate. If you want to take a stab at the scroll issue, you might find this resource helpful: http://theamazingweb.net/2013/09/10/debugging-and-fixing-janky-scrolling-with-paul-irish/ Please be nice to the Language Engineering team; they put in a lot of work into making ULS excellent in all the aspects that our development infrastructure is good at disclosing. There is a collective engineering responsibility here to get a handle on user-perceived latency and to integrate it into our code review and acceptance testing processes. In our defense the tooling for doing this kind of work is really in its infancy. (That scroll bottleneck detection tool? It's in the dev channel of Chrom{e/ium}; I don't think it's even in beta yet!)
Thank you very much for the analysis, Ori. For now, I've filed bug 56433 to consider temporarily scaling back the deployment of ULS to Wikimedia wikis.
(In reply to comment #75) I think you summed up the issue very well Erik capturing most of the problems around ULS. Following some of my thoughts regarding your post: > 1) Does ULS have an unacceptable performance impact on some users which needs > to be mitigated; That depends on the definition of "unacceptable". *After most of the serious performance issues are solved now performance is probably acceptable on most hardware given a sufficiently fast internet connection. *On old hardware or a slow internet connection performance is still insufficient as mentioned above. *For people who never use any of the features of ULS the the performance impact can always be considered unacceptable - why use substantial processing power, memory and bandwidth for an unused feature? > 2) Does ULS include functionality that is simply irrelevant for some users > while cluttering UI; Definetly yes! The only language feature I ever used is setting UI language - and I did that only once in the my user preferences. Therefore ULS is completely redundant for me. Regarding cluttering I'm especially annoyed on Commons (which has the language name written out prominently on top of the page. Since I set different languages on Commons (English) and my home Wiki (German) I often see distracting "Language changed from ..." pop-ups when navigating from German Wikipedia to Commons via interwikilinks. > 3) Is there a specific "third party" vs. "WMF" issue here. I don't think so. I'm not active on any third party Wiki that would use ULS. I'm having these Issues on WMF Wikis! > It's possible to force use of system fonts; however, I don't see an option to > disable font-loading altogether. Having that be an option within ULS itself > may be useful for users of slow connections. Has that been discussed? Not really. I mentioned it once but it wasn't really considered. But it would be definitly a step into the right direction.
Change 92562 merged by jenkins-bot: Add user preference to enable ULS https://gerrit.wikimedia.org/r/92562
Change 108666 had a related patch set uploaded by Ori.livneh: Add user preference to enable ULS https://gerrit.wikimedia.org/r/108666
Change 108666 merged by jenkins-bot: Add user preference to enable ULS https://gerrit.wikimedia.org/r/108666
Change 108667 had a related patch set uploaded by Ori.livneh: Add user preference to enable ULS https://gerrit.wikimedia.org/r/108667
Legoktm said: > I haven't actually tested it, but from a quick glance in Translate's code, the > module 'ext.translate.special.translate' is loaded, which has a dependency upon > 'ext.uls.init', which means ULS would be loaded regardless of the user preference. Was this tested?
Change 108667 merged by jenkins-bot: Add user preference to enable ULS https://gerrit.wikimedia.org/r/108667
The deploy lacked l10n. The checkbox <uls-preference> is unchecked by default it seems, no idea what it does though.
Created attachment 14350 [details] Translate missing language selection (In reply to comment #86) > Legoktm said: > > I haven't actually tested it, but from a quick glance in Translate's code, the > > module 'ext.translate.special.translate' is loaded, which has a dependency upon > > 'ext.uls.init', which means ULS would be loaded regardless of the user preference. > > Was this tested? Apparently not. I confirm Translate is broken.
No idea what to do, adding a few platform & product & fundraising & comm people + Andre so that the affected parties decide something.
Andre: can you please explain why you marked this bug report as immediate? Isn't this bug report now most appropriately marked resolved/fixed? I'm not sure there are still patches to review.
(In reply to comment #89) > Apparently not. I confirm Translate is broken. Did you enable the new ULS user preference? Is Translate still broken with the new user preference enabled?
(In reply to comment #89) > > Was this tested? > > Apparently not. I confirm Translate is broken. I tested this back in October and it worked fine for me locally, but there have been a ton of changes to ULS since then.
(In reply to comment #92) > (In reply to comment #89) > > Apparently not. I confirm Translate is broken. > > Did you enable the new ULS user preference? Is Translate still broken with > the > new user preference enabled? Enabling the preference makes Translate work fine, however the expectation (or at least mine was) was that Translate would continue to work regardless of preference setting. Still investigating.
*** Bug 60281 has been marked as a duplicate of this bug. ***
ULS provides vital functionality on Wikidata. We need it and need it enabled by default.
(In reply to comment #96) > ULS provides vital functionality on Wikidata. We need it and need it enabled > by default. Is the Wikidata team willing to donate engineering resources to help fix ULS so that it can be re-enabled by default? As I understand it, ULS was disabled due to ongoing and severe performance problems.
I can't say without knowing what is needed. Until it was disabled I wasn't aware of any issues with it on Wikidata.
Lydia: The main performance issues have been with the automatic font loading behavior. It should be possible to restore the base functionality (language selection, input methods) very soon.
Personally I am thankful to those made this change, although <uls-preference> is bit cryptic ;-). But like the complex structure of ULS (which unnecessarily mixed totally different requirements together), disabling it completely is also problematic. Webfonts and fancy scripts are more than a hurdle to most users but IME is a useful feature to most non-Latin users. Even though it was a less responsive, heavy, less distinguishable whether enabled or not script than old Narayam. By disabling a default input method, Indic wikis where pushed atleast somewhere before 2009. :-( IMO If possible, break ULS into different pieces or atleast make a more descriptive options to disable ULS which helps users to disable / enable components without affecting any other component.
Change 108698 had a related patch set uploaded by Legoktm: Make ext.uls.mediawiki depend upon ext.uls.init https://gerrit.wikimedia.org/r/108698
(In reply to comment #96) > ULS provides vital functionality on Wikidata. We need it and need it enabled > by > default. Change-Id: Ia4b865d41311e2436bb6a86593fb61eaf64891cc Someone will need to assess whether doing so will cause another load spike upon bits. (In reply to comment #101) > Change 108698 had a related patch set uploaded by Legoktm: > Make ext.uls.mediawiki depend upon ext.uls.init > > https://gerrit.wikimedia.org/r/108698 This should fix integration with the Translate extension.
(In reply to comment #100) > IMO If possible, break ULS into different pieces or atleast make a more > descriptive options to disable ULS which helps users to disable / enable > components without affecting any other component. THIS. Preferably the first bit. Although that should probably be a different bug. Or is it already?
(In reply to comment #103) > (In reply to comment #100) > > IMO If possible, break ULS into different pieces [...] > > THIS. Preferably the first bit. > > Although that should probably be a different bug. Or is it already? If that's the first bit you refer to, it was already possible; what this bug was mostly about is the (possibility of) a complete disabling, including the ULS trigger which is the only piece without a disabling feature. Later it turned into a bug about the default state, though. Making disabling/enabling of some features require less clicks would be e.g. bug 46044; while on the visibility of the trigger little can be done: some indic wikis would like it more prominent and some others less, the compromise was the (inter)language area.
Change 108698 merged by jenkins-bot: Make ext.uls.mediawiki depend upon ext.uls.init https://gerrit.wikimedia.org/r/108698
Change 108707 had a related patch set uploaded by Legoktm: Make ext.uls.mediawiki depend upon ext.uls.init https://gerrit.wikimedia.org/r/108707
Change 108709 had a related patch set uploaded by Legoktm: Make ext.uls.mediawiki depend upon ext.uls.init https://gerrit.wikimedia.org/r/108709
Change 108709 merged by jenkins-bot: Make ext.uls.mediawiki depend upon ext.uls.init https://gerrit.wikimedia.org/r/108709
Change 108707 merged by jenkins-bot: Make ext.uls.mediawiki depend upon ext.uls.init https://gerrit.wikimedia.org/r/108707
*** Bug 56433 has been marked as a duplicate of this bug. ***
(In reply to comment #89) > Apparently not. I confirm Translate is broken. And still is, I'm told: bug 60306. This bug is not properly fixed until bug 60306 is, but I suppose reopening this report would just make everything even more messy. Sigh.
So apparently what is wanted is: * Possibility for users to disable ULS completely: - This can be made temporarily for the session (including for non-loggeg in users - the ULS icon disappears - on page refresh, the ULS javascript is no longer loaded of it is just a stub - For logged in users, the ULS feature is within the Gadgets preferences * With URL still ebabled, we can disable each of its 5 features (keeping its associated settings) - disable the icon at the top: the gadget preferens are still accessible in user preferences or by following a link that allows reopenng the ULS dialog to reenable the icon - diable/enable input methods assistants - diable/enable per-langage font overrides (all languages in one operation, but keep their settings so that we can enable them again without having to reconfigure them all) - disable only webfonts (per-language font overrides may continue to work if they are effective, but users may have to install these fonts); this includes the Autonym font But I don't see any point for enabling/disabling the user language selection if ULS is still active, even uf the icon is hidden at top of page. It is a grear thing that we can switch the UI lanuage without having to visit the full User prefenreces pages: two clicks for switching. For non logged-in users, the possibility of switching the UI language is a key feature, notably on multilingual sites like Commons, Incubator, and Beta Wikiversity. But the UI language selection is not really a key feature of ULS, it just offers a smart dialog equivalent to the Language selection combobox of the user preferences. For this reason I think it should be kept (and probably the icon at top of page too). And yes trying to reduce the footprint of ULS in terms of bandwidth added to load a page should be a priority (but this is not exclusive to ULS, other gadgets or accessibility features (often very desirable) should be minimized as well. There's only one situation where ULS should be disabled completely in user preferenes within Gadgets: incompatibilities or problems with the user's own assistive technologies (using external tools, e.g. Braille readers) or some security tools (that may filter some javascripts conditionnally, or could modify them on the flow so that they could be broken) or form input assistants (e.g. password fillers...= or when it causes compatibility problems with some simpler devices (e.g. on some smart TVs or settop boxes, or smartphones, that embed a basic web browser often full of bugs and never updated, such as Opera Mini, or Opera Embedded, or Basic Android browser). Note that for smartphones, Wikimedia may offer a mobile version of the wiki which uses a simpler interface. In //*.m.wikipedia.org for example UTL cannot work, even if users are logged in, but the mobile version requires another ULS implementation. But mobiles visitings the mobile version of the wiki still have the option to visit the web version, and the web version should continue to work, and ULS should not add too much fullprint; You don't need to live in rural thirld world area to test this: use a basic Android smartphone to connect via a Wifi hotspot (NOT Wifi N or not connected to a fast broadband), then look with an indoor 3G+/HSDPA connection (which may switch to 3G/UMTS or even to 2G+/EDGE or 2G/GPRS with poor reception)
The Wikisources were using the functionality of ULS within templates as a means to show these character sets as per the works being replicated, and this enabled these different character sets, easily even something like the blackletter font-family:'UnifrakturMaguntia' Having this functionality OFF by default means that the Wikisources cannot know that the font will show unless we convince people to turn it on (somehow), and to even be able to notify them how to do it. Out of my technical grasp of how to now implement this, and for the broader communities to have to nut out the issue, from a bugzilla report about which they know nothing is not helpful. NOTE ABOUT PROCESS That this disabling out of the normal release cycle, and without information to the wikis is quite problematic. If changes like this are going to happen, it would be good for solutions to be provided prior to the change, for the change to communicated. We have have a forum for such things, and it wasn't used. It is not a case of the whipping boy, but this is a repeat of earlier instances, and a massive case of <grrrr> <face palm> with lashings of deja vu. How is WMF going to demonstrate that they will utilise the processes that they have advocated for such changes where the impact is broad?
https://www.mediawiki.org/wiki/Universal_Language_Selector needs updating by someone who has their head around what is happening.
What's going to happen next is that ULS will be re-enabled, but with _automatic_ font loading disabled by default. You'll be able to enable _automatic_ font loading within the ULS user interface. Once that version of ULS is deployed, we'll do additional data-gathering before any kind of progressive re-enablement of automatic font downloading. It's the font download component that can cause huge latency issues, and has been the main reason for ULS being completely disabled temporarily. The Wikisource use case is probably the most innocuous, but we also want to do some additional work on the JavaScript footprint required to deliver that functionality, especially if that JavaScript footprint needs to be loaded by non-Wikisource users as well.
Please make ULS enabled by default for all Indian language Wikipedias. It was like that till yesterday. From yesterday, ULS is available only after someone enables it from his/her preferences. That means no one can search Indian language Wikipedias without logging in because one can change the preferences only after logging in. This new change is seriously affecting the use of Indian language Wikipedias. Not many Indians are familiar with installing third party IMEs or enabling the IMEs given in the OS (Windows). ULS was helping such people. Hence I request to make ULS enabled by default for Indic Wikipedias.
Pavanaja, the previous input method behavior will be restored once ULS is re-enabled.
Erik you did not consider 7 to 10% of a population who are dyslexic. You consider all the use cases as secondary and in the mean time you stop providing a service. WHY
To everybody: Please think a moment if you really have to add a comment here. Many things have already been brought up and every comment creates bugmail. The situation and the plans are already covered in comment 115. (In reply to comment #116) > Please make ULS enabled by default for all Indian language Wikipedias. Different topic - see & discuss in bug 60323 instead, please.
