Last modified: 2014-09-10 02:57:08 UTC
This is a proposal submitted by Rob Kam at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Templates_for_new_MediaWiki_installs Anyone setting up a MediaWiki wiki, wanting to use templates, has to export/import them from another wiki (e.g. Wikipedia) or re-write and maintain some similar ones. This can create a confusing mess. It would be very useful to have a simpler way to install an up-to-date package of standard templates. Some of the problems encountered with setting up templates are discussed at [[mw:Help talk:Templates]] Posting it here for community review. We are looking right now for project ideas for Outreach Program for Women. https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7
This sounds reasonable to me. Two things: * I think it should be an option during installation. Probably opt-out. * Which templates? It would be great to have a list of standard templates somewhere, so we can adjust it in future versions.
Issues: * Upgrading. Changing wiki pages isn't trivial on upgrade, and compatibility of course. * Localization. The kind of template one would consider mandatory for encyclopedia-style wikis should probably be an extension or Lua module (References, Infobox, Citation?)
A possible solution might be to treat these templates like messages. Those which aren't modified localyy, can easily be upgraded and localized like messages. Those that are modified, keep their local value. However, that would mean a. extending MediaWiki namespace functionality to Template namespace or b. storing these templates in MediaWiki namespace b. seems like a bad option. So would it hurt to have "message" functionality in Template namespace? At first glance, I don't think so. If there is a predefined template, it will be "magically" present. Otherwise, Template: will just behave as usual. The only problem might be naming collisions. But we'll find our way around this. Having said that, though, I wonder what the implications from caching and things like rebuilding the localisation cache would be.
I filed this report under "Extensions requests" only because it was the most sensible location that came to mind. I'm not trying to propose any technical solution. Maybe Rob Kam or someone wants to start a wiki page to list template candidates? Potential candidates: https://www.mediawiki.org/wiki/Template:@ https://www.mediawiki.org/wiki/Template:U A template providing configurable frames for banners like e.g. https://www.mediawiki.org/wiki/Template:Mbox but without having to import a bunch of subtemplates. I'm also linking this request to "Bug 50329 - We need a common repository for Scribunto modules and templates" since a good setup would consider both.
(In reply to comment #0) > Anyone setting up a MediaWiki wiki, wanting to use templates, has to > export/import them from another wiki (e.g. Wikipedia) or re-write and > maintain some similar ones. This can create a confusing mess. It would be very > useful to have a simpler way to install an up-to-date package of standard > templates. I'm not sure this bug is valid. If functionality is really needed on many wikis, it should be put in core or into a MediaWiki extension. We can easily create parser functions, magic words, etc. The two use-cases mentioned ([[mw:Template:@]] and [[mw:Template:U]]) are not compelling: they're borderline hacks that should be killed, not spread. Poor man's e-mail obfuscation hinders site usability and the user experience with almost no benefit. The "U" template was created this year and has about ten transclusions: it's hardly a critical template. Perhaps there are better use-cases you can find that would make for a more compelling case for this bug. Broadly, decentralization seems like a pretty bad idea. For images, we implemented InstantCommons, allowing one site to be a central repository of images, preventing needless and costly duplication. We did this in an abstract way, allowing sites to easily use Wikimedia Commons, but also set up or customize other central repositories to use. I don't see why we wouldn't do the same for global bits and pieces.
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=4547
For what is worth: I have no opinion about any of the two approaches (prepackaging / crosswiki transclusion). I just copied a feature request by Rob Kam at Possible Projects that made sense to record here.
Hi, this project is still listed at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Templates_for_new_MediaWiki_installs Should this project be still listed in that page? If not, please remove it. If it still makes sense, then it could be moved to the "Featured projects" section if it has community support and mentors.
This project still makes sense, but has yet to get community support and mentors.
A new GSoC round is starting: https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014 There is still no agreement on a plan for this project idea. Should we forget about it and focus all the attention on Bug 39610 - Scribunto should support global module invocations Bug 50329 - We need a common repository for Scribunto modules and templates ?
(In reply to comment #9) > This project still makes sense, but has yet to get community support and > mentors. I'm not sure what you want as far as community support, but I think if you talk to non-WMF users of MediaWiki, you'll find people like the idea. As far as mentors, I could probably help -- but I need to know what that actually involves.
As for how to do this, doesn't someone just need to bundle an XML export of the templates they want, and then import them into the wiki? (In reply to comment #5) > Broadly, decentralization seems like a pretty bad idea. For images, we > implemented InstantCommons, allowing one site to be a central repository of > images, preventing needless and costly duplication. We did this in an > abstract > way, allowing sites to easily use Wikimedia Commons, but also set up or > customize other central repositories to use. I don't see why we wouldn't do > the > same for global bits and pieces. +1 to this.
(In reply to comment #12) > As for how to do this, doesn't someone just need to bundle an XML export of > the templates they want, and then import them into the wiki? > > > (In reply to comment #5) > > Broadly, decentralization seems like a pretty bad idea. For images, we > > implemented InstantCommons, allowing one site to be a central repository of > > images, preventing needless and costly duplication. We did this in an > > abstract > > way, allowing sites to easily use Wikimedia Commons, but also set up or > > customize other central repositories to use. I don't see why we wouldn't do > > the > > same for global bits and pieces. > > +1 to this. For a less than guru Mediawiki non-WMF admin. When finding out that templates are an essential part of setting up a wiki. They have to figure out which wiki to use as a source and then which templates. When the XML gets imported into the destination wiki, they've also got red links to missing sub-templates, details that apply specifically to the source wiki, (e.g. the name and logo of that source wiki) and maybe other features like style sheets that still need fixing. Afterwards how do they keep the templates up to date with changes and bug fixes. Every time the install is upgraded the process needs repeating. Their ought to be a simpler and efficient way to do this. Installing and maintaining extensions is mostly a neat and simple process. A central repository for this sounds like a good idea. I don't know enough about Mediawiki to be able suggest a possible right way this could be gone about.
(In reply to comment #10) > A new GSoC round is starting: > > https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014 > > There is still no agreement on a plan for this project idea. Should we forget > about it and focus all the attention on > > Bug 39610 - Scribunto should support global module invocations > Bug 50329 - We need a common repository for Scribunto modules and templates > > ? With the move of templates over to LUA it would make sense to merge this into 50329.
(In reply to comment #11) > (In reply to comment #9) > > This project still makes sense, but has yet to get community support and > > mentors. > > I'm not sure what you want as far as community support, but I think if you > talk > to non-WMF users of MediaWiki, you'll find people like the idea. > > As far as mentors, I could probably help -- but I need to know what that > actually involves. Thank you Mark. It was with non-WMF users in mind that I made this suggestion. A first step would be to get this to be a Featured project at https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Featured_project_ideas Mediawiki is not yet included at https://code.google.com/p/google-summer-of-code/wiki/Mentors
From a MediaWiki project point of view, I'd rather close this proposal as WONTFIX and remove it from Possible Project, if only to mark the direction where we want to go: a centralized system similar to Commons for images. We don't have this solution yet, but any energies invested in this problem could be better put in the right direction. There doesn't seem to be much push for the solution proposed here. If you think all this is wrong, feel free to reopen and start working on a template bundle that the MediaWiki release managers are happy to accept. :)
oooops
See bug 50329 - We need a common repository for Scribunto modules and templates instead.
