Multichill's SDC editing with pywikibot code as a reference

• https://github.com/multichill/toollabs/blob/master/bot/commons/depicts_monuments.py

This affects the query service which uses the formatter URL to render the URI.

I think that this will still work as an example for reading CSV/TSV row by row and updating wikidata based on values from the file.

Is it possible to behave / look like normal notifications (ie upper div box in beginning of the page) and then use CSS/Javascript to modify that for getting the low profile functionality for the wikis/user who like to have low profile ui?

Unwanted regression. CSS-classes for the lines in the history/recentchanges etc lists which will tell if the revision is reviewed or not is gone. An example light blue lines in this screenshot for the edits reviewed by Opa.

Given the context above, it may be worth considering whether to focus this change to focus only on newcomers. In this way, the more experienced editors would still get opportunities to contribute in a way that better suits them.

Hmm, If I understand this correctly the "sighted" (stable version) is enough for Google News and it doesn't use quality tier for aggregating news. It woud be nice to confirm somehow.

Another example case from finnish Wikipedia

• https://fi.wikipedia.org/w/index.php?title=John_Jairo_Arias_Tasc%C3%B3n_%27Pinina%27&oldid=19654768

In T277883#6932372, @Ladsgroup wrote:

So another point to clean up is rights, we have these rights:

• "validate",
  • God like, full review right on everything. Can be dropped once we removed tiers and dimensions.

In Finnish Wikipedia, they are used so that there is some set of articles (say featured articles) which edits are checked as normally for vandalism and then there is also the slower round where users are doing time to time more deeply checking what is changed after last quality revision.

I understand. But the choice here is not between "having tiers" and "not having tiers". It's between "not having tiers" and "undeploying flaggedrevs". The code under the hood is a big mess. My suggestion is to remove the tiers (and keep levels for now) and if needed:

• Either implemented later in a better way inside flagged revs
• or have a new small self-contained extension to handle that. I know there was some efforts in WMF to write something to allow users mark a revision/page in a structured way but I think this is out of scope of this extension. the extension job is about "pending changes" and should only do that (and do it well)

Ah, you mean that if the user can still select "well-sourced" when the user is reviewing then it is good enough(?) I try to explain again what I tried to say earlier.

Hmm, it seems that seeing the info requires suitable user group. However here is screenshot

Not sure if I was able to follow you on how you defined "tiers". In fiwiki there is in user interface

• stable = alias for any review
• checked = levels 1, 2
• quality = level 3

Right. You know that least fiwiki is using more than two levels.... I may not even be against axing the levels, but I was thinking that I was in some level to following what is happening with FlaggedRevs and it would be nice to even to hear or participate to the discussion where you are deciding things.

@Jdforrester-WMF if we are keeping levels inside single dimension it would be more useful to keep quality and pristine and link them together in documentation.

"SimpleUI" will currently break the fiwikis page layout as it will collide with some templates. "Non-simple UI" aka basic text box works well when the number of the pages where it is visible is low (like it is in fiwiki) and it will actually notify users that there is new changes to users to check.

I would keep the wording same as in documentation. Ie. "Flagged revisions will no longer have multiple tags like "accuracy", "tone" or "depth" and will only have single tag"....

Bug confirmed with Windows 7 and chrome 89.0.4389.82. It seems that if the link is in the bottom line then it is not activated when mouse cursor is hovered over the link. Link cannot be clicked either.

If somebody is fast enough, then there is still time to drop application to this years software/research project grants. Deadline is today 16.3.2021.

@Ladsgroup just some notes:

This is summary by Kyykaarme of the reasons why the community wants to disable the invitations to translate articles.

@Jdforrester-WMF Why WMF is not able to fund developing FlaggedRevs (or replacement)?

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 configuration values are merged (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.