Before we switch any wikis over to using Gadgets 2.0, we should have some community members test it out and give us feedback. Some specific questions to answer:
Send an email to Wikitech-l mailing list as well.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T34169 Action to join scripts and styles in one file | |||
| Open | None | T110014 Make gadgets easily customizable (merge Gadgets' branch "gadgetprefs" from GSoC 2011) | |||
| Open | None | T31272 Implement Gadgets 2.0 | |||
| Open | None | T125582 Get community feedback on Gadgets 2.0 before migrating |
I can tell you already that community members aren't going to be happy about the appearance of pages like http://commtech.wmflabs.org/wiki/Gadget_definition:AdminTool. At the very least, the gadget definition pages need to link to a page where this information is displayed in a more comprehensible format. Ideally, the prettified JSON wouldn't even be shown at all, and something nicer would appear in its place.
Such pages already exist - https://meta.wikimedia.org/wiki/Special:Random/Schema
True, but that's in a weird dark corner of Meta which only a few developers need to worry about. On the other hand, gadget definitions are user-facing (at least somehow more user-facing than event logging schemas, or whatever those things are), so they should be less cryptic.
Comments
@TTO: Under Gadgets 2.0, the Gadget definition pages are not intended to be edited manually. That's what the GadgetManager is for. Have you tried out the GadgetManager interface? Perhaps we could add an edit notice to the gadget definition pages pointing people to the GadgetManager. Do you think that would help?
Did we test the initial conversion step sufficiently ?
Not yet. It has been tested some, but it does need more thorough testing. There is one currently known bug: T119008.
What is the 'rollback' strategy in case something goes wrong with en.wp deploy ?
The interface itself is switchable with a config variable, but the conversion script is only 1 way. Perhaps we should write a reverse conversion script as well.
I think it wouldn't be totally unreasonable to change the json extension to be able to include an extra page header or something that can be configured with a local MediaWiki message. That way we could explain to people what this pages are for (see concern of @TTO). Don't forget that these will be 'findable' with the search engine for instance, so users might encounter them.
Agreed. I had a similar thought above.
Did we test what these new JSON pages do to bots and other recent changes checking tools ?
No. If you can suggest any specific ones to check, that would be great.
It's all jQuery UI, which we are trying to get rid off.. but it is fairly self contained, so I think that's ok for now, but is there a ticket for that ?
No, but I'll make one.
There is little documentation provided by the UI, there should probably be a follow up ticket for that as well.
Good idea. Any specific suggestions would be appreciated.
There is no 'non JS' fallback for creating a new gadget. Not sure if that is even possible, or makes sense... but perhaps a no script informative message would be a good idea.
You can actually still create gadgets completely manually (without JS), it just isn't obvious how to do so. We could create a no-script message explaining it, but I'm wondering if that's really needed or not. Are there really people creating Gadgets (which are mostly JS) that don't use JavaScript themselves?
It needs more than an edit notice. It should have a notice on page view, I think. Don't forget that for many users, the edit tab will instead be a "View source" tab on these pages, and users will most likely not bother to click on it.
@TTO: If they don't have permission to edit in the Gadget or Gadget Definition namespaces, they also won't have permission to use the editing interface in the Gadget Manager (the Modify and Create links won't be shown), so directing them to the Gadget Manager won't actually be helpful in that case.
@TTO: I made you an admin at http://commtech.wmflabs.org so you can test further.
What's the point of the gadget title? It doesn't seem to be used anywhere in the interface. I was expecting it to automatically show up in Preferences, like
instead of just
It's also not possible to reorder entries in the "Scripts" list in the gadget editor dialog. This is important for Twinkle (which I set up on the test wiki), because Morebits.js and Twinkle.js need to be run before the other modules, but if you get the order wrong when setting it up (as I did), you can only reorder them by manually edit the gadget description JSON.
But yay! Twinkle works.
Maybe the "edit" or "View source" link of "Gadget definition:Foo" should open Special:GadgetManager in Modify mode, instead of opening
http://commtech.wmflabs.org/w/index.php?title=Gadget_definition:Foo&action=edit
! In T125582#1995519, @kaldari wrote:
No, but I'll make one.
Done: T126446: Migrate GadgetManager from jQuery UI
It is used at Special:GadgetManager. See:
http://commtech.wmflabs.org/wiki/Special:GadgetManager?uselang=qqx
I was expecting it to automatically show up in Preferences, like
- Title: Description
instead of just
- Description
+1 for that. Currently
http://commtech.wmflabs.org/wiki/Special:Preferences?uselang=qqx#mw-prefsection-gadgets
only uses gadget-Foo-desc.
It's also not possible to reorder entries in the "Scripts" list in the gadget editor dialog. This is important for Twinkle (which I set up on the test wiki), because Morebits.js and Twinkle.js need to be run before the other modules, but if you get the order wrong when setting it up (as I did), you can only reorder them by manually edit the gadget description JSON.
Aren't gadget editors supposed to enforce the correct loading order of their scripts by creating separate modules, and using ResourceLoader dependencies or mw.loader.using? See e.g. the "hidden" gadget modules on Commons for example:
https://commons.wikimedia.org/wiki/MediaWiki:Gadgets-definition#modules
@Legoktm: Do you think it would be worth writing a reverse migration script (for moving Gadget files back to MediaWiki namespace) in case something goes wrong with a deployment?
What's the point of the gadget title? It doesn't seem to be used anywhere in the interface. I was expecting it to automatically show up in Preferences, like...
I'm inclined to agree with you about using "Title: Description" instead of "Description" in the preferences interface, however, many gadget descriptions already start with the title, so this would be awkward in practice. Maybe we should just get rid of the Titles and use the Gadget IDs in the Gadget Manager.
It's also not possible to reorder entries in the "Scripts" list in the gadget editor dialog.
This should be enforced using module dependencies, not script order.
@kaldari: Aren't they very limited with regard to which characters are accepted?
(In case it is: Isn't that bad for i18n purposes? It is common to have the gadget names translated from English to the local languages when people create forks)
Has Community Tech stopped working on Gadgets 2.0? :( I hope I won't have to wait another five years for the next burst of activity...
It's not clear to me what feedback is still possible, wanted or useful. Is this task now invalid?
That task has been closed as a duplicate of T108653: ResourceLoaderWikiModule should follow redirects for JavaScript/CSS content, which was resolved
Well, I see that almost all subtasks of T31272: Implement Gadgets 2.0 has been resolved. Only a few of them left. If this task is not blocked on anything else, then it should not be a problem to get community feedbacks on it. Deploying it on a test wiki and announcing on Tech-News would be the first steps to get community feedback, I suppose. I already see Gadgets namespace on production wikis. I think all it waits is getting feedbacks before fully enabling this new system on production wikis. I might be wrong though. @kaldari could you confirm if it's good to go?
I think T140323 should be resolved first. The fact $wgGadgetsRepoClass can be set by only one class either MediaWikiGadgetsDefinitionRepo or GadgetDefinitionNamespaceRepo is also problematic. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/389793 is for that, but not reviewed for 2 years.
The main issue at this point is just that no one is working on Gadgets 2.0 and it's not part of any team's goals at the moment. If anyone wanted to pick it up as a volunteer project, that would be welcome. A lot of the heavy lifting has already been done.