Template talk:Infobox mountain/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

topo_maker

I'm not sure when this parameter was added but I've only noticed it recently. I propose that this parameter support some pre-defined values. For example, NTS for National Topographic System (Canada). So setting it to NTS, it would be expanded to [[National Topographic System|NTS]]. RedWolf (talk) 19:02, 24 January 2021 (UTC)

deprecated parameters category

@Plastikspork: Hi. Can you provide more information as to why you added this tracking category? What parameters exactly are being marked as deprecated? I'm not a fan of complex non-LUA templates so I'm not going to start digging around in the template myself. What is your time frame in cleaning up all the pages in this category using a bot? Thanks. RedWolf (talk) 20:05, 3 March 2021 (UTC)

@RedWolf: It's all related to Task 8 which was initially requested by Rehman. After the first limited run on about 800 articles, hike395 identified some code bugs that resulted in data loss when the enumerated parameters were not in numerical order. I have fixed these bugs, and I am in the process of examining all 800 of these edits to make sure any bad edits are corrected or reverted (hope to be done by the end of the month). Once that is done, I will run the bot on all entries in Category:Pages using infobox mountain with deprecated parameters, which should generally complete the bot task (assuming that category covers everything in Task 8). Once that is done, the old parameters will be removed and tracked using the standard existing Category:Pages using infobox mountain with unknown parameters. I will probably re-run the bot from time-to-time after that to catch any new entries that may pop up. Thanks! Plastikspork _―Œ^(talk) 14:34, 4 March 2021 (UTC)

Thanks, Plastikspork. Standing by for the next run. Pardon me for not being around in the previous run, as I had to attend to some personal matters in RL. Rehman 06:41, 5 April 2021 (UTC)

Photo and map size again

Clearly there is something wrong with the photo and map size, compare for instance Jungfraujoch (mountain infobox) with Lake Ontario (lake infobox). Could somebody remove the left and right margin so that we don't have to spend time specifying map and photo size in every infobox? Zach (Talk) 14:03, 6 April 2021 (UTC)

Hello Zach. I believe this would be fixed once the OSM maps are integrated (see long threads above). It is a slow process, but will be done, and you are most welcome to voice in/help. Rehman 06:33, 7 April 2021 (UTC)

Ok, thanks! Zach (Talk) 14:23, 7 April 2021 (UTC)

@Zacharie Grossen: The image sizes in both of the infoboxes that you describe are adaptive, depending on the user preference of default thumbnail sizes. So I may not see what you see (because I set my thumbnail preference to 250px). Could you tell me more about what you see? The default size parameters for the templates are:

Item	Infobox mountain size	Infobox body of water size
Photograph	1.21x the default	1.14x the default
Map	256px	250px

Does the photograph look too large to you? It is 7% larger in the mountain than the lake. That may be causing the margins you see. — hike395 (talk) 05:10, 8 April 2021 (UTC)

Later: I think I see what you may be objecting to. Is it that the margins for both the photograph and the lake are too big? The mountain infobox is a little wider than the standard infobox, in order to minimize word wrapping of the labels. We can scale both the map and photograph to fit the larger width. I tested that in the sandbox. Could you (Zach) could take a look at the testcases and see if the sandbox version looks better to you? — hike395 (talk) 05:45, 8 April 2021 (UTC)

Yeah, I think they should be scaled to fit this nice infobox, so that the margin on left and right are not too big and possibly the same (like in the lake infobox). Otherwise I think it's a waste of space (well, at least for horizontal formats, but they tend to be more common than vertical formats, hence the upright option in thumbnails). My thumbnail preference is set to 220px, so we are not seing exactly the same thing. Zach (Talk) 12:27, 8 April 2021 (UTC)

I think the new version looks just fine. :-) Zach (Talk) 12:33, 8 April 2021 (UTC)

I've tested for both 220px and 250px thumbnails, and on Firefox/Linux/laptop, the new settings look better to me, also. Under Chrome mobile/Android/phone, the margins were previously squeezed out, so the net result is larger thumbnails. The images still fit comfortably within my phone, however.

Any other thoughts or comments from other editors? — hike395 (talk) 13:08, 8 April 2021 (UTC)

 Done I've update the live template. If anyone sees any problems or has any more comments, this is easy to change. — hike395 (talk) 16:54, 10 April 2021 (UTC)

Later --- I changed the default sizes for the photo and the image map to be in px, rather than in user-preference units. Previously, non-default thumbnail sizes were causing odd margins: now it's more uniform. — hike395 (talk) 12:50, 12 April 2021 (UTC)

Wikidata fallback

I am cleaning some issues related to {{convert}} and have noticed broken behavior at Segula Island. To demonstrate, edit that article and replace all the content with the following, then preview.

{{Infobox mountain
| elevation_ft = 3806
| prominence_ft = 3806
}}

That shows Module:Convert/extra as one of the "Templates used in this preview". That means an invalid unit is being passed to convert. The invalid unit is "rapid transit" because an edit on 28 April 2020 at Segula Island (Q1673626) added that to the elevation. Please do not fix the Wikidata item until this template has been tested. Why does the template fallback to Wikidata when elevation_ft is given? If someone changed Q1673626 to, say, elevation "5 foot", would this template show 5 instead of 3806? Johnuniq (talk) 05:28, 24 May 2021 (UTC)

I'm afraid I don't understand how the wikidata fallback code works. Maybe Rehman can fix? — hike395 (talk) 09:43, 8 June 2021 (UTC)

I fixed Segula Island (Q1673626) so the problem is avoided but it would be nice if a more fundamental fix were available. Johnuniq (talk) 10:48, 8 June 2021 (UTC)

Thanks for the ping, Hike. From what I can recall, this is caused somewhere in the bundle of code which supports the 3 options for each parameter (i.e. elevation, elevation_m, and elevation_ft). It should be a fixable bug AFAICT. I'm a bit caught up in RL at the moment, and will try to have a look at this over the weekend, if it isn't fixed by someone else by then. Cheers, Rehman 04:23, 11 June 2021 (UTC)

Ref spaces

@Hike395: Is there a way to remove the spaces that appear when ref parameters are used? For example, see the Level Mountain infobox which has unnecessary spaces between the text and inline sources. Volcanoguy 15:33, 7 June 2021 (UTC)

It seems to be caused by &#8239 which are "narrow no-break spaces". I'm not sure why they are needed, but were obviously a deliberate choice by someone. — Martin (MSGJ · talk) 19:18, 7 June 2021 (UTC)

I have removed the spaces from the sandbox for comparison, and you can see examples at Template:Infobox mountain/testcases#Sierra Nevada with and without the spaces — Martin (MSGJ · talk) 08:50, 8 June 2021 (UTC)

The thin spaces were introduced into the template when I merged in {{Infobox mountain range}}, which was a descendant of {{Geobox}}. If the consensus is that it looks better without the spaces, I'm happy to go along with whatever people think is best. — hike395 (talk) 08:59, 8 June 2021 (UTC)

In my opinion it looks better without the spaces. The spacings are also inconsistent with the sourcing of other parameters which do not leave spaces. Volcanoguy 15:21, 8 June 2021 (UTC)

 Done — Martin (MSGJ · talk) 07:37, 11 June 2021 (UTC)

Diameter

|diameter= and |diameter_ref= parameters would be ideal in the infobox. Volcanoguy 17:42, 9 May 2021 (UTC)

I'm still waiting for an opinion regarding this idea. Volcanoguy 01:50, 7 August 2021 (UTC)

Question

This is a bit trivial but is there a way make the |geology= parameter to display "Types of rock" and the |topo_map= parameter to display "Topo maps" for mountains that have more than one rock type/topo map? Volcanoguy 04:39, 26 September 2021 (UTC)

Category for infobox using multiple parameters

What exactly is the purpose of Category:Pages using infobox mountain with multiple parameters? All infoboxes are using multiple parameters so I'm not understanding the distinction of pages in this category? RedWolf (talk) 17:02, 29 July 2021 (UTC)

@RedWolf: Currently, there are rows that use numbered parameters (e.g., |region1=, |country19=), inherited from {{Infobox mountain range}}. These parameters are currently processed by the infobox into one label via {{enum}}. For example, if |country=Argentina, |country1=Chile, |country2=Paraguay, then the infobox displays Argentina, Chile and Paraguay.

In discussing the conversion of this template to use Wikidata, the consensus was that there were too many parameters in the infobox, and that the infobox should only accept |country= and not any numbered parameters. Editors would thus either enter |country=Argentina, Chile, Paraguay or use {{enum}} or other formatting as they see fit.

Plastikspork offered to run a bot job to convert the existing infoboxes to eliminate the numbered parameters. I found a data loss bug on an preliminary bot run, so we're waiting for Plastikspork to fix that. Category:Pages using infobox mountain with multiple parameters is a tracking category to help Plastikspork with his bot.

Hope this helps. — hike395 (talk) 05:28, 3 August 2021 (UTC)

I've converted all the numbered parameters in articles that were in this category. Volcanoguy 07:29, 3 August 2021 (UTC)

Thanks, Volcanoguy! That was very helpful!

@Plastikspork: I'm not sure what is happening with the bot: what is the state of Task 8 of Sporkbot? Did you need to go back and revert any edits? Can we remove the numbered parameters and the tracking category from this template? Thanks for any information! — hike395 (talk) 14:16, 3 August 2021 (UTC)

There are articles with numbered parameters that aren't in this category. Just thought I would let this be known. Volcanoguy 19:29, 3 August 2021 (UTC)

@Hike395: Thank you for the detailed explanation. Clears up the confusion I had. RedWolf (talk) 18:57, 5 August 2021 (UTC)

Perhaps Category:Pages using infobox mountain with numbered parameters would have been a better title. Volcanoguy 21:41, 5 August 2021 (UTC)

Indeed. RedWolf (talk) 20:16, 17 November 2021 (UTC)

Listing parameter

There is a discussion at Cerro Blanco's FAC about the purpose of this parameter. It currently links to List of mountain lists but this apparently causes confusion because the parameter is more commonly used for Wikipedia lists (e.g. List of mountains of XXXX) rather than notable mountain lists. Is there a more general list this parameter could link to? Maybe Lists of mountains? I'm not a template editor so I can't change it on my own. Hike395 what are your thoughts regarding this issue? Volcanoguy 01:36, 16 November 2021 (UTC)

@Volcanoguy: The documentation for the parameter suggests List of mountain lists. The original intent was to supply peakbagging or prominence lists (e.g., K2), but it seems that the usage has drifted (e.g., Mount Whitney). We can change the link to Lists of mountains, although I bet this will cause further drift in usage. — hike395 (talk) 03:31, 16 November 2021 (UTC)

I don't believe I have ever set listing to one of the world-wide list pages identified above. I usually set it to include List of mountains of XXXX. I don't think listing should ever include world-wide list pages; links to those pages should be in "See also". RedWolf (talk) 18:41, 16 November 2021 (UTC)

How useful is it to link to "List of mountains of XXX" in the infobox? That doesn't seem to be useful data by itself (beyond the link). I wonder if we should just remove |listing= and send all of these links to "See also" ? — hike395 (talk) 15:11, 17 November 2021 (UTC)

Sometimes the listing contains a link to List of the highest major summits of Canada with its rank order beside it. I think the number is self-explanatory in this context (IMHO) but if we move it to "See also", it would need additional text such as "ranked 24th". As to moving "List of mountains of XXX", one reason I like it under listing is I don't have to scroll down to the "See also" section to open these pages to update them in another tab. I can quickly flip between the two tabs without having to re-scroll back to see the data I need to copy to the listing page (i.e. elevation, range, name meaning). RedWolf (talk) 20:30, 17 November 2021 (UTC)

map-parameters

Hello, everybody and @Rehman: thank you for your motivation to improve this doc-page! But since March 2020 we are waiting for updates to follow but still there are no descriptions or explanations for the map-parameters:

| map                  
| map_caption   
| map_alt
| map_width
| map_size  
| map_relief 
| map_image
| relief
| label 
| label_position

Also in the Standard usage-section these parameters are missing! If no one can find informations about these parameters here, how will can we help people to add maps to the mountain-articles. Just one example here: Safēd Kōh. There are two Mountain ranges with this name: once near Herat¹ other one near the border Pakistan-Afganistan². If there is no map in the article, it is more diffucult to find this diskrepanz. All this is a pitty because the codes for the parameters allready existing!

So for the meanwhile I added a link to the previos Version of the description. And I propose to uncomment the parameters in the standard-use section. Are you ok with this? Thanks you! --W like wiki ^{good to know} 18:32, 5 January 2022 (UTC)

|language=

There is an undocumented parameter |language= which, purportedly, is used to identify the language of a 'name'. It is not clear which 'name' is to be so identified because this parameter is not documented. In the template code there is this:

| label20       = Language of name
| data20        = {{#if:{{{native_name|}}}||<!--
                  -->{{#if:{{{language|}}}|{{{language}}}|<!--
                      -->{{#if:{{{native_name_lang|}}}|{{ISO 639 name|{{{native_name_lang|}}}|link=yes}}}}}}}}

At Template:Infobox mountain/testcases § Jungfraujoch, {{infobox mountain}} has |name=Jungfraujoch and |native_name_lang=de but does not have |native_name= and |language=. The above dutifully produces [[German]]. This, to me, appears to be a misuse of |native_name_lang=. Blurring the meaning of a specifically named parameter |native_name_lang= between |native_name= and |<some_other_name>= parameter should not be done especially because |native_name= can receive multiple names in multiple languages.

So, oughtn't |language= be documented and the code above modified to remove the dependance on |native_name_lang=?

—Trappist the monk (talk) 15:12, 10 January 2022 (UTC)

native name parameters

I have started a discussion at Wikipedia talk:WikiProject Infoboxes § native name parameters, you participation would be appreciated.

—Trappist the monk (talk) 22:27, 27 December 2021 (UTC)

As a result of the above referenced discussion, I have modified this template and fixed many of the attendant errors. Some errors I have not fixed. Articles with native name errors are listed in Category:Native name checker template errors. This search returns a list of articles using {{infobox mountain}} in Category:Native name checker template errors.

—Trappist the monk (talk) 17:03, 12 January 2022 (UTC)

Template-protected edit request on 29 June 2022

Please implement this diff from the sandbox.

Effect: When the fetchwikidata parameter is set to ALL, the 2 parameter for {{Wikidata image}} is set which disables adding the page to Category:No local image but image on Wikidata — a hidden maintenance category. Any value already passed to {{Infobox mountain}} for nocat_wdimage overrides the behaviour but has the same effect. This fixes pages where images are pulled from wikidata and {{Wikidata image}} errantly adds a maintenance category indicating that the topic has an image on wikidata which is not included in the article.

/testcases shows no visible differences which is correct. The maintenance categorization impact can be seen when previewing changes on a page in article space if your user preference to show hidden categories is active. The A' Chrois is one article configured for fetchwikidata = ALL where this change can be tested in preview. --N8_wilson 🔔 19:00, 29 June 2022 (UTC)

Some more examples from the 'A's where this fix is helpful: Aakenustunturi, Aavasaksa, Aberdare Range, Abraham Peak, Acıgöl–Nevşehir, Adirondack Mountains, Aggenstein. Notice with mouse-hover the images shown in the article preview. These examples were all taken from Category:No local image but image on Wikidata which is an incorrect categorization. --N8_wilson 🔔 20:36, 29 June 2022 (UTC)

 Done, may take a little time for the servers to catch up with category entries. P.I. Ellsworth , ed. ^put'r there 22:32, 29 June 2022 (UTC)

Arc, belt and field parameters

Why is it that |Volcanic_arc=, |Volcanic_belt= and |Volcanic_field= don't work simultaneously? It's not unusual for volcanoes to be part of more than one grouping. An example which could use both arc and field parameters is West Crater, a lava dome in the Marble Mountain-Trout Creek Hill volcanic field which forms part of the Cascade Volcanic Arc. Chipmunk Mountain could use both arc and belt parameters since it is part of both the Pemberton Volcanic Belt and the Cascade Volcanic Arc. An example which could use all three parameters is Mount Price, which is part of the Garibaldi Lake volcanic field, the Garibaldi Volcanic Belt and the Cascade Volcanic Arc. Volcanoguy 17:05, 6 September 2022 (UTC)

@Hike395: [...] what's your views on my comment above? If we're able to use |Volcanic_arc= and |Volcanic_belt= simultaneously we could remove |Volcanic_arc/belt= because it would be redundant. By doing so there would be one less parameter. Volcanoguy 10:35, 1 October 2022 (UTC)

I went back and looked the history. The multiple volcano parameters were suggested by Droll back in 2012, although they folded them all into one data field in the infobox. There wasn't an explanation of why they were folded in that way, and sadly Droll is on an extended or permanent Wikibreak. I support the extra parameters. — hike395 (talk) 15:27, 1 October 2022 (UTC)

Thinsp

I don't think &thinsp is needed for infobox refs because it adds unnecessary spaces. Sourcing of the other parameters does not show such a space. For example, see the infobox in my sandbox. Volcanoguy 10:35, 1 October 2022 (UTC)

To my eye, the citation up against formula-like fields (e.g., coordinates) could fool naive readers into thinking that they're part of the formula. Maybe we can keep the thinsp for coordinate fields only? I've reverted the main template and testing it in the sandbox. See the new testcase that implements Volcanoguy's sandbox. Volcanoguy (and other editors), what do you think? — hike395 (talk) 15:03, 1 October 2022 (UTC)

I'm not really sure. It's pretty obvious it's an inline citation once a reader puts their cursor over it (or touches it on a mobile phone). Volcanoguy 16:41, 1 October 2022 (UTC)

Potentially incorrectly plural labels [sic]

@Plastikspork: So I'm trying to understand how pages get put into Category:Pages using infobox mountain with potentially incorrectly plural labels. Note: The [sic] is because grammatically it should be "Potentially incorrect". I'm not a template language expert but I think if "settlement_type" contains text not ending with 's' and "settlement" is not empty, pages get put into the category with a sort key of B. However, "Mayon" got put into the category even though settlement_type is "Cities and Municipalities". Can you explain why? Thanks. RedWolf (talk) 19:25, 28 October 2022 (UTC)

RedWolf, that category was created after the first bot run to update the parameter syntax. The bot used the "enum" template when there was more than one settlement, and hence, the check looks for the string " and ". Since Mayon is using "collapsible list" list, the check does not recognize that there are multiple values in the settlement parameter. I could write something more sophisticated, or we could just check all of them and then remove the check? Thanks! Plastikspork _―Œ^(talk) 13:47, 29 October 2022 (UTC)

Is there anything wrong with using {{collapsible list}} in one of the arguments? I don't see why we need to check for it or change it. — hike395 (talk) 05:41, 30 October 2022 (UTC)

@Plastikspork: I suggest either adding more supported templates in the check (e.g. unbulleted list, hlist, collapsible list) or just remove the check entirely. RedWolf (talk) 19:02, 12 November 2022 (UTC)

Template-protected edit request on 19 January 2023

Please change:{{#invoke:Check for unknown parameters|check|unknown=[[Category:Pages using infobox mountain with deprecated parameters|_VALUE_{{PAGENAME}}]]
to: {{#invoke:Check for unknown parameters|check|unknown=[[Category:Pages using infobox mountain with unknown parameters|_VALUE_{{PAGENAME}}]]

The category should be UNKNOWN parameters not DEPRECATED Zackmann (^{Talk to me}/_{What I been doing}) 06:27, 19 January 2023 (UTC)

 Not done for now: @Zackmann08 This template already uses Category:Pages using infobox mountain with unknown parameters, however the use of Category:Pages using infobox mountain with deprecated parameters has something to do with User:SporkBot (I assume tracking previously used parameters). Any change to this should be discussed with the bot operator User:Plastikspork first. Terasail^[✉️] 06:36, 19 January 2023 (UTC)

@Terasail and Plastikspork: it looks like the two categories need to be flipped. Terasail, thanks for catching that unknown is already in use. The {{#invoke:Check for unknown parameters... should definitely be sending things to the unknown category. Additionally it looks like there are two separate calls to Module:Check for unknown parameters. Perhaps a refactor of this is needed... --Zackmann (^{Talk to me}/_{What I been doing}) 05:22, 20 January 2023 (UTC)

Zackmann08, the deprecated category has the list of parameters that will be valid after the bot is finished and the deprecated parameters are removed. The unknown category as the current list of valid parameters. Everything looks fine to me, it is just taking time to complete the bot task because it requires human inspection of the edits (due to the complexity of the transformations). Thanks! Plastikspork _―Œ^(talk) 14:06, 20 January 2023 (UTC)

@Plastikspork right on! Thanks for the info. Hope you are well. Zackmann (^{Talk to me}/_{What I been doing}) 18:30, 20 January 2023 (UTC)

Geological formations

Does this infobox have a field for the names of geological formations that form individual mountains? I was looking to use |Formed_by= but that parameter is for mountain formation (i.e. the geological processes that underlie the formation of mountains) rather than geological formations. Volcanoguy 18:21, 20 June 2023 (UTC)

|rock=, |geology=, |geology1=, etc. — hike395 (talk) 04:53, 21 June 2023 (UTC)

|geology1= is deprecated. Multiple items are placed into |geology= using templates such as {{enum}}. RedWolf (talk) 06:57, 21 June 2023 (UTC)

Unfortunately, both |rock= and |geology= are for types of rock rather than geological formations which are not necessarily rock types but rather rock units. Volcanoguy 09:57, 21 June 2023 (UTC)

I think it would be ok to reuse the same parameter for formations. Editors have already done this at Black Forest, Mount Monadnock, and Elm (hills). — hike395 (talk) 10:30, 21 June 2023 (UTC)

It would probably be better if formations had their own parameter; I find it kind of strange adding them in a parameter for rock types. If there will ever be a parameter for geological formations I would suggest |rock_unit= since formations are only one type of rock unit; there are also beds, members, groups and supergroups. |rock_unit= could link to stratigraphic unit. Volcanoguy 11:13, 21 June 2023 (UTC)

The reason why those articles use |geology= for rock units could be because there isn't a better parameter to use. Volcanoguy 11:51, 21 June 2023 (UTC)

Clarify: When I said I found it kind of strange adding rock units in a parameter for rock types I meant the name of the rock unit only (e.g. XXXX Member, XXXX Formation, XXXX Group, XXXX Supergroup). It's reasonable to include the name of a rock unit with the type of rock forming a mountain like in the examples above but that might not always be possible. Volcanoguy 19:59, 22 June 2023 (UTC)

For example, if you had a peak that was made of the Chinle formation, you're thinking it would be strange to have |rock=[[Chinle Formation]], because it isn't a single type of rock? — hike395 (talk) 23:47, 22 June 2023 (UTC)

Yes because it can be vague; formations can consist of several types of rocks. Volcanoguy 00:38, 7 July 2023 (UTC)

English translation

Is it really necessary to have "English" in |English_translation=? This is English Wikipedia so the translation parameter would obviously be used for English translation. Volcanoguy 01:02, 7 July 2023 (UTC)

Possible additional 'elevation' parameters

Browsing Mount Nebo I saw that it is about 700m above sea level. But it is also beside the Dead Sea whose surface is about 430.5m below sea level. This means that it is 1130.5m above a local baseline. So I wondered whether there might be a case for additional elevation information, e.g. "local elevation", for cases where such a concept might be relevant. Probably not, but I thought it might be worth raising the idea. Feline Hymnic (talk) 14:35, 4 November 2023 (UTC)

Template for mountain ranges

Quick question - is there a template which would be more suitable for articles about specific mountain ranges or mountainous areas? I see that Alps, Andes, and Rocky Mountains use this template, but it seems a bit cumbersome as it was really designed for single mountains. Thanks, A.D.Hope (talk) 23:42, 4 February 2024 (UTC)

{{Infobox mountain range}} was merged into {{Infobox mountain}} in 2015, so this is the best one. — hike395 (talk) 00:45, 5 February 2024 (UTC)

Nowrap labels?

@Hike395: Is there some way to make parameters not break while using them in the infobox? This especially happens while lengthy parameters like "English translation" and "Range coordinates" are being used (e.g. Tennena Cone and Mount Edziza volcanic complex). Volcanoguy 19:34, 9 July 2024 (UTC)

Yes, this is an easy change to make on individual labels. I'll add nowrap to those labels and see how it affects the test cases. — hike395 (talk) 04:48, 10 July 2024 (UTC)

@Volcanoguy: Per your request from a year ago, I think it's good to drop "English" from "English translation". I implemented nowrap for "Range coordinates", but it needs to make the infobox a little wider to not cause a lot of ugly wrapping of data fields. Now implemented in the sandbox, see the testcases. What do editors think? — hike395 (talk) 05:06, 10 July 2024 (UTC)

It looks good to me. I was thinking maybe the box would have to be widened a bit while I wrote my last comment but wasn't sure. Volcanoguy 06:02, 10 July 2024 (UTC)

to clarify --- the box is only wider if |range_coordinates= is not empty. — hike395 (talk) 11:37, 10 July 2024 (UTC)

I'm not against widening the infobox slightly as an alternative if there's opposition to nowrapping labels. Volcanoguy 04:52, 11 July 2024 (UTC)

I don't use this template so take this for whatever it's worth. I would oppose nowrapping labels. Let your browser decide how best to render the infobox; don't micromanage. Don't like label wraps? Find a better (shorter) label. Use nowrapping for things that matter, don't nowrap when it really doesn't matter; see Wikipedia:Manual of Style § Controlling line breaks.

—Trappist the monk (talk) 11:52, 10 July 2024 (UTC)

I have to say the infobox looks tidier without any line breaks. Not sure if |range-coordinates= can be shortened. Volcanoguy 16:01, 10 July 2024 (UTC)

Does it even need to be in the infobox? The coordinates of the mountain are the important information. The range seems secondary — Martin (MSGJ · talk) 21:50, 10 July 2024 (UTC)

The highest mountain in a range isn't always known so |range-coordinates= would be used instead. Volcanoguy 23:00, 10 July 2024 (UTC)

And the highest point sometimes isn't in the center of the range: without |range-coordinates=, geohack could show a lopsided view of the range. — hike395 (talk) 23:34, 10 July 2024 (UTC)

Embedded

I think it would be ideal to add |embedded-caption= and maybe |embedded-alt= for embedded images in the infobox. Volcanoguy 17:39, 11 July 2024 (UTC)

Since the mountain infobox isn't overly big, I'd suggest going for a fully automatic {{Infobox mapframe}} in all articles. Static (pushpin) maps are good for general orientation, but cannot be zoomed in and out, and when clicked, the pushpin disappears. The only thing that would need to be done is removing the manually added templates from these. Ponor (talk) 11:44, 15 July 2024 (UTC)

Mountain range names not showing up

I've noticed the names of mountain ranges don't show up on the infobox map while |range_coordinates= is being used. Is this an error? Volcanoguy 00:59, 19 March 2024 (UTC)

For example, see Mount Edziza volcanic complex versus Mount Edziza. Volcanoguy 01:05, 19 March 2024 (UTC)

I suspect this is a deep programming problem that removes the intended default overlay code and is likely deeper than the infobox mountain template although topo-map parameter which is definitely buggy is used on one of the maps you refer to. The various infobox templates do handle mapping code differently I have discovered over the years and I tend not to report as bug if I can figure away around to get the display I want as often the code author assumes a certain way maps are presented in infobox. For example at the moment I am in the process of moving some topo_map using maplink generated geological maps with frames to the embedded= parameter as topo-map parameter associated code assumes I think pure image code not surrounded by divs and can completely fall over with unframed maplink template maps.ChaseKiwi (talk) 09:56, 20 April 2024 (UTC)

@Volcanoguy: Fixed As far as I can tell, this was for compatibility with {{Infobox mountain range}}, which did not have map labels, because of compatibility with {{Geobox}}. I can't think of a reason why we shouldn't display the label, so I fixed it. Apologies for the delay -- I missed your original post. — hike395 (talk) 11:17, 20 April 2024 (UTC)

Yes with work of many, not least user:Jonesey95 we now have better mapping options in this infobox than many and no longer need for maps the embedded= or module= functionality still forced for some maps in other info boxes. ChaseKiwi (talk) 02:29, 5 October 2024 (UTC)

Invalid zoom value

When I use |mapframe=yes it gives the following error: "<mapframe>: Attribute "zoom" has an invalid value". Volcanoguy 22:55, 7 October 2024 (UTC)

@Volcanoguy: Oh, that's not good. This is in your sandbox? — hike395 (talk) 22:58, 7 October 2024 (UTC)

@Hike395: See The Ash Pit. Volcanoguy 23:10, 7 October 2024 (UTC)

The error seems to show up in {{Infobox mountain}} when it has no map. Volcanoguy 23:20, 7 October 2024 (UTC)

I'm not seeing it at User:Hike395/sandbox, although perhaps I am not reproducing it correctly. Is there an existing page that shows the problem? — hike395 (talk) 23:56, 7 October 2024 (UTC)

Sorry, missed your link to The Ash Pit. Will investigate. — hike395 (talk) 23:57, 7 October 2024 (UTC)

When I copy the infobox to my sandbox, the problem goes away. It's either a namespace issue or a Wikidata issue :(. Will investigate further. — hike395 (talk) 00:01, 8 October 2024 (UTC)

Fixed It was a string handling bug. — hike395 (talk) 00:52, 8 October 2024 (UTC)

Mapframe outline

Out of curiosity, how are you able to outline mountains and mountain ranges as shown in the Saltoro Mountains article? Volcanoguy 20:44, 8 October 2024 (UTC)

You have to edit the Wikidata item so it links to an OpenStreetMap relation ID. If there is no OSM relation already, you can create it there (or just add a relation to an existing way, for example). Once that shape relation exists, it in turn has to be connected back to the same Wikidata item, and be of a certain known type. There's more info about this at Template:Infobox mapframe#FAQ Q4. --Joy (talk) 20:52, 8 October 2024 (UTC)

embedded = Infobox mapframe

There's quite a lot of instances of using the embedded or module parameters using {{infobox mapframe}}. Converting these to use the actually embedded syntax changes the placement of the image, from bottom to top, which might not be desirable. Maybe we could have another parameter to make this position configurable? --Joy (talk) 13:47, 6 October 2024 (UTC)

Actually what I think is happening when a user tries to use the embedded= syntax is that they get the {{OSMwhatever template}} subcluded which usually results in poor formatting with left indent. Only module= works or map-image= (if no map= call) as should. Topo= if you were naughty does not work without distortion but photo= does. As you say the default order of images can be different, as often mountain ranges best to have complex local images top and the general location image which can not show the important peaks in the range last in info box. ChaseKiwi (talk) 16:10, 6 October 2024 (UTC)

I personally prefer the map at the bottom of the infobox rather than at the top hence I still use |embedded=. It also doesn't have the zoom switcher which with a caption I find looks awkward. Volcanoguy 16:18, 6 October 2024 (UTC)

There's often use for two sets of maps - a general one, to help the average reader identify where it is in general, and a detailed one, to help the reader understand the relative positions of detailed toponyms discussed in the article. Both of these would typically benefit from some amount of zooming functionality, so it would make sense to have the option to use maplink for both. --Joy (talk) 17:44, 6 October 2024 (UTC)

Yes, but |map= already gives the option for a zoomed out map. Having two zoomed out maps is unnecessary. Volcanoguy 15:31, 7 October 2024 (UTC)

Not to mention mapframe can be zoomed in or zoomed out by clicking it. Volcanoguy 15:36, 7 October 2024 (UTC)

fwiw, I got rid of the zoom switcher. Can Joy or Volcanoguy give an example of a mountain article that currently uses embedded {{infobox mapframe}}? — hike395 (talk) 16:13, 7 October 2024 (UTC)

@Hike395: Nahta Cone. Volcanoguy 17:52, 7 October 2024 (UTC)

I understand now, thanks! I don't think we need to add another parameter. I would propose turning off mapframe by default if |embedded= is true. If someone wants a mapframe below, they would set |embedded=mapframe. If they want a mapframe above, they would set |mapframe=yes. If they want both, they would set both. — hike395 (talk) 18:50, 7 October 2024 (UTC)

Well, that's the poor man's solution that we're using right now - making this 'embedded' field effectively the place that one uses to embed another mapframe. But an infobox's parameter names should convey a meaning, they shouldn't be unclear by default. They should definitely be more straightforward than having to examine dozens of examples and talk pages to find the right wombo combo that does the trick :) --Joy (talk) 21:25, 7 October 2024 (UTC)

It can be made slightly more tasteful by making a new parameter called something like |extra-mapframe= which would be data56.5 (between |embedded= and |module=), and then turn off default mapframe if |extra-mapframe= is used. I think making a parameter that pushes items up and down in an infobox is not at all what people expect in WP. — hike395 (talk) 22:53, 7 October 2024 (UTC)

I'm not sure where we went astray, but I don't want us to turn off the upper mapframe by default anyway. If the infobox users want two of them, we should just let them have it. --Joy (talk) 09:32, 8 October 2024 (UTC)

This is also now available through the map_image parameter in the sandbox. --Joy (talk) 21:09, 8 October 2024 (UTC)

mapframe under Geography rather than at the very top

As I gained a better understanding of the logic of the infobox module and this template, I realized we were putting the mapframe on top of everything, even if a top image is present, but the other maps nicely go under the Geography heading when an image is there.

It does seem to make more sense to keep doing that for all map types, not just the 'old' ones.

While fixing something else in the sandbox, I also made that update to the mapframe position.

Any objections to publishing that in the live version? --Joy (talk) 20:57, 8 October 2024 (UTC)

Another possible way to look at this matter is through a more generic discussion of why would the Geography section be below the sections Highest point, Dimensions and Naming. --Joy (talk) 21:04, 8 October 2024 (UTC)

I agree the mapframe position would be better under the Geography heading. It's current position on top of everything doesn't make much sense that's why I used |embedded= instead. Volcanoguy 21:33, 8 October 2024 (UTC)

map overrides map_image

It looks like this template silently hides a specified map_image if map is already there. Why would we do this? --Joy (talk) 13:38, 6 October 2024 (UTC)

Yes, had identified this issue too, once logic identified I assume best to switch off. For moment I am using module= where there is a good map that some one has used but article could do with local orientation map. It is definitely best to try to push editors to but in maps in info box as I am presently trying to clean up multiple mountain articles where others have created maps 450px or more wide and left justified them. In due course we should be able to clean up the module = calls once we have map_image as an independent parameter although still detected by logic like you have at moment ChaseKiwi (talk) 15:57, 6 October 2024 (UTC)

This seems to have been in the original implementation in 2017. @Frietjes what was the reason for the image map not to be shown if there's a map already, did it really have to be just an alternative as such, or was that just the safe first implementation?

Since this parameter hasn't actually been documented as exclusive, I'd just move it to be normal optional.

For example, in {{infobox settlement}} we support multiple optional image maps and it works fine. I'd expect editors and readers to be comfortable with that at this point.

And it would also provide a nicer alternative place for {{infobox mapframe}} placement (cf. #embedded = Infobox mapframe). --Joy (talk) 14:07, 8 October 2024 (UTC)

who knows, at the time, there was some desire to limit the total number of maps in an infobox, but if we don't want a limit, we can certainly fix that. Frietjes (talk) 16:24, 8 October 2024 (UTC)

I tried to implement that in the sandbox, but it didn't work. I can't seem to get image26 to render using our existing trickery. Do you happen to know how to fix that?

I also asked for help at Template talk:Infobox. --Joy (talk) 18:38, 8 October 2024 (UTC)

I think I figured it out in the sandbox now. --Joy (talk) 20:53, 8 October 2024 (UTC)

This is live now. I added test cases and the ability to split captions, it seems reasonable. Let's see if there's any odd cases in the wild. --Joy (talk) 17:18, 9 October 2024 (UTC)

Coords problem

What is the reason for mapframe using the highest point coordinates in the Mount Edziza volcanic complex article rather than the range coordinates? Volcanoguy 17:14, 8 October 2024 (UTC)

Could it just be the default of |mapframe-coordinates= being coordinates from Wikidata, which differ? If so, you could amend either Wikidata or pass in desired coordinates through that parameter. --Joy (talk) 18:40, 8 October 2024 (UTC)

The Wikidata coords are for the volcanic complex rather than the mountain. I tried using |mapframe-coordinates= but it didn't make a difference. Volcanoguy 18:57, 8 October 2024 (UTC)

I just noticed that the same parameter wasn't working, but mapframe-coord was. Will have to look at why that would be. --Joy (talk) 17:26, 9 October 2024 (UTC)

The code there says:

elseif name == "coordinates" or name == "coord" or name == "coordinate" and not fixedArgs.coord then

The last part could be the problem - if coord is already set - or inherited - it won't override coord with coordinates? --Joy (talk) 18:03, 9 October 2024 (UTC)

I've just found out that if I remove the highest point coords in the Mount Edziza volcanic complex infobox, the mapframe will then use the Wikidata coords. Volcanoguy 18:18, 9 October 2024 (UTC)

mapframe implementation

I tried adding Module:Infobox mapframe to the sandbox, but it doesn't work on our existing test case. If someone can assist to figure it out, I'd appreciate it. --Joy (talk) 04:13, 1 October 2024 (UTC)

Apparently, |image27= is not valid. I lowered the image number but did no further testing to see if I broke anything. – Jonesey95 (talk) 18:44, 1 October 2024 (UTC)

The testcases look good, the Mount Edziza one is due to the testing done. I don't think the image # affects things, {{Infobox bridge}} has it set at a much higher entry for instance. I have noticed the maps integration only works if the onByDefault parameter is included or the template uses a nested infobox subtemplate such as at {{Infobox station}}. The conditional logic you've used in infobox mountain, basically show the mapframe if no other map is used, is quite nifty. Regs, The Equalizer (talk) 23:59, 1 October 2024 (UTC)

Agreed about the conditional logic. --Joy (talk) 08:29, 2 October 2024 (UTC)

Ah, so you moved it back to index 2, I see. What's the logic of Module:Infobox then, do we have to keep the slot 27 off limits as we seem to do with 26?

I also noticed that the sandbox example view itself is rendering this error:

Lua error in Module:Mapframe at line 384: attempt to perform arithmetic on local 'lat_d' (a nil value).

--Joy (talk) 08:24, 2 October 2024 (UTC)

The error seems to be happening because it's on by default with all other maps missing, but that doesn't seem to work with {{Parameter names example}}. I tried setting it to an explicit no there, but it didn't change. --Joy (talk) 08:39, 2 October 2024 (UTC)

I fixed the error in the documentation. I found one reference to parameters of the same type being "too far apart" in a discussion from 2013. It appears from a naive reading of the code that image parameters must be within 10 of the previous image parameter. The map in Infobox bridge is in a data parameter. – Jonesey95 (talk) 12:41, 2 October 2024 (UTC)

Ohh, I see now, it was part of the block that was actually commented out, because emptiness in the original map parameters would cause Lua errors in turn. D'oh. Thanks. --Joy (talk) 14:26, 2 October 2024 (UTC)

Is there a way to make the map zoom in and out? The Mount Edziza complex example doesn't show Mount Edziza Provincial Park which is the reason I added it in the first place; to show whereabouts it is in the park. Volcanoguy 14:12, 2 October 2024 (UTC)

Yes, we can always specify |mapframe-zoom= with a better zoom number in the infobox parameters. --Joy (talk) 14:24, 2 October 2024 (UTC)

Wouldn't it make more sense to place the mapframe parameters with the other map parameters in the geography section? Volcanoguy 19:26, 2 October 2024 (UTC)

Sure, I reworked the documentation do that.

Note that the doc is shared between live template and sandbox, so this is a tad confusing for the unsuspecting observer now. As soon as we publish the feature in the live version it will be consistent again. --Joy (talk) 08:33, 3 October 2024 (UTC)

Actually the mapframe should appear at the bottom of the infobox since it's not a geography map. Volcanoguy 16:50, 3 October 2024 (UTC)

Given the new logic to make it show up by default when no other map is available, I wonder what our default zoom should be.

The first iteration had it at 13, which didn't seem very useful to show map context by default with the test cases. I moved it to 7, and in some cases it seems fine, in some it's still very bland.

I wonder if we could somehow get it autodetected based on the size of the associated shape, or some other variable? --Joy (talk) 14:28, 2 October 2024 (UTC)

In absence of other suggestions, I changed it to not enforce any one zoom by default, but rather that it shows the zoom switcher. Would this be a good default here?

Note that we could still decide on a single zoomed in level, and keep the switcher, too. --Joy (talk) 14:53, 2 October 2024 (UTC)

As there's been no objections, I'll publish this version. Worst case if people don't like it we can tune and revert. --Joy (talk) 08:34, 3 October 2024 (UTC)

@Joy: I don't think the zoom switcher is needed here since editors can use |mapframe-zoom= with a better zoom number in the infobox parameters, not to mention I tested it in an article and I found it glitchy; looks fine zoomed in but while zoomed midway or zoomed out it doesn't show the pin or most of the map so they're pretty much useless. The zoom default could be 8 as I haven't had a problem with that. Volcanoguy 16:38, 3 October 2024 (UTC)

I was just thinking what's the best setup for the default, where nobody's even aware they need to use the mapframe-zoom parameter. Giving people a number of choices seems safer than not doing it. I've seen some glitches there when I am in edit mode, but as a reader I haven't had any problems (on my desktop Firefox). --Joy (talk) 17:15, 3 October 2024 (UTC)

I had followed this talk and some one seems to have enabled it without sorting out the documentation so not obvious how to switch it off or if the wonderful logic had not been tested against some common enough cases. Perhaps something as simple as detection of the construct map=nil can be detected as I agree default behaviour appropriate but pages can have two infoboxs when subjects not notable enough. Infobox mountain is also used for ranges and Infobox mapframe is usually not the best mapping tool for them or when a mountain has notable subfeatures not on the default OSM Map. Many articles have substituted quite well over the years for the mapping issues with this infobox. An example of where two maps in my opinion does not help the reader is Two Thumb Range which is how I immediately detected from my perspective the new functionality going live. ChaseKiwi (talk) 19:53, 4 October 2024 (UTC)

I have clarified the documentation. Does it help? As for Two Thumb Range, the other map is in |embedded=, which is not one of the standard parameters for a map, so adding |mapframe=no per the documentation is your best option. |embedded= is used in just 1% of the transclusions of this template, and many of those are not maps, so it is definitely an edge case. – Jonesey95 (talk) 20:10, 4 October 2024 (UTC)

Can we revert new map default functionality until it can be turned off by users

Waste of time at Hunga Tonga–Hunga Haʻapai where I had recenty removed {{maplink}} as uninformative and distorted by the wikidata presented by default after initially trying to rescue it by a maplink solution (all in sandbox so no record). The problem is that some wikidata can by association not be what you want to show and changing the default behaviour of the maplink associated maps is not understood by many editors ChaseKiwi (talk) 20:53, 4 October 2024 (UTC)

See the documentation and my response to you in the section above. I have disabled the mapframe map in that article. Check the diff to see how I did it. – Jonesey95 (talk) 22:27, 4 October 2024 (UTC)

Here is a search showing 36 articles that use {{OSM Location map}} and {{Infobox mountain}}, in case you are looking for suitable articles to modify using |mapframe=no. – Jonesey95 (talk) 22:36, 4 October 2024 (UTC)

Thanks -I have started work thru from bottom and discovered many do not need work but some that do. ChaseKiwi (talk) 02:09, 5 October 2024 (UTC)

Completed the work list with thanks to @Jonesey95 ChaseKiwi (talk) 17:43, 16 October 2024 (UTC)

Or you can put the OSM Location map into the map_image parameter, which automatically suppresses the mapframe map, per the documentation of this template. – Jonesey95 (talk) 22:41, 4 October 2024 (UTC)

Ta, I think the second option will be cleaner in most cases ChaseKiwi (talk) 00:31, 5 October 2024 (UTC)

Some of those Indian hill maps are a genuine work of art - yet seemingly very bad at being maps of mountains - I often found it hard to figure out where the mountain even is from all the clutter. --Joy (talk) 12:56, 6 October 2024 (UTC)

I also had a look at the same search for {{maplink}}, and found a few cases where some tuning was a good idea, but nothing horrible. --Joy (talk) 13:24, 6 October 2024 (UTC)

Yes had noticed on articles you detected where I had been the editor to first use {{maplink}} and agreed with your solutions. Also agree with your Indian maps of mountains comments. I was also impressed with some of the European Alps maps. As both used old OSM Location Map syntax from before the rewrite I have started process of reducing some maps to less than 300px so they can go in infoboxs and use new mouseover properties of overlay which can simplify. Your comment reminded me that I had failed to show a mountain shape on the busy map improvement of the Biharinath article. The Karakoram subcluded templates improvement will need lots of sandboxed fiddling one day. ChaseKiwi (talk) 16:55, 6 October 2024 (UTC)

I think the busy ones should actually be moved out of the infobox and widened, and then that can make sense.

For the infobox, the level of detail gets too busy too fast - the textual information can be dense, but it's usually straightforward: dimension X = value X, and even if there's a big amount of it, it's not complex. On maps, there are usually many dimensions: colors, lines, places, ... so adding more and more data points in a limited amount of space is just not as useful.

The 48-point map at Karkaoram definitely sounds like something that should stay separate from the infobox. --Joy (talk) 17:40, 6 October 2024 (UTC)

Agree ChaseKiwi (talk) 23:06, 6 October 2024 (UTC)

The infobox often has access to the actual size of the mountain or mountain range. I had some Lua code that computed the zoom level that keeps an object within the mapframe height. So I hooked up that up to the infobox and now it shows the mountain or mountain range nicely fitting into the mapframe. The default is 20km. This is nice, IMO, because it shortens the infobox by the height of the switcher. A user can always click into the mapframe and zoom in and out if they wish. — hike395 (talk) 02:35, 7 October 2024 (UTC)

Nice! I was angling for autodetected based on the size of the associated shape - can we also feed Wikidata into it, like the infobox does otherwise, the #invoke:WikidataIB getValue P2046 name=area stuff? --Joy (talk) 06:57, 7 October 2024 (UTC)

I'll poke around that after I get back from Wikibreak. — hike395 (talk) 15:16, 7 October 2024 (UTC)

Wikidata issue: Preferred rank items not honored

If I remove |elevation_m= from Mount St. Bride, the template code is taking the normal rank 3312 m value and not the preferred rank 3315 m value from Wikidata. RedWolf (talk) 21:39, 28 October 2024 (UTC)

It's coded to only use referenced values and the 3315 is unreferenced — Martin (MSGJ · talk) 22:06, 28 October 2024 (UTC)

Okay. Technically the 3315 had a reference defined but only to the English Wikipedia. Once I added "real" references, it then chose the 3315 value. Thanks. RedWolf (talk) 22:20, 28 October 2024 (UTC)

"References" that cite Wikipedia are not counted, per WP:CIRCULAR. Good job figuring out how to fix the problem. – Jonesey95 (talk) 15:14, 29 October 2024 (UTC)

Category:Pages using infobox mountain with potentially incorrectly plural labels [sic]

I have added a Purpose section to the talk page explaining the reason for this tracking category. I have also explained that the tracking category code is insufficient to accurately determine if a page is correctly using plural labels as it only supports the output from {{enum}} and not from other formatting templates such as {{hlist}} and {{unbulleted list}}. This issue was previously reported in October 2022 and can be found under "Potentially incorrectly plural labels [sic]" in Infobox mountain Archive 6. RedWolf (talk) 01:26, 17 October 2024 (UTC)

• It would be nice if the tracking code could also support {{hlist}} output. A simple solution would have been to specify an alternate pattern but unfortunately Scribunto expressions do not support alternates using |. Hmmm, looking at the generated HTML I see that using hlist generates an unordered list contained within a <div class="hlist">. RedWolf (talk) 20:10, 17 October 2024 (UTC)

@RedWolf: The existing code appears to be far worse than the standard technique of using {{Pluralize from text}} that is used in other infoboxes, e.g. {{Infobox settlement}}. I will attempt a fix, but the code for this infobox is so tangled, I may not be able to do it. — hike395 (talk) 10:31, 29 October 2024 (UTC)

I implemented a fix in the sandbox. Instead of using regular expressions and tracking categories, I used {{Pluralize from text}} to directly change the labels based on the entity. See the test cases. The {{Pluralize from text}} template is conservative: when it is sure that an input is singular or plural, it will emit, e.g., "Region" or "Regions". If it isn't sure, it hedges its bets and emits "Region(s)". The decision logic can be made more precise, but I need to ask an administrator to accept a change at Module:Separated entries. @RedWolf: was there an article that used hlist that you know of? Hlist should work, but it would be good to have a test case. See also the edit request at Template talk:Separated entries. — hike395 (talk) 11:09, 29 October 2024 (UTC)

• @Hike395: Pyrenees uses hlist for country. RedWolf (talk) 20:44, 29 October 2024 (UTC)

That seems to work, see the Pyrenees test case. I'll promote to the main infobox. Pages using infobox mountain with potentially incorrectly plural labels can then be deleted. — hike395 (talk) 01:39, 30 October 2024 (UTC)

• Nice work. The code did actually find some articles where countries was specified for the country_type but only one country given or multiple countries given but country_type not set so the category does have some use. If not deleted, I'd like to see the category name fixed (grammar issue) which would also mean the code needs to be updated as well. Alternatively, change it so it displays a warning in preview mode. RedWolf (talk) 09:03, 31 October 2024 (UTC)

Oh wait a minute. I just read exactly what {{Pluralize from text}} does so yeah the category could just be deleted now. That's what I get for replying here before going to sleep. :) RedWolf (talk) 09:07, 31 October 2024 (UTC)

I don't know how to automatically handle the case where |country_type= is not set correctly. We could set a tracking category for those kind of parameters, and then manually check and correct them with AWB. Many of the non-empty arguments can now be removed and the automatic code can work (esp if we use {{force singular}} or {{force plural}} in |country=, which would override the decision of {{Pluralize from text}}). — hike395 (talk) 14:29, 31 October 2024 (UTC)

Later --- The latest TemplateData report shows that there are low thousands of uses of |*_type=. OTOH, we may be able to use links from that report to quickly look at some of the most dubious uses, without doing a full "tracking category + AWB sweep". — hike395 (talk) 14:34, 31 October 2024 (UTC)

I'd suggest pluralizing |geology= as well since many mountains consist of more than one rock type. Volcanoguy 14:43, 1 November 2024 (UTC)

Good idea! Looking through the parameters, the following could be usefully pluralized:

• |nickname=
• |topo=
• |orogeny=
• |mountain_type=
• |geology= (per Volcanoguy)

I'll try these out in the sandbox and testcases, comments welcome. — hike395 (talk) 16:26, 1 November 2024 (UTC)

Could probably also pluralize |period= and |age= since the rocks comprising mountains can be of different ages. Volcanoguy 16:37, 1 November 2024 (UTC)

For example, see Mount Edziza. Volcanoguy 16:39, 1 November 2024 (UTC)

 Implemented in the sandbox. — hike395 (talk) 23:12, 1 November 2024 (UTC)

 Done promoted to main. Let me know if anyone sees any problems. — hike395 (talk) 16:36, 3 November 2024 (UTC)

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? --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 - - 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)

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)

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)

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)

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)

I've removed the deprecated |Volcanic_region= parameter from all articles. Volcanoguy 16:43, 2 August 2025 (UTC)

References