Category talk:Extensions/Archive 2007 to 2013

Where to discuss extensions?
If I would like to ask the community if, a kind of functionality exists in an extension, where would be the right place to ask? And if the answer is that the functionality does not currently exist, where would I request that the developer community consider creating it? Would this page be the right venue, or is there an existing forum? Thanks! — Epastore 18:16, 27 January 2007 (UTC)


 * There is currently no central place - to find an existing extension Google is probably still your best bet. Category:Extensions and meta:Category:MediaWiki extensions are good places to look if you want browsable indexes that may not be terribly complete, and you may want to look into the other sources of communication as well.
 * Regarding 'extension requests' - there is no formal process for making requests, and to be honest any such requests are likely to be ignored, as the volunteer developers will work on the extensions they want to write, not what someone else is asking for. You basically have three options:
 * Log it on bugzilla, though this (as I say) is likely to be ignored unless it is seen as 'very desirable' for Wikipedia or its sister projects.
 * Chat to a developer on IRC or some other forum and persuade them that your idea is really good and worth them spending their time over.
 * Pay someone to write the extension for you.
 * Hope that helps... --HappyDog 00:53, 7 February 2007 (UTC)


 * Maybe, but even if such requests were ignored by most developers, it still might be a good idea to have a page with wanted extension functionality. Sometimes people out there just think it is easy to accomplish and have fun writing such an extension. --GunterS 12:49, 12 March 2007 (UTC)


 * True, so long as it is clear that such requests may not get any response. --HappyDog 12:50, 2 April 2007 (UTC)


 * I was wondering where we could discuss extensions too.  has a forum which looks to be well used.  --Frantik 08:52, 26 August 2007 (UTC)


 * Project:Extension requests, the specific extension's talk page, Project:Support desk, etc. —Eep² 23:00, 26 August 2007 (UTC)

Recent reversion
Hi, I reverted this edit by Patrick, as this is not the right place to include such a link. It probably needs it's own page in the Extension namespace, but I haven't checked the link in detail so perhaps there is somewhere else it should go as well/instead. --HappyDog 13:43, 12 February 2007 (UTC)

Calender Extensions
Maybe all the Calender Extensions could be consolidated under a single link?--Rovo 01:21, 21 February 2007 (UTC)

This is a wiki. You can create a new category "Calendar Extensions" as a subcategory for Extensions and put all calender extensions in that. And yes, it would be helpful. --GunterS 12:44, 12 March 2007 (UTC)

Where to put a new extension?
Hi. Where can I submit a new extension I made? actually, more than an extension, I changed some code on the Wiki -thx, Chris


 * Create a page in the Extension: namespace. For example if your extension was called MyExtension then you would create a page at Extension:MyExtension.  The easiest way is to go to Template:Extension and use the box at the bottom of the page. --HappyDog 14:56, 22 April 2007 (UTC)

Extension categorization
I have manually sub categorized the extensions, and put them under category:extensions by category. Would anyone agree with removing category extension and keep only the extension subcategory. It would be easy to sub categorize the extensions that way, because the extensions with sub categories would no longer be in the extension category. Bouncingmolar 23:28, 24 June 2007 (UTC)
 * although I just realised it would be difficult to remove the extension category once a subcategory has been assigned, since the category:extension is embedded into the extension template - Bouncingmolar 23:40, 24 June 2007 (UTC)
 * What I might do is create a duplicate extension template which doesn't include the category:extension for use with sub categorized extensions. that way it could be easily reversed by readding category:extension to the duplicate template Bouncingmolar 01:05, 25 June 2007 (UTC)

Sub categorization discussion
Please explain the rationale for changing a large number of extension pages to use a template which, so far as I can see, provides no additional benefit. Examples of this are, , and. robchurch | talk 14:27, 27 June 2007 (UTC)


 * Hi robchurch. Yes I have made a template called extension categorized which is a duplicate of the extension template. The only difference is that it does not contain the category:extension.
 * The rational behind this move is that I have been going through every single extension manually and sub categorizing them and placing them within the subcategory category:extensions by category. I created a duplicate template because it is easy to revert if my work is disputed with the trade off of having an identical duplicate template. However I hope that you can see that I am slowly making progress. Why remove the you may ask? Well the main reason is that it is extremely difficult to sub categorize the extensions because it is hard to tell which ones are already sub categorized. This way the sub categorized ones are nolonger within this category and the uncategorized ones are retained in the extension category. I was using the category convention used in wikipedia. I just assumed it applied to mediawiki as well.
 * "Articles should not usually be in both a category and its subcategory. For example Golden Gate Bridge is in Category:Suspension bridges, so it should not also be in Category:Bridges."
 * I realise this rule doesn't apply to everything so if you think I should revert them all once i've finished sub categorizing everything let me know... however sub categorizing is proving to be a very slow process.
 * -Bouncingmolar 14:48, 27 June 2007 (UTC)

In that case, please make the change to the template in use. We do not wish to encourage forking of templates with an identical purpose, as it doubles the maintenance overhead. I would suggest making a complete list of all pages which need to be processed prior to removing the categorisation from the template, and then updating these. robchurch | talk 14:57, 27 June 2007 (UTC)
 * I see what you are saying Rob; that we don't need identical templates because if a new version of the template is made we have to update both. However the templates are not identical (even if it is only a minor difference). The Main purpose of the alternative template is that it has the removed. The problem with  modifying the original template:extension is that the category:extension information is stored there!(as i mentioned on the category:extension talk page.) :If i remove the extension category from the template then un categorized extensions will not be listed in the main extension category nor the extension subcategories. Which is a problem! So what the modified template does is it allows me to retain the original template structure without removing the category from all of the uncategorized extensions. I hope that makes sense.
 * Bouncingmolar 15:06, 27 June 2007 (UTC)

No, the categorisation difference is trivial. As I suggested above, use a list to store current categorisations and update the pages with them, or keep a list of extension pages which have been updated.

The current behaviour, introducing a useless extra template that will need to be changed back later is disruptive and redundant. You also provided no justification in the form of edit summaries, which is considered courteous in the least. robchurch | talk 15:13, 27 June 2007 (UTC)


 * Ok... making a list in either form as you suggest is easy to say but to do is another story. To illustrate my point I have already today sub categorized approximately 200 extensions. That requires loading each extension page and editing it (as well as reading most of them to understand what category they belong). It has taken me several hours to get this far and I am not even close to completing 1/4 of the extensions listed under the extension category. Unless you have an automated way of doing this I can't see an easier way to do it. Furthermore this is only todays progress. I created the category: extension by sub category and extension by author and some of the extension sub categories which I moved hundreds of extensions into prior to today.
 * I'm sorry that you think that my efforts to sub categorize the extensions is disruptive. but in my opinion it will make it easier for everyone to find the extension with the features they want, which is a huge improvement from sifting through every single extension, many oddly named. On a side note, because I think that the edit summaries is an entirely different and minor issue, I apologize for a lack of edit summaries. Unfortunately I gave up after the first few extensions, but if you have a tool I can use let me know! i'm all ears! Bouncingmolar 15:38, 27 June 2007 (UTC)
 * I just realised. this may be the list you are after? Special:Whatlinkshere/Template:Extension_categorized Bouncingmolar 15:42, 27 June 2007 (UTC)
 * OK I've figured out where sub categories can be added to the type field in the template:extension but I still have the problem that I can't tell which extensions are already sub categorized. I'm not going to make a list unless there is a way to tell which extensions are uncategorized. Currently if someone added a new extension I wouldn't know. I suggest removing the template that I have created after I have been able to sub categorize everything. Then we can as you have suggested modify the original template to include the sub categories under the 'type' field. But at the moment making a template which will have to be removed later is the easiest way i can think of doing it. Maybe a little help would not go astray. Bouncingmolar 16:13, 27 June 2007 (UTC)

Bouncingmolar: The forked template will not be kept. It is unnecessary to fork in this manner - instead a new field should be added to the existing template. All your edits that involve a switch to this new template will need switching back, and adapting to use the new field in the main template. See below for further discussion. I will look at the template and try and fix it to help you figure out what has and hasn't been categorised, but we need to agree to the structure I suggest below (with whatever modifications we choose to make) before I do that. You can hold of making the switch back until Template:Extension is updated though. --HappyDog 17:04, 27 June 2007 (UTC)


 * Happydog: yes I totally agree that removing the template... infact I think i've already said that in the last sentence I wrote. What i also said though was that this is an intermediate step. Since I am currently the only (or was the only) person sub categorizing them I had to do this as an intermediate step. I am perfectly happy to edit all of the template:extension categorized extensions after I have sub categorized them all. more discussion in the discussion below.... Bouncingmolar 10:43, 28 June 2007 (UTC)

How should extensions be categorised?
Here is how I think the extensions should be categorised. The top-level Category:Extensions just contains the sub-cats listed here. Each of the sub-categories (except 'All extensions') also contains only further sub-categories. Any pages in the categories themselves are awaiting classification. This will all be achieved automatically by Template:Extension, once we have agreed the structure.


 * Category:Extensions
 * Category:All extensions (all extensions go in here)
 * Category:Extensions by function/Category:Extensions by purpose (filled in from a new "function" or "purpose" field, whichever makes the most sense - however not "category", as that is just confusing.)
 * Category:Extensions by status (filled in from 'status')
 * Category:Extensions by type (filled in from 'type')
 * Category:Extensions by author (filled in from 'author')

Personally, I don't see any need for the 'by author' category. To me this appears to be categorisation for the sake of it. It might be more useful to have an 'extension authors' category that links to user pages of extension authors. Anyway - if people see a need for this, it is fairly easy to add from the template. Bear in mind that having a 'by author' category will require a lot of empty category pages to be created (in mulitple languages?), often holding just one item...

The above categories can all be filled in automatically from the existing template, with a few minor tweaks. The newly forked template should be deleted and all changes reverted/incorporated into the existing template.

Thoughts about this before any changes are made?

--HappyDog 17:04, 27 June 2007 (UTC)


 * Very good idea HappyDog, I like it. :-)


 * However, I'd like if you'd drop the Category:Extensions by author - I think it's the best if it will be added manually. Sometimes the author is unknown, or has written only one extension, so we'd end up with dozens of almost-empty categories this way...thoughts? -- Sayuri 17:11, 27 June 2007 (UTC)


 * Well - I don't think we need it at all (whether filled automatically or not). If someone could give an example of why it might be useful (rather than just encouraging authors to list their extensions on their user page) then please say so, otherwise I suggest we omit it entirely. --HappyDog 17:18, 27 June 2007 (UTC)


 * I agree - it can be kept as a parameter on the template, no need for those categories. -- Sayuri 17:42, 27 June 2007 (UTC)
 * Look just to keep the sub category extension by author in context. I didn't actually make the sub category and pull up a bunch of extensions and extract the author information. What actually happened when I was trying to sub categorize everything a few extension authors had made a sub category after their name. These categories were listed directly under the extension category. I also thought they were pointless but I also did not want to anger the authors of the extensions so I retained their categories but moved them under the category:extensions by Author. Go to that category and you will see author categories which I have absolutely nothing to do with creating! If you have a problem with authors creating their own categories then perhaps you should tell them. I was just trying to move them out of the extension category to reduce the clutter to make my sub categorizing easier for my self. In my opinion which you may think does not count for much, I say let them have their small kilobyte of glory, but lets just move it out of the way. Bouncingmolar 10:47, 28 June 2007 (UTC)
 * by the way I like the proposed extension tree you have created happydog. If you guys make a protocol that you can follow yourself... (ie not just me slogging it out by myself) then I would be happy to help subcategorize everything Bouncingmolar 10:53, 28 June 2007 (UTC)
 * Hi Bouncingmolar. The point about authors was in no way directed at you.  Most author categories exist because the extension pages that were imported from meta included the cat tag and it was never removed here, so given that they were red-linked it is unsurprising that the categories were subsequently created here, and it was helpful of you to organise them in the way you have.  However it seems the general view so far (and one I very much agree with) is that the author cats should be removed entirely.  Once we have agreed the structure (I'd give it a few more days at least, to see if there are any more comments) then I will make the necessary changes to the template and the top-level cats, as well as moving any existing cats to the right place.  I will probably leave the creation of new categories to other people though.  Before that happens, you will need to switch all your changes back to using the standard template, as I will delete that when I make the changes.
 * Re: Purpose/function/whatever - This category will hold sub-cats listing extensions by their pupose/functionality. E.g. 'calendar extensions', 'youtube extensions', 'authentication extensions', etc.  We need to decide (a) what to call this parameter (I think neither 'purpose' nor 'function' are ideal), and (b) how it should be implemented.  Ideally it will simply be a new line "|purpose=calendar" or similar, which will display "Purpose: Calendar" in the infobox and add the extension to Category:Calendar extensions.  However this will only work if extensions belong only to one 'purpose' category.  Are there situations where this is not the case?  If so some other method is needed.  (Bouncingmolar: you may want to wait until this is decided before 'switching back' your pages, as you could then do both (change back, plus add the new field) in one go.) --HappyDog 12:02, 29 June 2007 (UTC)
 * What about "type" or "category" (or even cat1, cat2) . Bouncingmolar 07:22, 1 July 2007 (UTC)
 * ah... you said not 'category' . is 'subcategory' better?
 * Yes I've put any changes I was going to make on hold. Google calendar is one example of an extension that would go under category:calendar extensions And category:google extensions(i suppose google extensions isn't really a purpose category) There are probably better examples than that,(1st one that popped into my head). Would having one main sub category in the template be ok? and then list the additional subcategories at the bottom of the page? or will that get messy? Bouncingmolar 07:22, 1 July 2007 (UTC)


 * I have done the status categories, and moved the extensions from the top-level to 'Category:All extensions', which should tidy things a bit, and make the tree-style navigation of the categories a bit easier. I have run out of time now, but I will do the type field next.  We haven't yet properly decided how to handle the function/purpose field (primarily, what name to use, and how to handle situations where extensions need to be in more than one cat) so I haven't done that yet.  Bouncingmolar - I know this is moving a little slower than you would like, but please be patient.  There is no point doing all your hard and valuable work in updating the extension pages if you end up having to change it all again once the template is finished.  If you want to do something useful right now, then see if you are able to sort out the extensions without status in Category:Extensions with invalid or missing status (though I don't know how easy that will be...). --HappyDog 13:41, 13 July 2007 (UTC)
 * I have been looking at the pages with missing status. Is it possible to have a robot which makes the status unknown if there is an existing empty status on the extension page? Bouncingmolar 06:48, 14 July 2007 (UTC)
 * There would be no point in that. If there is no value to separate out items where the status is 'unknown' from where the status is missing, then I will alter the template so only invalid values end up in this category (with blank values being equivalent to 'unknown'.  I did it like this so that the data could be fixed up, but if this turns out to be too difficult for anyone other than the extension author to do then it might be worth making the above change. --HappyDog 18:16, 14 July 2007 (UTC)
 * I'm not sure how it can be fixed without manually testing each extension to see if they work, so maybe it is something the author needs to do? or people who have tested the extension to see if they work. I doubt people who try the extensions will fix the page, but there is always that. I suppose in the end it doesn't effect the overall sub categorization progress, so it doesn't matter too much to leave it the way it is. Bouncingmolar 00:21, 15 July 2007 (UTC)


 * If the status is blank. doesn't that mean that we don't know the status and so it is unknown? Is there a situation where an authors would make an extensions and then purposely say that the status is unknown?
 * Happydog, There is no value in separating a blank status from unknown, because the template says: by default the value is unknown, therefore a blank status = an unknown status. Invalid statuses' should be statuses entered incorrectly (typos or a new status not included in the template) Bouncingmolar 14:04, 17 July 2007 (UTC)
 * OK - done. May take a while for the changes to filter through... --HappyDog 18:00, 17 July 2007 (UTC)


 * Have done type now. There is more work to be done at Category:Extensions with invalid or missing type too.  Also, any extensions still listed in Category:Extensions have a manual link to that category, which should be removed. --HappyDog 14:03, 13 July 2007 (UTC)
 * Cool good work! And thanks for directing my efforts to something useful, I shall start extensions without status. I'll let you know if I have any problems- Bouncingmolar 04:27, 14 July 2007 (UTC)

Proposed format for hypothetical "function/purpose field" in Template:extension
The things we need to consider are:
 * 1) What is the name of the field?
 * 2) What happens when there is more than one subcategory
 * Bouncingmolar 04:46, 14 July 2007 (UTC)

Name Suggestions

 * 1) How about Subcategory, I think it is sufficiently different from category to avoid confusion with mediawiki categorys?
 * Bouncingmolar 04:46, 14 July 2007 (UTC)
 * 1) I'm currently leaning towards subject.  That is sufficiently vague to allow "subject=calendar" and "subject=google", which is otherwise difficult if you use something like "purpose" or "function".  Category/sub-category is bad because you can have a "Category:Extensions by category" without it just being confusing. --HappyDog 18:21, 14 July 2007 (UTC)
 * Ok that seems to make sense. Would renaming "category:extensions by category" to "category:extensions by subcategory" work? I suppose we are trying to find a way of naming extension subcategories without using the word category. Perhaps you would prefer "category:extensions by subject". Which I'm not opposed to. My only criticism is that subject may not be the most obvious replacement for subcategory. but then again, most people should be able to figure out that subject will show subcategories of extensions. My alternative suggestion would be "extension by type" but that is already used for the extension method so unless we change the name of that as well that is not a good idea either.Bouncingmolar 00:35, 15 July 2007 (UTC)
 * 1) type
 * I just noticed that under the "type" field in the extension template, "category:user interface extensions is listed. Either this is in the incorrect location, or perhaps the subcategories we have been discussing should be listed under type ; type 1 ; type 2 etc. Bouncingmolar 00:56, 25 July 2007 (UTC)
 * Oh i just read your comment on the extension template page. I then conclude that ui extensions is in the wrong place. lets stick to "subject" Bouncingmolar 01:08, 25 July 2007 (UTC)

Seems to me like "type" and "subject" are too vague as well. Why not stick with more specific categories in the root or, at least, less vague/general ones? If "type" refers to data type, then the category should be renamed to "Extensions by data type". However, I think there should be "Extensions by function" and/or "Extensions by component" category names. A few days ago I started a root Category:MediaWiki components and have started several generalized categories for various parts/components of MediaWiki, as well as extension categories for them, in the past few days, which I think helps lessen the confusion when trying to find an extension. This type of classification can apply to variables and functions too, so remaining consistent when naming/creating categories helps in creating an easy-to-use navigation system. -Eep² 03:57, 1 August 2007 (UTC)
 * I suggest focussing on the name for the subcategory under the extensions category ie. currently called extensions by category We should focus on finding a new name for this first. Placing categories within the root is an entirely different subject that maybe we can work out later? I see no reason for starting a new category called mediawiki components as both these will be replaced by changes made to the template. See how the extensions will be automatically categorized by changes to template:extension. I will discuss with you on your talk page some ideas.Bouncingmolar 07:16, 1 August 2007 (UTC)

Multiple Subcategory suggestions

 * 1) Have a single subcategory within the template, but ad extra subcategories manually to the page?
 * 2) Is it possible to have multiple empty fields within the template for extra subcategories? or does that create problems with filtering extensions without subcategories?
 * Bouncingmolar 04:46, 14 July 2007 (UTC)
 * Current thoughts - We have a 'subject' field and an optional 'subject2' & 'subject3' fields. The template uses as many of these as are present.  If we find we need more, then subject4,5,6 etc. can be added.  At the moment I can't think of a better method than this, but there may be someone else who can. --HappyDog 18:21, 14 July 2007 (UTC)
 * Agreed. I have found that I have categorized some of the extensions to use 3 subcategories for some extensions, so that should be fine. Bouncingmolar 12:55, 16 July 2007 (UTC)
 * 1) Is it possible to have a single field which allows multiple entries perhaps seperated by an ampersand?( eg: |type = category1; category2; category3 ) - Bouncingmolar 11:59, 22 July 2007 (UTC)

extensions that haven't used the template
Hi happydog or sayuri, is there a way to make a dynamic list of extensions that haven't used the template? Bouncingmolar 05:43, 14 July 2007 (UTC)
 * i think it would be useful for finding extensions which have masked the absence of a template by adding the required categories manually Bouncingmolar 06:50, 14 July 2007 (UTC)


 * Not without a dedicated bot, I don't think. Perhaps you could somehow compare Special:Whatlinkshere/Template:Extension with Special:Allpages (extension namespace)? --HappyDog 18:25, 14 July 2007 (UTC)


 * is there a tool that can be used to do the comparing? Bouncingmolar 00:13, 15 July 2007 (UTC)

The physical subcategorization process
I have been thinking about the practicality of the process required. The biggest obstical to assigning categories to uncategorized extensions is being able to tell which extensions have no category. i.e knowing the uncategorized extensions makes an easy shortlist for subcategory addition. So if we are going to use the template modification mentioned by happydog there needs to be a way to separate categorized from non categorized. Otherwise there is always the temporary duplicate template idea which can be deleted again after subcategorization. Bouncingmolar 08:34, 29 June 2007 (UTC)


 * This will be handled by my changes to the extension template. Extensions with no category will 'drop through' to a suitable category which is just for this purpose. The templating system here is pretty advanced - there is NEVER any need for duplicate templates!  --HappyDog 12:05, 29 June 2007 (UTC)
 * Awesome sounds good! Bouncingmolar 13:09, 29 June 2007 (UTC)
 * When shall I start reverting the extensions with the temporary template? Bouncingmolar 13:11, 29 June 2007 (UTC)
 * Will we also be able to tell these apart from the extensions that have not used the template at all?

There has been no progress since we began this conversation so I have begun the intermediate step again of sub categorizing all of the extensions using a template which i will single handedly revert later. Until someone can make the template and satisfy the requirements: being able to tell what still needs to be sub categorized. then I am still happy to get rid of my template but only after I have sub categorized them all. and since I seem to be the only one categorizing the extensions, please give some constructive criticism if you are not going to help. Thanks Bouncingmolar 12:06, 10 July 2007 (UTC)

In response to a message left on my talk page
 * Okay, just stop it. If you want to categorize extensions, fine. Just don't use that forked template, template:extension categorized. It was never meant to be used. Use template:extension instead. Thanks. -- Sayuri 08:07, 11 July 2007 (UTC)
 * please read my response below. you may need to help modify the template:extension to address the obstacles to categorization listed below. I do not know how to manipulate the template to meet those requirements. Cheers Bouncingmolar 08:11, 13 July 2007 (UTC)

Bouncingmolars Categorization strategy
Before anyone else criticises my efforts to sub categorize the extensions please read this. Please read the Bouncingmolars four steps of categorization and please read obstacles that need to be addressed by alternative methods of categorization. If you read those and provide a logical and feasible alternative to my plan then I will be incredibly happy to follow your suggestion.

Bouncingmolars four steps of Categorization

 * 1) Manually visit, every single extension page and place an appropriate sub category
 * 2) place completed sub categorized extensions into a temporary forked template called template:extension categorized please don't stop reading here you have to read all four steps to understand my logic
 * 3) Once all extensions have been sub categorized there will now be no extensions within the category:extension list except for uncategorised extensions; I can then go through every single extension manually and remove all occurrences of my intermediate fork and ultimately delete the template:extensions categorized template.
 * 4) all existing extensions are categorized.

Obstacles that need to be addressed by alternative methods of categorization
If you think that categorization should be done differently please consider all four of the following obstacles I have faced and offer a solution, otherwise categorization of extensions is virtually impossible.
 * 1) There is no way to tell what has already been categorized. (my steps move sub categorized extensions out of the extension category and into the subcategory, meaning that anything left in the extension category is uncategorised)
 * 2) How do you tell which extensions are new. (new extensions using my method, are found within the extension category, anything in the extension category does not have a subcategory therefore needs to be sub categorized. if all extensions are there, how can you tell which one is the uncategorised one?
 * 3) Some extensions have not used any template at all and so making changes to the current template does not pull these extensions into any hypothetical extensions to be categorized category.
 * Is there a way to create a dynamic list of extensions that don't have templates? or is it already done!?

Current Criticisms that Bouncingmolar agrees with

 * 1) Happydog: "The forked template will not be kept. It is unnecessary to fork in this manner"
 * agreed. the forked template at the end of the day is useless and should be deleted which is my final goal
 * 1) Happydog: "This will be handled by my changes to the extension template. Extensions with no category will 'drop through' to a suitable category which is just for this purpose"
 * yay bring it on!... unfortunately i don't know how to do that myself. I already have alot of templates to manually revert and i havn't heard any response for a couple of weeks of abstinence so what is a few more extensions to revert later.... i'm going to be the only one doing it anyway...

please don't kill me
before I finish defending myself, I'd just like to say that I in no way want to vandalize mediawiki, and I feel that my intentions are good. I don't know how to make extensions, but I am willing to waste many days of my life for this cause. So if you have criticisms please help me channel this energy or I might just walk away leaving it half done. my ultimate goal is to have subcategories for the extensions so that they are easy to find. and easy to add new extensions. Happydogs idea of modifying the template sounds like the ultimate goal, but unless someone can show me how to do some tricky stuff with it like having an automatic category for uncategorised extensions and a category for extensions without templates, I have no idea how to do it. Bouncingmolar 06:37, 13 July 2007 (UTC)

criticisms of Bouncingmolars logic with a better solution
If your idea is to help me categorize jump on board it gets awful lonely reading through all these extensions.

Bouncing Molars Todo list

 * 1) remove manual category:extensions from remaining extensions in category:extensions
 * 2) *partially complete, still extensions with no templates within category:extensions
 * 3) sort out the extensions without status in Category:Extensions with invalid or missing status
 * 4) * awaiting reply regarding having an autobot replace empty status with unknown.
 * 5) sort out Category:Extensions with invalid or missing type too
 * 6) * oof! i'm putting that one in the too hard basket. I don't have enough knowledge to be able to determine the type when reading the extension pages.
 * 7) revert changes made to extensions containing template:extensions categorized
 * cool some robot fixed it for me... it even saved my subcategory changes woohoo Bouncingmolar 05:37, 14 July 2007 (UTC)
 * 1) research info to add to pages within category:Extension page to be updated

Add Wikimedia tool
Hiya, can you add to the page a link to Daniel's tool for building the extensions into packages ( @ http://tools.wikimedia.de/~daniel/repository/extensions/ ) --Stinkfly 16:43, 2 July 2007 (UTC)

Where to request extensions?
Is there a good place to request extensions? I have ideas from time to time but may not have the time or the skills to bring them to fruition.

One idea I had was for a "What Redirects Here" extension. At the bottom of the Edit page, there would be a list of pages which #REDIRECT to the current page, with a text field at the bottom of the list to automatically create a new redirect to the current page. This would save me a lot of time trying to figure out what pages were lacking adequate inbound redirects. -- Jonathan Kovaciny 21:18, 3 July 2007 (UTC)
 * You may ask them on BugZilla. I have limited skills too, so I may ask me for help as well. Huji 16:18, 10 July 2007 (UTC)
 * You can try Extension_Requests - Bouncingmolar 00:49, 15 July 2007 (UTC)

New authors code is now in the template!
I have made some modifications to the template to handle authors better. Previously there was a free-text author string, which some people added their name, some a link to their user page, some a combination of both. Now I have made this into two fields. You may omit either field, or both.
 * 1) author - A free text field that may contain anything you like, which is up to the extension's author (and for unmodified pages this will work exactly as before).
 * 2) username - This must either contain the username of the author at MediaWiki.org, or be blank/omitted.  If filled in, then the template will automatically create links to the author's user/talk pages.

So, here are some tasks that need doing (1 & 2 should be done together):
 * 1) Visit all pages that are in Category:Extensions by Author and its sub-pages, and remove the categorisation.  These categories will be deleted shortly, as per the consensus above.  If we decide at a later date that we want to group extensions by author, it will be easy to add this back in via the template, so the information is not 'lost', just the categories removed. (Note - don't remove the sub-categorisation from the categories themselves, as I'll need that hierarchy to exist so I can find them to delete them!)
 * I've done all except for the extensions under Category:Extensions_by_User:jldupont and Category:Extensions_by_User:Nad. I have asked Robchurch to use his RobBot to do the rest.Bouncingmolar 13:04, 22 July 2007 (UTC)
 * ah never mind i did it manually, I think robBot might have been too busy for such menial tasks. Bouncingmolar 23:41, 24 July 2007 (UTC)
 * Fantastic - thank you! --HappyDog 23:50, 24 July 2007 (UTC)
 * 1) Whilst at those pages, adjust the templates to use the new format, based on the info provided by the previous categorisation.  E.g. if you found an extension that was in the category "Extensions by lubito" you would add that info to the infobox (as either author/username, as appropriate).
 * the username field does not handle interwiki userpages - Bouncingmolar 12:31, 22 July 2007 (UTC)
 * True. That's probably a good thing.  In general we want to encourage authors to create a user page here so that they are contactable through the wiki (in theory at least).  Links to other pages can still be added manually via the author property. --HappyDog 23:50, 24 July 2007 (UTC)
 * 1) The final task is the much harder job of fixing up the remaining extensions.  Not a priority, as the old parameter values still work - perhaps it would be better left for the individual authors to deal with.  If it would be helpful, I could make a temporary category of 'extensions with no username field'.

Good luck to any brave soul that wishes to attempt all or some of the above, and many thanks for your efforts! --HappyDog 20:44, 16 July 2007 (UTC)

Subcategorization issues reflect problems with Category.php?
I don't like the fact that you can't see the list of all extensions in the Articles list on this page anymore. But if I understand things correctly, this is partly due to the fact that MW will not show subcategories correctly if there are too many articles see bug 1211 - that's what I wrote the cryptically named Extension:SplitCategoryPage to solve (it's "split" in the sense that it splits the subcategory query out from the articles query. SplitCategoryPage is probably not a solution, however, as it is significantly slower than CategoryPage.php. --JimHu 16:15, 23 July 2007 (UTC)


 * They are all at Category:All extensions now, instead.


 * I see what you mean. under the new page Category:All extensions not all extensions can fit on one page. I think that once we have subcategorized the extensions by function/purpose, then it will be easier to find what you are looking for. This will sufficiently break down the category list so that all extentions of the category you want to look at will be short enough to fit one page. Bouncingmolar 00:56, 24 July 2007 (UTC)


 * That was always the case - there were more than 200 extensions before we changed the category. The 'All extensions' category is useful for paging through an alphabetical list (though Extension:Matrix is probably more useful for this).  The various categories of extension (by status/by type/by purpose/whatever) help people locate extensions when they know what they are looking for.   Ultimately, if category intersections ever get implemented then you will additionally be able to do things like 'Show me all stable calendar extensions'.  But that's a long way off and doesn't really affect things now. :) --HappyDog 16:37, 24 July 2007 (UTC)
 * Ah, I just reread the bug request bug 1211 The problem mentioned, is that if the list of pages within a category exceed one page, the listed subcategories also spill to the second page. I actually found that annoying too, but perhaps that is discussion best left for bugzilla, rather than here. Bouncingmolar 01:03, 25 July 2007 (UTC)

Category:Extensions by category too vague and redundant
It's almost as badly named as "Category: Categories by category". I think it should be renamed to Category:Extensions by function or Category:Extensions by component. -Eep² 10:47, 31 July 2007 (UTC)
 * Exactly you are %100 correct. read above (Category talk:Extensions)for further discussion about this issue it has been discussed above. Input is greatly needed on this topic in the aforementioned section.Bouncingmolar 02:20, 1 August 2007 (UTC)

Categorizing the extensions
(Moved from User talk:Eep)

Hi eep. It is a huge relief to find someone else who is as committed to categorizing the extensions as I am. I agree that it is vital to improve the accessibility for extensions people will actually find useful. I suggest we coordinate our efforts rather than both slogging out our guts to attack the same problem in different ways. I have been trying to get this moving for a while now, and it seems that we currently agree with happydogs idea: That we should make changes to the template:extension to automate the categorization according to template field entries. This is the order of how I think we need to approach this to best coordinate our efforts: Unfortunately I have found that this has been very slow going. i suspect this is because we have no unanimous name proposal for the field. As you can see we have only come up with: category, subcategory, subject, function. I look forward to working with you on this mammoth project.Bouncingmolar 07:28, 1 August 2007 (UTC)
 * 1) We need to agree on the name for the field within the template.
 * 2) Once agreed, either happydog, or with help we will add the code to the template:extension
 * 3) we then need to visit every extension and figure out what category each will fit under and place it in the template fields at the top of each page.
 * 4) the template will handle the rest (placing them in categories/ making an automatic category for uncategorised extensions etc)
 * I should probably mention the reason why using the template is the preferred solution to categorization. Basically, manually adding categories to each extension page, has the problem that there is no way to tell which extensions do not have a category already. whereas you can create rules within the template to place all uncategorized extensions(the ones that haven't used the template) in one big pile for us to sort. Bouncingmolar 07:36, 1 August 2007 (UTC)


 * Hey, yea, template auto-categorization is the way to go, but the current Template:Extension needs to support multiple comma-separated extension sections (i.e. "special page, form, category") in order to categorize in Category:Special page extensions, Category:Form extensions, and Category:Category extensions, for example (like I already mentioned for multiple author support in the same template). Unfortunately, I don't have enough template experience to do it, but if an existing template can be found that does, it shouldn't be too hard to copy the syntax for the extension and other templates like Template:SettingSummary for variables (which I started adding support for other variable categories). The problem is, extensions, functions, variables, hooks, etc, can all be categorized in multiple component categories so I don't think a 1-category-per-extension et al approach is best. Using the existing http://svn.wikimedia.org/doc/ modules categories may be able to help. -Eep² 09:40, 1 August 2007 (UTC)


 * I think there is some confusion over names. 'Type' is used to specify whether the extension adds a special page, new UI features, parser hooks, or parser functions.  It has nothing to do with the purpose for which the extension is intended.  The new field we need is something like 'purpose' or 'subject' which will include things like 'google', 'calendar', 'syntax highlighting', etc.  This cannot be a comma-separated field as we can't split that up, but we could have multiple paramters (e.g. subject1, subject2, subject3, etc.)  It would probably be most useful if this conversation was continued at Category talk:Extensions.  I agree with Bouncingmolar that by 'being bold' you may have duplicated a lot of effort here.  A bit of co-ordination is required, I think!  --HappyDog 22:09, 5 August 2007 (UTC)


 * Well, a "type" of something can apply to many things, so perhaps "type" isn't the right word for categories that add things to MediaWiki. Perhaps, instead, just "extensions that add functionality" but, of course, that too is vague since "extensions by purpose" or "extensions by subject" also add functionality by default (since that's what extentions do by definition). This is why I think "extensions by type" should be removed and just use MediaWiki component categories off the main extensions category. However, a "parser type" field could be added for hooks and functions but "special page" and "new UI features" (or just "user interface") can easily be categorized under Category:Special page extensions and Category:User interface extensions, relatively. -Eep² 22:29, 5 August 2007 (UTC)


 * I suggest we temporarily forget about making a Mediawiki components category. Modifications such as that and changing the structure of the type field can easily be made with changes to the template in discussion after we have finished categorizing the extensions. Our primary goal is to choose a name for the extension sub categories. I will vote on "subject" or "function" (take ur pick and i will back you up) since happydog likes these and for the sake of progress I would accept this as the solution. Bouncingmolar 04:09, 9 August 2007 (UTC)


 * Well, I would have to pick "function" from those two, to at least remain consistent with the Manual:Configuration settings page. However, the code documentation refers to these categories as "modules" so that's what I'd go with (for both) to remain even more consistent... Perhaps Rob Church and other MediaWiki devs can chime in. -Eep² 07:08, 9 August 2007 (UTC)


 * Doesn't seem that this is on other devs priority list, so i think we need to decide between us. After reading the manual. Correct me if i'm wrong, but does not "module" as mentioned in http://svn.wikimedia.org/doc/ which you quoted is not synonymous with extensions or their subcategories and neither is function. And is being a google extension a function? I have to say i prefer function over subject however and not because of any "manual" conventions. I actually prefer extensions by subcategory, but apparantly that is too confusing. So how about we agree on function? what say you? Bouncingmolar 10:33, 20 August 2007 (UTC)


 * Er, "module", as used in the docs:


 * Ajax
 * API
 * Cache
 * Parser
 * Database
 * DifferenceEngine
 * Media
 * Exception
 * SpecialPage
 * Dump
 * FileRepo
 * Filerepo
 * Skins
 * UtfNormal
 * Pager
 * Profiler
 * Search
 * Templates
 * Language
 * Watchlist
 * MaintenanceArchive
 * Maintenance


 * ...stands for the various MediaWiki components. Now, granted, some of these don't really apply to extensions (like "API", "DifferenceEngine", "Exception", "Dump"/"Pager"--though these could be other names for output-related words like "list", "table", etc; "FileRepo"/"Filerepo", "UtfNormal", and "MaintenanceArchive"/"Maintenance") but most do. "Function", while generally can refer to what something does, can in this case be confused with the more specific computer science term "function" (of which every extension uses). However, on the other hand, a module is more general--even in computer science and is synonymous (at least according to the Wikipedia article anyway) with "component" (which I prefer over "module", "function", "subject", and "category", which are increasingly vague). I'd like to get other input on this besides us. —Eep² 11:01, 20 August 2007 (UTC)


 * It seems that wanting input and getting it are different things. I can see that module could be a replacement for the word extension. however since extension is already the named convention, I am not worried about changing the name for extensions/modules. If we did (which we're not) changed extension to module (is that the proposal? i'm not sure) wouldn't we then be faced with the same problem of making subcategories under module such as "modules by subcategory" or "modules by subject/function etc". Or were you actually proposing we make a category called extensions by module? which seems to me like saying extensions by extension; modules by module???? The reason why the extension subcategories are not placed under the extension category and under the current "extensions by category" was to separate the extension subcategories from the other categories within the extension categories: extension by type/author/ and pages like the extension matrix and other non extension but extension related pages.
 * perhaps you are suggesting we move the extensions back into the main extension category, however this is a change that can be made in the template. We need to first choose a name not for 'extensions' but for the subcategories which might take the form of extensions by functionBouncingmolar 01:13, 22 August 2007 (UTC)


 * Er, I'm not sure where you thought I suggested changing "extension" to "module", but I'm not referring to "extension" but, instead, "category"--as in the "extension by category", er, category (which we've been discussing for several weeks now...). While extensions may be considered "modules", I was just using "module" as how the MediaWiki documentation uses the term to define various components/parts/whatever of MediaWiki. If anything, I am suggesting "extension by component" over "extension by module" (and "extension by function", which I believe would cause confusion with MediaWiki's actual functions (whatever they may be; Manual:Code hints at some within "classes" but they are PHP-specific), implying the extensions affect the functions directly--and also cause confusion with the "parser function" extension type, which is already confusing enough with the actual extension of the same name--as evidenced on Category talk:Parser function extensions). Another option is to just use category:extensions by type and merge category:extensions by category into it. However, then there may be confusion between the programming term "data type"... "Extensions by class" is another alternative, but I think we really need MediaWiki developer input here to differentiate between all these programming terms better and how they apply to MediaWiki specifically... —Eep² 05:31, 22 August 2007 (UTC)


 * There is confusion running amok here. Perhaps some clarification is in order:
 * Extension will always be the name used to refer to extensions to MediaWiki (i.e. everything that is not part of core code). This cannot and will not be changed.
 * Type in its current context means, from a coding point of view, how the extension is implemented. There are just a few valid types: special page, parser function, parser hook, ui (javascript), and maybe one or two others.  Currently there are lots of values for this field that are not valid as far as I can see (database, table, category, etc.)
 * Purpose (or function or subject or whatever). This indicates what new functionality the extension provides.  Examples include 'calendar', 'mapping', 'code highlighting' etc.
 * As far as I am aware, these are the only things that we have been discussing on this page, and that anything else has arisen over confusion about what the various terms mean. Please correct me if I am wrong.  I believe the next step in this process is to clarify what we're talking as I think there is a lot of talking at cross-purposes at the moment.
 * --HappyDog 17:10, 27 August 2007 (UTC)


 * I don't think extension type should be limited to those few, so-called "valid" types, since there are more modules/components/functions/whatever that extensions deal with (database, table, category, list, etc). Purpose/function/subject/description are separate from type (and another reason why categorizing by "function" is a bad idea). I think it also needs to be determined whether or not to call "parser extensions" that or "tag extensions"--I think the latter to lessen the confusion with "parser function extensions". —Eep² 19:22, 27 August 2007 (UTC)


 * The type field was meant to indicate, in broad strokes, the type of functionality that the extension adds to the software. E.g. is it a new parser tag or parser function, or does it add a new special page, or some new UI widgets, or a completely new feature?  If this is what you mean as well, then perhaps it would be clearer to me what you were intending if you added a description to each of the items on your list to indicate what qualifies an extension to be in that group.  For me it would be as follows:
 * Parser Tag: Adds a new html-style tag to the wiki-text parser.
 * Parser Function: Adds a new -style parser function to the wiki-text parser.
 * Special Page: Adds a new special page that reports on some existing functionality of MediaWiki, or is a new feature solely contained within a special page.
 * UI Enhancement: Adds a new user-interface aide (e.g. InputBox)
 * New Feature: Adds a completely new feature that is out of the scope of the above.
 * If an extension is several of these, then the most relevant one is used. E.g. my WikiDB extension adds parser tags and a couple of special pages, but all of these are related to the new feature it provides, which is to add DB functionality to the wiki, so I would use the 'New Feature' type.
 * The above list may not be complete, but by my understanding the complete list would be nowhere near as long as yours. Perhaps the intent of this category is not actually that useful, and maybe that is where the problems are arising.  What information are we trying to crystallise here, and who is it useful to? Bear in mind that this is purely in relation to auto-categorisation.  If there is no use in categorising on this field then it may as well be free-text. --HappyDog 23:16, 27 August 2007 (UTC)


 * Hence why I'm proposing the merger of "extensions by type" and "extensions by category" as I see them as the same thing. "Type" is too vague and "category" is too broad; bringing them together can help narrow them down into multiple classifications (whatever you want to call it: type, category, function, module, component, etc). I would rather have multiple classification types than a single general one (even worse is "new feature", which could mean anything). I like knowing that an extension creates a special page, can act as a parser tag and parser function, has a form component (UI), creates tables/lists, creates a database table, etc, etc. The more specific classification, the better, I say. The extension template needs to be updated to handle multiple type/whatever fields--I tried (see its history) but it didn't work. —Eep² 23:47, 27 August 2007 (UTC)


 * Eep. Can we please just focus on what we have been working on. "the subcategory name". Happydog has said(correct me if i'm wrong) that type currently describes the methods used to make the extension work. The current extensions by subcategorydescribe what they add to the wiki. ie: editing extensions, map extensions, chat extensions etc. I suggest we work on one thing at a time and merging two categories is Not on our current list of things to do. I suggest we call it by subject and be done with it. we have to compromise to achieve a solution or we are just going to continue making pages and pages of pointless discussion.Bouncingmolar 01:00, 29 August 2007 (UTC)

This project has gone a bit stale hasn't it. I'm afraid to say that bureaucracy is leading to a loss of interest. Discussion has done nothing but pull this to a grinding halt. Someone agree with one of the proposals so we can move foward. Bouncingmolar 09:27, 7 September 2007 (UTC)


 * Sorry folks, I did not read the entire discussion (too long) yet, but just want to throw in a question/idea/suggestion:
 * how about categorizing extensions as to where and how the code, if any, can be obtained?
 * I found:
 * Extension in svn - avalable per anon svn checkout
 * Extension in MediaWiki svn - svn.mediawiki.org
 * Extension in MediaWiki wiki - www.mediawiki.org
 * Extension Code embedded in web page - needs to be extracted from e.g. a html page or some other format accessible per http
 * Extension Code is a web page - clean code downloadble per single http request
 * Extension Code is web pages - clean code downloadble per series of http request
 * up to now. Also, imho categories:


 * Extension requiring patch might be useful when anything beyound Manual:LocalSettings.php needs alteration,
 * Extension requiring setup for those that do not run out of the box, i.e. before/after drop in something like adding a name space, entering an application key, filling an installation form/menu, etc. is neccessary, before they are operational.
 * Greetings --Purodha Blissenbach 11:44, 8 September 2007 (UTC)

List all extensions with DPL
Since almost every extension uses Template:Extension and has detailed Template parameter, Maybe we can use DPL to list every Extension with its features in a/some page(s). That will be more convenient to let users to know every extension features.--Roc michael 03:28, 9 September 2007 (UTC)