Wikipedia:Templates for discussion/Log/2015 February 5
=February 5=
== [[Template:Res ipsa loquitur vs prima facie]] ==
:The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was delete as prose article content is undesirable use of templates Martijn Hoekstra (talk) 10:57, 13 February 2015 (UTC)
:{{Tfd links|Res ipsa loquitur vs prima facie}}
This template contains a block of substantive text replicated in two articles. I don't believe that we use templates in this way. bd2412 T 05:16, 5 February 2015 (UTC)
:How would you propose that we handle the situation? The block of text is fundamentally the same, but has been minorly tweaked for grammar, and the changes didn't replicate to the other article.
:::The difference between the two is that prima facie is a term meaning there is enough evidence for there to be a case to answer. Res ipsa loquitur means that because the facts are so obvious, a party need explain no more. For example: "There is a prima facie case that the defendant is liable. They controlled the pump. The pump was left on and flooded the plaintiff's house. The plaintiff was away and had left the house in the control of the defendant. Res ipsa loquitur."
:compare to:
:::The difference between the two is that prima facie is a term meaning there is enough evidence for there to be a case to answer. Res ipsa loquitur means that because the facts are so obvious, a party need not explain any more. For example:
::::"There is a prima facie case that the defendant is liable. They controlled the pump. The pump was left on and flooded the plaintiff's house. The plaintiff was away and had left the house in the control of the defendant. Res ipsa loquitur."
: Clearly, tweaked for grammar and style, but in two different ways.
: If you don't like my boldly implemented solution, what's your better solution? Jsharpminor (talk) 06:44, 5 February 2015 (UTC)
- : I appreciate the effort, and the boldness, but it's just not something we do. Is a source going to be added to the template? Outside the template in each article? How will a newbie react if they try to edit this text in the article and can't find it there? bd2412 T 15:54, 5 February 2015 (UTC)
- Delete - We do not create a template for the simple function of repeating the same passage in the main body text of two different articles. Template text should be copied and pasted into the main body text of both articles where it is presently transcluded, and the template deleted. First time I've seen this. Dirtlawyer1 (talk) 11:46, 5 February 2015 (UTC)
Well, it looks like this one is going to be snowed closed. But could I please get a more cogent answer than "we don't usually do that"? If it works and works well, and doesn't break anything, why not let it be? It might solve some existing problems, and may be copied and become something that we do on the rare occasion (such as this one) when it's actually appropriate to have the same text transcluded on more than one article. "It's not generally done" only prevents anything new from happening. If there's a good reason not to do it, please let me know what that is. In the meantime, I'll copy the text to the articles in preparation for the inevitable deletion. Jsharpminor (talk) 00:53, 6 February 2015 (UTC)
- Also, just so you know where I got the notion from, see the 2014–15 NFL playoffs article. It has more transcluded templates than I've ever seen. See especially the bracket. Jsharpminor (talk) 01:00, 6 February 2015 (UTC)
- 2014–15 NFL playoffs, like dozens of other articles in the series, has templates with many blank parameters that can be filled in, including templates that transclude into other templates. This is done so that sets of dozens of articles or more can have consistent styling even though they present different information. It is not done so that two articles can present the same block of text. bd2412 T 01:27, 6 February 2015 (UTC)
- Thank you very much for the reply. I suppose I understand about why the NFL bracket would have that, although I don't quite understand why it's appropriate for a bracket that is only linked on two articles, yet is inappropriate for text blocks. I also feel like there may be a fundamental flaw with this question, so please pardon in advance if that is true. Jsharpminor (talk) 01:54, 6 February 2015 (UTC)
- Let me rephrase the question. Is there a way to handle this without just copy/pasting text to two articles? That could lead to the text creeping slowly apart, still continuing to say fundamentally the same thing, while only half the editors see each version. How is this handled in other cases where this is a problem? Surely this isn't the only one? Jsharpminor (talk) 04:10, 6 February 2015 (UTC)
- We have a countless articles with some degree of overlap in content. We maintain textual consistency manually. Editors who are aware of specific instances of overlap can watch both articles to keep them as consistent as they need to be to accurately reflect the world. bd2412 T 04:26, 6 February 2015 (UTC)
- Subst and delete just because it is harder for many to edit this way. (If everyone knew how to edit templates, I may actually think this was a great idea.) —PC-XT+ 08:04, 6 February 2015 (UTC)
- Delete. We don't template article prose. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 6 February 2015 (UTC)
- Can we SNOW this one already? Jsharpminor (talk) 01:50, 7 February 2015 (UTC)
::Would it be improper for me to blank the template and CSD it under G7? Jsharpminor (talk) 03:27, 8 February 2015 (UTC)
::: Not really, but why bother? Subst it in the articles, unwatch it, and let it be. bd2412 T 03:32, 8 February 2015 (UTC)
:::: Please define subst. I have copy/pasted the text to the relevant articles; upon closure of this discussion the template can be deleted without further action. Is that what is meant by subst? Jsharpminor (talk) 04:20, 8 February 2015 (UTC)
::::: If you have a template
:The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.
== [[Template:Infobox mountain range]] ==
:The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was merge. There are some objections and reservations about the prepared combined template from Hike395 mentioned in the discussion. There is consensus to merge, but this discussion doesn't show consensus to use the proposed merged infobox as is. A consensus on how the merge should take place exactly can be established on the templates talk pages Martijn Hoekstra (talk) 10:52, 13 February 2015 (UTC)
:{{Tfd links|Infobox mountain range|type=merge}}
:{{Tfd links|Infobox mountain|type=merge}}
Propose merging Template:Infobox mountain range with Template:Infobox mountain.
Volcano Guy had a good suggestion: many mountains are really massifs, so they are more like ranges, and would benefit from the entries in the mountain range infobox. He suggested merging {{tl|Infobox mountain}} and {{tl|Infobox mountain range}}.
As an experiment, I built a merged infobox, which takes the formatting (mostly) from {{tl|Infobox mountain}}, the section headers from {{tl|Infobox mountain range}}, and accepts the union of the parameters from both. I was pleased to see that there was large amounts of overlap in the code between the two infoboxes: each is individually about 15K of code, while the combination is only 19K.
I used the new merged infobox in the test cases for both kinds of infobox. You can see the mountain tests here, and the mountain range tests here. The most noticable difference to our readers is the section headers: I prefer the merged ones, because "Highest point" and "Geography" are clearer than what we have today in {{tl|Infobox mountain}}.
I can see some advantages in merging:
- The formatting of both mountains and mountain ranges is now the same: uniformity is good.
- We only have one infobox to maintain, not two.
- Massifs and ridges, which have properties of both mountains and mountain ranges, will have less awkward infoboxes. I've heard editors complain that they had to use mountain ranges before, which was unnatural.
- Some of the range parameters (the geographic parameters: country, state, county, etc.; biome) would be nice to have in the mountain infoboxes.
The one disadvantage I can see is that some editors may misuse the {{para|range_lat_d}} parameter family.
I propose replacing contents of {{tl|Infobox mountain}} with User:Hike395/MtnComboBox, and have {{tl|Infobox mountain range}} then redirect to {{tl|Infobox mountain}}. There is one minor conflict in parameters: {{para|region}} in {{tl|Infobox mountain}} will have to be replaced with {{para|region_code}}. I can run AWB to fix this.
What do other editors think? —hike395 (talk) 03:20, 5 February 2015 (UTC)
- Comment reserving my vote for now. One issue I have with this is that many mountains in my area of interest (BC/Pacific Northwest, which has lots of mountains) is that many aren't part of a mountain range, or are on landforms, particularly plateaux, of other kinds. I'm unaware of there being an {{infobox landform}} though maybe if there is, that could be rolled into or considered as part of these deliberations. Also seem my comments on Template talk:Infobox islands though my concern there has to do with settlements rather than mountains-on-islands (most of those would be part of something like the Vancouver Island Ranges or Insular Mountains "metarange" but others, again, will be within landforms such as the Georgia Depression.Skookum1 (talk) 07:01, 5 February 2015 (UTC)
- Comment: The {{para|range_lat_d}} issue could be solved if that were to be just renamed. Instead of {{para|range_lat_d}}, which would appear under "Range coordinates" in the "Geography" section, why not choose a different parameter name that displays "Coordinates" like what exists in the "Highest point" section? That way it won't be conflicting with mountains which are not ranges. Volcanoguy 15:41, 5 February 2015 (UTC)
- Don't merge. Whilst there is some overlap in terms of parameters, which is good for the template technician, I think there is merit in keeping them separate because it's better for the ordinary user. In the vast majority of cases the difference between a range and a mountain is clear and as the individual templates are developed the divergence between them is likely to increase. If we merge them we could end up with similar problems to the horrible Template:Geobox that tries to be all things to all men and is just long, unwieldy and often doesn't meet the many different needs it serves. Bermicourt (talk) 19:44, 5 February 2015 (UTC)
- The majority of parameters in both infoboxes do not overlap. As Hike395 has stated, ridges and massifs have properties of both mountains and mountain ranges and as a result {{tl|Infobox mountain}} and {{tl|Infobox mountain range}} are awkward to use in such articles. If both templates are merged into one template that problem would be fixed. Geobox? LOL! This is far from Geobox since the two templates both have something to do with mountains. Volcanoguy 20:17, 5 February 2015 (UTC)
- And having separate Infoboxes for mountains and mountains ranges just doesn't make sense. If there should be a separate Infobox for mountain ranges why is there no Infobox for lake ranges? Well they might not be called "lake ranges" but there are names for series of lakes in a specific area, an example being the Summit Lakes which refers to a group of two lakes. But guess what {{tl|Infobox body of water}} is used in such articles, not something like "Infobox lake range". As you can see, {{tl|Infobox body of water}} can refer to a number of things, including lakes, bays, oceans and similar water bodies. Each different water body does not have its own Infobox because they are not necessary; a different body of water is still a body of water and a mountain range are still mountains. Volcanoguy 20:58, 5 February 2015 (UTC)
:::I agree with Bermicourt that {{tl|Geobox}} is a nightmare. In fact, {{tl|Infobox mountain range}} was originally designed to replace mountain ranges described by {{tl|Geobox}}, but made to have a design very similar to {{tl|Infobox mountain}}. In retrospect, I think that forking {{tl|Infobox mountain}} was not necessary. There is goodness in both infoboxes, and the combination would be better (and only have minimal extra possibilities for misuse, unlike {{tl|Geobox}}. —hike395 (talk) 02:05, 7 February 2015 (UTC)
- Support as the merge proposer. Volcanoguy 22:21, 5 February 2015 (UTC)
I don't think you're supposed to do this. Jsharpminor (talk) 04:13, 6 February 2015 (UTC)Disregard the preceding; I misunderstood what you meant.- Just to clarify for other editors: VolcanoGuy had the idea, but the proposal seems to have been submitted by Hike395. Jsharpminor (talk) 04:14, 6 February 2015 (UTC)
- I think a merge would be appropriate, as a single template that supports a set of mountains, which may include one or more mountains. —PC-XT+ 08:20, 6 February 2015 (UTC)
- support, seems like a good idea. Frietjes (talk) 16:36, 8 February 2015 (UTC)
- Neutral but leaning to support at present as I have a number of comments/concerns that need to be discussed. First though, kudos to hike395 for an excellent job of working on the combined template (with input from VolcanoGuy). I agree with consolidating to one infobox but the proposed new template generates some awkward results (IMHO):
- # Adding the "Highest point" heading for a majority of the mountains that really only have the one high point adds clutter. If we want to go that route, we should consider adding some parameters for significant lower points (e.g. On Mt. Everest, we have the Hillary Step, South Summit, South Col). The highest point header should then only be added if there is at least one secondary high point specified. On the downside though this could be considered going down the "parameters for everything" infobox type that I really don't like much for the most part. For me, the point of infoboxes is to provide a terse summary of the common attributes of general interest to most. When I see some of the huge infoboxes (e.g. for cities/states/provinces), I eventually have the tendency to ignore them as there's just too much detail in there that I don't care about that I have to jump over. It's "too much work" to find something. This though is also the drawback of going to a combo template which describes multiple mountain landforms and thus the need for more and more parameters to denote the differentiating features of each subtype (e.g. the extra parameters for volcanoes – not picking on them, just using as example).
- # One thing I did like about Geobox is the support for breaking up the location into country, state/province, county, etc. Same as what hike395 mentioned in point #4 of the proposal I think. The mountain infobox on the German Wiki site supports this and probably some of the other language sites as well.
- # I definitely like changing the "Location" header to "Geography". I recall this is something that was discussed in a previous conversion discussion but we really couldn't decide on a better name at the time.
- # In the Sunwapta Peak comparison example, why is "Easiest route" split between two lines for the Combo template?
- # Saying "Parent range" instead of simply "Range" for proper singular mountains within a range just seems to make it sound awkward and a bit confusing (idk, maybe it's just me). It makes sense for mountain ranges but not specific mountains. Parent range is ambiguous for a mountain because do you mean its immediate enclosing range or the parent of that range or the top parent? For example, are we supposed to use Front Ranges, Canadian Rockies or Rocky Mountains? Adding "Parent" just adds confusion (which reminds me of the varying definitions of parent peak where we have people using different definitions when they add it to the infobox but that can be a separate discussion).
:RedWolf (talk) 05:57, 11 February 2015 (UTC)
:The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review). No further edits should be made to this section.