Page MenuHomePhabricator

Add Gadgets Extension on Wikibase Cloud instances
Open, Needs TriagePublic

Description

(imported from GitHub issues)


Blocked on an upstream ticket now that block localizaiton cache build on image build.

See #7 (comment)

Upstream: https://phabricator.wikimedia.org/T237148

But this is now resolved.


Gadgets will become more important if user scripting is not available, especially for project owners. I modified User:Zvpunry/EntitySchemaHighlighter.js to use local URLs and it worked, but having to call mw.loader.load() for it manually is impractical. (Unfortunately scripts like User:Teester/CheckShex.js currently rely on similarly-hardcoded server-side code: https://github.com/Teester/entityshape/issues/14)

Though, do you want a shared gadget base? Some may still want to add their own; if they are not able to there will probably be more pressure to add them globally.


So IMO lots of things that are Gadgets should likely be included as part of the Wikibase offering.
The merge UI and ES highlighter are probably 2 good examples there.

Though, do you want a shared gadget base?

And this is another good point that has played into the decision of not yet adding the extension, which is that having gadgets maintained on many different wikis, and falling out of sync, and needing to be kpet in sync, and editable by users just doesn't seem like a super scalable and non confusing solution :/


In an ideal world, many of these features would be part of Wikibase or extensions to it. And over time, that can happen. Features like collapsible elements and WYSIWYG editing started out as user and site scripts. Probably you know some Wikibase-centric examples.

But there's a continuum stretching from core feature through [bundled] extensions, Lua, gadgets, site, skin and user scripts and CSS - JS-triggered tools/APIs are in there somewhere - each level with narrower impact or internal access, but also lower barriers to entry.

In terms of standardising and uplifting contributions, it might make sense to focus more on Wikipedia's Lua modules for Wikidata, since they're closely associated with Wikibase functionality, and have been developed as libraries to smooth over rough edges for editors. I don't know how much of that relates to remote use of Wikidata, but perhaps that's relevant for federation.

Heavy data lifting is probably also best done in Lua (if you can spare the cycles on the server side). But as I understand it, it's constrained in how it can impact the UI outside the content, and access external services. Will it provide the integrations that target users need - or the community tools and tweaks that they want?

Many people only know (a bit of) JavaScript; they're not interested in pull requests or gerrit or phabricator or waiting for the next release - they want to get stuff done, quick, and make their own lives easier, today. Customisation of UI and functionality is part of that. Otherwise you end up waiting years for something that may not come; or if it does, isn't quite what you want.

Perhaps more importantly for the community, they're a part of democratising the development process. Think of it as rapid prototyping that you don't have to do. Would you know that merge UI or ES highlighting were useful if they had not been created already? (And again, with all else to be done, would they be available yet? Central development is perhaps hardest to scale.)

Maybe it's unnecessary for an MVP evaluation service. But my own experience bumping into this with the two scripts above suggests that, at least in the area of entity schemas, there are gaps that JS of some sort can fill - and I suspect that applies to lexemes, too. Without it, the platform will appear less capable.

Or perhaps the vision is for this to be part of the stack, with user-facing consumers elsewhere? Used more like Wikidata from a Wikipedia perspective? But you'll still need tools to assist editors. Many potential users are new to both Wikibase and MediaWiki; it'll be enough of a stretch for them to manage one MW-based site, let alone a linked set of them. ~Plus, the current lack of CORS headers on the SPARQL endpoint make integration with scripts elsewhere problematic~ (fixed here and on Wikibase.cloud).

[Probably some of this belongs on a more general discussion of the future of the platform.]