An alternative is only showing embedded contents after a button is clicked.

There are too many dramas about granting CU/OS for test/development purposes, even to WMF staff accounts:

• https://meta.wikimedia.org/wiki/User_talk:-revi/Archives/2021#FYI
• https://meta.wikimedia.org/wiki/Stewards/Elections_2021/Questions#DannyS712
• https://meta.wikimedia.org/wiki/Wiki_governance_audit/2021/Other#Test_wikis

Duplicate with T310431: Unable to view all Wikimedia projects?

See also: https://grafana.wikimedia.org/d/000000170/wikidata-edits?orgId=1&refresh=1m&from=now-12h&to=now

For any individual wikis a local fix like T86453 can be used, but this task is about fixing it in Wikibase.

Add Wikidata tag: per recent discussion https://www.wikidata.org/wiki/MediaWiki:Talkpageheader is changed but currently the functionality only work if interface language is English.

At least CU data access is logged and if someone abuse it it may be easily detected. views of CU log is not logged (I am not sure whether this is a problem; and it seems there are no retention limit of private data inside) but such log includes primarily data of abusive users, not everyone.

It is still dangerous if someone with IP Info log access is compromised (since we have no log on viewing IP Info log). See {T310393}

Not a MediaWiki issue. The message is set at https://en.wikiquote.org/wiki/MediaWiki:Ipboptions

As checking value is part of constraint extension

Previous discussion: T109566: Let unregistered users file reports in phabricator

T120486: Set "https_upgrade" configuration flag for domainproxy to enforce HTTPS upgrade for GET|HEAD requests made the entire wmflabs.org HTTPS only

What do you see in your browser console, specifically the Network tab?

There are some tasks that explicitly will not be fixed by WMF:
T173589: CodeReview extension reads from updatelog table in onLoadExtensionSchemaUpdates breaking sql.php maintaince script when run on different cluster
T268541: Convert CodeReview to AbstractSchema
T218079: CodeRevisionListView::getRevCount is creating slow queries on mediawiki.org

The "Permanent link" in sidebar provides a link to current version and at least in Firefox and Edge you can copy the URL of the hyperlink.

I do not suggest this approach. What I suggested (since 2017) is a "virtual site" solution: You can add a sitelink to xyzwiki, which will automatically matched to (i.e. referred to) a subpage of Wp/xyz in Incubator. This also allow creating an production wiki without any change of existing sitelinks (i.e. you can switch what a sitelink refers to in configruation and all existing sitelinks will continue to work).

See also: T246524: Current time displayed as modification date

Probably we can reuse the TwnMainPage extension repo. It seems there are also a Translatewiki.net Magic extension.

In T67626#7620208, @Bugreporter wrote:

Listeria is a 3rd party tool, and we need a feature built-in Wikimedia. Also Listeria does not store the result in any structured way.

In T278962#6977242, @Bugreporter wrote:

I think we should tag the local pages with a specific magic word like __VALIDREDIRECT__.

Issues of HarvestTemplates are not tracked here. Instead see https://github.com/Pascalco/harvesttemplates/issues.

In T307322#7912878, @SunAfterRain wrote:

In T307322#7909405, @Dylsss wrote:

Note that this would introduce bypassing Lockdown without any checks that a user can access the undoafter revision.

May be we could add a config like $wgThirdWayMergeWhiteNamespaces or $wgMcrUndoWhiteTitleRegex? like:

$wgThirdWayMergeWhiteNamespaces[ NS_TEMPLATE ] = [ NS_USER, NS_TEMPLATE, NS_DRAFT ];

allow "3-way merge into template namespace" which source from user namespace, template namespace, or draft namespace.

Wikidata RecentChange and Watchlist would be benefit from more granular filtering (see T43686: [Story] Ability to filter recent changes and watchlist on Wikidata and subtasks). There are a number of other task about filtering of such lists (random examples: T23674, T42535, T12379, T124214, T45901).

In T277505#7913996, @Nikerabbit wrote:

I believe, though I have not confirmed, that a quick fix would be to add these names to LocalNamesXX.php in the cldr extension.

Another, more complete fix, would be to bundle the IANA language tag registry names in the extension, giving English names to all defined language codes. This is as far as I know the same data the Babel extension is using as fallback.

One thing to consider: if temporary accounts does not connect with CentralAuth, nane conflicts should be prevented if cross-wiki features are uses (e.g. Special:Import, FileImporter, Wikidata RC/Watchlist integration).

How is it different from the "user" group, which are also registered users?

One thing to consider: this may degrade ElasticSearch results.

Another thing to consider: Will removal of existing labels degrade ElasticSearch result (and thus term lookup)?

If you only want to use the map service in a private project, it is better to set up a proxy to maps.wikimedia.org instead.

Before fully removing it we can first hide the link in sidebar.

For clarification, the purpose of my note:

• "(text) table should be dropped" - which may still be used elsewhere (in other extensions) and migration is needed if we need to replace it with another storage.
• such extensions (if exists) will make future insertions to text table (which will consume auto-increment) even if we no longer add new text rows on ordinal edits (i.e. content table will directly refer to ES addresses).

A more ideal solution is introduce a proper user right to allow using this feature (T17622: Create a user right to allow using redirect fixer (replacing $wgFixDoubleRedirects)), and $wgFixDoubleRedirects may be removed.

Oh, what jcrespo said ("Metadata in the image table just points to the text table, which points to ES content servers.") is wrong. But further check may be needed for other potential extensions directly writing to the table.

To prevent confusion it may be better to archive the current project and then create a new ACL project.

"Best rank" aka "truthy" should be a concept built in Wikibase software. We should make data reusers least impacted if additional ranks are added to Wikibase (Example proposal: https://www.wikidata.org/wiki/User:ChristianKl/Draft:New_Ranks, which also change how normal rank statements are regarded).

In T63111#7847021, @Ladsgroup wrote:

Yes according to T291332#7527840. And text as well (but that table should be dropped, long story)

This can be a Toolforge tool instead of (part of) an extension.

Another possible workflow:
(1) once a sitelink/value/reference is unused it is put to a queue (deduplicated)
(2) use something like LDF to quickly filter out value or reference that is still used (no need to do this for sitelinks as one sitelink can only be used in one item) - we need to figure out how to do this once we no longer use Blazegraph
(3) remove if they are unused
(4) recheck

See also: T105427: Need a way for WDQS updater to become aware of suppressed deletes

A proposed workflow:

1. using some queries to find all orphaned sitelink, value and reference nodes (and recording the IRIs)
2. remove them from triplestore
3. recheck if they are still unused and if they are not we need to add them back to the triplestore

I don't think "once, twice or four times a year" is enough. If someone added sensitive information into Wikidata, we need to remove it as soon as possible.

Firstly translation pages have English subpages; secondly even uncommon, it is possible for any page in any wiki to be in any languages and there is interface (Special:PageLanguage) to change it.