Folks, I can't figure it out from the discussion, but does this solution consider:

• users without CX enabled
• the difference between items without wikidata items and with wikidata, but no IW?

Yes, I believe that table is correct.

@Stang you seem to have removed the Romanian versions (see the API call in the bug description) and now Proiect:Cod Wikipedia redirects to WikiProject:Cod Wikipedia and Cod:SIRUTA:10 sends to Code:SIRUTA:10. Could you please make sure the Romanian versions are the defaults and the English only alternatives? Thank you.

I added them above.

102 WikiProject
103 WikiProject talk
108 Code
109 Code talk

Confirmed working for rowiki, but I do suggest leaving the bug open until it's properly fixed.

Do we have any workaround until the code is fixed? On the other bug it fixed itself, but rowiki has almost 100 filters.

Checked, it works, thanks @Majavah

It used to call the parser function. Apparently I broke that a while ago, while moving to maplink, likely because my unserstanding was that maplinks also add the coordinates to the database - something i can't find any docs about today.

Note that the on-wiki proposal has been about a permanent ban on IP editing.

In T301908#7734951, @Xqt wrote:

In T301908#7734698, @Strainu wrote:

I continue to believe we need to support a version at least a year after Cloud Services have moved away from it, as described in https://lists.wikimedia.org/hyperkitty/list/pywikibot@lists.wikimedia.org/message/BSTDB6JYJ74DE3BTNWND4BAROLIXJTW5/

That would mean mid-2023 if I understood correctly the latest news about the Debian upgrades.

If I follow this your proposal:

1. two years after official support has ended (e.g. 7 years after launch) AND
2. one year after Toolforge moved to a newer Python version. AND
3. the percentage of users of a version goes under 5%

1. The official support has ended Sept. 2020; two additional years will be Sept 2022. Dropping Python 3.5 is not planed for an earlier date.
2. Toolforge migration has already started.
3. The percentage of users is already below 0,3 % except for Toolforge but this will decrease rapidly if the Python base is changed.

I don't want to fight for a few weeks or months. Release Pywikibot 7 was also postponed for few months. But I want to promote a change as early as even possible but this is also a long term process so that it can be planned.

I continue to believe we need to support a version at least a year after Cloud Services have moved away from it, as described in https://lists.wikimedia.org/hyperkitty/list/pywikibot@lists.wikimedia.org/message/BSTDB6JYJ74DE3BTNWND4BAROLIXJTW5/

Is this a duplicate of T123178 ?

You must create another edit in the top section of the page, save it (or preview it) and check if the text "top" is still in the edit description. It might either link to the article or appear as /* top */, depending on the context.

To generalize yes, but the issues I mentioned in T299380 all have a giveaway: quotes. Maybe you can work with short (3-5 words) quotes as one entity?

It's not immediately obvious to me why 1 is a problem if 2 isn't - they seem linked. What does "enough phrases" mean exactly? Intuitively, I would say that 2 or 3 links per article should be enough for the user to practice. You could then potentially reuse the same article such as this one for other users.

As a mentor, I would recommend that you first try 3, as the number of links added per article seems a bit high at the moment, so removing some of them wouldn't be damaging. The patch should be applied as the second option, but only together with a documentation update to make the issues crystal clear. For now, we're far from that.

@Jdlrobson I was able to reproduce in Chrome 96 on windows, signed out for en.wp. It seems that this codes's way of building the close window HTML is different from other such examples in the code, such as the VE (add citation popup) and ULS settings. You can open any of those, replicate the classes you use and you'll still see the problem.

@FonAfon, have you checked the translations? It looks like an ALT text of the closing icon. It can happen to show up if the text is too long - I've seen it on the mobile site a while back and it was solved by shortening the ALT text.

In T295696#7569794, @Johan wrote:

@Strainu I don't think this is the Android app – this is what MediaWiki does when you click the "edit section" link on the topmost, heading-less section (above the table of content). Here's a diff from when I've edited on desktop, for example:
https://sv.wikipedia.org/w/index.php?title=Mittitjärn&diff=prev&oldid=49299561

@Urbanecm I have the same complaint: since you implemented this without any advance notice (shame on you for that) we expect you to fix all the red links you created. Thank you.

Indeed, removing config.step from user-config.py solved the problem. I don't remember why I added that, maybe it's an inheritance from old versions (I have that config file all the way back from compat branch :D )

In T294463#7482170, @ppelberg wrote:

@matmarex identified that there might be two issues at play here:

1. The warnings that people see when attempting to leave a page without saving the changes they've made are inconsistent (this is the issue this ticket was created for)
2. VE is showing exit warnings regardless of the state of the Warn me when I leave an edit page with unsaved changes setting within Special:Preferences.

Thank you for your suggestions @Xqt and @matej_suchanek . Unfortunately I am still reproducing the issue after deleting all __pycache__ and apicache-py3 folders, using the simplified example (see below) and commits 28e31f98dcc2b152fde16385172a49f721394ed3 and 758de7a513c061c1741d77b8a684d24bba2c5fd0 .

OK, so I digged a bit, it seems when leaving the article (options 2,4,5 in the description) there is an option controlling the warning which in my case was not global. When exiting to the article itself, the VE warning is shown regardless of that setting. I believe the correct behavior is to always display the same confirmation window, which should be controlled by the user option. I updated the description accordingly.

On en.wp I also see the confirmation as in your screenshot, but I find it strange that you have the VE confirmation when exiting to the article (just like on ro.wp) and what looks like a browser confirmation for the rest - it still looks like these are separate code paths and it's unclear to me why.

Yep, also reproducible on ro.wp in safe mode (signed-in) and on Microsoft Edge (while signed-out).

Can also be reproduced on FF for Windows.

Pretty much any page, I've encountered it several times. Just checked for [[ro:Cod:SIRUTA:136]], it reproduces

I agree, it would have been preferable if the change in semantics came through a rename of parameters instead.

In T294456#7470724, @Urbanecm_WMF wrote:

Can you confirm it's still happening, please?

If this was fixed on 2021-10-12, why hasn't it reached the wikis yet? Do you have a slower deployment pace than the rest of the code?

I'll go even further than @Kudpung : most (8 out of 10) of these solutions are patches to the existing system, which the other side considers broken. What these people want is not to get and/or do work more effectively, by being able to patrol on mobile or receive echo notifications, but for the bad edits to *dissappear* from their watchlist so they have less patrolling work and implicitly more time for other activities on-wiki. Here is one of the feedbacks from pt.wp which resonates particularly well with what I am told when I try to calm down overzealous patrollers on ro.wp:

@Ladsgroup @Urbanecm @Nemo_bis I'm tagging you as the participants to this discussion who most vocally rejected the change, but this message is aimed at all members of the technical community who support anonymous editing. I am on the same page as you on this, *strongly*, but...

Since this is a visual issue it makes sense not to be a blocker, but a tech notice message would have been appreciated.

Has this been discussed on wiki? Last I remember,tthere was *some* community around that project.

Hey folks, the leftovers from this bug just hit some wikis really hard (see T288846 and duplicates). Would it be possible to get it some love, at least to the point where no math tags are inserted?

Short debugging seems to suggest the presence of empty math tags (<math />) is the cause. I remember seeing some tech notice about this a while back, can't remember the details.

@Reedy will you do the changes or do you need us to clean up? If the latter, can you provide instructions?

Unfortunately, adding the HD logos does not guarantee the blurriness will go away, see T274778

I double checked all monuments not in Sibiu and this issue seems to have been resolved (at least the correct P131). There is a mess for that property, but this will be solved on-wiki.

Can you add a link to Add a link (haha) so external watchers can get the context?

@TheDJ , thanks for the debugging. I think that if nobody will take on this bug in the near future, it should be mentioned in the documentation at least, to make sure others don't debug as much.

Mine is https://maps.wikimedia.org/img/osm-intl,16,44.47106,26.07805,500x500.png?lang=ro&domain=ro.wikipedia.org&title=Lista+exponatelor+din+Muzeul+Na%C8%9Bional+al+Satului+%E2%80%9EDimitrie+Gusti%E2%80%9D&groups=_6da8c72afb8620eeaee413dc72a574aefdccd3d8

In T240889#6973641, @Etonkovidova wrote:

The issue reported here is a bigger issue - how to provide better notification to anon users and, specifically, to the anon users on mobile?

I second the community members who asked for the increase of priority. Mobile edits are on the rise and this bug blocks the normal workflow the communities use to communicate with anonymous users without providing a replacement. Since this seems to be in the Growth team, I'd like to see what @MMiller_WMF thinks. What's the grand plan for edits on mobile?

I did not find anything relevant in the wikitech-l archives. What other options do we have here to "unblurry" the logos?

I think it would be good to revisit this a bit, maybe see if things have changed in the last 9 years.

Correct, that's the step. I'm no UX specialist, but I believe that having an inner scrollbar AND a lot of wasted space below (the user still needs to scroll to read the right column) is not a good experience.

The translations are good, but now I'm a bit confused at what we're trying to achieve. Looking at the diff vs the current output (see screenshot), it looks to me that the old version is closer to what we want. I believed that the sections are fixed, but if they're fully customizable, I would suggest that knowing how to edit and how to work with images is far more important than uploading an image (especially the cross-wiki uploader that is offered by the visual editor). I propose the json below. @FonAfon do you have an opinion on that?

Yep, sounds good.

@Trizek-WMF Does it need to be a local page? We haven't figured out the help pages completely, but VE has pretty good help pages on mw.org and I preferred to translate those rather than creating new pages.

In T274778#6831759, @Aklapper wrote:

The logos I get are https://ro.wikipedia.org/static/images/project-logos/rowiki.png and https://en.wikipedia.org/static/images/project-logos/enwiki.png .
Screen resolution on this one 1960x1080, scaling is 100%.