Template talk:Infobox mountain

English translation

In 2013, I brought up |English_translation= (apparently now just |Translation=) and asked if it's really necessary to have "English" in the infobox text with no response. "English translation" is rather cluttery and could be shorted to just "Translation" with the parameter changed back to |English_translation= so users know |Translation= is for English. Volcanoguy 19:27, 21 November 2024 (UTC)

How about changing just the label to "Translation" and making sure it's well-documented? I don't like long parameter names. — hike395 (talk) 06:09, 22 November 2024 (UTC)

Yes I'm fine with that. Volcanoguy 15:06, 22 November 2024 (UTC)

map_image_caption

Some one has depreciated this parameter which has mucked up pages with an inappropriate warning message if used and total muck up where its used for reason - eg last edit on Kapenga Caldera which is map heavy, mainly due to me I am afraid. I even have used embed which would not normally be case as usually OSM maps are done under map_image after work on this infobox template by others earlier this year.

Can an editor with power please revert when for good reason the documentation for this template does not suggest this parameter is depreciated. ChaseKiwi (talk) 22:26, 30 January 2025 (UTC)

I'm sorry -- I don't understand the problem? AFAIK, |map_image_caption= has not be deprecated. Is there a diff you could show that has a problem? — hike395 (talk) 00:45, 31 January 2025 (UTC)

It looks like you're talking about this edit by @RedWolf

I checked and the edit at the previous revision actually says:

Preview warning: Page using Template:Infobox mountain with deprecated parameter "map_image_caption"

--Joy (talk) 11:08, 31 January 2025 (UTC)

I've reverted the edit, but it is confusing why this deprecated warning happens, I can't quite see which part of the template code says so, either. It seems to be listed normally as a parameter to {{Check for unknown parameters}}. --Joy (talk) 11:10, 31 January 2025 (UTC)

There seem to be two separate calls to Module:Check for unknown parameters in the code, one for "unknown" parameters and the other for "deprecated" parameters. This one is being caught by the second call — Martin (MSGJ · talk) 11:30, 31 January 2025 (UTC)

Huh, you're right, there's two of them... and some of it also appears in my last move from sandbox, and I actually noticed this before but was distracted by other changes at the time.

These lists are such copy&waste magnets, it's such a bad pattern... --Joy (talk) 13:06, 31 January 2025 (UTC)

Ta, thanks for fixing issues ChaseKiwi (talk) 09:23, 1 February 2025 (UTC)

I think there are three problems that still need to be fixed.

1. Joy points out that the behavior of |map_image_caption= is not the same as |map_caption=. This means that |map_image_caption= is not deprecated and should be removed from any such list
2. Right now, Module:Check for unknown parameters is being misused in a confusing way. The template should be using Module:Check for deprecated parameters.
3. There are only a small number of pages that use the deprecated parameters (many of which are tests that I wrote). It could be time to actually remove the deprecated parameters if there are no more uses.

I can attempt a fix at these. — hike395 (talk) 14:22, 1 February 2025 (UTC)

 Done — hike395 (talk) 20:45, 1 February 2025 (UTC)

I'm not sure I agree with removing image_map/map_image options. It seems harmless? --Joy (talk) 13:22, 2 February 2025 (UTC)

I meant removed from the list of deprecated parameters, i.e., kept not deleted. — hike395 (talk) 19:05, 2 February 2025 (UTC)

OK but you actually removed them from being used? [1] --Joy (talk) 11:58, 3 February 2025 (UTC)

Not sure what "them" you are referring to? I didn't remove any usage of |map_image_caption=. The only pages I edited were subpages of User:Hike395 and some older test subpages of Template:Infobox mountain itself. — hike395 (talk) 19:54, 8 February 2025 (UTC)

Look at the link I posted above - [2] - that edit to the template seems to have removed the possibility for the users to interchangeably use both image_map and map_image, then map_image_caption and image_map_caption, etc.

Why would want to stop allowing these parameters with swapped words to be used by editors? --Joy (talk) 11:32, 9 February 2025 (UTC)

Oh I see what you mean: you are disputing whether |image_map= and |image_map_caption= should have been deprecated at all. There was a long and painful discussion five years ago over exactly which parameters to deprecate. A bot run was approved to remove usage of the deprecated parameters in articles, thus |image_map= and |image_map_caption= are currently unused in mainspace. No one had bothered to clean out the deprecated parameters until now.

I'm happy to restore |image_map= and |image_map_caption=. Given the previous discussion, it would be good to see if other editors agree. I'll start up a new section so that editors notice this. — hike395 (talk) 14:37, 9 February 2025 (UTC)

I just read through the old discussion and bot specification, and I don't actually see consensus around |image_map= and |image_map_caption= being deprecated. Given Joy's objection, I will just go ahead and restore those. — hike395 (talk) 14:55, 9 February 2025 (UTC)

Yeah I skimmed and searched it and can't find any mentions of this. Maybe it was subsumed under the goal #3 of removing duplicate parameters, but all I see about that was a discussion about a non-duplicate parameter :)

Obviously, if we never had code to support both parameter styles, it would be easy enough to say let's not introduce extra ones because the editors who try the inverted one will be warned by the parameter check code (which may not have existed before?) anyway.

But since we already do have it, and it doesn't actually seem to bother anyone, it doesn't seem to introduce any meaningful maintenance burden, and there's no obvious consistency guideline to be enforcing between different templates (TTBOMK), then I'd still say keep it. --Joy (talk) 16:35, 9 February 2025 (UTC)

I should probably add Module:Check for clobbered parameters for the incredibly rare case where someone uses both |image_map= and |map_image=. — hike395 (talk) 19:04, 9 February 2025 (UTC)

Thanks! --Joy (talk) 19:45, 9 February 2025 (UTC)

Naming

Would it be useful to have a parameter in this section of the infobox for when the mountain was named and by whom? Volcanoguy 20:29, 1 February 2025 (UTC)

No response? Volcanoguy 15:42, 5 February 2025 (UTC)

How much of this is in the articles as sourced material? Why should it be featured in the infobox? – Jonesey95 (talk) 23:55, 7 February 2025 (UTC)

I don't know how many articles cite such information, but I try to add it when I work on mountain articles. Government databases such as the US's Geographic Names Information System and Canada's Geographical Names Data Base give dates for when mountains and other features were officially named. It's only a tiny piece of information so I don't see why it shouldn't be featured in the infobox; it gives an idea of how long a mountain has been named. Yes, I know Wikipedia prefers to use common names over official names, but it's not unusual for common names to also be official names; most mountain articles I've seen use the official name. Since Canada and the US have thousands of officially named mountains and there are hundreds of articles about American and Canadian mountains on Wikipedia, a parameter for when a mountain was officially named could become of great use. I'd suggest |Adopted= if it were to be added in the infobox. Volcanoguy 01:00, 8 February 2025 (UTC)

And |Named_by= if there's information for whoever named the mountain. Volcanoguy 01:21, 8 February 2025 (UTC)

You are welcome to add a well-named parameter to the sandbox after syncing it with the live template. Then show how the new parameter would work on the testcases page. Note that the as yet undocumented parameter |authority= already exists; you might want to check how that is already used and whether it meets your request. Also, this template does not use capital letters in its parameter names, and |adopted= is an ambiguous name. Parameter names should be as clear and unambiguous as possible. Maybe check other, similar infobox templates for parameter naming ideas. – Jonesey95 (talk) 02:15, 8 February 2025 (UTC)

I'm not much of a template editor so it would be better if another user were to add it, not to mention {{Infobox mountain}} is permanently protected from editors like myself because it's a heavily used template. How is |adopted= more ambiguous than |authority=, especially if it were to be in the Naming section of the infobox? Authority usually refers to the agency responsible for making names official (e.g. see this BC Geographical Names entry). Volcanoguy 02:51, 8 February 2025 (UTC)

The documentation is not protected; feel free to explain |authority= there. The parameter name |adopted= is ambiguous to me; is there some "Friends of Mt. Foo" group that picks up trash there? Parameter names like |named_by= and/or |date_named= would be much clearer. Remember that parameters don't live in "sections" of templates within article code; parameters can be in any order in the wikitext, so it is helpful for them to have clear names. – Jonesey95 (talk) 07:20, 8 February 2025 (UTC)

|date_named= is fine with me I was just trying to come up with something shorter so it doesn't break in the infobox like |range_coordinates= does. But |date_named= is probably short enough for that not to happen. Volcanoguy 15:34, 8 February 2025 (UTC)

My concern with using |date_named= was that it could be misleading. Lots of landforms were unofficially named before their name became official so citing the date of when a name became official wouldn't be accurate if it was already used beforehand as an unofficial name. Volcanoguy 17:37, 8 February 2025 (UTC)

It sounds like you're talking yourself out of having this "when the mountain was named" information in the infobox, which is fine with me. Nuanced information should be explained in the body of the article. See MOS:INFOBOXPURPOSE if you have not looked at it already. – Jonesey95 (talk) 19:25, 8 February 2025 (UTC)

It could still be explained in the infobox by adding officially or unofficially with the date. For example, December 13, 1991 (officially). So I still support there being a |date_named= parameter. Volcanoguy 20:06, 8 February 2025 (UTC)

MOS:INFOBOXPURPOSE says the purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. The history of a name can definitely be explained in the body of an article as I've done in Tseax Cone, Cocoa Crater, Coffee Crater, Eve Cone, Tennena Cone, Nahta Cone, Ice Peak and elsewhere. Volcanoguy 20:59, 8 February 2025 (UTC)

Jonesey95 I don't understand why you said it sounds like you're talking yourself out of having this "when the mountain was named" information in the infobox? Volcanoguy 15:08, 11 February 2025 (UTC)

Because you said Lots of landforms were unofficially named before their name became official so citing the date of when a name became official wouldn't be accurate if it was already used beforehand as an unofficial name. I agree. Take your example of Tseax Cone. If we used |date_named=December 13, 1991 (or some other parameter name), we would be devaluing the local name(s) given to the mountain by indigenous people in favor of the "official" naming process used by 20th-century white people. This strikes of systemic bias to me, but others may have a different viewpoint. Potential sources of bias should probably be left for a nuanced explanation in the body of the article, as is done well at Tseax Cone. – Jonesey95 (talk) 16:05, 11 February 2025 (UTC)

Yes, I agree a nuanced explanation in the body of the article would be better to not devalue the local name(s) given to a mountain by indigenous people, but that's not always the case. I'm not aware of there being indigenous names for Cocoa Crater, Coffee Crater, Eve Cone, Tennena Cone, Nahta Cone, Ice Peak or many other mountains. It could be explained in Infobox mountain/doc that |date_named= should not be used to devalue local name(s). Volcanoguy 16:34, 11 February 2025 (UTC)

mapframes and missing OSM relation IDs

So it seems every mountain page I've looked at that has a mapframe is being put into Category:Infobox mapframe without OSM relation ID on Wikidata. I'm familiar with mountains being nodes in OSM but what sort of relation are you supposed to define for a mountain (besides routes)? Are there example mountains that have the OSM relation created (other than routes) and then linked to Wikidata? BTW, I find the existing default mapframe useless for an initial view because all it shows is a marker w/o the name or elevation. You don't even see other nearby mountains. Be much more useful if it got linked to the OpenTopoMap IMHO. RedWolf (talk) 17:21, 9 February 2025 (UTC)

I think this is some sort of a clerical categorization because we seem to be rendering OSM shapes regardless.

I don't know if there's support for topographic map layer rendering in {{infobox mapframe}} / {{maplink}}, it doesn't seem to be documented at least. Maybe ask there, at Template talk:Infobox mapframe?

It is possible to navigate to topographic maps, by clicking the map, then External maps, then choose Topographic from the dropdown menu, and then choose one of those. Granted, that's not very efficient. --Joy (talk) 19:57, 9 February 2025 (UTC)

Image from Wikidata not appearing

So I added an image to the corresponding Wikidata item for Mount Cordonnier, yet the image doesn't appear. Why? Is this a server caching issue? RedWolf (talk) 19:15, 4 March 2025 (UTC)

Does it work on any articles? If so, please link to one. I tweaked that article by adding the undocumented |fetchwikidata=photo. – Jonesey95 (talk) 23:20, 4 March 2025 (UTC)

The template says it retrieves the image property (P18) from WD. I looked at the template code and I see it asking for the value of P18. I think I had found an article that uses the WD image but that was a couple weeks ago IIRC. RedWolf (talk) 02:56, 5 March 2025 (UTC)

I also see that P18 is mentioned in the template documentation, and I showed how to make it work. If you find one that is working without |fetchwikidata=, post here and I will investigate. – Jonesey95 (talk) 05:49, 5 March 2025 (UTC)

Mapframe-zoom parameter doesn't work

Hi, for example in Mount Everest, the parameter mapframe-zoom has no effect on the zoom of OSM map. Please inspect. Thanks. Hooman Mallahzadeh (talk) 06:00, 24 March 2025 (UTC)

@Hike395 in this edit you replaced the #invoke: with a normal transclusion. Did this start shadowing all the unlisted parameters? Should this detail be reverted to get the full parameter passing to work again? --Joy (talk) 12:23, 24 March 2025 (UTC)

 Fixed by passing |mapframe-zoom=

@Joy: per your question. We can't use the module form that automatically copies parameters, because of the wikidata logic. If you call the module, you always get |mapframe-wikidata= as a default. I had to force |mapframe-wikidata=yes if none of the following is set: |mapframe-coordinates=, |mapframe-coord=, |range_coordinates=, |range_coords=, |coordinates=, or |coords=. If I remember correctly, this code is required to allow coordinates defined on enWP to override those defined in wikidata. Otherwise there was no way to override the wikidata coordinates. — hike395 (talk) 14:01, 24 March 2025 (UTC)

@Hike395 no but we could still use Module:Template wrapper, surely? --Joy (talk) 14:59, 24 March 2025 (UTC)

Unfortunately, {{infobox mapframe}} takes completely different parameters than {{#invoke:Infobox mapframe|auto}}, so all parameters would have to get manually copied in that case anyway. :( — hike395 (talk) 15:06, 24 March 2025 (UTC)

I'm rather busy IRL, so I don't think I can investigate this thoroughly enough until next weekend. The template works now, so I think it isn't urgent to make a more robust fix? — hike395 (talk) 15:09, 24 March 2025 (UTC)

I was going to report this at an earlier time, but I didn't take it seriously enough. The zoom is useful for increasing or decreasing mapframe size if a feature is too big or too small using the default. Volcanoguy 14:50, 24 March 2025 (UTC)

Leaving out |mapframe-zoom= was not intentional, sorry. Please feel free to mention missing parameters here at the Talk page. — hike395 (talk) 15:06, 24 March 2025 (UTC)

Warnings when infobox contains volcanic_field and volcanic_arc/belt

Infobox usage of both |volcanic_field= and |volcanic_arc/belt= now causes preview warnings about this and also places the article into Category:Pages using infobox mountain with conflicting parameters under V. I don't see any relevant discussion about this on the talk page and I don't see anything looking at edit summaries that shows exactly when this rule was put into place. There also seems to be a new parameter |volcanic_region=. How is one supposed to fix articles that are currently using both these fields and have different values? Why was this rule put into place? RedWolf (talk) 17:08, 20 June 2025 (UTC)

I've brought this up before and I didn't get a good answer as to why |volcanic_field= and |volcanic_arc/belt= can't or shouldn't be used simultaneously. Volcanoguy 00:37, 21 June 2025 (UTC)

With that being said, if |volcanic_arc= and |volcanic_belt= could be used simultaneously, |volcanic_arc/belt= could be deleted since it would be a redundant parameter. Volcanoguy 04:42, 22 June 2025 (UTC)

@Hike395: Comment? Volcanoguy 21:01, 24 June 2025 (UTC)

The multiple volcano parameters have been in place since 2012. They were first proposed by droll here. Droll implemented this as an if statement in this edit for label22/data22. That is, only one of |Volcanic arc=, |Volcanic belt=, |Volcanic field=, |Volcanic arc/belt= were allowed to be shown at once. |Volcanic region= was added in this edit as part of the massive editing trying to automate Wikidata entries.

I added the preview warning and tracking category because the code hasn't supported more than one volcanic field for 13 years. The template used to pick one silently, which I thought was unfriendly to editors.

We have a choice. We can either

keep only one volcanic field in the infobox, in which case the answer to RedWolf's question is that an editor should pick the one they want. Or,

we can allow multiple fields and allow |Volcanic arc=, |Volcanic belt=, |Volcanic field=, and |Volcanic region= to have separate lines in the infobox.

What do other editors think? It sounds like both RedWolf and Volcanoguy would be in favor of allowing multiple fields. I'm concerned about infobox bloat, so I can see why droll used the if statement.

Looking at usage of |Volcanic region= here, I think it tends to be used for "volcanic province", which is, as far as I can tell is the same as a volcanic belt? @Volcanoguy: you would know more about this.

— hike395 (talk) 23:09, 24 June 2025 (UTC)

Volcanoes can be in an arc, belt and/or field simultaneously so I think it would be logical to allow multiple fields. I've used |Volcanic region= in several articles mainly because it's a more vague term; I've never seen the Northern Cordilleran Volcanic Province described as a belt, arc or field in scholarly sources. There was a time when this volcanic province (or at least a part of it) was referred to as the Stikine Volcanic Belt, but this term seems to be largely obsolete since it's mostly used in older scholarly sources. A volcanic plateau could arguably be described as a volcanic region as well, so |Volcanic region= could have multiple uses. Volcanic belts, arcs and fields could also be placed in |Volcanic region=, but I have to wonder how all three could easily be placed in one parameter; it could be confusing to readers. If someone were to list several volcanic regions in |Volcanic region=, it could end up enlarging the infobox the same way as allowing |Volcanic arc=, |Volcanic belt= and |Volcanic field= to have separate lines. Volcanoguy 01:39, 25 June 2025 (UTC)

 Done Your explanation convinced me. I think we should deprecate |volcanic arc/belt=, per your comment above.

I agree with the deprecation, especially when MOS:SLASH is considered. Volcanoguy 20:28, 25 June 2025 (UTC)

I object strongly. Volcanic fields are not the same as Volcanic arcs or belts with as noted various uses depending on your school of geology with time. Action very premature and all destructive action should be reverted. eguser:Volcanoguy has removed lots of reasonable classification in templates I have contributed to having noted that there are multiple reasons why multiple parameters were established as far back as 2012. I did not read this discussion as moving towards a consensus when I came across it on 21st June and then a sudden action is noted on day 5 ChaseKiwi (talk) 18:14, 25 June 2025 (UTC)

I think the removals you're referring to are the ones using {{Infobox fault}} rather than {{Infobox mountain}}; I've reverted those removals. Volcanoguy 18:25, 25 June 2025 (UTC)

PS: Thanks for starting the reversion exercise on {{infobox fault}} which is nothing to do with this discussion ChaseKiwi (talk) 18:26, 25 June 2025 (UTC)

Just to clarify for those involved in this discussion, I accidently removed |Volcanic_arc/belt= in articles using {{Infobox fault}}, which are the ones ChaseKiwi seems to be referring to and has nothing to do with {{Infobox mountain}}. Volcanoguy 19:00, 25 June 2025 (UTC)

Yes but some of those contributing to the debate above may not have understood that propagating rifts/arcs are perhaps best described in the absence of geological consensus by term |Volcanic_arc/belt=. |Volcanic region= is an opt out term that loses known information. No objection to a new parameter |Volcanic_arc/belt/rift= to replace old |Volcanic_arc/belt= ChaseKiwi (talk) 01:46, 26 June 2025 (UTC)

Infobox parameters should be as short as possible; |Volcanic arc= and |Volcanic belt= are much shorter than |Volcanic_arc/belt/rift= which is unnecessarily wordy and lengthy. I don't understand how |Volcanic region= loses known information when the said information should already be mentioned in the main body of an article. Volcanoguy 04:32, 26 June 2025 (UTC)

Fair enough. ChaseKiwi (talk) 19:27, 26 June 2025 (UTC)

I'm a bit confused. I made two edits:

1. Allow multiple volcanic fields in the infobox
2. Place articles with |Volcanic arc/belt= in Category:Pages using infobox mountain with deprecated parameters.

@ChaseKiwi: were you objecting to the second edit? Or were you objecting to the continued use of |Volcanic region=? Or am I misunderstanding? — hike395 (talk) 05:06, 27 June 2025 (UTC)

I only tested the tracking category in the sandbox, I never made it go live. I am unsure how to respond to the objection.

@Volcanoguy: I believe you may be cleaning up uses of |volcanic arc/belt=. Would a tracking category be helpful to you? Is the deprecation controversial? Should we discuss further? — hike395 (talk) 11:52, 27 June 2025 (UTC)

I've replaced |Volcanic arc/belt= with |Volcanic arc=, |Volcanic belt= or |Volcanic region= in many articles by searching "arc/belt" but |Volcanic arc/belt= may be an empty parameter in some articles. If a tracking category can identify these empty parameters then it would definitely be helpful. I didn't replace |Volcanic arc/belt= in articles relating to volcanoes in New Zealand due to ChaseKiwi's objection above so I would wait what ChaseKiwi thinks about deprecating |Volcanic arc/belt= first. Volcanoguy 16:57, 27 June 2025 (UTC)

@Hike395: After no word from ChaseKiwi in the last 4 days I decided to remove |Volcanic arc/belt= from the remaining articles. With that being said, I kind of wonder if there should be a parameter for tectonic features associated with the development of volcanoes (e.g. East African Rift, Taupō Rift, Cascadia subduction zone, Mid-Atlantic Ridge, Aleutian subduction zone, Tonga–Kermadec subduction zone). Volcanoguy 23:14, 1 July 2025 (UTC)

|Volcanic zone= perhaps? — hike395 (talk) 23:23, 1 July 2025 (UTC)

No objection to volcanic zone as might be better in some cases than region and is shorter. ChaseKiwi (talk) 00:12, 2 July 2025 (UTC)

I'm not sure if there is a well-defined difference between a volcanic zone and a volcanic region. I wouldn't object to renaming |Volcanic region= to |Volcanic zone= if there is no well-defined difference between them. |Tectonic zone= could be a new parameter for rift zones, subduction zones, etc. I mentioned above. It could also be used in articles about non-volcanic mountains. Volcanoguy 01:02, 2 July 2025 (UTC)

I wouldn't mind changing |Volcanic region= to |Volcanic zone=. But I do worry that |Tectonic zone= might mislead readers. For example, Mount Shuksan could have |Tectonic zone=Cascadia subduction zone, but it formed from a terrane that collided 120 million years ago, not from the present subduction. — hike395 (talk) 02:38, 2 July 2025 (UTC)

The Cascadia subduction zone should definitely not be placed in |Tectonic zone= if this parameter were to be used in the Mount Shuksan article because the Cascadia subduction zone has nothing to do with Mount Shuksan. The Cascadia subduction zone is a much younger feature that formed about 55 million years ago. Volcanoguy 17:34, 2 July 2025 (UTC)

is much really a qualifier for 20 million odd years older at a first order guess ChaseKiwi (talk) 21:11, 2 July 2025 (UTC)

I realize that it's incorrect, but I worry that a typical editor may not realize it's incorrect, even if you document it carefully. How about |Tectonic origin= ? — hike395 (talk) 12:31, 3 July 2025 (UTC)

Actually I don't think we need |Tectonic zone= or |Tectonic origin=; |Formed by= covers mountain formation so the tectonic origins of mountains can be placed there along with tectonic regions (e.g. "Volcanism along the Cascadia subduction zone", "Extension along the Taupō Rift", "Uplift along the Alpide belt"). Volcanoguy 19:37, 3 July 2025 (UTC)

— hike395 (talk) 01:34, 4 July 2025 (UTC)

References