User:RL0919/Templates of Redundancy Templates

Template redundancy (or template fragmentation) is when there are multiple templates that serve the same basic function. Template redundancy occurs for a variety of reasons, and can cause a number of problems.

How it happens
There are lots of reasons redundant templates get created. Some of the more common ones are:


 * Editorial forking – An editor wants to change an existing template, but other editors disagree with the changes. So the first editor creates a new, duplicate template that includes the changes.


 * Lack of awareness – An editor wants a template for a specific function, and doesn't realize that such a template already exists. So they create a new one.


 * Copycatting – An editor sees a useful template related to a tv show/sports team/video game/street gang. But the person who created it made it specific to that show/team/game/gang, down to the name and color scheme. Clearly the editor can't use "Infobox Crips Leader" on articles about leaders of the Latin Kings. So he creates a new "Infobox Latin Kings Leader". Other editors follow suit and soon every gang has its own "Infobox Leader" template. A generic alternative could easily handle all of them, but because the inspirational template was made overly specific, all its copies are as well.

Why it is bad
Having multiple templates performing the same function can cause a number of problems.


 * Duplication of maintenance effort – Imagine for a moment that the infobox templates for cities were highly fragmented, with templates like "Infobox Texas City" and "Infobox Queensland City". One day, Joe Templatemaker gets the bright idea to add a mapping function to "Infobox Texas City" that generates a small map showing where the city is. This is a great idea, one that is applicable to any city. But to implement it across all city articles will be a huge chore, because there are hundreds, maybe thousands, of different templates to update. Many may be hard to find because they don't follow a standard naming convention and haven't been put in a common category with all the other city infoboxes. So, after months of hunting down the stray templates, Joe finally gets them all updated. The next day he thinks of another improvement and has to start the process again. If every article about a city used one standard infobox, Joe could make his changes once and be done.


 * Editing inefficiency – This is related to the problem of maintenance effort, but a bit different. Template maintenance and updates often require editing the template instances in individual articles as well as the templates themselves. If there is one standard template, then editors will be familiar with what the fields are and how to use them. If each article they go to uses a different template, then they will have a bit of new learning to do each time, slowing down their editing and making mistakes more likely. Automated tools, such as AWB, are also easier to use if the templates are standardized across many pages.


 * Inconsistent user experience – In the real world, most editors won't be as thorough as Joe Templatemaker in the imaginary example above. They would add their improvements to templates they already work with, but probably won't search out all the other similar templates. So, when readers went to an article about a city in Texas, they would see a map. But when they went to an article about a city in Queensland, they wouldn't. Of course with a project as large as English Wikipedia there will always be some inconsistencies, but having multiple different templates performing the same basic function in different ways creates inconsistency where it could easily be avoided.


 * Disputes over usage – When there is more than one template for doing essentially the same thing, editors may have different ideas about which version is best. This can lead to editorial disputes over which variation to use in specific articles.

When it may be good
Occasionally there are good reasons to create more than one template for similar functions.


 * Different shapes – With templates that are contained in defined shapes (usually boxes, such as infoboxes and navigation boxes), it can be difficult to create one manageable template that takes on different shapes. So if different shapes are needed – for example, a horizontal box to put at the bottom of articles that are entirely related to a topic, and a vertical box to put on the side of sections of articles that are only partially about that topic – making two versions of the template may be the best choice.


 * Specialized subsets – If there is a specialized situation that can be completely handled using a very small subset of a much larger template, it may be better to create a small, simple template for the specialized situation rather than forcing editors to use a much larger, more complicated template with functions they don't need. For example, if the specialized template has five fields and the generic template has 50, then it makes sense to have the specialized template. On the other hand, if the specialized template has 30 fields and the generic template has 35, then there is no real advantage to using two separate templates.

Alternatives
Sometimes the legitimate concerns that lead to redundant templates can be addressed in ways that don't require entirely redundant templates.


 * Redirects – If the main problem with a template is that the name confuses editors, then a simple redirect may be the solution. Some widely used generic templates, such as Infobox officeholder and Infobox settlement, use this approach, so that editors can use more familiar terms, such as "city" or "prime minister", even though the alternative infobox names all redirect to the same standardized source.


 * Container templates – Sometimes the generic template is a bit too generic for some editors. Maybe there are so many options that editors get confused about which ones apply to the subset of articles that they work with. Or perhaps the field names in the template are very abstract and don't match the terms that editors in a particular area are familiar with. A potential solution for this situation is to create a container template. The functions of a container template are provided by calling up another, more generic template. With a container template, the field names can use specialized language, and some of the generic template options can be ignored or pre-set. Using a container template ensures that all the templates have a similar look (based on the generic template), and that they can all benefit easily from improvements and fixes made to the generic template. However, there will still be a bit of extra work in order to make some changes, so this approach doesn't have all the advantages of moving to a single standardized template.

Eliminating redundancy
If you discover redundant templates, there are several options for eliminating the redundancy:


 * Redirect – If a template is totally redundant to another one, you could redirect one to the other. Typically it is best to redirect more specific template names ("Infobox Crips Leader") to more general ones ("Infobox Gang Leader"). When redirecting, make sure it will not have a negative effect on any uses of the template. For example, if there is any difference in the field names for the two templates, a simple redirect will not work. Also, if copycatting of an overly specific template has occurred, there may not be a generic template for the same purpose, and it would probably create controversy to redirect one specific template to another equally specific template with different parameters.


 * Merge – If the two templates are very similar but not identical enough for redirection, a merger may be the best solution. Proposals to merge templates can be discussed on the template talk pages or at Templates for discussion (TFD). Merging templates can be tricky, so if you aren't sure what you would need to do, a discussion at TFD is probably the best choice.


 * Delete – If there is already a generic template for the same function, and redirection won't work (or someone objects to the redirection), then the best choice may be to nominate the template for deletion at TFD. If the consensus of the discussion is that the template should be deleted and replaced with another template, the closing administrator and other TFD participants can help replace any transclusions of the redundant template. If the template is not used and is clearly redundant to another template, you can bypass TFD and nominate the template for speedy deletion using criterion T3.