In T332484#11109406, @Bawolff wrote:

Its not clear to me what exactly is being asked for here - is it solely about the cross-wiki aspect? Better editing UI.

Because you can already create json lists at the local wiki level.

Currently information in Wikipedia is scatter in many pages. Without Wikidata it is not easy to maintain a single source of truth (see: https://meta.miraheze.org/wiki/Help:How_to_manage_structured_data). Wikidata provides a mechanism to store data centrally, but there are no on-wiki query support, and some wikis have negative attitude to Wikidata since data in Wikidata is beyond local community's control.

They should not be used for privilege elevation except for the purpose of adding new 2FA methods (but they shouldn't be needed for that either, see T428980).

One case to consider is if user is already logged in and want to add a new 2FA method, they may already lost access to the current 2FA method.

In T423270#12001934, @matmarex wrote:

I know what it says in 1.45, but I don't know whether that is any more correct. For example, "json" definitely should not be listed any more, since this feature is now built in to PHP (it's not an extension any more since PHP 8.0).

If you want to investigate, and make a patch, documenting the reasons for the additions/removals in the commit message, I'd be happy to merge it. I don't think that work needs to happen as part of this task, though.

Account recovery page is now linked from https://foundation.wikimedia.org/wiki/Legal:Wikimedia_Foundation_Legal_and_Safety_Contact_Information#Security which will be linked from footer of every site.

private wikis haven't been used in years

but they may contain historical information that user may want to access.

In T420792#12005613, @Reedy wrote:

In T420792#12004658, @Bugreporter wrote:

No matter how we do there will always users without 2FA in private wikis.

Such is life. Doesn't mean they'll be able to use their account though.

Sending a recovery code to everyone does not solve everything. Consider:

• Users with no email set at all
• Users whose email is unreachable
• Users that missed the 2FA notification or recovery code email (e.g. email go to spam folder, or user does not check before the recovery code expiries)
• Users who do not know why they need to set up 2FA (e.g. T428733: "Two-factor authentication will be required for you to have access to this wiki" email for closed wikis)
• Previously blocked users that are later unblocked.

Alternatively we can add support to allow $wgOATH2FARequiredGroupRemovalPages to be null and reword message if it is null.

In T428667#12004569, @Jdforrester-WMF wrote:

In T428667#12002920, @Bugreporter wrote:

wfu_wiki
wfu_namespace_id
wfu_namespace_text

This can be normalized to a new table, similar to what globaljsonlinks does: https://phabricator.wikimedia.org/diffusion/EJSC/browse/master/sql/tables.json#L49

It could be, yes. Was this not done for GlobalUsage just due to it being a pain to migrate? Is there a task for it?

This can be normalized to a new table, similar to what globaljsonlinks does: https://phabricator.wikimedia.org/diffusion/EJSC/browse/master/sql/tables.json#L49

The 1.45 version is: (bold added by me)

Decline since this is about a removed feature in LilyPond so it can not be fixed.

Alternatively voter list can be imported in batches.

Oppose. It is better to raise $wgAutoConfirmCount to 10 globally instead.

In T428225#11988526, @Aklapper wrote:

Hmm, where would be a central place/URI where I'd put a very boring list of changes from Phabricator deployments? I don't feel like this is in scope for Diff.

Using AI to generate summaries for 25+ years of Wikipedia edits would use lot of computing power

So first (1) we should develop it to be run via either calling LLM provider directly or via an agent server not hosted in Wikimedia production; (2) be used with an opt-in basis (e.g. as a gadget).

See: T428137#11986130

Note: it is not a practice to mark statement as "preferred" if there are only statements with preferred rank. So we usually need to search normal rank statement if there are no preferred rank statement. The union of both is called "truthy" statements.

Ideally the edit form should not load at all.

Reopen. Such feature should live in MediaWiki core, similar to T197160: All security-sensitive MediaWiki functionality should require elevated security.

In T381187#11975708, @matmarex wrote:

FYI, the limitations that caused this problem have been removed today.

Note: This may be fixed once we start to use new termbox in desktop.

"request help from the Wikimedia Foundation's Trust and Safety team" - if user see Help:Account_recovery page they will not know other ways to contact it other than the Account Recovery form. Also if we decide to narrow the scope of the help page, remind other on-wiki pages may link to it (or link to Special:AccountRecovery. If some user forget their password, and either (1) have no access to email linked to account - which is original purpose of this special page or (2) have no directly).

https://meta.wikimedia.org/wiki/Help:Account_recovery directs users who can not login to use Special:AccountRecovery, and also there are pages directly or indirectlt links to Special:AccountRecovery. If some user forget their password, and either (1) have no access to email linked to account - which is original purpose of rhis special page or (2) have no email linked to account: they visited Special:AccountRecovery which ask user tryed to reset password first. They unsuccessfully reset their password, and turn back to Special:AccountRecovery, finding it is still unusable.

Note: apart from NewUserMessages user talk pages can also be created:

• Via MassMessage (e.g. notifying users for some events or votes, even if the user has no local edit);
• Manually or via AWB (zhwikivoyage once created user talk pages of all users in 2015);
• Via SynchBot (in this case it is the user themselves who asks user talk pages be created).

In T228745#11952120, @Amire80 wrote:

In T228745#11915933, @Bugreporter wrote:

Note T397367: Drop unneeded empty tables from wikis indicated Wikimedia is not scalable to have thousands of wikis in production (one cluster can host only several hundred databases). We need a different solution (such as "virtual wikis" - some way to have incubator looks as if they are multiple wikis with separate domains, but sharing one database and one common set of tables).

Where exactly is it written?

In T228745#11924292, @Theklan wrote:

Is the main problem for doing something that is easier for our communities is "polluting LLMs"... then we have two points for doing it.

Or, we can let users with log entries (except creation/autocreation of self account in any wiki) ineligible for automatically vanishing (i.e. require manual approval).

In T402595#11109361, @Bugreporter wrote:

Note https://meta.wikimedia.org/wiki/CAPTCHA_exemptions exists for user that can/should not use captcha, and we may need a new user right for that user group.

See also T102576#9949987

Note: special page aliases, namespaces and magic word translations are one-to-many relations since one special page can have multiple names, where one of them is considered primary. So we need some mechanism to store alternative translation in addition to the primary one. In addition, even English is considered original language, there are aliases in English special page/namespace name and we need to consider whether we allow to manage that in translatewiki.

Also note the current implementation of GlobalUserPage is buggy, e.g. see T89916 and T90978.

I'm reviewing the current situation for T425752: Produnto repository viewer: Package namespace

In T426696#11934593, @Aklapper wrote:

Removing good first task because I'd say this can be achieved by installing and setting up user languages like British English, if I remember correctly.

replace SPARQL queries with Cirrus Search queries

Note the modern way to do simple query is via https://www.wikidata.org/wiki/Wikidata:Wikibase_GraphQL. As it also use CirrusSearch as backend, it will also be affected by such change.

This can already be disabled via https://www.mediawiki.org/wiki/Manual:FAQ#How_can_I_suppress_actions_and_special_pages? but I am unsure it should be disabled by default.

generate links

It is sometimes intentionally used to track usage of scripts.

What software framework do you use? Also please use bot password or OAuth to login to your bot (not ordinary password), and make sure it is still valid.

It is not yet part of valid Wikitext. See T322775: Allow <thead> <tbody> <tfoot> as literal HTML tags in Wikitext

And again, it's OK if it's just languagecode.wikipedia.org right from the start as long as patroling for vandalism works reasonably well.

One of points against "skip the creation of incubator wikis and instead just start them immediately" is such domain may easily be treated as official projects, so if someone that does not fluently speak such language created a such project (or if there are no validation that content is in correct language), such content will pollute LLMs.

Note T397367: Drop unneeded empty tables from wikis indicated Wikimedia is not scalable to have thousands of wikis in production (one cluster can host only several hundred databases). We need a different solution (such as "virtual wikis" - some way to have incubator looks as if they are multiple wikis with separate domains, but sharing one database and one common set of tables).

https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_46/RELEASE-NOTES-1.46#L18 is outdated too since the lowest version that upgrade is supported is 1.39. (RELEASE-NOTES-1.47 also needs fixing.)

Note somebody file a duplicate of T399442: In Vector-2022, the "Add interlanguage links" button should be moved from the toolbox to the "Add languages" button which should be considered in ULS rewrite.

Note: currently AbuseFilter does not know anything outside the variables AbuseFilter can read.

Tooladmin is for managing tools hosted in Wikimedia Toolforge, which is only a subset of all tools in Wikimedia.

In T425893#11910620, @KineticPelagic wrote:

As part of my Clinic Duty rotation, I am moving this task to the "Needs Further Discussion" column of our MWI workboard because:

• An internal MediaWiki team member identified the issue.
• The task description gives some insight into a workaround and how much effort this workaround takes.
• I wonder how frequently we are asked to delete files with this many versions.
• I am not sure if this task should go to Radar and be for the MediaWiki Platform team. I have asked in our team Slack channel. I see that Bill completed a related task in 2018.
• I need more context from our team to understand where this task fits in our priorities.

Some small wiki has crats for historical reason and sometimes it causes a lot of troubles. Before U4C exists many RFCs in Meta concerns potential issues of wiki governance (e.g. a crat becomes de facto dictator of wiki). See also https://meta.wikimedia.org/wiki/Wiki_governance_audit

As a reference, local wiki can use AbuseFilter to block account creation with unwanted name.

If a group is already removed from the wiki then it can not be emptied from wiki. We need to run emptyUserGroup.php to empty them. (All user groups, include built-in ones, should be emptied.)

BTW, one of major missing feature of current Wikibase UI is T47224: [Story] Custom edit summaries.

The potential concern is crats in any wikis can technically grant any user sysop and crat with no discussion at all, and this did happen in some small wikis. We have no technical way to enforce a discussion before granting. Some potential solutions are:

• Technically prevent granting sysop/crat to user lower than TAIV threshold (while stewards can override). Not a good solution since this means flagging adminbots may often require steward action.
• Disable access to IP Reveal for sysops and crats lower than TAIV threshold. Stewards can still manually add them to TAIV group. This may require splitting checkuser-temporary-account right.

This may be added to crats of all private and fishbowl wikis since stewards are unable to do that.