Reverting rEWBA66bcfe6704a8: Add errorformat parameter to wikibase API requests fixes the issue for me locally, so this seems to be fallout from T242769: Wikibase UI API calls should request a specific errorformat. Apparently we take the parameters for the message from the error returned by the API, so it seems that with the new error format we no longer get the parameters, or something like that.

This is due to T174504 (see especially T174504#5534713) and should be resolved with the next full WDQS reload, which will hopefully happen soon (cf. T230588#5534626).

@Michael Is this ready for Verification already or is more work still missing?

Not a bug, as explained above and on project chat. I’ve expanded the documentation a bit, hopefully that helps.

If this is done, I’d say the interface(s) should be renamed, because having a “store” that’s write-only and doesn’t support reads doesn’t make sense to me.

FWIW, Jakob’s comment at T217770#5778186 seems to mention the ?uselang “hack” as something that still needs to be cleaned up, so maybe that was never intended to be in scope of this task?

I think the unit conversions are also ultimately derived from the Wikidata statements (rOMWCa15236c286d8: Add more units for conversion indicates a maintenance script), but I don’t know the details. I just think it would be nice to avoid an extra config if we already have the unit conversions (but up to you, of course).

It might be possible to use the unit conversions (UnitStorage interface) for this – any item with a unit conversion from (centimeter) or to it (meter) is probably a useful unit.

Unassigned myself – anyone is free to pick up #2 and #3.

remove existing storybook installation on toolforge

i noticed this as well. i am not how costly it would e to improve this and depending on that whether @Lydia_Pintscher
sees this as part of step 1 or not.

We were unable to find any split more fine-grained than this in the task breakdown:

Notes from task breakdown:

You’re right – I’ve added a separate novalue link now.

somevalue is the internal name of “unknown value”.

I created T244726: WikibaseQualityConstraints can’t cache constraint results in federated setups for the bug described above.

Hm, now there’s an exception:

Either the lag in WDQS needs to be fixed, or we need to introduce some scaling factor in Wikibase so that lag is usually under 5s like we have for the job queue.

Why would we call them “blank values” if we’re transitioning away from blank nodes as the underlying mechanism?

Great, thank you :)

contentadmin, I suppose (I wasn’t aware of the difference before).

CCing @mkroetzsch and @Denny for input on the RDF model – they probably have some use cases in mind.

Hm, it reports results too:
…
the status is reported as “not implemented”

In T244572#5859549, @Lucas_Werkmeister_WMDE wrote:

But it looks like the constraint type is broken?

>>> $results[0]->getConstraint()->getConstraintTypeItemId()
=> "One of"

That’s not an item ID; presumably, that’s why the status is reported as “not implemented”:

>>> $results[0]->getStatus()
=> "todo"

Ah, but Beta Commons has no idea that Q505107 means “one of” – InitialiseSettings-labs.php only configures that for Beta Wikidata:

Hm, it reports results too:

Hm, it looks to me like the “reading constraint definitions” part itself is working:

Might be the same thing as T244115: Investigate & Fix holes for aliases in new property terms table (take 3)?

• Virtual usages comes into play here.

Being connected via sitelink is the original "virtual usage" considered by AffectedPagesFinder. We discussed also treating the description from wikidata as a virtual usage, since it's visible in the mobile view. Don't remember how that played out.

I assume this is what caused https://twitter.com/fnielsen/status/1225404037622849536, because in the error logs I saw this:

This task so far talks only about the directionality of a message; however, I imagine getting its language its also important, so we can set the correct lang attribute if necessary, e. g. for screenreaders. (For example, T32182: Untranslated gadget descriptions have incorrect directionality in RTL user languages was mostly fixed by applying dir="auto", but the language of untranslated gadget descriptions remains unchanged (i. e., the page content language, not the language of the message that was actually used)).

Do we still need to wait, or did browsers other than Chrome and HTML5 catch up?

sounds good to me 👍

Yeah, I also thought of encoding the statement ID in it, but the STRSTARTS is a bit ugly. Also, this doesn’t provide an obvious path for unknown values used in qualifiers and references… what could those use? (I assume the main requirement for the updater is that, whatever these IDs look like, they should remain stable between RDF exports of different revisions?)

@Michael @Tonina_Zhelyazkova_WMDE do we want to reduce any more duplication (e. g. in the <template> and <script> parts) or is this enough?

Uh, another thing… we still need to pass the property label into the message, rather than the property ID. IIRC we said during code review that we were going to do that in a separate change – well, we still have to do it :)

So either we apply the same fix (scale the margin appropriately to cancel out the font size), or we rethink this whole px-to-em business, because at least I don’t understand it at all.

Ah, I see – seems to be the same issue as the one fixed in fix vertical spacing for the button: the element (in this case, the heading) has a font-size, which throws off the size of the margin.

Now on integration-agent-docker-1006.

And

SELECT ?human
WHERE { ?human wdt:P106 ?o }

Would now mean: All entities with a known occupation
As opposed to All entities with a known or unkown occupation
which should be written as:

SELECT ?human
WHERE { {?human wdt:P106 ?o} union {?human a wdunk:P106} }

I have an idea for how to do this, and it seems to work, but I need to wait until the other spacing fixes are merged (currently in gate-and-submit) before I can upload it.

I’d say that’s up to the train… manager? person? Anyways, up to you :)

Should the heading really be “Editing the value for $property is not supported”? That’s the same heading as for unsupported datatypes (T235753), but in this case, the problem isn’t the property, it’s the particular statement.

@Lucas_Werkmeister_WMDE do you want to make an extra ticket for this? since this was not part of the initial AC

currently looks like this in my browser (firefox)

we only pass in a DOM element with the user name, not anything that could be passed into {{GENDER}}.