The "Used by" template and "missing" extensions
7 views
Skip to first unread message
Yaron Koren
Jul 6, 2022, 9:09:06 PM7/6/22
to Canasta
Hi everyone,
There was a discussion for a while of adding a "Used by" template to mediawiki.org - showing, for each extension or skin, which distributions and wiki farms include it. In April, soon after the official release of Canasta, I finally created this template, and started adding it to a bunch of pages, based on the information I could find:
https://www.mediawiki.org/wiki/Template:Used_by
Since then, various other people have improved the template, added it to other pages, etc. And the template now populates, for each relevant wiki farm and distribution, categories to show the full set of included extensions or skins:
https://www.mediawiki.org/wiki/Category:Extensions_by_usage
https://www.mediawiki.org/wiki/Category:Skins_by_usage
(There are also two additional categories included there that are not populated by "Used by" : they hold the extensions and skins used within Wikimedia projects.)
This has become, in my opinion, a quite useful additional source of information about which extensions and skins are important. Of course, WikiApiary is great (to the extent that it's accessible these days), but it represents the actions of "the masses" - many people who are just setting up default installations, or who otherwise lack expertise about all the available choices. These new categories, on the other hand, represent the views of experts and power users.
One interesting piece of information that can now relatively easily be obtained is the "missing extensions" for each distribution and wiki farm - the extensions that are found nearly everywhere else but there. I was curious, so I wrote up a little script that scrapes these new category pages and does that kind of analysis. I'm apprehensive about publicizing this information too much, which is why I haven't put the results anywhere: to the extent that this information is useful, it's because each wiki farm and distribution has acted more-or-less independently about choosing what to include. As soon as everyone is aware of what everyone else is doing, and starts to feel pressure to include some extension because "everyone else has it", I think it would lessen the value of this kind of analysis.
That said, there is some interesting information there. Canasta doesn't have any major gaps in its functionality - there are no extensions that everyone but Canasta has, for example - but the two most prominent extensions that Canasta lacks are CLDR and CookieWarning:
https://www.mediawiki.org/wiki/Extension:CLDR
https://www.mediawiki.org/wiki/Extension:CookieWarning
These both seem like useful (and harmless) extensions. If we're going to add either one of these, I would strongly support adding CookieWarning - which is invaluable for wikis based in the EU. I don't know if we ever discussed this extension; maybe it's because none of the main creators live in EU countries, so we haven't had to deal with it.
By the way, Jeffrey, if you're curious, the most prominent omission in MyWikis is the TitleBlacklist extension, which is used by literally everyone else:
https://www.mediawiki.org/wiki/Extension:TitleBlacklist
I don't know how useful it actually is, though. And if you were to now include it, maybe that would be an example of peer pressure at work. :)
One other interesting thing my analysis revealed is the relationship between the most-used extensions and the extensions bundled in with MediaWiki. Not too surprisingly, there's a strong correlation between the two: there are eleven extensions that *everyone* uses, and all of them are bundled in MW. And there are six extensions that everyone but one distribution/farm uses, and all but one of them (Page Forms, yay) are bundled in MW as well.
Looking through the results, it's possible to also see what the most obvious omissions are from the set of extensions bundled in with MediaWiki. Page Forms is one, of course, but I'd say that there are valid reasons for core MediaWiki developers not to want to get involved with this very large extension. Another is the Echo extension - which apparently a lot of people do want to get into the bundle, but there's some complex reason involving the CentralAuth extension and PostgreSQL that is currently keeping it out:
https://phabricator.wikimedia.org/T191738
EmbedVideo is another - I would say everything it can do should just be done with Widgets, but clearly "the market" disagrees with me:
https://www.mediawiki.org/wiki/Extension:EmbedVideo
Of all these extensions, though, I think the clearest candidate for addition to the standard MediaWiki bundle is Pavel Astakhov's CodeMirror:
https://www.mediawiki.org/wiki/Extension:CodeMirror
It's in 6 of the 8 collections - including on Wikimedia - and it integrates nicely with VisualEditor and WikiEditor, both of which are already bundled in with MediaWiki. I don't know if there has been any strong push to add CodeMirror in to the MediaWiki bundle, but I think there should be - clearly a lot of people view it as important.
There was a discussion for a while of adding a "Used by" template to mediawiki.org - showing, for each extension or skin, which distributions and wiki farms include it. In April, soon after the official release of Canasta, I finally created this template, and started adding it to a bunch of pages, based on the information I could find:
https://www.mediawiki.org/wiki/Template:Used_by
Since then, various other people have improved the template, added it to other pages, etc. And the template now populates, for each relevant wiki farm and distribution, categories to show the full set of included extensions or skins:
https://www.mediawiki.org/wiki/Category:Extensions_by_usage
https://www.mediawiki.org/wiki/Category:Skins_by_usage
(There are also two additional categories included there that are not populated by "Used by" : they hold the extensions and skins used within Wikimedia projects.)
This has become, in my opinion, a quite useful additional source of information about which extensions and skins are important. Of course, WikiApiary is great (to the extent that it's accessible these days), but it represents the actions of "the masses" - many people who are just setting up default installations, or who otherwise lack expertise about all the available choices. These new categories, on the other hand, represent the views of experts and power users.
One interesting piece of information that can now relatively easily be obtained is the "missing extensions" for each distribution and wiki farm - the extensions that are found nearly everywhere else but there. I was curious, so I wrote up a little script that scrapes these new category pages and does that kind of analysis. I'm apprehensive about publicizing this information too much, which is why I haven't put the results anywhere: to the extent that this information is useful, it's because each wiki farm and distribution has acted more-or-less independently about choosing what to include. As soon as everyone is aware of what everyone else is doing, and starts to feel pressure to include some extension because "everyone else has it", I think it would lessen the value of this kind of analysis.
That said, there is some interesting information there. Canasta doesn't have any major gaps in its functionality - there are no extensions that everyone but Canasta has, for example - but the two most prominent extensions that Canasta lacks are CLDR and CookieWarning:
https://www.mediawiki.org/wiki/Extension:CLDR
https://www.mediawiki.org/wiki/Extension:CookieWarning
These both seem like useful (and harmless) extensions. If we're going to add either one of these, I would strongly support adding CookieWarning - which is invaluable for wikis based in the EU. I don't know if we ever discussed this extension; maybe it's because none of the main creators live in EU countries, so we haven't had to deal with it.
By the way, Jeffrey, if you're curious, the most prominent omission in MyWikis is the TitleBlacklist extension, which is used by literally everyone else:
https://www.mediawiki.org/wiki/Extension:TitleBlacklist
I don't know how useful it actually is, though. And if you were to now include it, maybe that would be an example of peer pressure at work. :)
One other interesting thing my analysis revealed is the relationship between the most-used extensions and the extensions bundled in with MediaWiki. Not too surprisingly, there's a strong correlation between the two: there are eleven extensions that *everyone* uses, and all of them are bundled in MW. And there are six extensions that everyone but one distribution/farm uses, and all but one of them (Page Forms, yay) are bundled in MW as well.
Looking through the results, it's possible to also see what the most obvious omissions are from the set of extensions bundled in with MediaWiki. Page Forms is one, of course, but I'd say that there are valid reasons for core MediaWiki developers not to want to get involved with this very large extension. Another is the Echo extension - which apparently a lot of people do want to get into the bundle, but there's some complex reason involving the CentralAuth extension and PostgreSQL that is currently keeping it out:
https://phabricator.wikimedia.org/T191738
EmbedVideo is another - I would say everything it can do should just be done with Widgets, but clearly "the market" disagrees with me:
https://www.mediawiki.org/wiki/Extension:EmbedVideo
Of all these extensions, though, I think the clearest candidate for addition to the standard MediaWiki bundle is Pavel Astakhov's CodeMirror:
https://www.mediawiki.org/wiki/Extension:CodeMirror
It's in 6 of the 8 collections - including on Wikimedia - and it integrates nicely with VisualEditor and WikiEditor, both of which are already bundled in with MediaWiki. I don't know if there has been any strong push to add CodeMirror in to the MediaWiki bundle, but I think there should be - clearly a lot of people view it as important.
Ike Hecht
Jul 8, 2022, 4:50:53 PM7/8/22
to Canasta
Thanks for this very interesting write-up!
As much as I hate extensions, I think that EmbedVideo is a great extension that surpasses Widget capability. For one, it allows playing local audio and videos with the usual [[File:Something.mp4]] syntax. Also, the parsing that the "evu" tag does, to automatically detect the video service and ID would be difficult to replicate in a Widget.
CodeMirror is really good too.
Yaron Koren
Jul 11, 2022, 9:40:08 AM7/11/22
to Ike Hecht, Canasta
That's true, I hadn't thought about handling of local files - EmbedVideo definitely handles those better. Although for local files, there's also the TimedMediaHandler extension (also contained in Canasta), which I believe does the same overriding of the "File:" syntax. (I did a web search to see what happens if the two are both installed - it looks like EmbedVideo takes priority in that case, unless you disable the local-files part of EmbedVideo.) [1]
Also, for what it's worth, EmbedVideo's code is not great, including very spotty i18n, [2] presumably due to being hosted on GitLab.
Anyway, this doesn't have to be a discussion about EmbedVideo - though it does seem that we're not quite there as far as an ideal set of extensions for handling video and audio. Assuming TimedMediaHandler really is as good as EmbedVideo for local files, maybe what's needed is a sort of "EmbedVideo Lite" extension, which only defines the equivalent of the #evu parser function - i.e., you just have to pass in the URL (and maybe some optional display parameters)? Or maybe all of that can just be done instead with a "super-Widget" that contains a huge "if" statement?
But also, yes - CodeMirror does still look like the most-overlooked candidate for bundling in MediaWiki.
-Yaron
Reply all
Reply to author
Forward
0 new messages