add it to the fishbowl list

This will result in issues described in T171501: Disable accountcreation on ptwikimedia. There may not be really a need either since wiki may be closed in some unspecified future date.

Reopen, since this just mean we don't need to mention it in "Writing an extension for deployment". The second point "Create a new manual page about usernames and IDs" is still valid.

So marked as stalled. As an interim solution, adding .* <noedit> to MediaWiki:Titleblacklist will prevent non-admins from editing wiki (though this is not intended as a permanent solution).

It should become basically empty

Until we resolved T381599: Migrate current references of text table rows from afl_var_dump, there are still more than 30 million rows in text table in enwiki and Wikidata.

Closure does not mean deletion of any existing contents in the wiki.

Should wiki be closed? Closure mean editing will be restricted to stewards and global interface editors, and all sysops and crats of the wiki be removed.

Note this should also apply to mentors/mentees who are globally blocked or globally locked.

The most common usecase of moving Flow page is user renaming.

See T364617: Deprecate and remove alllinks API endpoint for arguments that this should not be done.

Many wikis has discussion split by month (or three months/half year), but archives of English Wikipedia Village Pump and Administrators' noticeboard are split by constant size.

because the -x-QID syntax mostly creates invalid language tags.

See also: T167166: Specify the use of extended language codes in Lexemes

Note currently conversion rules can be disabled via -{-|...}-. For compatibility of Parsoid, the sematic of this should be changed to a "blacklist" mechanism.

Em, it should not be a problem as long as the linter, validator and minifier does not do wrong. All of these currently does not touch inside dynamically created regex at all.

To enable 2FA to your account: See https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions#Requests_for_2_Factor_Auth_tester_permissions
If others are unable to login due to 2FA enabled: Assuming your app use MediaWiki API to edit Wikimedia projects, please let them create a bot password (https://meta.wikimedia.org/wiki/Special:BotPasswords) and let them to use bot password to edit.

This is a third-party tool, whose issue does not track here. See https://en.wikipedia.org/wiki/User_talk:Neechalkaran instead.

This specific issue will be resolved since T381079#10418299 is completed, but fixing xtools to ignore wikis with replica not yet set up may be considered.

In T381537#10418761, @gerritbot wrote:

Change #1105907 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] startup.js: Add test for Array.prototype.includes

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

If we implement this as a global partial block, we'd need to decide on the likely eventual scope of global partial blocks. Should we assume that it would eventually need to handle global blocks against articles (perhaps unlikely, since defining global equivalents might be challenging), namespaces, or other actions? If so, we'd need to design the special page and the database structure accordingly.

See: T373367, T373380

If we revoke access via any kind of global block, and if we need to prevent local exemptions, we'd need to design a new type of global block that can't be locally exempted. There may be research involved here, such as whether we would need to restrict what kind of block can be un-exemptable (e.g. would we also allow this for sitewide global blocks?).

This should apply to all kinds of blocks, since GlobalBlocking will complete replace the lock feature in CentralAuth eventually (T373388: Merge CentralAuth locks into GlobalBlocking).

But instead of displaying English language names of such languages, such languages should be removed from valid lexeme languages.

Let's merge other tasks here since the thing to do is the same.

Remove $additionalLocalizedLanguages does not fix the issue; $additionalTermLanguages should be removed too.

You may want to use bot password instead.

Wikimedia Maps is just an OpenStreetMap tile server, and you can use other ones.

In T381537#10409889, @Bhsd wrote:

@MusikAnimal What do you think? The CodeMirror 6 library contains ES9 unicode property escapes (\p).

Issue not tracked here. See https://www.mediawiki.org/wiki/Talk:Snippets/Hide_prefix_in_category and https://www.mediawiki.org/wiki/MediaWiki_talk:Common.js instead.

In T382082#10405807, @Urbanecm wrote:

In T382082#10403527, @JJMC89 wrote:

In T382082#10403117, @Niharika wrote:

We only want to allow global IP reveal blocks, not local ones, because if someone is abusing IP reveal on any wiki, they should not be able to use it on other wikis.

This is basically what we were discussing with Legal yesterday. I believe local IP reveal blocks should be permitted because if a local admin or Checker detects abuse, they should not have to wait for a steward or global sysop to take action against them.

Per policy, only Stewards and Trust & Safety are permitted to remove access.

Not 100% true. The policy also states Users who are blocked from editing a Wikimedia project will lose access to temporary account IP addresses on that project., which means admins can block the user to suspend/terminate their access.

A workaround is install https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/ and load (edit) this property using one of debug hosts.

Note when we previously use Wikitech to manage LDAP accounts, user names must be valid in MediaWiki (and @ is invalid), and the user name must pass through both TitleBlacklist and AntiSpoof.

Note RegEx lookbehind is only supported since Safari 16.4. This and several other Regexp features also requires Firefox 78. We may first want to implement a ES9-without-regex-feature mode (i.e. code can use ES9 except regex features) - other features in ES9 are already supported by major browser passing startup test. However Peast does not check regex content at all, and ESLint seems only check whether regex conforms the latest JS standard, without checking which ES version the regex is supported.

Note Special:Contributions does not have feature, though API supports ucuserprefix param.

Browser APIs are unfortunely not part of any ES but for many cases there is a workaround (compared with syntax feature that we must not use in order to guarantee support in older browser.

It should not be possible to have a local exception to a global block that prevents IP reveal.

T355385.

If a user who is globally blocked from IP reveal has more than one block, the other blocks should apply the same as before, and the IP reveal block should be added to this

So we may need a multi block feature. We may reuse some of features (like UI) from ongoing multiblock project.

See also: T300912: Add a polyfill for IntersectionObserver to ResourceLoader

Per caniuse IntersectionObserver is added in Safari 12.1 and iOS 12.2 and current grade A is Safari 11.1 and iOS 11.3.

So we may want to 1. resolve T231755: Local language name should be translatable in translatewiki.net first; 2. migrate existing translations of languages to CLDR extension.

Can some other admin confirm that it is CC-BY-SA 4.0 (with share-alike), not CC-BY 4.0?

As I said above, the Grade A JavaScript requirement is already higher than ES8.

Note if you must use Python 3.13, you can create a Bookworm Kubernetes shell using toolforge webservice python3.11 shell (note you can no longer use Bastion for this since decommision of Grid Engine), and manually compile Python 3.13 there from source code. Several years ago I did this for 3.7 before it is available (T230961).

In T368113#10375890, @gerritbot wrote:

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

[mediawiki/core@master] [WIP] file: Basic support for writing to the new file tables

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

We should still keeps the current revdel/suppression and deletion system functionally separate. For example:

1. Someone created an article for a BLP
2. A user added disparaging information to the article, it got revdeled
3. A user added PII to article, it got oversighted
4. Article is deleted for lack of notability
5. Article is recreated
6. Article is moved elsewhere; currently we do not move deleted revisions with it. (But we can let user choose whether to move the deleted revisions together with it? By doing so, user should know existence of deleted revisions beforehand.)
7. Older revision is restored, but we don't want revision hidden in step 2 and 3 to come back.