Note: any magic words that behave differently based on user language or interface languages need to check whether they have parser cache pollution issues. A simple check: view and purge a page using English, then view the page using (uselang) a different language.

{{int:lang}} is a hack, and requires wikis creating some MediaWiki messages. See T4085: Add a {{USERLANGUAGE}} magic word

user language

Although not really a blocker, please note Parsoid currently does not have the concept of user language, and will always use page language when parsing. See T85581, T4085, T322206 and comments on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1032542.

https://meta.wikimedia.org/wiki/Global_blocks
A global ban should be discussed in its own RFC and mentioned widely on meta, and on all communities where the user is active in the local language. Notice should be given, at a minimum, wherever local bans are discussed – or on the village pump if no local process exists

Note: If this feature can only view contributions of an IP/range (and potentially account) in last 90 days (which is the limit of CheckUser), it will not fully replace XTools or GUC.
One option is allow viewing xwiki contribution of (regular or temporary) account for infinite time, but there may be scalability issue if using a infinity-stored variant of global table like T368151: Add a shared table to CheckUser that records changes to different wikis per IP address of the user, since it will need to store every edits in every wiki forever - so querying local database one-by-one may be the only viable solution.
Alternatively, such feature can only allow viewing cross-wiki contributions of IP or IP range, and should be named Special:GlobalIPContributions instead.

See also current way to create venv: T363071#9732167 although this is not obvious.

In T303433#9945363, @kostajh wrote:

In T303433#9945350, @sbassett wrote:

In T303433#9945321, @kostajh wrote:

I see, thanks. The example patch in the task description is enabling CAPTCHA for just one wiki. Are there circumstances where we want to set $wmgEmergencyCaptcha across all projects without involving SREs? If not, then the AbuseFilter + showcaptcha consequence seems like it would suffice for the use case described in this task.

We've certainly seen attackers target multiple projects, so this might be a desired feature during certain incidents.

Ok. But then it sounds like the mechanism would be:

• Enable a global abuse filter for showing a CAPTCHA on all projects
• Create two local abuse filters on enwiki and jawiki

Which doesn't sound that bad. Just trying to avoid the need to build new software for this, if it can be easily solved with something we've already got.

See also T273600: Migrate Entity Page Views from JQuery to Vue and T54136: [Epic] Redesign Item UI for Wikidata repo. To use Codex to rewrite Wikibase interface may require server-side rendering of Codex, which we currently do not have.

when using curl, please specify a custom user agent.

A workaround:

• First you need to become a tool user. If you do not have a tool you need to create one.
• When using a tool account, create a "build shell" using webservice python3.11 shell
• Inside this "build shell" there is gcc

In T34815#9437885, @Bugreporter wrote:

Simply we can just do so:

• Remove the user row from user table. Now MediaWiki will treat the account as unregistered
• Change the actor_name to something like "Deleted user #123123" so histories and logs now shows the anonymized name, and (optionally?) actor_user to null
• Some table (e.g. user_groups, user_properties) now contains rows that make no sense, and can simply be removed
• Now the user is deleted for good

For non-Wikimedia wiki, this provides a simple way to remove e.g. (1) spam/vandalism only account and (2) account closed on GDPR request.

Does some extensions assumes the existence of a user_id? Check and fix them

If you have database access you can modify wb_id_counters table manually. But we need a maintainence script to do that.

In T368524#9951393, @Xaosflux wrote:

These are likely good things, I've added this topic to next weeks steward meeting (it's been an ongoing topic). We also likely need more phab tasks on this to ensure we delivery a consistent result for the user story of "I want to deactivate my account" regardless of the mode of intake.

Entities can not be directly edited. You need to use wbeditentity, or import from dump after setting $wgWBRepoSettings['allowEntityImport'] to true.

How is a password hash personally identifiable information?

It may be, especially when combined with passwords leaked in previous database leaks (in unrelated websites).

Wikimedia is not a wiki hosting service. See https://www.mediawiki.org/wiki/Hosting_services if you want to host your wiki.

Should we only lookup IP addresses that were used for edits

Note: when blocking an account, an autoblock may be placed on one most recent IP of the account based on rc_ip column.

What I mean is it should be shown in all 3 places: the disabled account, the admin account and main page.

Whatever this is, which should more likely be called "account deactivation"

forcibly "unvanishing" accounts

I updated my comment above, but say here again: If the purpose of undoing vanishing is prevent avoiding scrunity, simply undo renaming (and linking two accounts public in user page, if policy requires that) is enough. The old account will still be unusable.

In T368524#9948534, @Xaosflux wrote:

Then what is the process for "undoing" an "account vanish"? There may be a collision in the terminology and expectations here that need clarification.

If there are many options to choose (e.g. natural languages), then a simple drop-down is not really appropriate. Based on how Wikidata implement drop-down, the features needed are:

In T368153#9947819, @Etonkovidova wrote:

Another question - the order in which the items (i.e. months) are displayed is alphabetical on Special:ListObjectsByType/Z16098 and the order in the drop-down menu on Z13163 is difficult to identify.

Special:ListObjectsByType/Z16098	Z13163

It might be confusing to users to search for a month in the drop-down to make a correct selection.

Note: in future we will get rid of Names.php, see T190129: Consolidate language metadata into a 'language-data' library and use in MediaWiki

Note: autoblocks only last for one day, though there are proposal to extend it: T43479: [Spam/vandalism] Raise $wgAutoblockExpiry noticeably - Note if I read the task correctly, the current blocker of increasing $wgAutoblockExpiry is not a technical one, but a social one, namely we need to measure how increasing it is effective.

Note the current implementation of isSystemUser may be unreliable in the future, see T214722#9936533. In that task I proposed another solution that does not use a user group either.

An alternative solution is to reopen T212720: System users should be in a dedicated user group, which at least provides a better way to detect system accounts than the current one.

In T214722#9937698, @Tgr wrote:

In T214722#9936533, @Bugreporter wrote:

However it will also make the user displayed as system user (isSystemUser) in various places.

isSystemUser() basically just detects whether it is possible to log into the account somehow, so that's hard to avoid.

Yeah, but one may argue whether not having a feature to remove password and email complies with GDPR (many website did remove password and email on account closure; they may even have their accounts hard deleted. cf T34815).

See also my comment at T214722#9936533.

In proposed account vanishing procedure in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1050675/3/includes/GlobalRename/GlobalRenameUser.php we used User::newSystemUser() with the steal option to make an account unusable. However it will also make the user displayed as system user (isSystemUser) in various places. To differentiate these two kinds of users, I will emphasize my proposed solution of making a special format for system user name at T214722#8845922.
Also the steal option code may be split into a new function such as revokeAccess()

See also various tasks linked from T325235#8697072. Also GitHub username can be changed and the old username can be reused by other users, so maybe we should record GitHub user ID instead of username.

Another alternative is not using a existing library at all and make a service to generate SVG from stratch.

FYI, if you want to remove all members from a group, you can also let sysadmins run emptyUserGroup.php instead.

Language name is managed by CLDR extension. See https://phabricator.wikimedia.org/diffusion/ECLD/browse/master/CldrNames/CldrNamesFr.php$218
Either it should be fixed upstream, or overrided at https://phabricator.wikimedia.org/diffusion/ECLD/browse/master/LocalNames/LocalNamesFr.php

An alternative is revoke the password completely (such as https://phabricator.wikimedia.org/diffusion/EDAC/browse/master/SpecialDisableAccount.php, though we need to make sure this will also work for CentralAuth user).

In T357498#9926151, @Dreamy_Jazz wrote:

On the beta wikis, there is a entry showing the temporary account on wikis other than that used to make the first edit. For example, when I make an edit on cswiki and then open dewiki there is a log entry as follows:

This can be fixed by running namespaceDupes.php

Some other charting libraries:

• RGraph
• Teechart
• Plotly.js
• Chart.js (HTML canvas only - canvas can be easily converted to raster images, but not vector ones)
• Mermaid
• DataDraw (cf T338098, but seems inactive since 2023)

Wikimedia plans to develop Charts as a replacement of Graph.

See also: T354701: Enable migration of WebAuthn credentials to loginwiki by @Tgr

Windows Mobile is no longer supported by Microsoft; please reopen if you can reproduce it in a supported browser listed in https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

Edge Legacy is no longer supported.

Edge Legacy is no longer supported.

IE is no longer supported.

IE is no longer supported.

IE is no longer supported.

IE is no longer supported.

IE is no longer supported.

IE is no longer supported.

See T169027#9362252 for something to be considered.

Note: We need to first consider whether to render chart server side. If chart is client JS-only feature, it will not be shown in various places.

Very important issue to consider is (1) we need to be able to use template and template parameters inside chart syntax (e.g. {{Charts:foo|param1={{foo}}|param2={{{1}}}}}; (2) Lua module should be able to generate chart tag with variable number of parameters.