Template talk:Extension/LQT Archive 1

Hello, Is there any complaints if we add to this a link to where the extension can be seen in action? --Rick 03:28, 25 September 2006 (UTC)


 * No - that sounds sensible. --HappyDog 11:59, 25 September 2006 (UTC)
 * ditto -- :Bdk: 16:01, 25 September 2006 (UTC)

Formatting is weird
Take a look at Extension:OpenID. What's going on? --wikitravel:User:Evan


 * I'm not sure what you mean - please elaborate. --HappyDog 19:16, 21 October 2006 (UTC)

Here is?
Why the change from "This is a MediaWiki Extension" to "Here is a MediaWiki Extension"? I think it sounds frivolous. I propose it is reverted. If anyone is against reverting it, please speak up... --Fernando Correia 10:24, 1 February 2007 (UTC)


 * I agree, I reverted it.--Patrick 10:29, 1 February 2007 (UTC)

Tools
I propose that a new type is added to the list: "tool". This could be used to indicate modules that provide additional functionality to a MediaWiki installation. Examples would be Extension:AddPageService and Extension:Word2MediaWikiPlus. --Fernando Correia 13:52, 20 February 2007 (UTC)


 * Perhaps it would be even better to have a separate namespace for them. After all, they are not really extensions. -- Duesentrieb ⇌ 23:46, 22 February 2007 (UTC)

That may be a good way. Although they "extend" MediaWiki core functionality, they are really not extensions in the sense that they are called by MediaWiki code. Actually the call MediaWiki. They are similar to pywikipediabot and to the "maintenance" directory scripts. Anyway, I think a clarification on this would be helpful, because some tools used to be classified as extensions on Meta, and at the same time classified as Category:MediaWiki tools. --Fernando Correia 11:11, 23 February 2007 (UTC)


 * The namespace was originally designed to hold all 3rd party extensions relating to MediaWiki (including tools that are worked on in the MediaWiki SVN tree, but which are not distributed as part of a standard MW install). Therefore tools should be included in the extensions namespace.  Only include tools that are specifically MediaWiki related, e.g. a Notepad style text editor that happens to be usable as an external MW editor (via user preferences) should perhaps be listed on a page of compatible editors, but it doesn't deserve its own page as a 'MediaWiki tool'.  Ditto stuff like apache or MySQL.


 * If we find that there are a sufficiently large number of MW-related tools that they warrant their own namespace then it might be worth creating one, but I suspect not. A better solution might be to use a different infobox for tools.  Or at the very least, it should be expressed in this box very clearly... --HappyDog 01:43, 22 March 2007 (UTC)

I'm glad you think they belong in the Extensions namespace. So, I propose that a new type is added to the list of extension types: "tool". --Fernando Correia 20:36, 22 March 2007 (UTC)

Categorise by author
I tried to get the template to categorise into Category:Extensions by "author" but couldn't get it to work. --Nad 21:38, 22 February 2007 (UTC)


 * Personally, I don't think this is very useful. I would suggest a better approach would be to create a new category called something like Extension authors, which authors can add to their user page, which should list all extensions they have authored.  Aside from satisfying the OCDers desire to categorise, I have yet to see a useful application of listing extensions by author... --HappyDog 01:43, 22 March 2007 (UTC)

Extension of multiple types
type = parser, hook, special puts it in "Category to catch extensions with an unrecognised type". It should be in all three extension categories. -- [[User:Skierpage|Skierpage 05:22, 17 March 2007 (UTC)


 * I added that combination. More combinations may have to be added. An alternative would have been to have a boolean parameter for each type.--Patrick 07:18, 17 March 2007 (UTC)


 * I guess the question is, why are we categorising and displaying this information? I would suggest it is so that people can find extensions, therefore 'special' is for extensions that are special pages (e.g. providing meta information), 'parser' is for extensions that add an extra piece of syntax.  If an extension is both, then it should be listed under it's main purpose.  E.g. a special page that uses a tag to gather its data (e.g. a special 'dump' page that provides a tarball of all pages that have the requested attribute in a &lt;dump&gt; tag) should be 'special'.  A tag that is supported by a special page (in the same way that the ISBN magic word works) should be 'parser'.  In cases where an extension is made up of all these different components, I feel that it should really be in a separate category, e.g. 'mixed'. --HappyDog 01:43, 22 March 2007 (UTC)


 * I'd rather have specific categories for each various extension type because it makes sorting/finding extensions easier and more intuitive. Special page extensions are not just extensions that are special pages but ones that manipulate/alter/edit/redisplay special pages, too. Multiple extension type support is badly needed in this template. It's too confusing to try and figure out which "mother" type extensions belong to, which is why I've been adding various categories for form, table, list, etc under category:extensions by category (nice redundant name, eh?). -Eep² 05:35, 29 July 2007 (UTC)

Extra info for template users
The template page could use some additional "noinclude" comments for extension users. In particular I am confused by some of the terms like hooks. Does this mean that the extension uses a hook or creates a hook? I assumed the former, but this and other items could use additional comments/instructions for newbies. --Sunergos 19:18, 22 April 2007 (UTC)


 * There is no 'hooks' parameter. 'hook' is one of the potential extension types, so if your extension creates a new parser tag then you should use this type. --HappyDog 22:59, 20 May 2007 (UTC)

Question about style object - css
Hi,

I'm interresting to use a similar extension into my wiki. I try to understand how it works but i don't understand where the class object are located (first line of your template: . I seen MediaWiki:Monobook.css but not found information about ext-infobox.

Thx, --Ouaibsky 13:48, 21 May 2007 (UTC)

extension by subcategory
I have created a duplicate template so that subcategorized extensions can reside within either category:extension or in their own category:subcategory, but not both. Bouncingmolar 01:07, 25 June 2007 (UTC)

Additional fields depends/suggests
Two additional fields could be added, one for extension dependancies (depends) and one for suggests which could be other extensions or third party code such as http://mootools.net or whatever --Zven 23:43, 25 June 2007 (UTC)

Extension Lang
I want to make Template:Extension/es in spanish

who agree?

--Hsilamot 00:27, 9 July 2007 (UTC)


 * I'm not sure how useful this would be. A Spanish version of the template would only be placed on Spanish versions of the extension page (e.g. Extension:MyExtension/es), and these pages will need to be translations of the English version to which they are connected.    Personally, I think attempting to translate the extension namespace is a bit of a lost cause, as it is written by the extension authors and changes so much that any translations will become out of date very quickly.  My recommendation would be that it is not worth creating this template unless there are a sufficient number of Spanish extension translations to make it worthwhile. --HappyDog 21:37, 11 July 2007 (UTC)

obsolete status
there are some extensions which may have become obsolete because of changes to mediawiki. should there be a special status for them? Extension:Email_notification - Bouncingmolar 02:29, 15 July 2007 (UTC)


 * Probably. I suggest 'obsolete' :-)  I will add that sometime soon and post here when it's done. --HappyDog 16:40, 24 July 2007 (UTC)


 * I have added it as historical, because retaining the pages is only for historical interest. I stole this idea from the enotif extension which the author used the template I have also added this template to the extension template conditionally for when the status is set to  historical. Bouncingmolar 23:26, 24 July 2007 (UTC)


 * 'obsolete' would probably be better, as that is what is used elsewhere on the site. The historical template was copied from meta in March because Extensions that had been copied here used it, but we should be working towards some kind of consistency here, I think.  That said, there may be a case for having both that I have not thought of... --HappyDog 23:48, 24 July 2007 (UTC)
 * ok i have changed historical to obsolete. I will just start tidying up a few loose ends Bouncingmolar 00:11, 25 July 2007 (UTC)


 * the template:obsolete doesn't seem to apply to extensions that have been replaced by better extension versions (see Extension:Open Office Export). I have left the template:historical for the moment Bouncingmolar 00:14, 25 July 2007 (UTC)


 * Hmmm... You're right. I guess we need to think about that.  Why extensions 'no good'?
 * Broken - don't work. These should have status 'experimental', I think.
 * Replaced by built-in functionality - obsolete from version X (but still useful for people using older versions)
 * Replaced by a different extension that offers the same (or more) functionality. Note that 'similar' is not a good enough reason, as some people may prefer extension 1, while others prefer extension 2.
 * I don't know if you can think of any more scenarios...
 * For that last one, I would suggest that instead of a new status, we should have a field 'replacedby' that allows you to specify an alternative extension as a replacement. The status may be 'beta status' but never finished because someone got there first.  We lose this info if we replace 'beta' with 'historical'.
 * --HappyDog 00:23, 25 July 2007 (UTC)
 * True re: historical/beta. hmmm  if only we could have more than one status. Bouncingmolar 00:40, 25 July 2007 (UTC)
 * This has since been reverted without any discussion by user:Voice of All Can someone please explain this? Bouncingmolar 05:42, 30 July 2007 (UTC)

field for extension stored externally
There are many extensions I have noticed that have their main content located on another site (eg bluecortex). Perhaps there should be a field such as "main site" which allows authors to put their content there, that way we can include in the template a warning message saying that more up to date info can be found on eg:bluecortex Bouncingmolar 00:48, 25 July 2007 (UTC) I would prefer if all the content was on mediawiki.org, but many authors are already avoiding that.. Bouncingmolar 00:49, 25 July 2007 (UTC)


 * Well, take a look at my WikiDB extension. That has most content held off-site, but still has a page here with the basic information and links to the detail.  I don't think there is any need to flag up 'off-site' extensions, except to note it on the extension page itself. --HappyDog 13:03, 25 July 2007 (UTC)


 * I agree. That method has worked very well for your extension, but I have viewed many extension pages which do not do as you have done. Perhaps adding a field with a similar meaning to offsite storage, then it could be included in the template and a standardised message (similar to the one on your page) could be put to tell people to visit the offsite link. At the moment I have been doing what you have done on your extension page, and pysically visiting the offsite extension and copying some of the info back here and adding a custom message to visit the offiste page for a more up to date version. I made this suggestion after seeing a need for it. Bouncingmolar 05:27, 30 July 2007 (UTC)

Add type: authentication
There's quite a few extensions that deal with authentication, can we add a type for these?

See Extension:Shibboleth Authentication for an example. Djcapelis 21:47, 23 July 2007 (UTC)


 * No - that's not what the type is for. We are in the process of working out a way to include the purpose(s) of an extension in the template, and once that's done then functional groupings (e.g. "authentication extensions") will be created automatically based on these new template parameter(s). --HappyDog 16:43, 24 July 2007 (UTC)


 * Okay, what is the type for? I've written  Extension:BOINC Authentication.  My next best guess is to use type 'interface'.  Is that correct?  --Eric Myers 12:25, 6 September 2007 (UTC)


 * My sense is that type identifies the technical method(s) of implementation - types are intended primarily as an aid to programmers who need help finding examples of extensions that use different kinds of entry points and programming techniques. Egfrank 07:27, 7 September 2007 (UTC)


 * So I changed the type to 'interface' and now the page seems to be categorized correctly by whatever system does that. I also explicitly added the category 'Authentication and Login', which seems to be the practice for most other auth extensions.  --Eric Myers 14:58, 7 September 2007 (UTC)


 * And I made similar changes to the Shibbolith page. --Eric Myers 15:45, 7 September 2007 (UTC)

Multiple authors
How to add multiple authors without the "author" parameter's auto link screwing up and combining multiple authors into a single author? -Eep² 02:08, 30 July 2007 (UTC)

hmmm. I've just been comma separating them and I have not been using the username field. I suppose that may cause problems for any future categories such as extension by author. Perhaps we need to add an author2 author3 field? Bouncingmolar 05:19, 30 July 2007 (UTC)


 * Yea. I tried doing something like that for extension type, but also transcluding (whatever) template:extensiontype into the switch function but it doesn't seem to work, so I undid it. Check it out if you can make it work right. -Eep² 08:53, 11 August 2007 (UTC)

Template page revision
I've added the ability to handle up to 6 types in any order and updated the documentation accordingly. In the course of this enhancement I've also made the following changes:


 * teased apart documentation and code: Documentation is now on a separate page: see Template:Extension/Doc. Hopefully this will make the code a bit easier to maintain as we go along.
 * This will also reduce the amount of material that has to be parsed when including a template and reduce the already small risk of a page with lots of transclusion being pushed over a pre-expand include limit.
 * '''added a "nocats" mode to the template so it can be included as an example on documentation pages without accidentally adding the host page to various categories.
 * fixed 3 bugs related to missing or empty attributes:
 * blank name fails to default to : now it does
 * blank types do not add extension to the unknown type category: they now do
 * blank download does not default to no link: now it does

I've run this through several tests - mostly involving alternate types and combinations of blank values. If I've missed some combos and you see a problem that isn't obvious to fix, please let me know. Egfrank 12:08, 8 September 2007 (UTC)