@patilise - Because of the nature of the problem, we unfortunately can't share many details right now. We consider this issue high priority and are actively working to resolve it, but the problem has turned out to be more complicated than initially expected. We are still hoping to be able to re-enable the Score extension in safe mode once a couple more bugs are fixed and we have completed a security audit of Score and Lilypond. Unfortunately, some features will not work under safe mode, so even that will only be a partial solution. (Some of the features that are disabled under safe mode are listed in the description of T174413.)

@MoritzMuehlenhoff - Did you ever receive a response from the Lilypond authors?

@tstarling - Anything left to do here or can this be closed?

If we create them on write (ie. when an actor ID needs to be inserted somewhere), the user will be detached from their contribution if the user agent does not persist the session (e.g. browsing with cookies disabled) without us being able to detect it beforehand and warn them.

I don't imagine that a warning would have much effect anyway. Any user worried about getting detached from their contributions would presumably create an account.

No, there is no production/external API for Tesseract, and we would not want to call Toolforge from production. If Tesseract is needed, we'll need to request that Platform Engineering build a service for that. Since Platform Engineering already has a large backlog, we should make that request as soon as we are sure that Tesseract would be needed in production, as it could take a long time (a year or more) to get such a service up and running in production.

@ifried, @Samwilson, @aezell - I talked with Alexandros Kosiaris about how we could communicate with Google's OCR API from a production extension (similar to what Content Translation is already doing). He informed me that all you have to do is proxy the API requests through the HTTP proxy specified by $wgCopyUploadProxy. Thus it should be relatively easy to move Wikisource OCR into a MediaWiki extension, if we decide we want to do that.

@akosiaris - I updated the documentation at Manual:$wgAllowCopyUploads. Feel free to tweak further.

@Tpt, @Xover - We have upgraded Tesseract on Toolforge to 4.1.1. Can either of you confirm whether this fixed the problem with phetools OCR tool? It should also be noted that the Google OCR gadget has been improved in the past year and may be a viable alternative.

@akosiaris - Thanks for that info! That's super helpful!

The UX still works fine for me, including for audio files. I guess we'll have to agree to disagree.

@akosiaris - Thanks for the reply and clearing up my misunderstandings. We have no need to keep the OCR service on Toolforge and would like to eventually move it into a MediaWiki extension (which would also make it easier for all the Wikisource projects to utilize). But it won't make any sense for us to do that unless there is an API proxy available in production that can communicate with the Google Vision API. What API proxy is cxserver.wikimedia.org utilizing to communicate with Google? Would it be possible for us to use that as well or have a similar proxy set up for this service?

I am not sure that T258622: Poor display of media on Special:NewFiles is personal opinion :)

Regardless of whether its an opinion or not, it's purely a cosmetic issue. I don't think that should block deployment, personally.

This was causing breakage on all the group1 wikis, so Dan rolled back the deployment. I imagine you may need to do a 2-step change to the CSS in order to accommodate server-cached HTML.

See also T265187 (Commons search auto-suggest for "files depicting..." should filter out articles).

@ST47 - Sorry I didn't notice this task until now. I've marked the patch as -2 as we explicitly chose not to use the Unicode confusables list in Equivset for several reasons. Most importantly, confusables.txt and Equivset have different purposes and are not intended to be utilized in the same way. Confusables.txt is intended to be used to see if two strings can be confused with each other, but it isn't intended to be used to create filter strings like we do in AbuseFilter, nor does it handle casefolding as Equivset does. This allows you to filter with a single string like "POOP" instead of "Pp|Oo|Oo|Pp" in AbuseFilter. It also results in significantly different mappings. For example we don't map capital I to lowercase L even though they are confusable. Otherwise you would have to filter out the word "idiot" with "LDLOT" instead of "IDIOT" in AbuseFilter. Secondly, confusables.txt is much bigger than our list with lots of obscure symbols mapping to other obscure symbols which we don't actually care about (for the most part). For AbuseFilter, we have to run every character of every edit through the entire Equivset list, and the longer that list is the more of a performance hit it is on saving an edit.

Since we're moving from OOUI to Vue, it seems likely that OOUI will be deprecated before jQueryUI is. At some point we may want to convert WikiLove to Vue, but converting it to OOUI seems like it would be counter-productive at the moment.

@dmaza - Can you provide a summary of what ended up being deployed with the 1.35.0 release?

@Mvolz - I would be fine with that, but there are a couple caveats:

• The refToolbar code isn't foolproof, and in fact, there is no foolproof way to handle the WorldCat author data since its formatting is just too inconsistent.
• It currently handles "Jr." and "Sr.", but not suffixes or prefixes that may exist in other languages.

If you want to use it, the most recent version of the code is at https://github.com/alexz-enwp/reftoolbar/blob/master/lookup.php#L139.

@daniel - I'm not too worried about restoring the old version unless it will prevent future problems. For example, any idea what would happen currently if I clicked "revert" for the old revision? Otherwise, I'm more concerned about preventing the problem in the future, as sometimes new image versions are vandalism and we actually need to revert to the old versions.

To summarize the outcome of those two tickets:

• T240697: We cannot accurately determine the percentage of edits made without JS due to tracking blockers. T263505 would be the next step forward on this.
• T253033: We did not measure percent of pageviews without JS, but instead used a proxy measurement of percent of pageviews from grade A browsers vs. lower grade browsers:

Hey @MaxSem, nice to see you! Yes, it was in core originally, and there is a bit of a chicken and egg problem, as I mentioned in T100402#6057011. In order to fix T249944, we need to move it back to core though. It would also be useful for other cases (see T100402). What do you think?

@Jdlrobson - This task is about EventLogging via the EditAttemptStep schema, not revision tagging. EditAttemptStep doesn't even have a "platform = mobile" option. Platform can be set to desktop, tablet, phone, or other, and is supposed to indicate the "device through which the user is attempting to edit the page" per https://meta.wikimedia.org/wiki/Schema:EditAttemptStep.

@MMiller_WMF - The audit (T229887) has been abandoned, so please feel free to move ahead accordingly.

Boldly marking as resolved since it seems unlikely we are going to get more information than DLynch's audit above (T229887#5819921), especially since the task has been unassigned for the past 8 months.

@ppelberg - I think the cause of the confusing order (and T189569) is that most of those dialogs are created by the GettingStarted extension, step 6 is created by the Citoid extension, step 7 is created by VisualEditor, and no one ever evaluated the interplay between them all (AFAIK). Since no one is maintaining GettingStarted, I personally favor decomissioning it entirely (T235752).

@phuedx - Since I can't get any traction with the Growth team on this, any chance you'd like to own it?

@Whatamidoing-WMF - It looks like the Library of Congress is using the same "weird" punctuation and capitalization as WorldCat:

@TheDJ @Tgr - It seems that most of the work currently being done in relation to this is at T259617 and associated subtasks. Not sure why those aren't connected here though.

@eranroz - I implemented a work-around for RefToolbar. You can probably use a similar work-around for Checkty: https://en.wikipedia.org/w/index.php?title=MediaWiki%3ARefToolbar.js&type=revision&diff=977779611&oldid=972381502.

Reopening per @eranroz's comment above. I also confirmed that this bug occurs with RefToolbar on English Wikipedia (which also uses Citoid). We should implement a fix within the Citoid service itself, rather than just in VE.

@Esanders - Thanks for the clarification. That is very helpful information.

I'd like to hear more thoughts about https://ko.wikipedia.org/w/index.php?oldid=27478403&diff=prev&diffmode=source and https://en.wikipedia.org/w/index.php?oldid=977124090&diff=prev. For me, the most annoying feature/bug of VE is its tendency to add unexpected <nowiki> tags (although its much better than it used to be). If this problem also occurs with DiscussionTools, I imagine it will affect community buy-in for the feature. Is the addition of <nowiki> tags strictly necessary? When is such addition considered "correct" or "incorrect"? Is it possible to fully eliminate "incorrect" <nowiki> additions or is the problem too complex to decisively resolve? Sorry for my ignorance on this and if it's already been discussed elsewhere.

@eprodromou - Could you elaborate on what this task is about? The description is rather vague.

@Charlotte - I don't see that information reflected in Phabricator. Right now T257944 is the "Feature Requests to Review" column of the Platform Engineering board. That doesn't sound like it's ready to be worked on. But maybe Evan just hasn't moved it to a more appropriate column yet. @eprodromou, can you clarify?

I think the new editing API may take a while to actually materialize (as there are higher priorities for Core Platform at the moment). Would it be possible to just disable description editing on English Wikipedia on Android in the meantime? I imagine it's already confusing to users since about half the English Wikipedia articles are using local descriptions now rather than Wikidata descriptions.

@Dbrant - I'm not sure I understand the connection. Search shouldn't be dependent on editing.

@Dbrant - Any insights into why this is "blocked/waiting"? Anything I can do to help?

@marcella @MMiller_WMF - I really don't want to micro-manage here, but we've been kicking this bug around for 2 and a half years now. Any chance we could slide it in some time soon? It creates a poor experience for every new editor on our projects :(

It looks like this was previously discussed in T252891.

Reopening per T257091

@ssastry - If they're the same thing, definitely feel free to merge.

@ssastry - Would you be so kind as to flesh out this ticket for Platform Engineering? Thanks!

The main issue related to this (T239220) has been resolved. Will reopen if T250084 requires any follow-up from Platform.

If y'all end up needing follow-up support from Analytics or any other teams in the Technology Department, please let me know.