Category talk:Extensions/Archive 2007 to 2013

2007

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:

1. 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.
2. 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.
3. 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. [1] 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)

Calendar Extensions

Maybe all the Calendar 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 [2], [3], [4] and [5]. 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 [[category:extension]] 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 [[category:extension]] 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)

2. 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)

3. 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)

3. 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

2. 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
   • partially complete, still extensions with no templates within category:extensions
2. sort out the extensions without status in Category:Extensions with invalid or missing status
   • awaiting reply regarding having an autobot replace empty status with unknown.
3. sort out Category:Extensions with invalid or missing type too
   • 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.
4. 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)

5. 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.

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.

You may omit either field, or both.

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)

2. 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)

3. 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#Categorizing the extensions)

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:

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)

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)

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 {{#func: }}-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)

like this page? Extension Matrix - Bouncingmolar 07:53, 13 September 2007 (UTC)

There was some talk about installing DPL with no real concensus [1]. However, as far as I can see, the Extension Matrix does what you want here. --HappyDog 13:16, 14 September 2007 (UTC)

Type taxonomy

After having sorted most of the (200+) invalid/missing type extensions, I've put a proposal for some changes to the "Extensions by type" taxanomy together and would like some feedback.

The proposal is at Template_Talk:Extension#Type taxonomy.

Thanks, Egfrank 05:36, 10 September 2007 (UTC)

OK to delete Category:Uncategorized extension?

Its currently empty. Also any extensions without at least an implementation type will end up in Category:Extensions with invalid or missing type, so at this point it may be redundant. Can we delete it? Egfrank 06:28, 18 September 2007 (UTC)

I think this is redundant, but check the template. It may be used there to catch extensions with missing fields (although in that case it should probably be renamed). However I think it was created by someone manually tagging uncategorised items and then working through the list, in which case it has served its purpose and can be deleted. --HappyDog 13:14, 20 September 2007 (UTC)

yes exactly... I think if you see 'someone' replace that with "bouncingmolar". I was manually tagging stuff. When I started there was not really any categories. All the extensions were filed under category:extensions, and it was the only way i could think of to separate the categorized from non categorized. It used to be full of extensions i hadn't assigned categories to yet. I really like the direction this is going :)Bouncingmolar 14:06, 21 September 2007 (UTC)

Extensions by category, revisited

Oh no! not again - the most overworked (and unresolved) topic? But here it is: what exactly is this category for? At this point it seems neither here nor there. I've added a lot of new categories to help people find tools that integrate with their system (see Category:Extensions by integration target) or create specialized content on their wiki pages (see Category:Extensions by visual element, Category:Extensions by audio element).

I haven't added the new categories to this category because I haven't been sure of what it is for. Some possibilities:

• All known categories containing extension articles - analogous to Category:All extensions, so that people can look for categories by scanning an alphabetical list rather than bouncing up and down one or more Extension by ... trees? - If so, might we consider moving the members (and all other categories) to Category:All extensions?
• Leftover categories - i.e. categories of extensions that don't seem to fit in any of the Extension by ... categories. If so, should we rename it to "Extensions by miscellaneous categories", "Extensions - other", or some such name?

• None of the above... fill in the blank

Aside from my current passion for organizing, I'm worried that a top level category without a clearly discernible meaning is liable to confuse people. If they start searching there, they may conclude that we don't have what they need when in fact we do. Help! please. Egfrank 10:38, 20 September 2007 (UTC)

Extensions by category should be removed. It was created by someone (can't remember who) who intended category in this context to mean usage or purpose or something along those lines. The name is clearly unsuitable and so it should be deleted. --HappyDog 13:12, 20 September 2007 (UTC)

i can't remember who that someone was either, but they were clearly delusional Bouncingmolar 14:21, 21 September 2007 (UTC)

in process Egfrank 07:16, 21 September 2007 (UTC)

Stray categories where do they go?

In order to get rid of the Category:Extensions by category, we need to find a home for some stray categories. What should we do with the extension catagories that don't seem to belong to any Extensions by... category. The one's we have so far I think answer questions people might actually be asking. If we just try to force the remaining one's into similarly named top level categories I think we'll end up with a lot of meaningless ones that exist for no other reason than consistancy and will make the important ones hard to find. Some options:

1. Category:Other extensions, Category:Extensions by other or some other name.
2. Place the remainder in the top level

I'm inclined to solution 1:

• its clean and leaves the top level free for categories about extensions (e.g. Category:Extension examples, Category:Extension variables.
• readers are less likely to be mislead into thinking that the Extension by... categories are grouping of the ones in the top level rather than additional categories.

Egfrank 07:19, 21 September 2007 (UTC)

Are stray categories ones that you've analyzed and they still don't fit into any category. Or are they ones that just haven't been assigned a category yet? don't place them in the top level, I like 1. maybe unassigned extensions?

Bouncingmolar 14:12, 21 September 2007 (UTC)

Ultimately, we need to categorise them into our hierarchy. In order to do that we need to identify them, i.e. put them all in one place. The top level will mix them up with other valid categories, so a new temporary sub-category is best. I don't care about the name, as this is only a temporary solution - a place to hold them while we figure out where they should go. Beyond that, I can't really comment until I've seen the specific items in question. --HappyDog 16:40, 24 September 2007 (UTC)

Delete Category:Extensions_not_stored_on_MediaWiki.org?

Can we get rid of this? It doesn't appear to be maintained and if it isn't going to maintained it is misleading. Also, who would be looking explicitly for extensions that are offsite? We can't even certify the ones we have on-site so what difference does it make if they are hosted off-site? Egfrank 07:24, 21 September 2007 (UTC)

yes.. we can delete it. Actually I created it when i was manually trying to repair the missing template items on the extension pages, and I was having trouble filling out the blanks on some extensions because the author had not put any info on the mediawiki extension page, and I had to keep loading other wikis to find out more info about the extension in question. My thoughts at the time were to have a field in the extension template such as "located = eg. bluecortex" . However, maybe people wouldn't really look for that so maybe its pointless.

Bouncingmolar 14:17, 21 September 2007 (UTC)

It is pointless. Extensions on other sites should still have a page here pointing to the code (and would need one in order to be in the cat) so the category only shows extensions whose code is held off-site, which is probably about half of them. Given that, I don't see this as a particularly useful categorisation. --HappyDog 16:43, 24 September 2007 (UTC)

Extension:Anysite

Two editors in May 2007 added a really serious warning template to Extension:Anysite, which the creator removed, and which I now restored:

{{XSS alert|[[User:Duesentrieb|Duesentrieb]] [[User talk:Duesentrieb|⇌]] 10:41, 7 May 2007 (UTC)}}

In addition, this extension is listed as stable on Extension Matrix under the name Extension:Anywebsite. I changed this to experimental.

I think at the least this template page should be protected, and maybe it should be deleted. Odessaukrain 02:43, 30 March 2008 (UTC)

2008

Reflist and other common templates

I installed MediaWiki on my website and I want the templates reflist, infobox and some of the more common templates to work on my MediaWiki installation. I was told I would need to install some extensions to get these to work and was wondering if someone would be kind enough to tell me what extensions I need to install and how exactly go about doing that. If you'd like you can contact me on yahoo instant messenger. My username is projectfanboy. --14 June 2008

Which extensions does Wikipedia Use?

Is anyone aware of a list of extensions used by Wikipedia? SeanFromIT 22:20, 25 August 2008 (UTC)

See Special:Version on Wikipedia. Servel333 20:33, 2 October 2008 (UTC)

2009

Question about making Extensions

I made a extension for mediawiki but its not written in php because i have absolutely no experience in php, literally 10 minutes at the time of coding. The actual code is written in java, and theres a php client that acts the same as any extension. I am wondering if i can still make a extension page for it even though its mainly written in java, and the users (sysop of the mediawiki install) must have java runtime environment installed to use it. I use GCJ, and it also works with SE. Deo Favente 22:51, 13 January 2009 (UTC)

Never mind, i found the answer on the IRC channel.

Authorship extension

Hello! Is there an extension that shows the author of an article? thanks in advance.

Downloads broken

The download function is currently broken: "Invalid response from remote subversion client." -- 193.254.183.243 09:58, 24 February 2009 (UTC)

20090714-20090715 Special:ExtensionDistributor/Renameuser select 1.13.x Continue Result:Unable to contact remote subversion client.

How does one download an extension now? Keep in mind that I've never used subversion or git. Where do I start?

Spoiler extension

Has anyone written a Spoiler function where certain users can see the spoilers or section, but average users or users outside that group can't? I think it would be useful for writer wikis, and wikis based on multimedia fandoms. Or even a show spoilers, hide spoilers. I thought something like giving function to an XML tag would do the trick so the script omits the tagged text for certain users.--66.214.143.64 02:18, 30 April 2009 (UTC)

Probably easiest to just create a spoiler template, with a div style="visibility:hidden;" or text the same color as backgrounds, which users could enable viewing of via a gadget or user css. Splarka 02:21, 30 April 2009 (UTC)

Or you can use w:Template:Collapsetop and w:Template:Collapsebottom. See also Manual:Using content from Wikipedia. Tisane 19:12, 25 May 2010 (UTC)

How to submit a new extension?

I wrote an extension to integrate JIRA issue list into mediawiki. It is a bit different than existing JIRA extension, but works much like as JIRA integration plugin to Confluence. How to submit it into mediawiki? Jazle 07:50, 16 June 2009 (UTC)

Index this page

Someone should index these extensions and put them on this extension list/matrix: http://www.mediawikiwidgets.org/Main_Page 2 173.79.16.233 19:59, 15 November 2009 (UTC)

2012

Many extensions out of date and not working

Does anyone regularly review the accuracy and status of extension info here? Many of the extensions have no status for any recent MediaWiki versions and possibly a majority don't work with 1.19.x. --173.13.177.204 21:06, 28 September 2012 (UTC)

This is not done, I' afraid, since this mostly depends on the extension's programmers. --[[kgh]] (talk) 07:50, 19 May 2013 (UTC)

2013

Name of an extension?

I hope this is the right place to ask? If not, please tell me where to go (lol)

When editing in Wikipedia, we have a couple of toolbars under the edit window. When editing here, they are a little different. (I think the one here is "mw-edittools-charinsert" or class="mw-charinsert-buttons" [or both?])

Can anyone tell me what the one in Wikipedia is called, and if we can use it on our Wiki? (ver. 1.20.0)

Thanks Chaosdruid (talk) 00:06, 22 May 2013 (UTC)

#Top and #Down

If I use the teg-command [[#Top]] to go to the top of the page, what should I use to get down? --Cherus (talk) 15:50, 6 October 2013 (UTC)

language section and tables

What kind of command or what type of a bot should I use to obtain the relevant title of an article from another language section? For example, I need to automatically enter the titles of the articles from German ([[de:***]]) and/or from Spanish ([[es:***]]) and/or from Latin ([[la:***]]) language section into the new table, if I have an article in English ([[en:***]]). --Cherus (talk) 16:08, 6 October 2013 (UTC)

Symfony

Documentacion oficial

Comandos Comunes

Actualizar Compouser

php composer.phar self-update

Actualizar Dependencias

php composer.phar update

Actualizar Instalar Recursos

php app/console assets:install <dir> --symlink

This page could use some love

There are quite a few useful categories that are not listed.

How can I now see the newest extensions?

The Extension Matrix page provided useful information like a list of the newest extensions and filters for status and MW version. Now all we seem to have a a huge A-Z list of all extensions.

Why was Extension Matrix page removed? Or has something else been provided to allow people to see the newest extensions or sort by date? --Mitchelln (talk) 15:26, 18 July 2014 (UTC)

I have to agree with the users comments. It has almost become impossible to find out new or recently updated extensions. With the number of extensions it is next to impossible to remember based on names. Please find a way to bring or add functionality to filter for new and updated extensions!!! Wikimanz (talk)

What extension does this?

I want this funcionality in my wiki, i´m talking about the popup that shows the conversion. what extension does that? Crystian Marquez 30 july 2014

Semantic MediaWiki. Sorry for the late response. :) Yaron Koren (talk) 20:20, 15 March 2015 (UTC)

(something in Slovenian about a "new application for a medical center, somewhat like Wikipedia")

Zdravstveni dom App

To je nova aplikacija za zdravstveni dom. Izdelali so jo dijaki 3. TRB letnika iz Elektro Računalniške šole. Aplikacija se imenuje zdravstvenidom app. Bolj natančno je aplikacija za podporo celotnega sistema. Aplikacija je narejena tako, da deluje na vseh mobilnih napravah(tablicah, mobilnikih...). Aplikacija je narejena nekako tako kot wikipedija. Lahko boste dodajali oz. izboljševali članke. Administrator nam bo poslal napake, mi pa bomo sporočali koliko smo že teh napak odpravili. Za več informacij boste dostopali preko naše suradne spletne strani ali celo preko Facebook-a.

Navodila uporabe

Aplikacija je zelo preprosta. - Najprej seveda zaženemo aplikacijo - Nato se moramo prijaviti(lahko tudi preko facebook-a) - Če aplikacijo prvič nalagate, morate še izpolniti nekaj podatkov o sebi - Potem počakate da se aplikacija naloži - Ko pridete v aplikacijo, bodo kratka navodila kako uporabiti aplikacijo - Upam, da vam bo aplikacija všeč

Mnenja

Če boste hoteli podati kakšen komentar, vam bo na voljo v aplikaciji oddati svoje mnenje. Lahko pa nam pišete tudi na našo Facebook stran.

— Preceding unsigned comment added by Prototype214 (talk • contribs) 2015-02-10

My First Topic

Hello Sir, I am Media Wiki Users. I am using first time Media Wiki and after that I am trying to Customize of this applicatioN

mediawiki with extension?

how to download working 'production' tarbal with all current (eg those used on wikipedia) extensions? To fulfil my request best will be to publish the same software which is deployed on the main site: wikipedia.org.

I did use it some 10 years ago but now it seem complicated. Some tips are inaccessible the free software is somehow incompatible with licence we contributed years ago it may look for me like kind of job security tactic or what?.

Plese tell how to get mediawiki with working all free used by wikipedia extesnsions .