In T364245#11302139, @STran wrote:

T407651: IPs can't be revealed for some temporary accounts on itwiki may be another report? However the revision also isn't available to cu_changes which is a larger scope than this ticket mentions.

In T407651#11302136, @STran wrote:

no information about this revision would be available to CU either

I can confirm that while performing a CU on that temporary account does reveal the IP (account creation's IP, I suppose), no edits are reported from that IP.

In T340995#9199254, @kostajh wrote:

@Dreamy_Jazz and I reviewed existing usage; it's low enough that we are going to keep this in someday/maybe column for a future iteration of work.

In T397221#11240375, @Dreamy_Jazz wrote:

In T397221#11239713, @Titore wrote:

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

As I understand it, logs should only be generated when an entry has not null protected variables. I thought IPReputation variables such as ip_reputation_ipoid_known were only available for logged out users or during account creation.

Is this the intended behavior, or should I file a new bug report? You can see what I mean by inspecting the log on itwiki.

When was this log created? We have made other changes to the logging code, so it's possible that this has already been fixed.

Additionally, it would be useful to link the specific log and log entry created when viewing it.

I was initially confused and thought of a bug when I noticed that according to the logs I had viewed protected variables of experienced users, bots, or even sysops that never even triggered an abusefilter, or did it years ago. Eventually, I was able to reproduce it by using Special:AbuseFilter/test to test filter 785 against recent changes.

In T405522#11211981, @Dreamy_Jazz wrote:

It seems that on itwiki only admins and arbcom members have the rights to do this (based on Special:UserGroupRights).

Done, manually imported the new ones and I'm going to delete the backported ones. Thanks everyone!

If you can backport, it would be better. We're trying to import some of the messages, but that's only a small part of them.

As reported on itwiki, I can switch from 2010 editor to VE if I start editing with the former, but there is still some issues switching between the two. To reproduce it:

• Open https://it.wikipedia.org/wiki/Test
• Click on "Modifica"
• Click on "Modifica wikitesto"

In T390949#10712341, @ArthurTaylor wrote:

The fix for this has been rolled out to production - please retest and let us know if the issue is resolved for you. We have filed a follow-up ticket T391089 to add automated tests of the functionality to avoid similar regressions in the future.

In T390949#10707543, @Mbch331 wrote:

I tested this and when I click on add interlanguage links I get redirected to the corresponding Wikidata item. (I tested it on https://en.wiktionary.org/wiki/Template:uk-1928_superseded_spelling_of ) and both logged in and not logged in. So doesn't sounds like a software issue.

I can confirm I was able to see the first link while being logged out. At first I thought it was a cache issue, but the issue persisted for a while even after appending &action=purge.

Since T377765, the checkbox is only shown when saving a filter with protected variables.

In T379640#10343930, @kostajh wrote:

@Titore thanks for filing this. Could you please provide links to some filters that are using this type of functionality (page_recent_contributors rlike '\n127.\0')?

In T386804#10564350, @XXBlackburnXx wrote:

So apparently, the mobile app sets user_mobile==false but user_app==true, which is why it didn't match the filter. You'll probably need to account for this discrepancy in the filter.

https://test.wikipedia.org/wiki/Special:AbuseLog/105529

Upon closer inspection I noticed said edit has the "App section source" tag. Not long ago these edits were actually reported in edit summaries as hashtags (T360164). If so this is unrelated to temporary accounts (sorry about that) and could be because the hashtags are converted to actual tags after saving. It's just a guess, but that would explain why /test looks fine. Still, this is unexpected and may mess with filters checking for summary.

In T377967#10254694, @elukey wrote:

@Titore do you feel that the above Wikitech change is enough? The link is visible on the MOTD, so it should be easy for a user to get the privacy info. Lemme know :)

In T376814#10239083, @Ebrahim wrote:

I can't see the issue locally so guess I need help for reproducing this

While this looks fixed for the most part, it's still broken for watched categories.

Looks like it's back up and running.

In T363826#9770644, @Melos wrote:

Analizzando i tool già presenti abbiamo Xtools che permette di estrarre una determinata categoria di edit automatici:

Ah, ma quel tool è la svolta!
Non so se avrà seguito, ma intanto ho richiesto che vengano aggiunti i collegamenti suggeriti delle attività per nuovi utenti.

Fixed in T346686: https://gerrit.wikimedia.org/r/973229.
Thank you!

I resorted to just use nowikis, but I would call both ways workarounds. While it has been kind of known that collapsed sections are still sections (they do end up in TOCs, after all), I think users do not expect something they put inside a collapsed template to affect the subscribe link visibility.

@Jdlrobson Yes, thank you!

Users are reporting similar issues on itwiki and enwiki.

In T357202#9531349, @Nardog wrote:

In T357202#9531155, @Titore wrote:

Other buttons are not showing up either, i.e. "Mark as patrolled" (for users with the "patrol" user right in wikis with $wgUseRCPatrol set to true).

"Mark as patrolled" doesn't appear when viewing a diff on desktop either so I doubt it should on mobile. What are the "other buttons" you allude to?

Other buttons are not showing up either, i.e. "Mark as patrolled" (for users with the "patrol" user right in wikis with $wgUseRCPatrol set to true).

The IP from itwiki just confirmed that it used to clear after clicking to "new messages", which is just a link to your own talk page, by the way. I just tested it on MediaWiki 1.39 (not Wikimedia though) and I can confirm it too.

@vadim-kovalenko Since https://gerrit.wikimedia.org/r/769692 some previews stopped working on itwiki. You can check it by hovering
Siniša Mihajlović or Héctor Puricelli on https://it.wikipedia.org/wiki/Wikipedia:Officina#Anteprima_a_volte_non_disponibile (and many others on Serie A 2021-2022). Reproduced it with a local copy of mediawiki-services-mobileapps.
It looks like your latest patch (https://gerrit.wikimedia.org/r/774436) fixed it, though.

Yes, the __DISAMBIG__ magic word is provided via the Template:Disambigua, used in both pages.
Could it be related to this? It looks like if the extract is empty (i.e., no lead section) it always returns TYPE_GENERIC.

It isn't, just a "note" for the reproduction steps.

Note: it only happens with the old mobile frontend, doesn't occur using the advanced mode.

Hey, I'm the one who reported this in meta. Looks like the issue is solved now, thanks to whoever took care of this. This also happened last year, might be related to the new year start, because it also stopped populating the feed after December.

Looks great, overall. I can still reproduce step 3 from T234142 with the following error:

Seems related to T233994.

In T233994#5531651, @SUM1 wrote:

Should also mention that this totally breaks the editor, at least it did for me.

Tried to cut a paragraph containing citations, and it failed to cut most of it, and some buttons and functions would not work after this (such as Publish changes or Undo). This was the same behaviour as the vanishing reference, which also vanished when cut (not just "dragged" as the original post suggests). I could no longer Undo or click Publish changes. I'd say this is a very urgent issue to fix.

It's happening again to me today, even in safe mode. Sometimes it looks like the entry finally gets unbold, only for it to become bold again after some time.

Since at least February 12 I cannot reproduce the Error, edit not saved. that I reported. My steps were simply typing "Test https://www.google.com" while logged-out, and now the captcha is indeed shown with no error. Not sure if you're testing some more use cases though.

I would expect it to be consistent with what's shown without any parameters, and it used to work this way when action=raw was paired with usemsgcache=true. The MediaWiki NS currently shows the localized message from the i18n cache if the custom one is deleted. I.e., https://it.wikipedia.org/wiki/MediaWiki:Nextdiff shows "Differenza successiva →".