Hey @Pikne and thanks for the input. We decided now on providing a configurable template that will be automatically appended to the file info of the imported files. The Commons community can then further define how this template should be used to better surface the fact that the file was imported see the ticket and discussion around that here: T256205: Add configurable template to imported file info

I just created the panels on the Grafana board. Data should come in once this is deployed and people start using it.

I just noted that it seems that the broken browser tests are at least partly related to the wdio v6 update. - Other recent patches just worked fine and had no problems getting merged with passing tests.

In T254440#6251000, @gerritbot wrote:

Change 607259 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Add missing margin after message box on "copy" special page

https://gerrit.wikimedia.org/r/607259

In T208318#6248065, @Gopavasanth wrote:

I was searching around and found few insights, One possible way could be adding a class to the rev.getParsedComment() at line 510 and adding CSS properties hypens: auto / break-word: normal to the class should solve this bug I guess.

@WMDE-Fisch what do you think?

Still to demo:

Not quite yet :-)

In T254440#6230683, @Lena_WMDE wrote:

thanks @WMDE-Fisch! Elisha and I thought about this and what we landed on was that it should be the same title as the Edit Conflict you're coming from (which is what we used in screenshot 3 in the ticket) so that you still have the context of what you're looking at/why you're looking at it.

@ecohen @Lena_WMDE One question to the page that shows the text to copy: What should be the heading of that page?

Reviewed at the end of the sprint review meeting. Title is there and deployed on the beta cluster.

Not as a blocker but I just wanted to mention that we currently "use" DNT to avoid that QuickSurveys "mess" with the expected results in our Two-Column-Edit-Conflict-Merge selenium daily browser tests on the beta cluster. I would appreciate e.g a cookie setting to disable QuickSurveys but all that could be discussed in the ticket linked above.

Ah and also I guess that it makes sense to have a different title when one of the select all options is selected. Something along the lines of All of the other's revision's versions are selected?

1. Add browser tooltip to each of the radio buttons under 'Select all.' For the yellow button, "Click to select all of the other version's revisions" For the blue button, "Click to select all of your version's revisions"

Really seems to be no issue anymore. Closing this ticket.

Just for the implementation idea here. I gave it some thought while working on the JS version.

I rechecked after some rebase action and it looks like a CI hick-up. See
https://integration.wikimedia.org/ci/job/wmf-quibble-selenium-php72-docker/41971/console

In T224802#6176402, @thiemowmde wrote:

A note from yesterdays discussion: Bad SVGs (see T216516) and most AbuseFilters (see T223288) are about files that are potentially bad. In contrast, OTRS tickets mark files that are known to be good. Therefore it appears like we can skip this OTRS check, even for the latest file revision.

However: It seems like this check is implemented as an AbuseFilter. We can not just disable all abuse filters for older file revisions, because we would disable all critical filters as well then. It's also not a good idea to somehow hard-code a few filter IDs somewhere, because of the hard to manage Technical-Debt this causes. We currently explore a way to inverse this dependency, see T253876.

The investigation is done I created three follow up tickets for next steps. Probably not all of them will be implemented right away.
T253872: Respect AbuseFilter warnings triggered by imports
T253874: Add tags to the import if triggered by the AbuseFilter
T253876: Offer variables that surface the import steps to the AbuseFilter

In T253727#6172321, @MichaelSchoenitzer_WMDE wrote:

In T253727#6172250, @thiemowmde wrote:

abusefilter_warning_copyv2 […] Makes no sense on older revisions

Oh, take care. A copyright violation in an older revision is still a copyright violation. It's accessible for everybody. Wikimedia hosts it. Wikimedia can be sued. Or worse: The original uploader can be sued.

Normally old versions with copyright violations are suppressed. Then there should be no need to handle them specially/different than other cases of files with suppressed versions.

Detailed look into the AbuseFilter rules.

Overview over all errors we log ( defaults to the last 30days ):

@Meno25 @Helmoony @Jeff_G @Slowking4 it would be really great if we got some feedback on the above questions. We currently try to figure out what additional data would be helpful so that the communities can better deal with situations like this. Thanks! :-)

In T250992#6151005, @Ammarpad wrote:

In T250992#6150940, @JJMC89 wrote:

Those are the templates that get removed on Commons, not the source wiki.

I am sure that's not correct. They're meant to be removed from the source wiki not Commons.

Thanks for the initiative here, but I think just querying for the file name does not fully reflect what the FileImporter does to check for duplicates. See [1] where we check he sha1 hash of the current revision. - If you try to import a file with an existing title, but the sha1 of that file is not found on the target wiki we still allow the import but enforce a title change.

Hello again,
we're currently picking up some of the left overs in the Move-Files-To-Commons realm and came back to this issue and possible options to help. We try to focus on options how to better identify imports from specific wikis so they can be filtered for potential cleanups. We currently have two options for that in mind.

• (1) use the existing comment added to the wikitext and the import log entries
  • there is a comment in the format <!--This file was moved here using FileImporter from //en.wikipedia.org/wiki/[filename]--> added to each import
  • imports show up in the import log with a simmilar message as summary line Imported with FileImporter from //en.wikipedia.org/wiki/[filename]
  • imports are tagged with the fileimporter tag [1]
  • the comment could be used with CirrusSearch with insource: to identify uploaded images from specific projects [2]
  • both could in theory be used to trigger bots that are watching recent changes or uploads
• (2) add a specific category to identify uploads that are done by the FileImporter that communicate the source wiki
  • these could for example say something like Importet from en.wikipedia.org

Just for documentation. We want to avoid using tags because at the moment it seems not clear if they are meant to be used in large scale to support possibly hundreds of combinations in the form of imported from {en|de|ar|..}.wikipedia.org. So the most feasible options remaining are the usage of the search with the insource keyword or adding categories. The latter by probably using the format described.

I still wonder if a solution like using CirrusSearch with insource: is not already sufficient. e.g.