To point (2) we should display messages like: ...

+1, these are great suggestions.

Yep, seems to be working now! That was bad timing for a server upgrade :P

I switched to Firefox and was able to log in successfully. Maybe a cookie issue?

@Mvolz - Is this something you could look into?

Boldly moving to "Upcoming Work" so it isn't forgotten about. Feel free to move elsewhere if appropriate.

Since the only wikis using $wgWikibaseAllowLocalShortDesc are English Wikipedia and Test Wikipedia, I think we should just repurpose that config variable rather than creating a new one. To implement this change, we'll probably need to do some refactoring in client/includes/Store/DescriptionLookup.php and client/includes/Api/Description.php and update all the associated tests (within the Wikibase extension).

It seems like Approach #1B would be a lot more feasible as a parser function (ala T128535) rather than a template.

@ppelberg @marcella - This task was unblocked in October 2019, but is still sitting in the Blocked column. Can we either move this forward or decline it?

Is it expected that users of IE8 have access to some foundation web properties in some form?

Per my discussions with Volker, no. IE8 users may be totally unable to reach our sites next week, and that's OK. Of course, my hope is that they will still able to use the site in a minimal capacity, but if not, we will no longer expend effort to support them.

@Nuria - We were hoping that we could handle this with the existing instrumentation. Right now, in both editors, the ready action is recorded on the client-side by EventLogging (as far as I understand). We were hoping to use that as an indication of whether someone has JavaScript turned on or off. Do you know if ad blockers interfere with EventLogging recording the ready event on the client-side? Do ad blockers prevent all client-side EventLogging? If so, what's the best way to work around that? Would we have to build some type of custom tracking system?

Marking this as resolved (more or less). The conclusion is that EventLogging should not support DNT, for the following reasons:

• DNT is a failed experiment which was not fully adopted by browser vendors and is now being removed by some of them.
• There is no consensus on what DNT should apply to.
• Our existing implementation of DNT-support is inconsistent.
• Our Privacy Policy already states that we do not support DNT, and Legal has no definite opinion on the matter.

Theoretically, we could allow brackets at the end of the title...

Allowing brackets or parentheses after the number doesn't seem like a bad idea. Since we're already limiting it to numbers with 3 places or less, (most) years won't be a problem.

After consulting with the other Product leaders, we have no objections to moving forward with removing IE8 from basic support (and the related T248062 task).

@Bahnfrend - The change was made by @Urbanecm to fix T250410. Specifically, in titles like "Covid-19 pandemic.jpg", the number was being treated as a sequence indicator rather than an integral part of the title, so you would then get titles like "Covid-20 pandemic.jpg" and "Covid-21 pandemic.jpg". Now only numbers at the end of the file name are treated as sequence indicators. To get the proper sequencing that you want, you can work around the issue by removing the parentheses, e.g. "[subject], [year] 01" rather than "[subject], [year] (01)".

@Cparle - I think it would make sense if the blocklist were on-wiki rather than in a config variable. That would allow the community to maintain it and free y'all from having to worry about it. It should be relatively easy to implement this with the JsonConfig extension (which now has a nice tabular editing interface, BTW).

Here's the script I'm using to update the Africa map: https://github.com/kaldari/covidmaps/tree/master/Africa

@AntiCompositeNumber - You've convinced me.

Therefore, I'd like to ask something. Is it possible to reroute thanks to bot's edits, so that bot owner's account would receive it? Or is it too much to ask?

Currently there is no way to accomplish this since there is no reliable way to associate a bot with an owner. This would be the ideal solution though.

@aborrero - Awesome! I just tested it from Tool Forge and it seems to work:

kaldari@tools-sgebastion-07:~/ocr$ tesseract hindi-test.jpg hindi-test-output-new
Tesseract Open Source OCR Engine v4.1.1 with Leptonica
Warning: Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 280
kaldari@tools-sgebastion-07:~/ocr$

Thanks for your work on this!

I was initially thinking we could just set redirects=resolve in the opensearch API call, but @AlexisJazz's post reminds me that Commons category redirects aren't actually redirects. <Bangs head on wall>

There are currently some internal and external factors that necessitated using this approach first.

@Ramsey-WMF - Anything I can help with? I created an on-wiki configuration system for WikiLove a few years ago. It's pretty easy to implement.

When is it acceptable to load external non-script data (Current de-facto: With user consent, for non-default scripts only)

The "non-default scripts only" part isn't accurate, and even the "with user consent" part is iffy. Almost every wiki has default (or WMF-installed) scripts that load external data:

• The UploadWizard on Commons supports importing images from Flickr via the Flickr API (with a privacy warning to the user).
• Wikisources use the Google Vision API (via a Cloud Services proxy) to do OCR. This is a site script (Common.js) on many of them and a gadget on others.
• Many Wikipedias (including English Wikipedia) still use WikiMiniAtlas (aka GeoHack) which is a site script with no consent/privacy warnings.
• Wikivoyage maps have several features that load content or scripts from external sites (with a privacy warning).

@Nikerabbit - I'm not seeing the "[Report Only] Refused to connect..." warnings when loading suggestions in ContentTranslation. Are you still seeing the warnings? FWIW, I'm not seeing the warnings anywhere anymore. Perhaps someone turned them off.

@Reedy - How close are we to actually enforcing CSP on production wikis? Is there a place we can review all the wmflabs.org endpoints that are still being called from production (maybe even ranked by how frequently they are being called)?

Ah, no, wait, it DOES support DNT. My bad, cause we discussed this and I thought we decided on not including it.

@Nuria - So does that mean that the Analytics team has already decided this question in favor of supporting DNT, and thus we should move forward with adding DNT support on the server-side for parity? If so, I'm OK with that decision (even if I don't like it much personally).

@Effeietsanders - That's awesome. Could you specify which maps exactly you are updating?

My opinion is that EventLogging should not be affected by DNT. Here are my reasons:

• DNT is a failed experiment and has been superseded by ad blockers, browser-based tracking protection, and laws like the GDPR. The W3C's DNT working group was disbanded in January 2019 and most other websites, including Google, don't respect DNT.
• It seems unlikely to me that our EventLogging activity even constitutes "tracking" as intended by the DNT draft documents. The draft documents (which were never finalized) seem to almost exclusively refer to third-party web tracking. The full title of the standard proposal is "Do Not Track: A Universal Third-Party Web Tracking Opt Out". EventLogging is purely internal tracking, not third-party tracking.
• Strict adherence to DNT makes it harder for us to understand how users are using our site. We need comprehensive logging data to make decisions about features and products. Since a lot of Wikipedia's most active editors are also very privacy conscience, we may be skewing our data by ignoring users with DNT, even though its unlikely these users are intending to prevent us from collecting strictly-internal usage data that is not used for targeting or advertising.

@Nuria - Actually, it looks like there's a bigger question to resolve first: T252438 ([Spike] Should EventLogging support DNT?)

@Nuria - Could you take another look at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/EventLogging/+/595005/ ?

Marking this as done since it was just to create a list.

@ppelberg - I have to respectfully disagree with @Whatamidoing-WMF here. Adding an interface for inserting special characters is a large addition to the UI complexity of what is supposed to be a simplified interface. This would have been justified 10 years ago, but OSes and mobile devices have come a long way since then. It is now trivial on most devices to use diacritics (the main use case mentioned in the description) and pretty much all OSes now support easily switching between various international keyboards. This is essentially an OS problem, not an editor problem, and I don't think we should overload the UI with it (speaking as an editor, not an engineering director). If we're going to think about adding peripheral features like this and T249391 (which I'm also skeptical of), we need to look at ALL the features we are lacking compared to the full editor and rank which ones are the most important to carry over, and then choose the top 1 or 2 (which maybe you've already done). If we add every feature that is asked for, the Reply button will quickly turn into the full editor.

@Volker_E - Yes, you're correct that T248061 and T249788 would free us from having to have ANY png fallbacks, but if we can make the site (barely) usable by 0.2% more people just by adding one line of CSS for a single fallback, wouldn't that be worth doing? I'm not saying it should be a requirement, just that it might be worth making a tiny exception for. What's your opinion?

Got it. Thanks for walking me through that. Product has no concerns about discontinuing basic support for Android 2.

Marking Unbreak Now since this is widely affecting actual project content.

I've surveyed a bunch of folks in Product and there are no objections to moving this forward as proposed. Pending an answer to the question above, I'm prepared to sign off on this on behalf of Product.

Thanks for moving this along @marcella, @kaldari and @kostajh. Does the below accurately describe what the experience will be like for contributors once this patch is merged?

@ppelberg - Basically, yes, although whether you initially get the Visual Editor or the Wikitext Editor depends on what Wiki you are on. Regardless, you get conflicting dialog boxes either way and the solution is still the same.

@JTannerWMF - Per @phuedx's comment above, we should move forward on this task.

So if we're not reverting, would anyone object to the idea mentioned in T234450#6114406 (creating a new user right that allows auto-confirmed users to bypass the 500 limit)?

As this seems to be stalled (or at least not making timely progress), we should either revert the "temporary" 500 limit or declare the limit to be permanent. Alternately, could we create a new user right that allows auto-confirmed users to bypass the 500 limit?

Querying Turnilo directly, I see that we got about 36 million requests from Android 2 devices in the last 30 days

@Krinkle - How is 36 million requests per month less than 0.1% of traffic? That seems like it should be about 0.2% of traffic unless my math is wrong.

@nettrom_WMF - Ugg, I imagine that means that everyone with an ad blocker will show up as a no JavaScript editor, thus terribly skewing the results (as there are likely to be far more editors using ad blockers than editors that actually have JS turned off).

@matmarex - Thanks! That fixed it!

This is finished now.

I don't think the close icon needs PNG support. It only shows with JS so the search icon is likely the only icon that would need the PNG.

Thanks for the info! In that case, it sounds like we only need one PNG fallback, so let's just hard-code that one and remove all the rest.

I ran into a data problem updating the Africa map (https://commons.wikimedia.org/wiki/File:COVID-19_Outbreak_Africa_Map.svg): Several of the territories in Africa aren't countries, but are overseas territories of European countries (thanks colonialism!). Reunion and Mayotte are included in the state level data for France, but Madeira, the Canary Islands, and Saint Helena, Ascension and Tristan da Cunha are not included in the data at all and have to be updated by hand :(

@Volker_E - Actually I was proposing that we go ahead and remove .background-image-svg() from mediawiki.mixins.less, and just have 2 hard-coded .background-image-svg() styles for the mobile search icon and mobile close icon. Two lines of CSS shouldn't be much overhead and it leaves the site basically working in Android 2 and IE 8. Wouldn't that be a better solution for everyone?

I agree with @DLynch. Especially when it comes to counting edits, using existing EventLogging data should be more reliable than browser resource requests (so long as we only need sampled percentages and not absolute numbers). It's also not clear to me how resource request data would actually be used for counting edits, as that isn't mentioned in the proof of concept document. I can imagine how it could be used for looking at visits to the editing interface, but not actual edits. For that, I think T240697#6094827 would work better.

Putnik's problem is common, but should be relatively easy to deal with (per Mvolz). Where we really run into problems is with the reverse situation: where Wikidata properties conflate multiple concepts that may be handled distinctly in Wikipedia infobox parameters. Many Wikidata properties are vague or inconsistently used due to Wikidata's fuzzy, must-fit-all-languages ontology.

@AlexisJazz - This has been delayed by a deployment blocker: T251457. Once that bug is fixed and Commons is re-updated to wmf.30, we can reschedule this deployment.

I've scheduled this to be SWAT deployed tomorrow (April 30) at 18:00–19:00 UTC.

Tested on Commons and nothing seems broken...

@Volker_E - If the main goal here is to reduce code overhead and development time, we can probably achieve that without waiting on T248061. As far as I can tell, there are only two cases where PNG fallbacks are needed for insuring Grade C support: The search icon on the mobile site and the close icon on the mobile site (which are needed by IE 8 and Android 2 for using search). You could go ahead and remove the PNG fallbacks for all the other icons in MediaWiki if you want.

@Krinkle - Yes, I was only talking about Android 2 on the mobile site.

After doing a bit more sussing out, I think I've come up with specific steps that could be used to answer each of the 3 questions in the task description:

FYI, if T249945 is completed soon this task may become easier to complete.

@kaldari Are you able to approve this on behalf of Product?

To get back to Krinkle's question, the only features that I'm worried about supporting for Android 2 are reading and searching. The only UI elements that are needed for those are the search button (magnifying glass) and the close button (x). Is it possible for us to retain PNG fallbacks for just those two buttons (which I believe are mediawiki-ui buttons rather than OOUI buttons anyway)?