The issue is the API should not exist in Wikibase at all - see T282170: Move "Short Descriptions" feature outside of main Wikibase.git code.

if you're creating a new page go through a lot -- but importantly not all -- of the steps involved in creating a page.

This would be comparible with undeleting a page.

LDF service is retired.

Don't suggest Codex until there is basic feature parity.

In this case OOUI should be used for now.

Per T433814: New DB request: etherpad Wikimedia will create a new Etherpad instance. Once it is online, the current Etherpad would be retired.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/1308044 and related patches (except last one) should be merged by someone with +2. They are already backported to wmf.13

It should better be lazily loaded (i.e. loaded only when button is clicked) and only loaded when there is a Wikidata Bridge edit link.

In T432298#12169843, @99of9 wrote:

I think I prefer being able to save. I've had situations when I've written something very complex, tried to save, and been told that something was wrong, but had to do something IRL and lost the work.

I like the fact that the unfilled field shows up red. To me that's a reasonable gentle warning.

Compare the pager of https://commons.wikimedia.org/wiki/Special:GlobalUsage/The_Earth_seen_from_Apollo_17.jpg which you can select custom page size.

But at least we should warn that the current composition is invalid.

Per https://meta.wikimedia.org/wiki/Requests_for_comment/The_future_of_Abstract_Wikipedia I believe we are not ready to show links to Abstract Wikipedia articles in other Wikimedia projects yet. The link should for now be unidirectional.

But this should be linked from Striker.

Note: If we choose to prevent users without 2FA from logging in, we need to make sure they can not receive email notification (both core enotif and Echo), otherwise content can be leakes via watchlist notifications (see T54453 and T199993).

What I mean is two-folded:

In T424647#12150725, @Nikerabbit wrote:

For clarity, there is no decision to migrate translatewiki.net to Wikimedia production, only explorations on technical feasibility.

An alternative approach using system messages (e.g.,  MediaWiki:Cldr-language-name-gsw/fr) is also possible via the existing i18n message system, but would require the CLDR extension to check for message overrides at runtime, which has performance implications.

Merge to more general task since most discussion will happen there.

So I changed the task title since this is what I proposed in the very beginning.

Reopen. CLDR should not be an extension; it should be a library.

In T420823#12149299, @CodeReviewBot wrote:

jforrester opened https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-schemata/-/merge_requests/392

definitions: Add Z2053/qqa-x-lor ZNaturalLanguage

In T238417#11905455, @Tacsipacsi wrote:

Thanks! By the way, Produnto modules could also rely on https://www.mediawiki.org/wiki/Help:Tabular_Data and Commons (which allows for near-instant appearance of translations and doesn’t require translators to have a third-party account) instead of Banana JSON and translatewiki.net. Tabular Data has already existed when the development in the present task began (although apparently not when the task description was last revised), so the development was already done with a focus on multilingual wikis.

Translations will be collected manually in a restricted document

Alternatively we can install Extension:Translate in checkuserwiki and let checkusers do the translations there. Then it can be synced with a private repo via a bot.

As an alternative we can remove recent change rows of Wikidata patrolled edits in client that is older than 24 hours.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Mathoid will be deprecated.

Reopen, it is still a useful feature. For example currently nothing is shown in page preview if the content of page is replaced with {{copyvio}}.

Users would still retain the ability to download their data with this (at least on public sites). If a user blocked with this option logs in, below the block form the only options should be "Download your data", "Change password", and "Log out".

Note to we need to delete files made by banned users automatically (otherwise user can bloat NFS usage via creating multiple accounts) - and this should retroactively be done for previously banned users, but we may still want to give some time so user can appeal.

I want an opt-in filter, not an opt-out one. Items like Q183 (Germany) is still quite large even if external IDs are stripped. If I want only one label, then fetch and return that label only, not fetching anything else.

In T386422#11638575, @YoshiRulz wrote:

I believe support for literal Z8s in the composition editor is the subject of T394458.

Another deficiency is EasyTimeline does not support Unicode characters.

We can instead hide all closed wikis by default (but still allow users to display them).

I believe once we complete the script to generate reports (Commons needs every report other than LonelyPages), we can generate reports of large wikis every day using such script (and should, to reduce database load).

I believe we should wait until T309738: Move MediaWiki QueryPages computation to Hadoop is resolved, then we will have a better way to generate query pages. (T422446: Move SpecialLonelyPages computation to Hadoop should be reopened)

In T197137#12112551, @Od1n wrote:

I'd like to add a bit of perspective here as an aside.

This ticket was opened in 2018, and in practice nothing here was ever actually exploited until a single, unique 2026 incident — caused by one person who went as far as executing thousands of scripts without any verification. The scale of discussion this ticket has generated feels disproportionate to what we have seen on the ground: we're mostly debating a hypothetical, not a widespread or common attack pattern. That should tip the balance toward avoiding friction that is, ultimately, largely unnecessary. And regardless, there's also the "already lost" aspect: once malicious code actually executes in a privileged session, there isn't much any of these reauth mechanisms can do about it anyway — as has been pointed out repeatedly on this ticket.

As a complementary (not alternative) track, it might be worth exploring automated static analysis over the codebase — e.g. a bot flagging suspicious patterns (dynamic script loading, eval-like constructs, obfuscation, etc.) across site/user JS — rather than relying purely on friction at edit time.

Also, while we're at it, I want to resurface a point I raised back in April (T197137#11821610):

A related — and significant — issue I'd like to mention is that when editing one's own personal JS (and CSS) subpages, the code is executed/applied during the preview! This is very surprising, an open invitation to shoot oneself in the foot, and potentially even a security hole. I cannot recall a single instance where this "feature" was actually useful to me.

This seems like a genuine low-hanging fruit: probably easy to fix, and a pure win on both security and usability at the same time.

that are not welcome on Commons

Note files are allowed on Commons as long as they are used in any Wikimedia project, include Wikitech.