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)