Template talk:Extension
 Archives |
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Broken in Safari | 2 | 17:12, 22 May 2013 |
| date | 0 | 21:38, 20 April 2013 |
| tnx!!! | 2 | 18:54, 14 April 2013 |
| Unmaintained status | 3 | 16:29, 13 February 2013 |
| Wrong usage of type = page action? | 0 | 19:20, 23 December 2012 |
| Forthcoming extensions | 0 | 02:08, 22 October 2012 |
| Want to use this template but don't know what to copy | 1 | 22:10, 12 June 2012 |
| Author/username field is broken | 0 | 20:27, 1 December 2011 |
| Add parameter to indicate whether DB update is needed post extension installation | 3 | 14:28, 11 November 2011 |
| issues | 1 | 01:36, 18 October 2011 |
| What is "nousage" for | 1 | 09:22, 17 October 2011 |
| Support for multiple authors | 0 | 08:52, 17 October 2011 |
| Missing link | 0 | 08:43, 17 October 2011 |
| User rights documentation | 2 | 08:42, 17 October 2011 |
| typo | 1 | 08:40, 17 October 2011 |
It is enabled by default for every account. It isn't intended as an option. It is provided as a gadget because there are no other means for loading user/site provided scripts from the wiki.
I suppose we could make it hidden and initiate the load from Common.js instead. However that will cost an extra http request instead of joining the main load queue for gadgets.
Doesn't seem worth the cost right now. Perhaps Gadgets can be given a feature that will hide the gadget but still make it load regularly.
Thanks for the link to wikiapiary! Very useful website!
Glad you like it Yury! I saw you just created an account. Thanks!
It's funny, because I was ready to edit the template text and add the link to wikiapiary myself :)
Mark added this status and started adding it to extensions which already had the relevant template.[1] This, in general, produces information loss: it's usually not the maintainer (except the most diligent ones) assessing the status, so it's not a valid assumption that an extension without a maintainer can't have valid status information. I think it may be acceptable on extensions whose page is very old/unwatched or which are unused, but this would mean considering them case by case.
I only used this on extensions that had the unmaintained template but were also marked stable. My intention is that extensions marked stable should be work with the LTS. We can't say that about extensions that are not maintained.
I think this status would be appropriate for other extensions that the maintainer has no intention of ensuring work against the LTS since it adds the extension to the Category:Not LTS ready.
That said, maybe a better status would be "Not LTS ready" so that it is clearer what the intention is.
I understood your purpose after writing my message because I saw [Wikitech-l] Extensions and LTS. However, I think you may be confusing different things, because for instance Niklas said Translate is not going to support the core LTS (1.19) till end of life, but this doesn't make it less stable nor less maintained. I'm not sure what "LTS ready" can exactly mean and I leave it to the devs to comment, but surely it should be another parameter, not "status"; simplest thing to do would be adding a template to the "mediawiki" field. Then if, say, Translate doesn't support LTS you can have it included in your category and a volunteer can pick it up and do... I've no idea what, maybe create a branch that supports LTS or whatever devs find suitable.
Another field actually seems like a good idea to capture this information.
Going through Category:Page action extensions I though it lists extensions adding page actions or modifying its normal behavior. But it doesn't seem to be true, being Extension:WikEd just one example: it just loads a JavaScript file that alters the page content on the client-side, it has nothing to do with page actions at all. But on the other hand, it doesn't seem to be a more proper categorization of that extension.
Should there be another extensions status "forthcoming"? E.g. what happens if someone submits the code to gerrit, writes the extension page so the reviewer can read how to use it, and then is waiting for review? In the meantime, the code hasn't been approved for the repository, but other people viewing the extension page might not know that. There also seem to be a few extension pages out there where someone put some partially-completed, non-working code, apparently with the intention of finishing it later. "Unstable" would be an understatement; "not working" or "not finished" would be more accurate.
On the one hand, adding that status might encourage people to post such half-completed work (which would not be a big deal if people had more of a tendency to come back and finish it). On the other hand, unless we're going to delete pages with non-working code, then we're keeping around pages with an inaccurate status. Perhaps the solution is to put a notice banner at the top stating that it's unfinished.
I would like to use a modified version of this extension template on my own wiki, but I don't know what templates are required to be copied. Any assistance would be appreciated!
Have you tried Special:Export? It has an option to "Include templates" which may be of some help.
See https://www.mediawiki.org/w/index.php?title=Extension%3ASoundManager2Button&action=historysubmit&diff=459466&oldid=459459 -- the author had to add another string to get the authorship to show up, even though the documentation says, "If omitted then the 'username' field will be used (if present)." Please fix either the documentation or the functionality.
<Wikinaut> yvipanda: does it need to run update.php after installation ? (this is not mentioned on http://www.mediawiki.org/wiki/Extension:ShortUrl ) <Reedy> Yes <Reedy> That's somewhat stndard practise <Wikinaut> Reedy, standard, yes/no, then please modify the Template:Extension info box, so that "php update.php" needed yes/no can be quickly indentified
Kthx.
Hi, having this parameter was a very good idea. However I suggest to remove the explanation "php update.php needed after installation" from display. I takes heaps of space. I think everyone may just click on the link which takes one directly to the documentation of the parameter and its implications. Cheers
Adding
1.15 to
|compatibility = 1.15
makes:
- the word "compatibility" not show up and
- check usage (experimental) appears outside of the template at the top of the page.
That's not how it works. It's supposed to accept a {{Extension Testing}} table. But the project died in 2009, and I don't think I've seen anyone use the field correctly since then. Since it causes breakage when used improperly, I'd prefer to kill the field, or at list stop mentioning it in the {{Extension}} documentation to discourage its use.
There is an optional parameter in the template for "nousage", which it appears is supposed to be set to "yes" or "no"; what is the purpose of it? It's not documented anywhere.
It would be nice if we added a couple of more username/author combos for extensions that have more than one, So we can define them separately instead of just just sticking them in the one author field.
in the section "Content Parameters"->Types->Interface->special, the external link to the SpecialPage.php is broken. i am not sure where should it link to.
User rights documentation
I've created Category:Extensions which add rights. Currently, additional user rights are not documented anywhere, and this can be very confusing (see e.g. Extension:AbuseFilter) because you have to look for a wiki where the right is available and check Special:ListGroupRights. Hopefully, all rights descriptions are in Mediawiki:Right-<rightname> messages, so I think that we could use the rights parameter to automatically list them with {{int:Right-<rightname>}}. To pass the list, we could either split the parameter in rights1, rights2 etc. or use the #titleparts "string parser & converter" (rights=name1/name2/name3 etc.); to add additional notes, I wonder if we should create a rightsnote1,2... or a single rightsnotes parameter.
Right away I found two extensions that were using the rights field incorrectly, so I fixed them. I also found Extension:Ajax though, which has None entered into the rights and parameters field. Should that be removed to prevent the incorrect appearance of the extension adding user rights when it really doesn't?
Rights descriptions may not fit into the infobox well. "Perform captcha triggering actions without having to go through the captcha", which appears to be the longest extension-based right description on this wiki, spans two lines when I stick into the existing rights field. If there are several rights, or the descriptions are particularly long, that may get unwieldy. Also, getting the rights descriptions from messages is not something that will work in a lot of cases, because only a small amount of the extensions listed here are actually installed on MediaWiki.org. Perhaps it's best to just discuss the added rights in the extension documentation, as people are already being encouraged to do.
To avoid at least a part of the duplicated work, we could create a template which creates a table with names, description and notes, where the description is taken directly from system messages if you say the template to do so (when the extension is installed here). What do you think?
In russian version of the template the word 'status' is spelt 'statut', it should be either correctly spelt in english or yet better it should be translated into russian ('статус').
So nobody with the rights is interested in changing this? Beta M 15:43, 4 February 2010 (UTC)
