I copied the acceptance criteria from the older ticket as these are merged. Feel free to edit them, but if you are dropping the "if the local wiki configuration allows to, users can publish translations anonymously" then please give some well-thought rationale for it as it feels like a point where there is a collision between what user communities think and technical design.

Root cause for the problem could be race condition when (Warning this was not never validated)

• https://phabricator.wikimedia.org/T237191#5910406

In T121797#1980980, @Bawolff wrote:

Not sure if we would be able to do that kind of comparison in a SQL query (but the power of SQL keeps surprising me).

I looked into this a little while back. Usually for these types of hashes, you want to find everything within a certain hamming distance of the current hash, which is very difficult to index for in sql.

Very low tech workaround for decreacing the current load could be generating unsanitized id / timestamp pair tables where user could query possible min/max values for the primary ids. This could be even compacted so that it would contain only one pair per day.

Yes, the connection was started after your "Tue, Feb 2, 3:53 PM" comment.

Thanks for fixing. I was able to log in but connection (or timeouts) is still little bit shaky.

Seems to be down

Sure, in July 2019 when i wrote the comments the rev_actor fields werent documented

• https://www.mediawiki.org/w/index.php?title=Manual:Revision_table&oldid=3266294

I just tested Phash (ImageHash.py :s implementation) and for detecting duplicates it would be huge improvement compared to SHA1 even if it would be used for testing the exact matches which would be fast using SQL. There would be false negatives though.

Ok, thanks. By default pythons ImageHash librarys pHash length is 64 bit and even if I change it longer it doesn't generate same hashes. So it is confirmed that its pHash and JImageHash PerceptiveHash doesn't generate same hashes.

Hi, is it possible to get some phash hash values for pictures in Wikimedia Commons? I would like to see if the JImageHash would generate compatible hash values with Pythons Imagehash, but I expect that it doesn't do that.

• https://github.com/JohannesBuchner/imagehash

Use case example

In T215858#6744188, @Jhernandez wrote:

In T215858#6742843, @Zache wrote:

Is it possible to get information how big the commons/wikidata tables are on the disk? (ie. which are the problematic tables in the replication point of view)

The tables individually I'm not sure. The databases for sure. What would that info help with?

Is it possible to get information how big the commons/wikidata tables are on the disk? (ie. which are the problematic tables in the replication point of view)

Some generic examples how I am using cross-database joins. Problem is not really if I know how to recreate those using code, but if the cross-database joins are going away they are a lot more complex to implement (=more work to do write the code). They are also a lot slower to run if I need to first fetch all the data locally to do manually the matching as now the work is done transparently by the SQL server.

In T262196#6727759, @Ammarpad wrote:

In T262196#6727539, @Osnard wrote:

Why has the patchset been abandoned?

There are no reviewers

If this is still true:

Just FYI, there is a discussion in commons about this tool .

• https://commons.wikimedia.org/wiki/Commons:Village_pump#Very_large_number_of_troubling_edits_with_SuggestedEdits

More specifically I am interested on largest editor communities not readership as the readrship is rather skewed when comparing wikidata/wikipedia/commons. I tried to analyze this by myself by using how many wikidata editors from last 30 days have ever edited finnish Wikipedia in any significant amounts and same for Commons. However, this ignores all of those who dont edit fiwiki and includes users whose contributions are historical langlink edits and global vandal fighting.

Ok, thanks for the info. Also, if you catched the general idea of the information what i am trying to get then feel free to refine the question more easily resolvable if needed.

@Aklapper I didn't say that you would have bunch of unused developers. I wrote that priotizing this as low priority and postponing this to some unknown future is an error.

@MarkTraceur. I would like to question your triage to low priority I demonstrated on the ticket that responsiveness could be mostly fixed just by CSS which is trivial and by focusing on creating a new upload tool the problem will be still there on 2025. Also uploading files to Commons are the most basic features of the site. It is a more elemental feature for the usage of the site than for example the structured data.

One use case for the historical data.

• https://meta.wikimedia.org/wiki/Requests_for_comment/Flagged_revisions_should_display_latest_versions

And for current uses, least I am using them for the graphs. Though, this is not realtime as it used to aggregate data from other tables too than flaggedrevs_statistics so i have updated the stats when I have needed them.

• https://fiwiki-tools.toolforge.org/fr_stats_example.html?db=fiwiki_p,huwiki_p,dewiki_p,plwiki_p&frs_key=pendingLag-average

I think the most important use case is statistics analysis. Also afaik i think it is needed also WMF/Community figures out what to do with the FlaggedRevs as we don't really have much a data how the the FlaggedRevs is used.

Please don't purge them. If one wants to do timelines or graphs (Like i do) of how the revieweing have been developed or wants to compare different language versions he or she needs historical data.

Actually not least by T237191 as Tgr noted in second ticket.

Does this still exist or was this solved too when [[phab:T237191]] was fixed? (by https://gerrit.wikimedia.org/r/627332)

Does this still exist or was this solved too when [[phab:T237191]] was fixed? (by https://gerrit.wikimedia.org/r/627332)

Backlink to the Community Wishlist Survey 2021 proposal
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Multimedia_and_Commons/Add_Structured_data_during_file_upload_with_Upload_Wizard

This seems to be same as T246746

Another idea. Currently the recentchanges rc_params contains this information for remote edits and it is already used for generating backlinks to wikidata. This could also contain the rc_patrolled value from Wikidata which could be used for filtering.

One solution could be to hide all the edits which are autopatrolled in Wikidata. However, currently all wikidata edits are propagated to client wikis (what is correct term for this?) with value rc_patrolled=2 so there should be either correct value for autopatrol status OR more possible values for separating local autopatrolled edits and remote autopatrolled edits.

Yes, it sounds agreeable to me.

In finnish wikipedia there is two use cases for disabling the links because the page is archived or project page. Currently there is no known problems with this except that the css is custom local change.

In T265291#6619631, @Esanders wrote:

This still won't catch top level comments that end with a signed list item.

First, thank you for fixing this. Do you have any best/worst guess when the tooldb is up again? There's WLM jurying going using http://montage.toolforge.org which is down and we need to inform the jurors of when the reviewing the photos is expected to continue.

In T265291#6617114, @matmarex wrote:

Thanks for letting us know. I have to say that we can't promise that reply links will always be compatible with that CSS, and it makes it harder for us to debug any issues that occur on Finnish Wikipedia. Also, that CSS is loaded for everyone, and not only users who enabled the beta feature. But we can't stop you… :)

@Vis_M in which wiki you were planning to use it?

@ppelberg just FYI that I added some quick CSS workarounds for problems mentioned earlier in this page.

In T265446#6586018, @matmarex wrote:

There was also comment [1] that Reply-tool currently adds [ reply ] to archived parts of the discussion which should not be changed. These links can be hided even by local CSS so it is not blocker but just FYI that it is something which needs to be solved somehow.

In T265446#6583562, @ppelberg wrote:

Oh interesting, @Zache – does this Wikipedia:Poistoäänestykset/Katariina Räikkönen discussion [i] show what you are describing above?

Is it possible to configure reply tools so that it would add [ reply ] link only when line starts with :? I think that there is newer such a case in Finnish Wikipedia when line starts with # or * when user should reply. All of those are either votes OR participants lists and actual discussion is in separated section.

Article previews doesn't work because RESTBase config is broken? This is a visible problem because the article preview is toggled on by default in the settings.

I created a discussion on the wikidata project chat for defining the community side of the process.

• https://www.wikidata.org/wiki/Wikidata:Project_chat#Updating_SPARQL_federation_input_review_process

In T265446#6566619, @ppelberg wrote:

Deployment timing
Note, the Reply Tool was not made available as a Beta Feature at fi.wiki today, 20-October, as previously planned.

This happening is blocked on us, the Editing Team and volunteers at fi.wiki, coming up with a way resolution to T265291.

In T265291#6563170, @Esanders wrote:

Also the proportion of users using 2017WTE+Syntax highlighting is probably relatively low, so this would only work for a minority of users.

@Zache are you able to describe what you are referring to above in a bit more detail? I want to make sure I'm understanding what you are saying before responding.

In T265896#6560903, @Lucas_Werkmeister_WMDE wrote:

I don’t understand what this task is asking for. The proper way to access the Commons query service from the Wikidata query service would be through SPARQL federation, not MWAPI – as you certainly know, since you created T265891: Add Wikimedia Commons Query Service endpoint in the WDQS federation whitelist just before this task. The only reason I can think of to use MWAPI is because commons.wikimedia.org is already on the WDQS MWAPI allowlist…

! In T265291#6557038, @ppelberg wrote:
With the above said, we'd like to experiment with the Reply Tool not outputting any content/syntax that people did not explicitly type themselves to start.

It seems that we could do spacing with nowiki also instead of html-comments. With nowiki broken comments would not fail silently.

In the enwiki's help page, the spacing between items should be done using comments. Like this in wikicode.

@ppelberg It was to make editing the wikicode easier. The original proposal was in the village pump discussion "Selkeyttävä ehdotus in 2005. It was low volume and contained only three comments. The next village pump discussion which referred to empty lines in discussions was in 2015 (Muistutus_keskustelusivukäytännöstä) when Otrfan notified that writers should follow the new line guideline to make commenting more easier.

Thanks. It however should be able to handle cases like this too (in wikicode) where comment is splitted to multiple dd:s.

At HTML-level it looks like this. So, with newlines, the extra margin between rendered comments comes from the margin between separate lists. However, as Whatamidoing (WMF) noted in village pump the separated lists are an accessibility problem for screenreaders etc.

Hmm, it seems to be working now though I tested the url before I submitted the bug report. If it stays up then this can ticket can be closed.

In Wikimedia Commons is language selector of old wgExtraLanguageNames languages is now broken. Those languages cant be selected from the user interface. If I understand code correctly currently those languages are defined in wbTermsLanguages.json for CaptionsPanel.js.

@Marostegui can you check if problem exists in the production db too or just that we cant see those users in labs database because of sanitization?

Investigated little bit. I suspect that there has not been any edits for those users, but i cant confirm this edits could be deleted with oversight too. However, user_id 310454 was referenced from abuser_filter_log table and second user_id 318872 from logging table.

T262196 seems to be related to same root cause too.

Thank you!

Confirming, the map seems to work, thank you for everybody involved!

So it would be just to add wikilovesmonuments.org to config files regexp?

Thanks, here is some screenshots from my computer.

@AntiCompositeNumber @Aklapper This seems to trivial to fix as it is just configuration change in maps.wikimedia.org, however I don't know who to ask. Do you have any ideas who to ping?

hmm, oauth works for with maps.wikilovesmonuments.org but not in monumental.toolforge.org

I think that the reason is that there is still old callback url, but site itself is moved to monumental.toolforge.org and login security doesn't survive from redirection.

I can confirm the error

Quickfix could be to use https://monumental.toolforge.org which seems to be whitelisted. This doesn't work for all of the use cases (ie. main site is still broken)

fixed by Para. Thank you.

If communities want to continue to use where they should contact to get some of the teams to be responsible? (afaik this is the current situation as there is no replacement and the communities like it as a tool)

So,. if I understand correctly the problem is that the views used currently in the tool labs are fucked by design and because that everything is unusable slow?

pushing this little bit up. It would be nice to get goodfaith working.

In T246720#5938796, @Wickie37 wrote:

Looks like I was right with the faulty 'fp_stable' in the 'flaggedpages' db table: