I’ll do the cascade protection part next.

T128486 doesn’t look like it’s going anywhere (we asked in the scrum of scrums for an update on its subtask T152425 three times, to no reaction at all as far as I’m aware), so I think we’ll need to work around this in our own code. I see two options:

On the technical side, we need to make some kind of API call during the submission step that will test against a given property's constraints.

In T238956#5716923, @mmodell wrote:

I see the "related gerrit patches" box on this very page.

Per T232006, the LDF service was still up (though sometimes sending the wrong cached responses) in early September at least.

Questions about the messages:

Sounds reasonable to me as well. One could argue that this is a variant of the existing “item requires statement” constraint – see T175562: Check “conflicts with” and “item requires claim” constraints on qualifiers and references?.

I think so, yeah.

That should resolve all the issues in the task description, I believe.

Unassigning myself in case someone else wants to tackle block errors.

The recently added Gerrit integration directly beneath a tasks description seems to be gone, could that be related to this switch?

The list of modules using RANK_TRUTH somehow grew in just 1½ months (due to frwiki gaining «Module:Carte interactive/Bac à sable» and frwikisource gaining «Module:Centralizer»); I’ve edited the pages on mediawikiwiki and test2wiki to counter this.

In T239760#5711872, @Lucas_Werkmeister_WMDE wrote:

Ah, but a “check experimental” on Wikibase is going to fail even after this fix, due to T239761. I’ll upload a noop WBQC change to test this.

Ah, but a “check experimental” on Wikibase is going to fail even after this fix, due to T239761. I’ll upload a noop WBQC change to test this.

In T235753#5674720, @Lucas_Werkmeister_WMDE wrote:

"in the wikitext" link leads to the wikitext editor of the article

( new mw.Title( mw.config.get( 'wgPageName' ) ) ).getUrl( { action: 'edit' } )

EDIT: Actually, this can give you the VisualEditor if that was the last one you used. If we always want a wikitext editor, we might need other/additional URL parameters. veaction=editsource always gives you the VisualEditor wikitext editor, but is ignored when combined with action=edit, and if we only specify veaction then on wikis without VisualEditor installed the action will be “view”. action=submit can be used to bypass VisualEditor (and should work on any wiki), but isn’t very nice (users might not expect the non-VisualEditor wikitext editor to be used).

References and values are identified by a hash computed over their properties. It is not a stable ID as it is always generated on the fly when extracting the entity data.

Still needs to be deployed, though. (And does it make sense to have a Done task in the Campsite’s Verification column?)

This task probably needs some rephrasing, because, not being an admin, I was unaware that backlinks are actually warned about on the deletion page itself:

Actually, make that six builds:

In T239451#5705598, @dbarratt wrote:

In T239451#5705017, @Anomie wrote:

But would making intestactions=full be subject to replica lag harm the use cases it's meant to support?

Do you have an example?
I guess a use-case could be checking permissions before performing an action, but that is unreliable anyways because the permissions could change between those two calls even if you are reading from master. It would be better, I think, if clients would attempt to preform the action and catch the error.

It means I can’t run Docker locally, because my system uses cgroupsv2, so I can’t develop using Docker.

Well, I only started doing it because the automated builds broke due to T235651. Anyone should be able to do the same thing by running grunt deploy (depending on your Gerrit/SSH config, you might need to do the final git push from the build/ directory by hand).

(Just to be clear – the above changes have been merged, but not deployed yet, so please don’t set any CSP headers yet :) )

Can we avoid having the discussion in two places, please? There’s already a lot more arguments on the mw.org talk page (also linked in the task description).

But in general, are these triples interesting in wdqs? Since they're never used as subject there are no way to use them directly, it seems the only thing that we can do is to display them (T173248).

select ?p (count(*)as ?cnt) {
  ?s ?p ?o .
  filter ((!isLiteral(?o))&&(!isUri(?o)))
}
group by ?p

The solution from StackOverflow is in fact already incorporated into the proposed fix: https://gerrit.wikimedia.org/r/c/wikidata/query/gui/+/552541/3/examples/code/R.txt

We recently changed how example loading works (there’ll be an announcement with more information soon), and one consequence of that is that examples which don’t show up in the parsed wikitext – in this case, because the parser’s “post-expand include size limit” was exceeded – no longer load as examples in the query service UI.

I don’t think this is a bug… at least the example in the RDF dump format documentation uses different IDs as well:

Well, that module is part of the WikibaseView extension, which we don’t load on client wikis – I don’t think this has changed recently, at least it’s also the case on English Wikipedia, which is currently running Wikibase code from 4/5 November (1.35.0-wmf.5).

Ideally, we would combine this with other action=query API calls, but I think that doesn’t have to be in the initial version.

Example: a wikitext-only revision might change from

<revision>
  <!-- ... -->
  <model>wikitext</model>
  <format>text/x-wiki</format>
  <text bytes="16" xml:space="preserve">Wikitext content</text>
  <sha1>basgq6oyo0kf51ykrohsumsutvpda86</sha1>
</revision>

to

<revision>
  <!-- ... -->
  <origin>2748</origin>
  <model>wikitext</model>
  <format>text/x-wiki</format>
  <text bytes="16" sha1="basgq6oyo0kf51ykrohsumsutvpda86" xml:space="preserve">Wikitext content</text>
  <sha1>basgq6oyo0kf51ykrohsumsutvpda86</sha1>
</revision>

– almost the same, but there is now a sha1 attribute on the <text> tag and the <origin> is new.

Forwarded to wikidata-tech for now, not sure if it should also be on wikidata-l proper.

We decided to implement this differently (see T235154#5694141).

We decided to implement this differently (see T235154#5694141).

Yeah, I think we can remove it.

In T235154#5689460, @Lucas_Werkmeister_WMDE wrote:

With regard to T235154#5640545, we decided:

• We will parse messages PHP-side, before replacing parameters, and add the result (HTML potentially containing $1, etc.) to the parser output – most likely in mw.config under a name like dataBridgeMessages (analogous to dataBridgeConfig, but not a part of that). The JS-side code will then substitute the parameters without any further processing (but HTML-escaping them where necessary, of course).
• The init module will load those messages and add them to mw.messages (using mw.messages.set()), so that they are available to the standard mw.message()/mw.msg() function and no modification to our MessagesPlugin or MwMessagesRepository is necessary.

Ah, MediaWiki has a “grouppage-sysop” message we can use for the client version, I think.

Links in mocks
administrator(s): $repourl/wiki/Project:Administrators

Actually, let’s put this in verification. Can someone update the storybook? (See T235763 for instructions.)