Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14

Permissions archives

This page has archives. Sections older than 10 days may be automatically archived by Lowercase sigmabot III.

I think that it would be natural to log the {{Welcome-arbpia}} under filter No. 602, since it's a sort of a contentious topics notification that makes users aware of the topic area as well as restrictions within it. Currently, someone who checks the filter logs would miss when somebody is assigned the template, which could lead to redundant notifications. If we log this, it would be improved.

(Courtesy ping to ScottishFinnishRadish, who created the template.)

— Red-tailed hawk _(nest) 05:06, 27 December 2024 (UTC)[reply]

I think this would have to go through ArbCom because only {{Contentious topics/alert}} and {{Contentious topics/alert/first}} count as the "official" standardized awareness notices (i.e. simply using the welcome template does not make the user formally "aware") IIRC. C F A 05:28, 27 December 2024 (UTC)[reply]

I had thought that they got rid of the super formal requirements for "awareness" when we moved from DS to CTOP. But looking at the language in CTOP, there is still some strictness for the first CTOP alert. Maybe it's worth a WP:ARCA to see if ArbCom is OK with this sort of thing. — Red-tailed hawk _(nest) 05:57, 27 December 2024 (UTC)[reply]

Probably not a bad idea. C F A 15:01, 27 December 2024 (UTC)[reply]

That's why I normally drop the alert/first along with it, but that does work against the purpose of not BITING and flooding the talk page with a bunch of legalese. ScottishFinnishRadish (talk) 15:03, 27 December 2024 (UTC)[reply]

In my mind, the obvious obstacle to it being considered sufficient for awareness is that it only mentions one of the three restrictions active in the area. —Compassionate727  20:29, 27 December 2024 (UTC)[reply]

That's fair. — Red-tailed hawk _(nest) 19:51, 28 December 2024 (UTC)[reply]

I think we should stick with considering that template an informal introduction. Perhaps /alert/first could be transcluded into the Welcome-arbpia template, so it's presented at the same time, which would allow it to be considered a CTOPS formal alert? That would satisfy the requirement that the specific template be used, and still present a summary picture of CT procedures, rather than legalese alone. EggRoll97 02:39, 28 December 2024 (UTC)[reply]

I think that checkyourfact should be removed from line 3, given that the recent RfC closed with the source being deemed generally reliable (see: WP:CHECKYOURFACT). I would ordinarily do this myself, though I participated in the discussion, so I'm asking someone else to do it. — Red-tailed hawk _(nest) 22:22, 31 December 2024 (UTC)[reply]

Courtesy link: 869. JJP_Master (she/they) 22:40, 31 December 2024 (UTC)[reply]

 Done. -- zzuuzz 23:05, 31 December 2024 (UTC)[reply]

For now, unlike Meta and other projects, there are only the user_groups variable available on enwiki. Because of this, I have listed some various filters that might need a temporary workaround until user_rights can be brought back here:

• 51 (hist · log) and 54 (hist · log) (line 2)
• 102 (hist · log) (line 76)
• 425 (hist · log) (line 3)
• 579 (hist · log) (line 2)
• 887 (hist · log) and 890 (hist · log) (line 2)
• 1156 (hist · log) (line 16)

Any comments, suggestions or thoughts? Thank you. Codename Noreste (talk) 03:12, 1 January 2025 (UTC)[reply]

Anyone know the technical reason that enwiki doesn't have this? Is this something we can change with a #wikimedia-site-config phab ticket? Is there a reason we turned it off? –Novem Linguae (talk) 06:26, 1 January 2025 (UTC)[reply]

user_rights exists if you visit Special:AbuseFilter/examine - at least it does for me and my recent edits. And this example. The filter has always had these weird context-sensitive variables that don't reliably show up in the log details, and I wonder if this is one of those. -- zzuuzz 09:54, 1 January 2025 (UTC)[reply]

We definitely used to have it. I remember seeing it pop up in filter hits before. I wonder if it was disabled as part of IP masking? EggRoll97 22:02, 1 January 2025 (UTC)[reply]

User_rights is a lazy loaded variable, meaning it only loads whenever a filter asks for it. This helps conserve computing resources. XXBlackburnXx (talk) 15:17, 3 January 2025 (UTC)[reply]

Yep, this was caused by these three changes back in August. All those changes are "correct" (see WP:EF/TP#user_rights), but combined they have the side effect of removing user_rights from most hits (though the filters listed above will continue to work fine). If anyone wants it back (for testing purposes), we can create a filter like "user_rights; /* and other variables we want */; false;" to force its generation. Compare filter 1201 (hist · log). Suffusion of Yellow (talk) 19:04, 3 January 2025 (UTC)[reply]

Are you saying that user_rights will show up in the details of every filter log as long as a filter is always checking its value?

It makes sense as an optimization, it's just surprising that it's shown at all in the logs of filters that don't use it (before, after).

Is this only for lazy loaded variables? No risk of a filter checking an IP and causing the variable to be shown in a public log? – 2804:F1...B4:2F7D (::/32) (talk) 00:08, 4 January 2025 (UTC)[reply]

Correct; there's one variable dump shared by the all the log entries from a single action. Non-lazy-loaded variables just appear in every hit. Not sure about IP addresses, but based on a few minutes of checking on testwiki, it looks like user_unnamed_ip is replaced with a placeholder if viewed without the appropriate rights. With the "Enable revealing IP addresses for temporary accounts in AbuseFilter" option unchecked in my preferences, I can still view testwiki:Special:AbuseLog/105182 but user_unnamed_ip is an empty string. With the option checked, the full IP does show even though testwiki:Special:AbuseFilter/94 isn't checking it. Suffusion of Yellow (talk) 01:42, 4 January 2025 (UTC)[reply]

Those articles are about emojis themselves, and preventing people from inserting emojis on articles about emojis limits collaboration and defeats said articles' purpose. Therefore i kindly request that all users should be free to insert emojis on articles that have the word "emoji" or "emojis" in their title, for example Eggplant emoji and Pile of Poo emoji. 67.209.130.188 (talk) 08:14, 9 January 2025 (UTC)[reply]

I think we could just add a line to the code: !(page_title irlike emoji), which should solve the problem. – PharyngealImplosive7 (talk) 18:32, 9 January 2025 (UTC)[reply]

What about changing the last line from:

• !(new_wikitext irlike "\bastro|category:unicode blocks")

to:

• !(new_wikitext irlike "\bastro|category:unicode blocks|category:individual emoji")?

While the IP proposed the creation of an article where the title is emojis, that doesn't seem to be common. – 2804:F1...48:45EA (::/32) (talk) 20:09, 9 January 2025 (UTC)[reply]

Looking at the articles in the category (few that there are) to see how often this is a false positive vs disruptive edits, I only found a single false positive (log) vs a handful of disruptive ones. I mean that's admittedly not a lot of disruption, but it's still some.

Are there more articles about emojis that aren't in the category? – 2804:F1...48:45EA (::/32) (talk) 20:19, 9 January 2025 (UTC)[reply]

Regarding that false positive (as well as the page title exclusion), that's why !(old_wikitext rlike emoji) (instead of removed_lines) should solve that specific problem, if such FPs happen often.

Regarding the articles in the category, what category are you talking about? Codename Noreste (talk) 02:49, 10 January 2025 (UTC)[reply]

The words the category are a link to Category:Individual emoji, that's the category both example pages are part of (and the one my speculative change added).

Like Daniel I also checked the past filter hits, though for the whole category, and only found the one good attempted edit - that's why I was asking if there were more example articles, as if this is it then the filter is way more likely to stop bad edits than not, by not excluding emoji articles. – 2804:F1...BA:8B28 (::/32) (talk) 15:28, 10 January 2025 (UTC)[reply]

But the problem is that emoji is a variable for the emoji regex, and there are only Unicode blocks for emojis. For now, regarding the page title exclusion, I agree with Daniel. Codename Noreste (talk) 02:40, 10 January 2025 (UTC)[reply]

I reviewed the last 4 matches of filter 680 on Eggplant emoji and Pile of Poo emoji and 3 out of 4 are bad edits. I don't think it makes sense to exclude emoji articles from this filter. Daniel Quinlan (talk) 01:54, 10 January 2025 (UTC)[reply]

I echo what Daniel said above. Status quo seems best here. EggRoll97 10:46, 11 January 2025 (UTC)[reply]

Yes, now that I think about it, I agree with the others. Keeping the filter the same seems good here. – PharyngealImplosive7 (talk) 17:17, 11 January 2025 (UTC)[reply]

Could someone add eadaily.com to filter 869, per WP:RSP#EADaily? Thanks. Aaron Liu (talk) 19:40, 12 January 2025 (UTC)[reply]

 Done. –Novem Linguae (talk) 21:36, 12 January 2025 (UTC)[reply]