I personally am very used to Wikidata way of presenting structured data. Can we have alternative skin on Commons that mimics wikidata look, or extra tab with wikidata-like display of all properties currently stored in Structured data? I also think it would be nice if we could display somewhere the M-ID or entity ID of each structured data page. Those options could be optional and not activated by default.
Description
Related Objects
- Mentioned In
- T227116: Enhanced support for geo-coordinate Wikibase datatype
T239172: Enable support for the none (novalue) and unknown (somevalue) "special value" types in SDC UI - Mentioned Here
- T157014: CONSULTATION/PLAN: Managing Complex State and GUI on MediaWiki (e.g. for Wikidata/Wikibase UI)
T230314: Show constraint violations on SDC statements
T233036: Enable support for all WB data types in top-level Statements and Qualifiers
T239172: Enable support for the none (novalue) and unknown (somevalue) "special value" types in SDC UI
Event Timeline
My understanding was the the existing Wikidata.org front-end was EOL'ed by the Wikidata team and they plan to replace it with their new Vue-based system (which won't work for Commons's needs and they didn't want to make work for that use), which is why we had to build a new one. Not sure if that's still the plan, and if so, what the timeline is, and what that will mean for other uses?
Lead ticket for Vue migration for Wikidata would appear to be T157014 . After sustained activity in 2017, followed by a short spike in June-July 2018, it's not clear how much further progress has been made, or is currently anticipated on this. There is a mention that the Lexemes roll-out in 2018 included some Vue templates and widgets with PHP server-side rendering, which was going to be reviewed.
There's also mention at the top of that ticket that: "State management and data/event propagation goes beyond of what OOUI can provide". If so, it's not clear why that wouldn't be a problem fo SDC too; or alternatively if it is not a problem for SDC, why it should be a problem for Wikibase.
It does seem rather odd to have two different teams working on two different interfaces, with utterly different implementations, for what is essentially the same functionality against the same backend. From the outside it's hard to understand the fork as creating other thanextra work and extra delay now (cf T239172 "somevalue", T233036 (statements for most types of properties), deprecation, referencing, T230314 constraint checking, etc, etc etc); plus extra duplicated maintenance cost and implementation cost of any additional features gadgets and extensions going forward.