Template talk:Infobox mountain

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)