@TJones one more question regarding this change: will it affect the results on Romanian wikis? I know the search is diacritics-insesitive, but I wonder if cedilla redirects will be favored in relation to the redirect targets, which are using comma diacritics.

@TJones is there something the Romanian community can help with? What would it take to accelerate the changes upstream?

This is a site request that cannot be approved without clear consensus obtained on the Romanian wikis first, and not on meta or here. I suggest you open a discussion on the Romanian Wikipedia and invite participation from the rest of the projects if you are really serious about pushing this.

@John_Smith_Ri I still do not see any consensus or discussion on this in the Romanian projects. Please provide a link to the discussion before reopening.

In T326864#8522515, @TayfunEt wrote:

Hello,
I don't know, they use the Ǧ ǧ and Ș ș letters as Ğ ğ and Ş ş often, it can be that you are right. The alphabet is actually shown in the book named "Alfabe" from UDTTMR. When you like, you can try to contact with UDTTMR, to ask which Orthography is official.

Here is the alphabet shown: https://www.facebook.com/photo/?fbid=1795600770673670&set=ma-_-_-me-_-_-%C5%9Fa-_-_-ta-_-_-qirimtatartiliuyrenemiztatarlar-tatars-%D1%82%D0%B0%D1%82%D0%B0%D1%80%D0%BB%D0%B0%D1%80-tata

Sometimes they use the Ǧ ǧ and Ș ș letters as Ğ ğ and Ş ş.

Let's clarify the terminology and separate the concerns here:

• I suggested that, based on the usecase, pageview data might be better retrieved from the Wikimedia.org REST API ( https://wikimedia.org/api/rest_v1/#/ ) which is different from the REST API on the other sites (see here). As usual, extensions can add their own endpoints (see for instance /pages/talk at https://en.wikipedia.org/api/rest_v1/ which is missing from MediaWiki Confusing, I know.
• Pageviews are only part of the Wikimedia API, so it is not exposed through the PageViewInfo extension. From a design point of view, they're totally separated and could potentially return different data at least occasionally (although I suppose they share a common data source)

@Edtadros both tests seem to have been made in landscape mode. Would you mind confirming that the fix also works in portrait mode? I know that since there is a fixed viewport it is very likely to work, but I think it makes sense to check before deploying. Thank you.

In T322984#8392072, @matmarex wrote:

An API request to https://ro.wikipedia.org/api/rest_v1/data/citation/mediawiki/https%3A%2F%2Fbiblioteca-digitala.ro%2F%3Farticol%3D107019-gradina-botanica-din-bucuresti-un-vast-muzeu-al-lumii-plantelor--revista-muzeelor--4-1994 gives the following JSON (note the correct URL):

I get the following response with an incorrect URL:
Notably, mine has source: Zotero, while your has source: Citoid.

I'm not so sure that would help in my case. The screen resolution is (2340 ×1080 pixels), but experimenting with the basic code from Mozilla seems to indicate the limit is ~200px in portrait mode and ~750px in landscape. Do you have any idea why I would see these results?

Hi folks, is this task being actively worked on or planned for the near future? If not, maybe we should remove links to https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide/Citations-Full until it can be translated? We're sending people from wikis to these help pages (e.g. https://m.mediawiki.org/wiki/Help:VisualEditor/User_guide/ro ) and we would much rather have them localized.

Confirmed working, thanks @matmarex

Probably not the same as T303109, that one is FF+SwiftKey. You can try reproducing this one with SwiftKey to confirm.

@Yupik could you explain what smn and sms are in this context?

I think it can be closed, I haven't seen a 504 in a long time.

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?