Jump to content

Template talk:Infobox mountain/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6

Add white border around mountain marker?

I was concerned that the existing red mountain marker would blend in too much on the new default relief maps. After a little experimenting, I found that adding a 1-pixel wide white border around the marker really makes the mountain pop out. Check out {{Infobox mountain/testcases}}, especially the Hawaii test case towards the bottom.

What do other editors think?Shall we make this change go live? —hike395 (talk) 01:19, 2 October 2011 (UTC)

  • Hmmm, good idea — white is fine if the underlying map segment is dark but not if it's a light color. I thought you were using some CSS magic to add that white border but I see it's just an image that is being used by another language wiki. Replacing the white with some suitable alternative that would work equally well with dark and light map areas would make it more suitable IMHO. I have inkscape installed but haven't used it much so not sure how easy it would be to change the border color. RedWolf (talk) 05:00, 4 October 2011 (UTC)
Well, the red of the triangle is pretty dark. Against a light background (like the Manitoba example), I think the red stands out on its own, and the white border is scarcely noticable. Against a dark background, the white border sets off the red. So, I think we've got both cases covered. —hike395 (talk) 05:31, 4 October 2011 (UTC)

Please copy Template:Infobox mountain/main/sandbox to Template:Infobox mountain/main. See above for discussion: seems uncontroversial. —hike395 (talk) 15:05, 11 October 2011 (UTC)

 Done Looks good to me. But I note that File:montanya.svg is not currently licensed in such a way that we can avoid linking to the image description page. Rather than mess with trying to change it to the equivalent of {{PD-shape}} on Commons, I just created File:Red triangle with thick white border.svg to use instead. Anomie⚔ 02:52, 12 October 2011 (UTC)

Geobox

I have proposed that we delete {{geobox}}. That may effect this template. You are invited to participate in the Geobox deletion discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:52, 3 January 2012 (UTC)

Geobox with type=mountain

Now that we have tracking categories, we can see that {{Geobox}} is only used with |type=mountain 63 times, compared to 12,198 for this infobox. I therefore propose that we add any necessary parameters to the infobox, convert the 63 articles, and deprecate then remove the type from Geobox. This will offer improved consistency to readers and editors of articles about mountains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:02, 16 March 2012 (UTC)

Change row order for Ordnance Survey grid references

I am requesting that the content of Template:Infobox mountain/main/sandbox be moved into Template:Infobox mountain/main. The new version changes the order of some of the rows. The "OS grid" and "OSI/OSNI grid" rows are relocated so that they come before the "Coordinates" row. Currently they follow the "Topo map" row. I believe the change to be non-controversial. The rational being that Ordnance Survey grid references, in the UK and Ireland, are comparable to global coordinates. –droll [chat] 06:37, 17 March 2012 (UTC)

 Done — Martin (MSGJ · talk) 20:55, 18 March 2012 (UTC)

Isolation parameter

We don't seem to have the "isolation" parameter that geobox has and of course the template is locked (why??) so I can't add it. Can someone please sort this out. German Wiki has a neat way of displaying isolation and prominence - see here - they also clearly indicate which height reference system is used for elevations if known, perhaps we could emulate those too. Thanks. --Bermicourt (talk) 06:19, 16 April 2012 (UTC)

You asked for this about a year ago, and no one implemented it (perhaps because the template is locked only for admins to edit). It seems like a completely reasonable request.
Let's do this in two steps: Droll removed the dependency of {{infobox mountain pass}} on {{infobox mountain/main}}, so we can finally get rid of the subtemplate. After that, I'll clean up the unneeded traversed parameter, and add isolation. I am not an admin, so this will be a slow process.

Please copy Template:Infobox mountain/main to Template:Infobox mountain, because the subtemplate is no longer needed. —hike395 (talk) 08:49, 16 April 2012 (UTC)

Yay, finally.  Done: there are still 10,000+ pages waiting to be purged, after which I'll delete the sub-template. Chris Cunningham (user:thumperward) (talk) 13:08, 16 April 2012 (UTC)
Thanks for the quick response, Chris!
Next step --- fellow editors: please take a look at the Mount Baker and Sunwapta Peak examples in the testcases. I have added three parameters: isolation (the distance to the nearest higher peak), isolation_parent (the name of the nearest higher peak), and isolation_ref (reference that supports other two parameters). The latter two parameters only work if isolation is defined. What do you think: shall we make this change live?
(I didn't implement isolation_mi or isolation_km, because that would require modifying {{Infobox mountain/convert}}, also a locked template. We can do that as a separate edit, if there is consensus.) —hike395 (talk) 04:35, 17 April 2012 (UTC)
Just for the record, I am opposed to the addition of {{{isolation}}}. In almost all cases it is a very trivial bit of data and when it is of encyclopedic interest it can be mentioned in the text of the article. Adding the parameter to the template will encourage editors add the data. As I mentioned in an earlier discussion, in most cases there are very few sources for a peak's isolation and they are usually primary sources. See WP:PRIMARY. –droll [chat] 05:41, 17 April 2012 (UTC)
P.S. Reading the information at the bottom of the list, World Peaks with 1000 km of Isolation, makes it clear that the list is a primary source and that the criteria, especially for island peaks, is arbitrary. –droll [chat] 06:16, 17 April 2012 (UTC)
It sounds like we don't have consensus to change after all. Bermicourt: do you have a counter-argument for Droll? —hike395 (talk) 08:41, 18 April 2012 (UTC)

Fix a serious bug

There's a bug in the existing template. See the test case: the map is sometimes duplicated in the infobox. There is an easy one character fix.

Please copy Template:Infobox mountain/sandbox to Template:Infobox mountain to fix the bug, above. —hike395 (talk) 09:07, 18 April 2012 (UTC)

I totally support this edit. It should be done as soon as possible. –droll [chat] 14:45, 18 April 2012 (UTC)
Done --Redrose64 (talk) 15:20, 18 April 2012 (UTC)

Modified version in the sandbox

I have a modified version of the template in the sandbox with test cases. I didn't change any visible styling this time. Other than a bit of cleanup, all the changes involve parameter names.

  1. Removed traversed – it's not used nor is it useful.
  2. Removed   that followed elevation and prominence – not consistent with the appearance of other data.
  3. Removed border:0px; – default is 0.
  4. Added markup which displays a error message, if no name is supplied. Also enters the page in a maintenance category.
  5. Added native_name as a synonym of other_name – commonly used in other templates and I think it should be included to avoid confusion.
  6. Added photo_width and map_width as synonyms for photo_size and map_size – commonly used in other templates and better describes the function of the parameter.
  7. Added x% and y% – allows a third method which to be used to superimpose a marker and label. This was discussed in the past.
  8. Added child – allows the template to be embedded in another infobox.
  9. Added embedded – allows another template to be embedded in this template in a orderly fashion.
  10. Added volcanic_arc, volcanic_belt and volcanic_field as alternatives to volcanic_arc/belt. Each displays an appropriate label. This allows for less ambiguity and will reduce the number of times data is forced onto two lines.
  11. Added markup which makes the template less prone to unintended results.

If there are no suggested changes I'll ask that the template be edited. These are the changes I would like to see at this stage. We can consider changes in styling after these changes are made.

P.S. I should mention that {{infobox map}}, which this template transcludes, is now capable of displaying a label when the x,y or x%,y% parameters are used. However, I'm now of the opinion that labels are usually clutter when only one mark shows on a map. Without a label the mark could be a bit larger. –droll [chat] 16:45, 27 April 2012 (UTC)

I support all of the changes you've made in the template. I also agree with you: labeling the mountain when there is only one mark is cluttered. —hike395 (talk) 01:39, 28 April 2012 (UTC)

The modified version of the template is in the sandbox and test cases are here. –droll [chat] 01:06, 29 April 2012 (UTC)

 Done -- WOSlinker (talk) 10:07, 29 April 2012 (UTC)

Infobox mountain range

I am proposing that we use {{Infobox mountain range}} instead of {{Geobox|Range}}. Please feel free to join the discussion. —hike395 (talk) 02:37, 30 April 2012 (UTC)

Change to relief map setting

Recently an editor make a change to this template. The markup before the edit was:

| relief = {{#ifeq:{{{map_relief|}}}|0||{{{map_relief|}}}}}

and now it is:

| relief = {{#ifeq:{{{map_relief|}}}|0|{{{map_relief|}}}|1}}

The result is that relief is always none empty and so {{location map}} will always attempt display the image assigned to image1 in the Location map template (which is not necessarily a relief map). This happens even when an editor sets relief=0. I would like to know what others think of this change. The markup prior to the recent edit was in the markup before my requested edit (above). –droll [chat] 07:36, 12 May 2012 (UTC)

Sorry, Droll -- I just noticed this talk entry. You're right. This is a bug: the current code makes it so that you can never turn off relief! To make the code shorter and easier to read, I changed the sandbox to
| relief = {{#ifeq:{{{map_relief|}}}|0||1}}
so that an editor can specify map_relief=0. The test case at Template:Infobox mountain/testcases#relief=0 now works (it has been broken for 2 months)

Please copy the sandbox to the main infobox. Thanks! —hike395 (talk) 15:56, 21 July 2012 (UTC)

Done As a side note, I see that |map_border= is only recognised when |photo= is set; when |photo= is blank or absent, |map_border= is ignored. --Redrose64 (talk) 16:26, 21 July 2012 (UTC)
Fixing Redrose's bug was relatively simple: |map_border= was missing from one of the two calls of {{infobox map}}. Please copy the sandbox to the main template. Thanks! —hike395 (talk) 17:56, 21 July 2012 (UTC)
Done I didn't do it myself because it was a fifty-fifty choice whether to add one, or remove the other. Sometimes parameters are deliberately removed, but the person doing the removal overlooks one use. --Redrose64 (talk) 18:58, 21 July 2012 (UTC)

Rock parameter

Can someone please add a parameter that enables the infobox to display the type of rock a mountain is made of. e.g. "rock=Ramsau dolomite and Dachstein limestone". --Bermicourt (talk) 10:52, 15 July 2012 (UTC)

  • You can use the "type" parameter. As an aside, a better name would probably be rock_type to be more descriptive of its usage although this parameter has been there for a very long time. RedWolf (talk) 06:31, 21 July 2012 (UTC)

Please copy Template:Infobox mountain/sandbox to Template:Infobox mountain. The only change is the wlink in the "Listing" parameter, which should point to List of mountain lists, now a list of peakbagging lists. (see Wikipedia talk:WikiProject Mountains for the discussion).

Thanks! —hike395 (talk) 23:33, 18 August 2012 (UTC)

 Done — Mr. Stradivarius (have a chat) 18:48, 19 August 2012 (UTC)

Edit request to add default_map_width parameter

{{Location map+}} now supports the use of a default_width parameter, and {{Infobox map}} has been updated to accept default_map_width and pass it to {{Location map+}}. The code in the sandbox replaces 

| map_width = {{least|{{ifempty|{{{map_width|}}}|{{{map_size|}}}}}|272}}

with 

| map_width = {{#if:{{{map_width|}}}{{{map_size|}}}|{{least|{{ifempty|{{{map_width|}}}|{{{map_size|}}}}}|272}}}}
| default_map_width = 272

This change will allow vertically oriented maps to be modified by a preset value given in the location map scheme in order to avoid overly large maps. --Paul_012 (talk) 10:48, 12 December 2012 (UTC)

Note that Paul changed the use of {{template sandbox notice}} back to {{documentation}}, to facilitate an admin copying the sandbox to the main template. Instead, I modified the <noinclude> code to test whether it is on a subpage or not (code taken from {{Infobox mountain range}}). If on a subpage, it shows the {{template sandbox notice}}, otherwise it shows the {{documentation}}. The code looks odd, because it was designed by User:Wikid77 to minimize expansion depth and avoid errors. This should not affect template behavior, just the appearance of the sandbox.
Closing admin --- please copy the whole sandbox to the main template. Thanks! —hike395 (talk) 13:43, 12 December 2012 (UTC)
First I changed the parameter name in the sandbox (and at {{Infobox map}} from default_map_width to default_width which is unambiguous without being so long. Also it is the parameter name used in {{Location map+}}.
I feel very confident that this edit will be a change in the right direction and I am confident that there are no bugs. However, I'd like to wait till after this same modification goes active at {{Infobox protected area}}. This is a somewhat visible change and something might be learned that would be of use here. I think that rolling out new versions should be done with caution. {{Infobox protected area}} is transcluded more than 5700 times. This template is is transcluded about 13000 times. –droll [chat] 06:04, 13 December 2012 (UTC)
P.S. My only concern is that there might be negative feedback from the edit to {{Infobox protected area}}. That template has now been modified. I think we should wait a few days to gauge the response to that edit before modifying this template. I don't anticipate a problem. I just think it is best practice. –droll [chat] 21:56, 18 December 2012 (UTC)
Done It looks like the update didn't bring up any problems at {{Infobox protected area}}, so I have applied it here as well. Let me know if there are any issues with it. — Mr. Stradivarius (have a chat) 09:41, 23 December 2012 (UTC)

Minor changes to the appearance of the infobox

Active template
Map
Highest point
Coordinates36°34′43″N 118°17′31″W / 36.578580925°N 118.291994950°W / 36.578580925; -118.291994950[1]
Climbing
Easiest routeWalk on up
Sandbox version
Map
Highest point
Coordinates36°34′43″N 118°17′31″W / 36.578580925°N 118.291994950°W / 36.578580925; -118.291994950[1]
Climbing
Easiest routeWalk on up

I have a slightly adjusted version of the template in the sandbox. It will reduce the number of times that line wrap occurs. This should solve, in most cases, the problem with the bottom note link (e.g. [1]) for coordinates causing line wrap. The changes are:

  1. Reduced the padding around label and data cells.
  2. Added 1 em to the minimum width of the table. This will not effect infoboxes with default width photos or maps.
  3. Removed vertical-align:text-top; from label and data cell style because in is unneeded.
  4. Bypassed the redirect to the Ordnance Survey National Grid article.

The adjustment to the padding above and below rows will reduce the overall height of the infobox. I don't think there will be any negative impact. –droll [chat] 01:28, 24 December 2012 (UTC)

Done — Mr. Stradivarius (have a chat) 08:38, 24 December 2012 (UTC)
Why do we have styles in this template at all, rather than using the defaults in {{Infobox}}? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:24, 24 December 2012 (UTC)

Adding embedded parameter?

Could someone add a parameter for an embedded field to the infobox? I am particularly interested in including a designation for National Natural Landmarks since many NNLs are mountains, or at least features using the mountain infobox. See Warren Woods State Park for an example of how this would look. Fredlyfish4 (talk) 18:03, 24 February 2013 (UTC)

 Done --- Already implemented: I simply updated the documentation. —hike395 (talk) 18:43, 24 February 2013 (UTC)

Geobox/mountain

I'm planning to convert the last 30 mountain articles using {{Geobox}} (down from 63 in March this year), to use this infobox. As can be seen on Rakytov, there are some differences, such as the second map. Should such features be added to the infobox? How else might we handle conversions? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 6 September 2012 (UTC)

I think that two maps is excessive. For an infobox The coordinates link to geohack: that should fulfill users' mapping needs. I recommend a single map. —hike395 (talk) 03:05, 7 September 2012 (UTC)
Later --- I just converted all of the remaining Eastern European mountains. Now there is no need for a double map. —hike395 (talk) 11:29, 7 September 2012 (UTC)
Many thanks; could I trouble you to make the final 10 conversions, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:07, 7 September 2012 (UTC)
See this discussion from 2009. I'm reluctant to convert the West Virginia mountains without getting consensus at the West Virginia WikiProject. Once I've converted all of the mountain ranges to {{Infobox mountain range}}, I think the argument for converting the last 10 mountains becomes a lot stronger. —hike395 (talk) 10:48, 8 September 2012 (UTC)
WikiProjects don't own articles and can't enforce local standards; especially via a three-year-old discussion with only one dissenter. With 12,670 transclusions of Infobox mountain vs. the remaining ten Geoboxes for them, I think it's unequivocal where the community's consensus lies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 8 September 2012 (UTC)
Shouldn't you at least bring it up at WP:West Virginia? —hike395 (talk) 15:31, 8 September 2012 (UTC)
(Only just seen that, sorry) No, I don't think that's necessary. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:11, 2 October 2012 (UTC)

Can we get this done, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:12, 26 December 2012 (UTC)

 Done —hike395 (talk) 16:54, 4 November 2013 (UTC)

Could we swap the last_eruption parameter wikilink, which currently leads to Volcano, to Types of volcanic eruptions? Brandmeistertalk 09:48, 3 August 2014 (UTC)

Done, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:29, 3 August 2014 (UTC)

Map size

Template states default value is 250.

The |map_size= default and maximum values are both 300.

Also please check the same for |photo_size=. The infobox photos began displaying smaller a couple months ago so something about this changed. Thank you. --RacerX11 Talk to meStalk me 13:33, 3 August 2014 (UTC)

Infobox Berg1

there was a TfD for Infobox Berg1, with the outcome that we turn that template into a substitute-only wrapper for this one. for the most part, all the parameters in that template are in this one, with a few exceptions, |isolation= for isolation, |rock= for the composition, |access= for access, |normal_route= for normal route, and |remarks= for additional comments/remarks. there are also about five additional images in that template, but I think those can be migrated to the article. any objections to adding additional parameters? Frietjes (talk) 17:43, 28 February 2014 (UTC)

I think |rock= can map to |type=: the original intent for |type= was to contain either rock type or landform type. I also agree with underlying that free fields like "remarks" do not belong in infoboxes. —hike395 (talk) 06:14, 2 March 2014 (UTC)
will do, have added isolation, normal_route, and access, but did not add the others for now. thank you. Frietjes (talk) 15:15, 3 March 2014 (UTC)
Isolation works but not isolation_km and isolation_mi (you can see an example here). Do you or someone else know how to fix it? Otherwise we have to use the convert template and it's kind of annoying.. ZachG (Talk) 11:56, 10 August 2014 (UTC)

Merger proposal

I propose we merge Template:Infobox ski area into Template:Infobox mountain. There are approximately 614 articles using the former template, but in my humble opinion it ought to be phased out. Having two is slightly redundant since ski hills are generally mountains or geographic features for which we use this infobox, and Infobox ski area is missing many important parameters present in Infobox mountain. Documentation is poor and there have been relatively few efforts to improve it recently. I therefore recommend we deprecate Infobox ski area and require new articles about ski areas to use Template:Infobox mountain. - SweetNightmares 22:26, 7 August 2014 (UTC)

Also, as this template is protected, I cannot add a notification at the top. If someone with template editing rights or adminship can add the following for me, I would be most grateful:
<noinclude>{{mergefrom|Template:Infobox mountain|discuss=Template talk:Infobox mountain#Merger proposal|date=August 2014}}</noinclude>
Thank you! - SweetNightmares 22:43, 7 August 2014 (UTC)
Oppose --- I can see several reasons not to merge:
  1. Ski area articles are often distinct from the article about the underlying mountain: e.g., Mammoth Mountain and Mammoth Mountain Ski Area
  2. Ski areas sometimes span multiple peaks, e.g., Whistler Blackcomb.
  3. Most importantly, there are many mountains that are not ski areas. merging the two infoboxes will allow sloppy editors to supply ski parameters to non-ski-area mountains. (I have seen such editing in the use of {{Geobox}}).
I am happy to add documentation or additional parameters to {{Infobox ski area}}, if that helps. Which parameters do you think are important? —hike395 (talk) 07:06, 8 August 2014 (UTC)
You do make a good point about ski areas spanning multiple peaks. However, I don't see anything wrong with using the same infobox for both a mountain and its ski resort. I also don't think sloppy editing will be much of a concern provided the proper documentation and placement of these parameters is observed.
In any case, if we are to keep the infobox, here is a short list of improvements that ought to be made.
Parameters to change:
  • picture -> photo
  • caption -> photo_caption
Parameters to add:
  • other_name
  • top_elevation_ref
  • base_elevation_ref
  • isolation
  • isolation_ref
  • prominence
  • prominence_ref
  • translation
  • language
  • range
  • topo (+grid_ref_UK/grid_ref_Ireland)
- SweetNightmares 14:10, 8 August 2014 (UTC)
  • Completely oppose For one thing, many ski areas aren't actually on mountains (one in Prince George BC comes to mind, but there are others, including in the big coulees within Edmonton, and Olympic Park in Calgary, and Mount Royal Park in Montreal - yes, that's on a mountain but the mountain and accompany park is its own entity far beyond the rope-tow), and the term also includes x-country areas (though not many of those as yet have articles). And in accordance with Hike395's comments, there are many, many many more mountains than ski areas, and ski area infoxes would contain many different fields that are irrelevant to the vast/predominant realm of non-ski area mountains.Skookum1 (talk) 12:47, 8 August 2014 (UTC)
  • Oppose merge. Regarding parameters to add: I can see no reason to add the isolation and prominence parameters, as they have nothing to do with a ski area. Those are topographic data for a mountain's summit. --RacerX11 Talk to meStalk me 21:59, 8 August 2014 (UTC)
  • Oppose. Mountains and ski areas are intrinsically different things (even though they are related to each other, I admit, like glaciers or mountain passes). The only common parameters are location, summit elevation and coordinates. That is certainly not enough to justify a merge. ZachG (Talk) 11:37, 9 August 2014 (UTC)
  • Oppose as ski areas often cover the slopes of many mountains. However, we may be able to use this proposal to improve Wikipedia in other ways. E.g. where there is a ski area associated with a single mountain, could its infobox include some ski area parameters? Bermicourt (talk) 17:15, 10 August 2014 (UTC)
  • oppose, but I see no problem with making {{Infobox ski area}} have a |embed= parameter so it could be embedded in this template when it make sense. Frietjes (talk) 17:20, 10 August 2014 (UTC)

Isolation

Example mountain
Highest point
IsolationFoo bar

How come the isolation parameter isn't working? I've looked at the source code, but I can't figure it out, although I don't know Lua. Seems to me that it's identical to elevation/prominence, so what gives? - SweetNightmares 03:33, 23 August 2014 (UTC)

Seems to work here. Where specifically isn't it working? Jackmcbarn (talk) 03:46, 23 August 2014 (UTC)
Sorry, I meant isolation_km. Isolation is working fine, I just have to use isolation={{convert|foo|km|mi}}, because isolation_km=foo doesn't work. Haven't tested with isolation_mi. - SweetNightmares 05:14, 23 August 2014 (UTC)
Both isolation_km and isolation_mi don't work, I already commented about that above in "Infobox Berg1". So if someone can fix it, it will be appreciated. Maybe Frietjes has an idea as she worked on the template a while ago... ZachG (Talk) 09:15, 23 August 2014 (UTC)
Example mountain
Highest point
Isolation1,000 km (620 mi)

 Fixed --- The Infobox was using a deprecated unit conversion method. —hike395 (talk) 10:16, 23 August 2014 (UTC)

Oh, thanks! ZachG (Talk) 10:37, 23 August 2014 (UTC)

Template-protected edit request on 26 September 2014

Please alter this template so that prominence is displayed above isolation. The convention is to display elevation, prominence, and isolation in that order. Thanks,  Buaidh  22:13, 26 September 2014 (UTC)  Buaidh  22:13, 26 September 2014 (UTC)

Where is this convention laid down? --Redrose64 (talk) 22:41, 26 September 2014 (UTC)
Reliable sources such as Peakbagger for example, tend to list prominence before isolation. --RacerX11 Talk to meStalk me 22:55, 26 September 2014 (UTC)
Not in a Wikipedia guideline then; in which case, Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Redrose64 (talk) 23:27, 26 September 2014 (UTC)
I wouldn't mind at all having prominence just after elevation. Both are vertical distance measurements, unlike isolation, so it makes sense to have them together. ZachG (Talk) 13:52, 27 September 2014 (UTC)

Coordinates field

Can anyone explain why, at precisely 13:42 UTC, 27 October 2014, recompilations of Template:Infobox mountain started displaying a blown Coordinates field. I made a minor edit to Mount Princeton at 13:41 UTC with no problems. When I made a similar edit to Mount Yale at 13:42 UTC, "[" appeared in the Coordinates field. Subsequent edits to other articles invoking Template:Infobox mountain produced similar results. You can reproduce this by editing Mount Princeton and then immediately invoking Show preview without making any changes to the article. Neither Template:Infobox mountain, nor Template:Infobox coord, nor Template:Coord were altered during this period. I am stumped. Thanks for your help.  Buaidh  15:26, 27 October 2014 (UTC)

Resolved.  Buaidh  15:44, 27 October 2014 (UTC)
@Buaidh: Please see Wikipedia:Village pump (technical)/Archive 131#Coordinates display appears to be broken. That's where problems like this usually go. --Redrose64 (talk) 15:49, 27 October 2014 (UTC)

Photo size

The default size used to be 285 pixels but it is now is 250 px (looks like an unintentional change as it is still indicated 285 px for the default size). I think a value around 280-300 px makes more sense given the size of the infobx and the size of the photos in the article (220 px). Would anybody mind it? ZachG (Talk) 17:27, 1 December 2014 (UTC)

ZachG, I would mind. the value of 250px is approximately equal to 22em, which is the default width of most infoboxes. I would like to avoid the width of the infobox being different from other infoboxes, and the width of the infobox depending the inclusion of an image. however, since the default width of this infobox is 23em, I don't see a problem with either (a) reducing the infobox width to the default value of 22em or (b) increasing the default image size to upright=1.2, which roughly matches 23em. Frietjes (talk) 17:43, 1 December 2014 (UTC)
On the Matterhorn and Mount Everest page the photo is 280 px wide (upright=1.25 I think) and it looks the ideal size to me (compared to the infobox), although the map is slightly smaller (272 px). But I think upright=1.2 would be ok. ZachG (Talk) 18:08, 1 December 2014 (UTC)
ZachG, added some examples showing what happens when you use a value larger than the box. seems like 1.2 is about the maximum that doesn't significantly change the box width. it also looks like the upright keyword rounds up to the nearest 0.05, so 1.16 is the same as 1.20. Frietjes (talk) 18:27, 1 December 2014 (UTC)
There's something I don't understand. The mountain infobox is always about 300 px wide (I checked on several web browsers), so why not having a 280 px wide image in it. 250 px doesn't look right (see the Gasherbrum I page for instance, the photo is floating in the middle of the infobox.) A while ago every mountain article looked ok but now I have to add "photo_size =280" to every page otherwise there is this large space between the photo and the margin of the infobox, which I don't find aesthetically pleasing. ZachG (Talk) 18:41, 1 December 2014 (UTC)
probably due to the extra border-spacing. in any event, the solution (in my opinion) would be (1) reduce the box width and font-size to the default, and (2) slightly increase the default image sizes. I have a version in the sandbox (see Template:Infobox mountain/testcases). Frietjes (talk) 19:27, 1 December 2014 (UTC)
Looks much better, thanks. ZachG (Talk) 19:34, 1 December 2014 (UTC)
I agree --- sandbox version is superior. I was not aggressive enough when I used upright=1.15.. Can we make the map_size default to 272, though? JPEG files like to have dimensions that are multiples of 8 (for best compression) —hike395 (talk) 08:16, 2 December 2014 (UTC)
I had a further look and I find the sandbox version really great. May I also suggest boldfacing the map label? I find it sometimes not very readable, especially on detailed maps. ZachG (Talk) 13:44, 2 December 2014 (UTC)
now partially done, I left the default mapsize to 272 as requested. go ahead any additional changes to the sandbox and we can discuss further changes. Frietjes (talk)
Thank you. On second thoughts I think I will leave the label as it is. ZachG (Talk) 14:50, 3 December 2014 (UTC)

edit protected merge from sandbox

Please merge {{Infobox mountain/sandbox}} here. As per Template talk:If empty, the current Infobox mountain includes a false transclusion of {{error}}. I've re-written the check for the name parameter to not use the module (which would also an unnecessary call to the module). —CodeHydro 04:31, 27 December 2014 (UTC)

Done — {{U|Technical 13}} (e • t • c) 05:27, 27 December 2014 (UTC)

Parameter "normal/easiest route"

Hi folks. Currently this parameter links to climbing route, but many, if not the majority, of normal routes up mountains do not involve any actual climbing. Now that there is an article on normal route, it would make sense to change the link to that. The "normal route" article links in turn to "climbing route" but also to other types of route that may be encountered. I would do this myself but the template is padlocked... --Bermicourt (talk) 09:56, 25 January 2015 (UTC)

done. Frietjes (talk) 20:43, 31 January 2015 (UTC)

Nomination for merging of Template:Infobox mountain range

Template:Infobox mountain range has been nominated for merging with Template:Infobox mountain. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. —hike395 (talk) 03:22, 5 February 2015 (UTC)

The result of the discussion was to merge {{Infobox mountain range}} into this template. Further discussion on the design of the merged template is at the Mountain WikiProject talk page —hike395 (talk) 03:53, 15 February 2015 (UTC)

Image captions

I was just doing some work on a few articles and noticed that the images slightly overlapped the image caption. Here are a few examples: Dongdaesan (Ulsan), Hoemunsan, Sikjangsan. Maybe it's just my display, but it doesn't look like other infoboxes are doing that. Perhaps adding a small buffer of whitespace between the two elements would look better? Alternatively, please let me know if I'm doing something incorrectly. Thanks in advance for your feedback! Rystheguy (talk) 16:34, 20 March 2015 (UTC)

 Fixed I'm not sure what's causing it, because a) I don't see it in Firefox, and b) we aren't doing anything special with the captions. I went ahead and added a little bit (0.2em) of padding above and below the image caption, which will hopefully fix the problem you're seeing. —hike395 (talk) 06:14, 4 April 2015 (UTC)
Such styling would be better applied at {{Infobox}}, rather than here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:15, 4 April 2015 (UTC)
They're saying that it only shows up in Mountain infoboxes, for some reason. I don't understand why. —hike395 (talk) 15:37, 4 April 2015 (UTC)
could be caused by the datastyle? I would remove the labelstyle, datastyle, captionstyle, ... and see if it is still a problem. Frietjes (talk) 14:52, 12 April 2015 (UTC)

Template-protected edit request on 7 December 2015

At the end of field 39 (Range coordinates), the {{#if}} block for parameter range_coordinates_note should be completely outside the outer {{#if}} block. That is, the range_coordinates_note should appear even when the range coordinates are specified (in this template's documentation, range_coordinates_note is described as "Add a note after the Range coordinates link"). That's how the range_coordinates_note parameter behaved back at {{Infobox mountain range}}.

More specifically, line 231 should read:

}} }}{{#if:{{{range_coordinates_note|}}}| {{{range_coordinates_note}}} }}

instead of

}}|{{#if:{{{range_coordinates_note|}}}| {{{range_coordinates_note}}} }} }}

—Laoris (talk) 19:42, 7 December 2015 (UTC)

fixed, not exactly how you suggested, but should be fixed. Frietjes (talk) 22:37, 7 December 2015 (UTC)

Requested edit to incorporate native_name_lang parameter

The parameter native_name_lang is discussed in the documentation but not used in the template. I think this is supposed to be used by wrapping all appearances of native_name like so:

<span {{#if:{{{native_name_lang|}}}|lang="{{{native_name_lang}}}"}}>{{{native_name}}}</span>

This is consistent with {{Lang}} and the way this is handled in other infoboxes, such as {{Infobox settlement}}. Ibadibam (talk) 20:14, 16 December 2015 (UTC)

 Done I restored the code from the pre-merge version of {{Infobox mountain}}. —hike395 (talk) 04:42, 17 December 2015 (UTC)

Diameter

It might be appropriate to add a |diameter= parameter for mountain ranges and large mountains. Volcanoguy 05:09, 31 December 2015 (UTC)

Proposed deletion of maintenance Category:Pages using deprecated coordinates format

A maintenance category used for this template, Category:Pages using deprecated coordinates format, is being considered for deletion here. Your input is requested.   ~ Tom.Reding (talk ⋅dgaf)  14:34, 16 January 2016 (UTC)

Altitude conversion error

Whilst editing a page on Les Droites, which has an altitude of exactly 4,000 metres, I noted that the Infobox displayed a wildly incorrect automatic conversion to feet. (namely, 13,000 ft, when it should have been 13,123 ft). It became clear that the Infobox template is not using the correct precision parameter for the field elevation_m, and is automatically rounding exact numbers of thousands of metres into an equivalent round number of thousands of feet. All other, heights convert correctly. This is something that users of the Template:convert can control, but I don't know how it's operating within the mountain Infobox. See below:

With no precision parameter used: {{convert|4000|m|ft}}

5000

  • 5,003 metres (16,414 ft)
  • 5,002 metres (16,411 ft)
  • 5,001 metres (16,407 ft)
  • 5,000 metres (16,000 ft)
  • 4,999 metres (16,401 ft)
  • 4,998 metres (16,398 ft)
  • 4,997 metres (16,394 ft)
  • 4,996 metres (16,391 ft)

4000

  • 4,003 metres (13,133 ft)
  • 4,002 metres (13,130 ft)
  • 4,001 metres (13,127 ft)
  • 4,000 metres (13,000 ft)
  • 3,999 metres (13,120 ft)
  • 3,998 metres (13,117 ft)
  • 3,997 metres (13,114 ft)
  • 3,996 metres (13,110 ft)

With correct precision parameter: {{convert|4000|m|ft|0}}

5000

  • 5,003 metres (16,414 ft)
  • 5,002 metres (16,411 ft)
  • 5,001 metres (16,407 ft)
  • 5,000 metres (16,404 ft)
  • 4,999 metres (16,401 ft)
  • 4,998 metres (16,398 ft)
  • 4,997 metres (16,394 ft)
  • 4,996 metres (16,391 ft)

4000

  • 4,003 metres (13,133 ft)
  • 4,002 metres (13,130 ft)
  • 4,001 metres (13,127 ft)
  • 4,000 metres (13,123 ft)
  • 3,999 metres (13,120 ft)
  • 3,998 metres (13,117 ft)
  • 3,997 metres (13,114 ft)
  • 3,996 metres (13,110 ft)

Perhaps someone is able to edit the Infobox to correct this problem and ensure that users are aware of this issue when they use only the elevation_m field? Parkywiki (talk) 15:53, 23 May 2016 (UTC)

Update: The problem is more widespread than I thought at first - altitudes given in elevation_m as rounded units of 10 metres are also themselves rounded, so these errors will be much more common. e.g.: Aiguille de Tré la Tête appears in the Infobox as 3,930 metres (12,890 ft) instead of 3,930 metres (12,894 ft) Parkywiki (talk) 16:08, 23 May 2016 (UTC)

It's not an error -- it's ambiguity in the number of significant figures. When someone enters 4000m, the software doesn't know how many significant figures the editor meant to use. It could be 1, it could be 4. Not all mountain peaks have elevations that are accurate to 1 meter.
There is a relatively easy work-around: don't use |elevation_m=, but use |elevation= and use {{convert|4000|m|ft|0}} as the value. —hike395 (talk) 03:06, 26 May 2016 (UTC)
I suspect that most mountain heights are correct to the nearest metre, so changing the infobox to round to this accuracy might be appropriate? — Martin (MSGJ · talk) 08:02, 26 May 2016 (UTC)
I'm sorry, hike395, but the Infobox conversion process is creating an error - an error in the metres and feet height being displayed. Work-arounds are quite inappropriate here, especially if users aren't aware there's a problem in the first place. Any field with a name "data_m" is clearly asking for data in metres - just read the parameter explanation for Elevation_m: "Height of highest point in the range, in meters, as a number (e.g., 8848). Will automatically convert to feet." (Except that it doesn't do this correctly with numbers ending in '0', '00' or '000'!) So if the user ever gets as far as reading the template field explanations, she/he would expect the metres to feet conversion to be done accurately, rounded to one whole unit - and that's clearly not happening for mountain heights ending in one or more zeros. I'm not saying the rounding up/rounding down process is happening incorrectly within the "convert" procedure. I'm saying The Infobox is employing the incorrect "convert" protocol, and that rounding up or down should not be happening here within this template field at all. The work around you suggest is not a practical solution - that's what "elevation" field is for, surely: free form text such as "c.5,000m" if there's uncertainty. The current rounding down of a 5,000 metre mountain introduces a displayed error of 400 feet, which is by no means insignificant. The displayed error due to rounding down also exists in the elevation_ft field (e.g.Mount Pinchot (California)).
The Infobox mountain template definitely needs to be modified to do true conversion of metres to feet, and vice versa, rounded to an accuracy of whole units. Parkywiki (talk) 08:21, 26 May 2016 (UTC)
I dispute that rounding to the nearest m/ft for elevation (or prominence) is "correct". What if the user enters |elevation_ft=946.5 ? Is the right answer 946.5 feet (288.5 m) or 946.5 feet (288 m) ? —hike395 (talk) 13:54, 26 May 2016 (UTC)
You raise a valid but completely irrelevant point to the much greater concern over inaccuracy in height conversion that I am raising in this particular discussion. What's at issue here is that users of the current Infobox mountain (or any of its derivative Infoboxes in other Projects) would reasonably expect elevation_m or elevation_ft to do a fair conversion of the figure they enter, whatever accuracy they enter. This is simply not happening with the current convert protocol being applied in elevation_m whenever heights contain one or more zeros on the end. I believe it needs to be addressed by an authorised manager of this Template as a priority.
Enter exactly 4,000 metres into elevation_m in this Infobox and a mountain's height is 'incorrectly' converted and appears rounded down by 123 feet to 4,000 metres (13,000 ft). Add on one centimetre (0.001 m), and the converted height shoots back up to the correct converted figure i.e. 4,000.001 metres (13,123.36 ft). An error of hundreds of feet is much more concerning, and it's misleading readers. That's the issue I'm trying to raise here. Parkywiki (talk) 20:02, 26 May 2016 (UTC)
Hike395's comments are relevant actually. The point he/she is making is that if you enter 4000 there is no way for the conversion template to know how accurate your value is supposed to be. (Nearest thousand / hundred / ten / one?) Enter 4000.0 and there is no ambiguity and the template works just fine. — Martin (MSGJ · talk) 08:07, 27 May 2016 (UTC)
Of course there's no way for a conversion template to know what anyone means when they enter 4000 feet, or 4000 metres! Editors should only enter 4000 if they mean 4000, and can derive that height from a reliable third party source. If an editor can't, then they shouldn't enter that figure at all - and certainly not in a field clearly intended to display a known altitude and then make an accurate conversion from one set of units to another. But it is failing to achieve that task every time a mountain's height has one or more zeros on the end. (e.g.4,000 4,500 or 4580) I thought Wikipedians were meant to care about accuracy, but the work-around you have suggested is that editors add a false level of additional accuracy by adding .0 to almost every mountain's altitude simply to make a conversion formula display the desired figure correctly on Wikipedia. If the height of a remote mountain is still only known as a rough number of thousands of feet or metres, isn't the place to enter that figure as freeform text in the 'elevation' field, and not 'elevation_ft, or elevation_m? Meanwhile, the Infobox mountain is still not using the most appropriate conversion formula, and I'm simply requesting that it be corrected. I note that edits have just been made to Les Droites to solve the problem on that particular page, but there must be thousands of mountain pages where summits have an established height that happens to end in units of ten, twenty, thirty, forty, fifty, sixty, seventy, eighty, ninety or hundreds, be they feet or metres. Are you proposing we edit them all, when a simple change to one conversion protocol in one Infobox template would be the elegant and logical solution? Parkywiki (talk) 09:48, 28 May 2016 (UTC)
@Parkywiki: Breaking news: it is impossible for any mountain to be exactly 4000m high. It could be 4000±500, 4000±50, 4000±5, 4000±0.5, 4000±0.05, etc. Why are assuming (incorrectly it seems from hike395's analysis) that the 4th one is the intended accuracy? — Martin (MSGJ · talk) 09:07, 8 June 2016 (UTC)

Yes, we have to edit them all, using a tool like WP:AWB. MOS:CONVERSIONS and MOS:UNCERTAINTY are quite clear about this. If the source of elevation (or prominence) is accurate to one meter or foot, then we should use that accuracy in the |elevation= field. Many peaks in South America are only accurate to 10 meters, and we should not add undue precision. —hike395 (talk) 12:57, 28 May 2016 (UTC)

we could add a tracking category to find them. just add something like {{#if:{{{elevation_m|}}}|{{#ifexpr:{{precision|{{{elevation_m|0}}}}}<0|[[Category:Pages using infobox mountain with an imprecise elevation]]}}}} to the foot of the template code ... Frietjes (talk) 14:05, 28 May 2016 (UTC)
"Works around" are not the answer. This is a serious flaw in the template logic that editors will be totally unaware of and therefore needs to be fixed. Meanwhile I've added a warning on the template page. Bermicourt (talk) 14:13, 28 May 2016 (UTC)
This is not a flaw in the template. This behavior is by design and follows the MOS (as described, above), just like the {{convert}} template.
I just spent 1 hour working with WP:AWB, going through ~1,000 of the ~20,000 articles that transclude this template. I used AWB to filter down to articles that use |elevation_ft= and whose values end in one or more zeros. I carefully checked and fixed 17 articles --- some of which did not use the best sources, so I found better elevations for a subset (perhaps 6?). In addition, I had to leave 6 articles as they are, because the best sources (even for North America) did not have elevations that were accurate to 1 foot. Those articles are:
From this sample, forcing elevation_ft to be precise to 1 ft will fix only about twice as many errors as it causes (via overprecision). Given MOS:CONVERSIONS and MOS:UNCERTAINTY direct us to be conservative in precision, I oppose the proposed assumption of precision.
If Parkywiki and Bermicourt wish to change the general behavior of rounding and precision for Wikipedia, I would suggest joining the discussion that MSGJ started at Template Talk:Convert, or bring up the issue at WP:WikiProject Geographical coordinates and WP:WikiProject Mountains.
I will continue to (slowly) fix any lack of precision using AWB. If any other editors wish to help out, they are more than welcome. The editing is slow, due to needing to consult elevation sources to determine their precision. —hike395 (talk) 15:43, 28 May 2016 (UTC)
Later -- I went back and counted: I changed the elevation on 6 of the infoboxes. So, 11 articles could benefit from forcing precision to 0, while 6 articles would be overprecise. I suspect for |elevation_m=, the fraction of harm would be higher, because there are many regions in the world where elevations are not precisely determined (Himalaya, Andes, Antarctica). —hike395 (talk) 16:00, 28 May 2016 (UTC)
I started working on |elevation_m=, which is more difficult. Many of the worldwide elevations are unsourced. From a small sample, Wank (mountain) seems to have precision +/- 0.5m, while
have reliable sources with conflicting elevations, so +/- 5m is a more appropriate precision. More evidence against rounding to the nearest meter. —hike395 (talk) 17:21, 28 May 2016 (UTC)
I'm afraid I don't understand what you're on about. It's got so technical that no-one is ever going to apply this Infobox correctly, it would seem. Where units are known to an accuracy of a whole unit (feet or metres), or better, they should be entered in elevation_m or elevation_ft and correctly converted, but this is not happening. Where heights are estimates, or not known to a unit of a single metre, or better, it seems to me that their values should be entered as free-text in the elevation field, and the template's instructions should be clear on how to use the convert template to reflect this uncertainty. I remain concerned that users of the current Infobox mountain template and its child templates will not appreciate these subtleties, and that significant errors of conversion will exist on numerous Wikipedia pages and repeated as nauseam until the template and its instructions are modified. Sorry to be negative, but I can't see the value of editing innumerable pages when they're not at fault. Perhaps I'm missing something in this discussion, but I still don't understand why you're being so protective of the Infobox mountain template when its elevation conversion protocol is so flawed for mountains with a known height. Parkywiki (talk) 23:25, 7 June 2016 (UTC)

Trying to summarize: in WP, there's a standard method of rounding values without known precision, following the guidelines at MOS:CONVERSIONS and MOS:UNCERTAINTY, described at {{convert}}. This infobox (and several others) follows the standard method. When I look at mountain elevation data that editors actually entered that ends in 0, about 2/3 of |elevation_ft= is precise to 1 foot, while about 20% of |elevation_m= is precise to 1 meter. So, always rounding to 1 foot or 1 meter introduces overprecision errors, and goes against the guidelines of MOS:CONVERSIONS and MOS:UNCERTAINTY. Not sure what else to say or do, other than to try to fix the underprecision errors via AWB. —hike395 (talk) 11:18, 8 June 2016 (UTC)

Data from Wikidata

Shall we get some data for this infobox from Wikidata, if it is not specified in the article? I'll make a list of fields that might usefully get their data from Wikidata properties ... — Martin (MSGJ · talk) 07:48, 22 April 2016 (UTC)

As a start there are the following relevant properties: — Martin (MSGJ · talk) 08:03, 22 April 2016 (UTC)
Sounds like a good idea. I don't know how to implement it, but perhaps you do? —hike395 (talk) 14:52, 22 April 2016 (UTC)
I know a little, but I'm not an expert ;) I have asked a question at User talk:Mike Peel#Question about using Wikidata which is generating some discussion. Probably better to wait and let the technical details get ironed out for now. — Martin (MSGJ · talk) 08:29, 26 April 2016 (UTC)
Code to use the elevation from wikidata is now in the sandbox. Tested and working. This will only happen if the elevation field is undefined in the infobox. Can I implement this as a start? — Martin (MSGJ · talk) 19:09, 13 June 2016 (UTC)
No comments so now  deployed and tested on 5 mountains. — Martin (MSGJ · talk) 13:19, 15 June 2016 (UTC)

Similar code for Prominence and Isolation is now in the sandbox — Martin (MSGJ · talk) 13:24, 15 June 2016 (UTC)

The automatic linking of the "parent" or "range" parameter in the template footer is not a good idea; editors should be able to choose whether the parameter is linked or not, particularly if it is a red link. Also, the automatic linking in some cases links to a disambiguation page, as on Mount Helicon, which links to the dab page Helicon. This cannot be fixed with the template in its current state. The specific change needed is to remove the square brackets on the parameter:

Old: 

| data40   = {{#ifexist:{{{parent|}}}|[[{{{parent}}}]]|
             {{#ifexist:{{{range|}}}|[[{{{range}}}]]|
             {{ifempty|{{{parent|}}}|{{{range|}}} }} }} }}

New: 

| data40   = {{#ifexist:{{{parent|}}}|{{{parent}}}|
             {{#ifexist:{{{range|}}}|{{{range}}}|
             {{ifempty|{{{parent|}}}|{{{range|}}} }} }} }}

—swpbT 13:51, 17 June 2016 (UTC)

In that case I don't see the purpose of the ifexist checks. — Martin (MSGJ · talk) 13:57, 17 June 2016 (UTC)
I don't either, I was just going for the minimal necessary change in case there was something I wasn't seeing. If there's no more need for them, they can go. —swpbT 14:19, 17 June 2016 (UTC)
The following code should be fine. Then editors can link if they choose to. — Martin (MSGJ · talk) 14:36, 17 June 2016 (UTC)
| data40   = {{{parent|{{{range|}}}}}}

Please implement the code change as specified by User:MSGJ immediately above this request. —swpbT 18:08, 20 June 2016 (UTC)

Ok, then add an opt-out parameter. The current status of the template isn't just unusual, it breaks best practice. Leaving it is not an acceptable option. With opt-out: 

| data40   = {{#if:{{{no_range_link|}}}|{{{parent|{{{range|}}}}}} |
             {{#ifexist:{{{parent|}}}|[[{{{parent}}}]]|
             {{#ifexist:{{{range|}}}|[[{{{range}}}]]|
             {{ifempty|{{{parent|}}}|{{{range|}}} }} }} }} }}

Further discussion

Please implement the opt-out parameter described above, and add the corresponding "no_range_link" parameter to the /doc. —swpbT 20:35, 20 June 2016 (UTC)

@Swpb: It might be better to seek consensus than to add yet another param, since param growth is something many folks disapprove... but this doesn't look exactly controversial. I'll leave it to BU Rob13 or others, but this can go live if there are no further comments I think. Also, swpb, next time, consider updating the template's sandbox and testcases (as in here) so that folks who have no context have a quick reference for the visual change. — Andy W. (talk · ctb) 21:07, 20 June 2016 (UTC)
Suggestion: Why not (1) create a tracking category with all the articles which are being automatically linked, (2) have a bot switch all the entries in the tracking category to explicit links, then (3) remove the automatic linking. Once this is done, any links to disambiguation pages can be addressed on a per-article basis. Seems much better than having some complicated opt-in/opt-out for automatic linking when automatic linking is already deprecated. Thanks! Plastikspork ―Œ(talk) 23:09, 20 June 2016 (UTC)
Full agreement with this. Auto-linking is in every transclusion (as far as I can tell from the code), so that's ~20800 pages. The bot should be wary of the field already having an explicit link, not to link again, otherwise, seems simple. Clarification: meant that a bot could do the "ifexist" check. — Andy W. (talk · ctb) 23:51, 20 June 2016 (UTC) 23:58, 20 June 2016 (UTC)
As the editor responsible for the code, I support Plastikspork's suggestion. The autolinking was inherited from {{Geobox}} --- I never thought it was a good idea, but didn't want to break backward compatibility in porting over articles to {{Infobox mountain range}}. Anyone volunteer to write the bot/AWB script? —hike395 (talk) 01:53, 21 June 2016 (UTC)
Later --- the fact that this feature came in with the merge of {{Infobox mountain range}} may make this simpler. The autolinking can be turned off in the template, and the bot can skip any article that transcludes {{Infobox mountain}} directly, because autolinking only occurred post-merge, and we'd be returning the template back to its original behavior. —hike395 (talk) 01:59, 21 June 2016 (UTC)
I have disabled the request as we are still discussing this. Personally I oppose the idea of a separate opt-out parameter. Automatic linking is generally a bad idea and I suspect a lot of these were never to be links by their editors. If we have agreement here we could remove all these links and see if anyone actually objects. I will drop a note on Wikipedia talk:WikiProject Mountains now. — Martin (MSGJ · talk) 10:31, 21 June 2016 (UTC)

Turn off all autolinking

If someone is going to go to the trouble of writing a bot, might as well turn off all autolinking behavior, on parameters:

  • |highest=
  • |elevation_system=
  • |parent=
  • |range=
  • |orogeny=
  • |period=
  • |period1=
  • |geology=
  • |geology1=
  • |geology2=

Comments? —hike395 (talk) 02:06, 21 June 2016 (UTC)

I could write the bot code pretty quickly, but I probably won't have time until this weekend to file the formal bot request. Plastikspork ―Œ(talk) 03:36, 22 June 2016 (UTC)
Will your bot be able to detect disambiguation pages? How could it avoid linking to inappropriate articles? — Martin (MSGJ · talk) 08:07, 23 June 2016 (UTC)
Anyone up for writing a bot? Plastikspork? Or should we just remove the autolinking entirely? —hike395 (talk) 19:42, 25 June 2016 (UTC)
hike395, I have a bot which could do it. I will write up a formal BRFA tomorrow. Thanks! Plastikspork ―Œ(talk) 22:04, 25 June 2016 (UTC)

Rounding of elevation and prominences

I've started a discussion about rounding of elevation and prominence values given by reliable sources, such as Peakbagger. The discussion is occurring at WT:WikiProject Geographical coordinates#Rounding of elevation and prominences in mountain infoboxes. Feel free to join in. —hike395 (talk) 14:24, 28 August 2016 (UTC)

Error message and tracking category for unsupported parameters

I have added error tracking for unsupported parameters to this template. See Category:Pages using infobox mountain with unknown parameters. A red error message appears when you Preview the article, between the edit screen and the rendered preview. In the category, the articles are sorted by the name of the parameter that is unsupported.

I have added this error-checking to a number of heavily used infoboxes, and it usually goes smoothly, highlighting errors that improve the articles that end up in the category. Every once in a while, parameters are missed or something goes wrong. If that happens, don't panic, just post here and I will be happy to fix it. Revert the change if you feel that you must.

If I have made any mistakes in coding, or if template changes are desired, please let me know. – Jonesey95 (talk) 04:04, 7 September 2016 (UTC)

What to expect: The category will add pages over a period of a few weeks. Since an organized check has presumably never been performed, the infobox has been silently ignoring unsupported parameters, so it will not be surprising if a few thousand articles end up in the maintenance category. I'll be happy to help clean up those unsupported parameters or help knowledgeable editors decide what to do with them. So far, I'm seeing a few hundred articles whose infoboxes use parameters like |relief=, |timezone=, and |category=, along with a scattering of others. Articles in the "0–9" group are using unnamed parameters; that is usually a typo of some sort, or a remnant of a previous version of a template that supported unnamed parameters. – Jonesey95 (talk) 04:53, 7 September 2016 (UTC)

Proposed deletion of maintenance categories

As far as I can tell, the template merge with infobox mountain range is complete, and the following two categories are no longer needed. They do not appear to be referenced in the template code:

Is it OK to mark these categories for speedy deletion? – Jonesey95 (talk) 13:55, 7 September 2016 (UTC)

Excellent catch. Yes, please delete those categories. —hike395 (talk) 09:51, 8 September 2016 (UTC)

Template edit request: add activity level parameter

For volcanoes using the infobox mountain template, would it not be useful to include an activity level indicator, to specify whether it is extinct, dormant, or active. Although the "last eruption" parameter is used to serve this purpose in quite a few volcano articles, frankly it seems backwards, and it would definitely be useful to include a more direct parameter to indicate their current state. exoplanetaryscience (talk) 19:36, 31 January 2017 (UTC)

The volcano article says that those three words are "practically meaningless to scientists". – Jonesey95 (talk) 21:22, 31 January 2017 (UTC)
I agree with Jonesey: activity level is too vague to put into the Infobox —hike395 (talk) 04:35, 1 February 2017 (UTC)

Coordinates syntax

per WP:Coordinates in infoboxes, I have enabled the use of |coordinates= in the location map. this has exposed some bad syntax in the coordinates fields, with some articles popping up in Category:Pages with script errors. the error is easy to fix, so this should just be a temporary issue. please let me know if there are any more serious problems. Frietjes (talk) 17:45, 14 March 2017 (UTC)

Interior Mountains

I just removed Thudaka Peak from the Interior Mountains infobox because it is not the highest point of that range. But for some reason the elevation of Thudaka shows up in the infobox despite it having been edited out. How can it be removed? Volcanoguy 22:01, 24 May 2017 (UTC)

This appears to be an issue on all articles that use this template and should be looked at. Volcanoguy 22:01, 25 May 2017 (UTC)
This effect is caused by a call to wikidata from the template:

| label6   = [[Summit|Elevation]]
| data6    = {{#if:{{{elevation|}}} | {{{elevation|}}}
             | {{#if:{{{elevation_m|}}}{{{elevation_ft|}}}|{{convinfobox|{{{elevation_m|}}}|m|{{{elevation_ft|}}}|ft}}|{{convert|input=P2044}} }}}}
The "P2044" wikidata element is "elevation above sea level". If you go to the article and click "Wikidata item" in the left sidebar, you will see this information. This change was introduced by MSGJ on 15 June 2016. – Jonesey95 (talk) 05:36, 26 May 2017 (UTC)
If the information is incorrect, then just remove it or update it on Wikidata. — Martin (MSGJ · talk) 23:12, 26 May 2017 (UTC)
What is the purpose of Wikidata? Volcanoguy 18:08, 27 May 2017 (UTC)
Basically to share data across all Wikipedias so that each language Wikipedia does not have to maintain its own set of data — Martin (MSGJ · talk) 08:24, 9 June 2017 (UTC)

Rounding elevation

Wikid77 added |0 to the call to {{convinfobox}}, which would force conversion to be to the nearest foot or metre. While mountain elevations are generally known to 1 foot in the United States, in many parts of the world (e.g., the Andes, Antarctica), the elevations have 10 meters of uncertainty, or even more. According to MOS:CONVERSIONS, conversions should "should use a level of precision similar to that of the source quantity value". We can't globally decide this inside the infobox code. MOS:UNCERTAINTY says "the precision presented should usually be conservative". If we aren't reasonably sure that a value is good to 1 foot or metre, then we shouldn't round it that way.

Comments? Thoughts? —hike395 (talk) 16:02, 2 July 2017 (UTC)

hike395, I agree with your assessment and revert of this change. Frietjes (talk) 16:08, 2 July 2017 (UTC)
  • Elevation should allow hand-conversion or precision override: Formerly, by specifying both "elevation_m=" and "elevation_ft=" it was possible to allow hand-conversions of amounts, but recently elevation_m has reset elevation_ft. Also, we need a precision parameter such as "elevation_prec=" to pass "|-1" for rounding to nearest 10, but note how nearest "10 m" is nearest "33 ft" or such, and the old convert formerly allowed "near=30" to round nearest 30 feet. We can fix the current templates to handle these issues. I see some sources have both m/ft values (which could be hand-specified to avoid over-rounding). For example, both "5,960 m" and "19,549 ft" could be shown to avoid automatic conversion "19,549 ft (5,959 m)" plus link source for both. For over 11 years, we have had similar problems with hurricane windspeeds which are measured in knots then rounded by NHC to nearest 5 mph and km/h to reflect precision, but those mph & km/h do not cross-convert, and some users have forced conversions over 10 years unaware of source values. -Wikid77 (talk) 22:24, 2 July 2017 (UTC)
OK, this sounds like an issue with {{convinfobox}}, although poking around, it looks like it hasn't substantially changed since 2013. I don't understand the details of the template: it looks like we want to make {{convinfobox/prisec2}} not be a redirect? Frietjes, it looks like you've edited this template before, can we make it do what Wikid77 wants? —hike395 (talk) 06:35, 3 July 2017 (UTC)
Later --- without any template editing, editors of articles can always choose to use |elevation= instead of |elevation_ft=, and use {{convert}} or {{cvt}} directly. Would that satisfy you, Wikid77? —hike395 (talk) 06:36, 3 July 2017 (UTC)
hike395, I think the automatic overwrite of "elevation_ft=" needs to be fixed, to allow both to be specified by users when needed. There are regulations in various nations about how conversions should be calculated (increase precision+1 when first digit lower), with special rules for precise limits, as with safety of heights or maximum temperatures, so it is best to use the converted values from a source, such as both "5,960 m" and "19,549 ft" together, just as hurricane windspeeds should set both mph+km/h directly from source (not cross-converted or re-rounded). The conversions can be quite complex to meet legal restrictions, and hence {convert} has over-rounded amounts for over 10 years (very difficult to match regulation conversion rules in many cases), and so hand-coding both is easiest for now. -Wikid77 (talk) 15:08, 3 July 2017 (UTC)
@Wikid77 and EncMstr: I disagree that Wikipedia should follow sources in their rounding (see previous attempt at discussion here). I believe that rounding is a matter of formatting, rather than verifiable fact or legal requirement. Rounding should be governed by MOS:CONVERSIONS and MOS:UNCERTAINTY. Other editors have disagreed with this statement: it would be great to get consensus in favor / against. —hike395 (talk) 21:51, 3 July 2017 (UTC)
If the reliable source provides a statement of the accuracy, the rounding should reflect it. For example, the National Geodetic Survey datasheet gives an orthmetric height for Killington Peak and links to an NGS page where the accuracy can be computed (1289.1 m ± 0.04 m, 95% confidence level, North American Vertical Datum of 1988). Jc3s5h (talk) 23:06, 3 July 2017 (UTC)
Cvt allows +/- as {{cvt|1289.1|+/-|.04|m}}: 1,289.1 ± .04 m (4,229.33 ± 0.13 ft). -Wikid77 (talk) 10:53, 4 July 2017 (UTC)
I agree with Jc3s5h's statement, and believe it does not contradict what I said. We can rely on sources' estimates of accuracy to guide our rounding. However, many sources, e.g., Peakbagger, round to the nearest meter regardless of the underlying accuracy. I don't think we should follow that sort of rounding. —hike395 (talk) 02:59, 4 July 2017 (UTC)
Rounding upward can be used to ensure clearance, such as radio reception, where a half-metre rounded below peak blocks radio signals, while above gets signal. U.S. conversion regulations (NIST) handle official product verification, tested to highest amount, such as 16 ounces often truncated to 453 grams (on labels), so a product will be tested below 454 grams. We should handle legal restrictions, per sources, on specifying elevation. Meanwhile, MOS:CONVERSIONS is wrong where Moon is 380,000 km (236,000 mi), not "240,000" as violation of U.S. numeric regulations. -Wikid77 (talk) 10:53, 4 July 2017 (UTC)
hike395, using |elevation= with {{convert}} instead of |elevation_m= and |elevation_ft= is definitely the way to go for cases where you need to override the default precision. Frietjes (talk) 13:02, 3 July 2017 (UTC)
I reject all of Wikid77's legal musings. Laws and regulations only apply to the specific field addressed by the law, such as radio regulations on calculating coverage areas of commercial radio stations, or regulations on describing potential hazards to aviation. Since Wikipedia is a general-interest publication, these rules and laws do not apply. And last time I checked, the Moon does not belong to the United States. Jc3s5h (talk) 11:36, 4 July 2017 (UTC)

Ha ha, ok I'll play along with joke, as the Moon is actually made of "green cheese" so it must be owned by Martians (also green) who measure distance in Mars bars, and everyone knows they hate converting to other units. No seriously, the international standards are codified for America by the U.S. NIST (as in NIST Handbook 30 or document SP1038) so that conversions of technical specifications can be used internationally, not just for scientific projects, but along with global commerce for packages manufactured to be sold also in the U.S. Those regulations merely specify calculations which have been known for decades as "best practices" in converting units for state-of-the-art technical specs, so that is why standard conversion to miles has precision+1 for lower first significant digit (see PDF: page 6) of Moon distance: 380,000 km (236,000 mi), as 236 not "240" thousand miles. Other unit conversions are more complex, so I am creating another conversion template to display those amounts which {convert} cannot calculate by the simple rounding techniques used during the past 10 years. -Wikid77 (talk) 20:26, 4 July, +PDF links 20:51, 4 July 2017 (UTC)

I have no problem following NIST best practices that are intended to be useful in general situations. It's only using laws or rules aimed at particular fields where overstating may be better than understating (or vice versa) that I have a problem with. Thanks for the reminder of page 6 of SP1038; I've been trying to remember where I saw that sort of procedure. Jc3s5h (talk) 21:46, 4 July 2017 (UTC)
If you want a large number of articles to adopt your template, then I strongly recommend going to WT:DATE and getting consensus around using NIST Handbook 1038 as the preferred rounding mechanism, rather than what is described in MOS:CONVERSIONS today. —hike395 (talk) 20:15, 5 July 2017 (UTC)
I also wanted to confirm similar rounding in other cultures, such as increasing precision +1 when a conversion calculates the first significant digit as lower (German: "erste signifikante Ziffer... kleiner"), but it would be good to discuss this issue with WT:DATE so that more people would be aware to increase precision by +1 in similar conversions. -Wikid77 (talk) 19:33, 8 July 2017 (UTC)

coordinates_ref not being displayed

The coordinates_ref parameter does not seem to be working after checking several pages where it's actually specified. I searched the infobox code and it is still used but for some reason it won't display. I really haven't gotten into LUA coding so can't tell at first glance where the problem lies. Could it have been broken by the conversion of the individual coordinates? RedWolf (talk) 19:38, 6 August 2017 (UTC)

RedWolf, thank you for reporting the bug. it should be fixed now. if not, please ping me. Frietjes (talk) 19:49, 8 August 2017 (UTC)
Looks good. Seems it was caused by some missing braces -- I guess the LUA parser can't detect that to output a warning. Thx for the quick turnaround time. RedWolf (talk) 01:36, 9 August 2017 (UTC)

First winter ascent

Definitely missing in the infobox "First winter ascent". — Preceding unsigned comment added by Mike Lewacki (talk • contribs) 14:03, 28 August 2017 (UTC)

Elevation: Snow & Rock

Requesting parameter for Snow and Rock height. Example: Mount Everest: the rock height (8,844 m., China) and the snow height (8,848 m., Nepal) <-- Infobox Data Twillisjr (talk) 05:47, 10 October 2017 (UTC)

|nocat_wdimage=yes not supported

Needed to use this parameter here but it doesn't seem to be supported. (Peña de los Enamorados is the specific case. Frietjes can you take a look. MB 03:56, 13 October 2017 (UTC)

MB, added. by the way your attempt to ping me didn't work. I believe it is because your signature doesn't include a link to your talk page. per Wikipedia:Signatures#CustomSig A customised signature should make it easy to identify the username, to visit the user's talk-page, and preferably user page. so, if you are finding that people are not responding to your pings, this is probably why. Frietjes (talk) 15:52, 13 October 2017 (UTC)
Frietjes, thanks for the fix. Was unaware of possible ping problem. Please let me know if this one works. MB 16:02, 13 October 2017 (UTC)

Remarks parameter

Please could we add a "Remarks" parameter. Currently when I translate mountain articles from German Wikipedia, the infoboxes are automatically replaced by this one and all the parameters display properly except for the equivalent of "Remarks" which displays under "Listing". It would be great to have a Remarks parameter so we retain the information rather than losing it or incorrectly displaying it as at present. Thanks. --Bermicourt (talk) 20:49, 1 December 2017 (UTC)

Unlisted parameters

It appears not all parameters of this template are listed in the "Parameters" section, with |geology= and |range_coordinates_note= being a few examples. The geology parameter shows up as "Type of rock" in the infobox which could be piped to list of rock types. Volcanoguy 19:16, 7 February 2018 (UTC)

 Done, at least for those two. —hike395 (talk) 08:47, 20 October 2018 (UTC)

child name

It seems that when child=yes, the name parameter is ignored. See: Old revision of Toro Negro State Forest#Campgrounds. There are attempts here to work around the problem by inserting the name between infoboxes. In the next update I worked around the problem by moving the name into other_name. —Anomalocaris (talk) 06:30, 14 June 2018 (UTC) —Anomalocaris (talk) 06:30, 14 June 2018 (UTC)

@Anomalocaris:  Not done The |child= parameter is for when the mountain infobox is part of a larger infobox (as opposed to being a second or later infobox on a page). So you probably don't want to use |child=. If I misunderstood, let me know. —hike395 (talk) 08:50, 20 October 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_mountain/Archive_3&oldid=922275082"