Another potential use case is admins who are blocked with bot option can unblock self, which will solves T232908: Admins blocked by User:Abuse filter cannot unblockself.

Note since the Kazakh government introduced a new Latin script (latest revised in 2021), there are now multiple Latin orthographies for Kazakh.

In T249989#9329582, @Lydia_Pintscher wrote:

OpenSearch support was intentionally added in the past based on user requests to allow people to add for example search keywords in Firefox. So I do not want to remove that again. However as the ticket description says we will look at the suggestion issue as part of T190454.

Note It is proposed to change (most of) current proxy blocks to this kind of setting, which needs a global RFC in Meta; though no RFC is needed to make this feature available.

In T323948#9324590, @Xaosflux wrote:

Meta NOOP is really about "global bocks", this task isn't even tagged for global blocks, is that the intent here? This seems to be about local blocks right now, and each project would be able to determine when this "lesser" type of IP block would be appropriate for them.

This can be turned back as an extension if needed by third party users.

In T350684#9314569, @gerritbot wrote:

Change 972472 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] Drop language coverter for Kazakh

https://gerrit.wikimedia.org/r/972472

Those are stable concepts in the platform

Once IP Masking is enabled any anonymous users will become registered on their first edit. only "named" user is a stable concept.

Per T139246: Migrate local group names to WikimediaMessages and T230103: Systematize wgRestrictionLevels it is not recommended to invent a new protection level not used in other wiki. The protection level and user group should be named extendedconfirmed.

Note once IP Masking is deployed there will be three classes of users to differ: named users, temporary users and anonymous users that yet to have edits on the project.

First we need to have this feature, then we discuss how this can be used.

Wouldn't that mean that the large numbers of users (not logged-in, or not confirmed) receive a block message when they try to edit? To me this would count as collateral effect.

Currently checkusers may issue hard range blocks which block everyone without IPBE. If only non-confirmed accounts are blocked, the impact is reduced. In my previous comment, I also propose that most open proxies, which are currently hard blocked, may be changed to this kind of block; this require an amendment of Meta NOP policy and thus a global RFC.

See T117845: Rename the language codes sr-ec and sr-el to the BCP 47 conform codes sr-Cyrl and sr-Latn

In T344609#9257699, @Michael wrote:

Yesterday, 2023-10-16, the proposed ADR was rejected by an executive decision of @karapayneWMDE, the line manager of the engineers proposing it. For the rationale of the rejection, see the Gerrit comment from today (2023-10-17): https://gerrit.wikimirror.net/r/c/mediawiki/extensions/EntitySchema/+/951482/24#message-09debd89349f9930fd236a543ef3463c1c3b8126

See: https://meta.wikimedia.org/wiki/Talk:Title_blacklist/Archives/2021#U+3164_(Hangul_Filler)

If you copy a cURL commend from browser console it will include all cookies for the request.

Note Windows and Linux wraps parameter in different ways and thus browser usually provides two options for these two formats.

What's the use case? Currently Translate extension stores different translation pages in different page language (page language is a core feature), and is it enough to get the language there?

What I proposed in T54971#3569663 takes another approach:

• Add column ips_virtual_site to wb_items_per_site, and then drop ips_site_id
• Create table wb_virtual_site, with columns:

Currently Wikibase suppose an injective relationship between item and local page, and there are mechanism and usecase for conversion in both directions. Once we can have multiple sitelinks to same site

• The page -> item is still a single map, though we need some code change to ensure this once we allow one item to be connected to multiple pages of the same site.
• But item -> page will not. In this way, if we does not provide a "primary" language for a site, parser functions and formatValue will break, since there are no defined meaning for the page connected to an item in a site.

In T222281#9233386, @Tgr wrote:

In T222281#9233326, @Bugreporter wrote:

For usage in non-CentralAuth sites we may build a feature in MediaWiki core

Sure, I just mean, does anybody need that feature?

BTW (not directly related to this task), the hidden and suppressed status of global accounts is stored in gu_hidden_level column (added in T297094) and is a per user flag; while local suppressed status (ipb_deleted) is per block. For the latter, see also T346716: Split user suppression/hiding (ipb_deleted) out of the ipblocks table.

For usage in non-CentralAuth sites we may build a feature in MediaWiki core, but this (local) feature should be disabled if CentralAuth is installed (it may no sense to disable login of local SUL accounts).

Global locks also prevent users from logging in. Until we solved T222281: Add a way to prevent user from log in and disable a users session when blocking and also have a similar option in GlobalBlocking, global blocks and locks should co-exist; compromised accounts should still be locked (and globally banned users may, though not must, be locked instead of blocked). Edit: to enforce global bans, what is more important is blocks/locks of banned users should not be able to be locally disabled, even if we can disable global blocks locally.

There are another one: Pages using DynamicPageList (intersection-category).

In T17294#9104267, @Xaosflux wrote:

It seems that a primary concern of the user story in the request is that locked users are lost and have no idea what to do? This appears to have improved over the 15 years since this request was opened. We routinely get global lock appeals via the contact form today.

Using an existing right as protection level is not recommended; please introduce a new right. See T230103: Systematize wgRestrictionLevels

I instead propose to replace pt_user, pt_reason_id and pt_timestamp with a new column referring to the logging table.

everything wanting a user list must join on ipblocks and filter by ipb_deleted.

In the new schema it is still the case: If we hide the actor of a revision a actor_deleted row is needed, though the user itself is not hidden, so we can not know the account hidden status without ipblocks. A new column in actor_deleted like ad_user_is_hidden may help. Note the ipblocks table in some wiki may be very large due to admin bot blocking proxies.

Addition note (only my opinion): in principle, global locks is not better than global blocks, since locks is effectively a kind of block that local community can not control or opt-out, thus breaking community's self-governance. Japanese Wikipedia opted-out global abuse filter since it is out of their control and can not be disabled locally, but no wiki can opt out (any) global locks.

For fixing CLDR data, also ping @Nemo_bis.

CLDR seems to be defacto used as a repository for names for language codes that happen to be used by people. Not at all as an authoritative source for language codes. Are we ok with using it anyway?

What is that CLDR mentioned in the CLDR extension itself?

https://en.wikipedia.org/wiki/Common_Locale_Data_Repository

Note: The UserMerge extension would require different handling of blocks depending on whether we have multiblock. To reduce the long-term maintanence burden we may consider always allowing multiblock once the feature is stable.

T346293: ipblocks schema redesign for multiblocks propose to add a is_deleted field to actor (and one user may have multiple rows for different hidden status), and something similar may also happen in comment (though there is currently not a task for this).

In the WMCS database replicas, the actor_p view attempts to respect the denormalized field values by joining on every change-related table (archive, image, oldimage, etc.)

T346293: ipblocks schema redesign for multiblocks propose to migrate the suppression state to actor table. If similar also happens in comment field, rev_deleted will only concern the text.

The UI for hiding usernames is part of Special:Block. Blocking a user with the "hide user" option causes the user's name to be hidden everywhere. Unblocking such a user causes the user's name to be shown everywhere. In changes (revisions etc.), this is implemented by denormalizing the user-hidden flag into the *_deleted bitfield. In user lists, there is no such denormalization, so everything wanting a user list must join on ipblocks and filter by ipb_deleted.

Gather feedback on Growth's proposed IP Masking approach to handling Flow boards: Logged out traffic can't post to Flow discussion boards until they have either logged into an account or created a Temporary account (by editing any non-Flow board). We will provide an informative message for logged out traffic that attempts to edit Flow boards

Note: Currently AbuseFilter stores potentially non-existent user names as performer for account creation (including automatic creation) action, which is not supported by the actor mechanism. See T188180: Read from and write to `actor` table in AbuseFilter

In T343768#9154613, @Punith.nyk wrote:

Hey @DVrandecic @Jdforrester-WMF I am looking forward to contributing to wikiLabda but I am unable to setup the wikiLmbda page locally

In T345037#9137889, @matmarex wrote:

All the interfaces tell you, "You can view it." But only administrator can view it.

See T264765

The excerpt from the deletion log is not shown to logged-out users.

This is apparently intentional: https://gerrit.wikimirror.net/g/mediawiki/core/+/965f722117315082d53e0fff53b4532bbc639121/includes/page/Article.php#1487

		# Show delete and move logs if there were any such events.
		# The logging query can DOS the site when bots/crawlers cause 404 floods,
		# so be careful showing this. 404 pages must be cheap as they are hard to cache.

In T20493#9150101, @Ladsgroup wrote:

What problem semi-deletion is planning to solve?

Probably I will write a longer comment about this later.

Also, the proposed "ultimate" list of language codes may be language-data library; See T190129: Consolidate language metadata into a 'language-data' library and use in MediaWiki for core integration and T281067: merge CLDR extension to core for proposal to fold CLDR to it.

See also T231755: Local language name should be translatable in translatewiki for localizing language names.

"semi-deletion" essentially means that the deleted page can be restored by anyone

(quoted to village pump)

A very old idea, T5843: Implement semi-deletion, may also be taken into account when we start to do this (it is not required, but a future schema change may make some reservation to make it easier to happen). Probably I will write a longer comment about this later.

English Wikipedia recently proposed this again.

some people are really keen on having ability to share query results of WCQS/WDQS without auth even if it's stale. Like basically HTML of the result copied and stored somewhere.

See also: T104762: Setup sparqly service at https://sparqly.wmflabs.org/ (like Quarry but for SPARQL)