jacob.jose wrote:

Please refer here for the discussion

http://ml.wikipedia.org/wiki/Wiki_Panchayath_Technical#English_translation_of_the_proposal_being_voted_here

jacob.jose wrote:

Changed title since that has been the primary limitation due to which users wanted ULS disabled

drajay1976 wrote:

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.

viswaprabha wrote:

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.

viswaprabha wrote:

(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.

anilankv wrote:

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.

drajay1976 wrote:

(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.

drajay1976 wrote:

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.

viswaprabha wrote:

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.

drajay1976 wrote:

(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/

viswaprabha wrote:

AFAIK, A well implemented DOM model can even detect the rendering dimensions, not just the kind of available fonts, on the output screen.

viswaprabha wrote:

Oh, the comment#48 above is a very good demonstration of what I mentioned in comment#49!

viswaprabha wrote:

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

viswaprabha wrote:

https://en.wikipedia.org/w/index.php?title=Wikipedia%3AHelp_desk&oldid=562961777#Odd_lag

viswaprabha wrote:

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
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.

Attached:

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.

Gerard.meijssen wrote:

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.