Template talk:Infobox mountain/Archive 4

Municipalities and cities?
A while back, added municipality to the infobox. To me, that seems redundant with city (which really should be called settlement). Should we remove municipality? —hike395 (talk) 08:52, 20 October 2018 (UTC)
 * hike395, I added "Category:Pages using infobox mountain with municipality parameters" to get a better idea of the scope of the usage of these parameters. if the use is infrequent, and/or unnecessary, we can certainly delete these parameters. the suggestion that city should be settlement makes sense, but it would probably be less work to keep city as an alias. Frietjes (talk) 14:45, 21 October 2018 (UTC)
 * --- thanks so much for adding the tracking category! There aren't that many articles that use municipality: I'm happy to convert them with AWB. I agree that we should stick with city. That parameter was inherited from Geobox when I created Infobox mountain range in 2012 --- it was too much work to rename it back then, too. —hike395 (talk) 17:34, 21 October 2018 (UTC)
 * hike395, I think the tracking category may be still filling up; but it does look like there aren't that many. changing them to city, city1, ... with Municipalities or Municipality is probably fine, but we need to make sure we don't introduce any parameter collisions if both are being used at the same time.  I could scan the articles in the tracking category to see if any are using any of the city parameters as well, but I will wait until the category stops filling.  Frietjes (talk) 17:40, 21 October 2018 (UTC)
 * --- when I use WP:AWB, I look at every single edit. If it looks like there is a collision with city, I will fix that manually. We should certainly not remove muncipality until the tracking category is filled and all of the edits are done.
 * I can set Municipality (or plural), but I wonder if that is correct in general. A small sample of four shows that the entities in the listing are "town", "township", "unincorporated town", and "municipality". I wonder if "settlement" is a more general (and hence more correct) label. —hike395 (talk) 17:55, 21 October 2018 (UTC)
 * hike395, in that case, I would say use Municipality or Municipalities (depending on if there is more than one listed). I have added the alternative syntax. Frietjes (talk) 18:01, 21 October 2018 (UTC)
 * Sorry, I may not have been clear. I was not proposing settlement_type. I was bringing up the issue of whether we should "Municipality" as the label. I've started the conversion process (it's a small task), and will maintain "Municipality" as the label.
 * I see that municipality has been misused in a number of these articles. One or more editors have been filling it in with U.S. counties. I've been fixing the articles as I find them. —hike395 (talk) 18:18, 21 October 2018 (UTC)
 * hike395, yes, clearly we should only use Municipality when the entry is classified as a municipality. if it's a county, then that usually goes in district with County.  if the entries are a mixture of cities, CDPs, populated places, etc. then "settlements" is the most accurate.  I would say that "settlement" is correct, but more generic than other labels.  I certainly don't want to review every use of city and try to figure out the settlement type. in any event, the tracking category is now empty, so I have removed the municipality parameters.  any new ones will pop up in the standard unknown parameters category. Frietjes (talk) 14:42, 22 October 2018 (UTC)

Language parameters
They seem to be broken, or I just couldn't figure it out. --Qbli2mHd (talk) 10:58, 11 February 2019 (UTC)
 * takes place of  if the latter is empty, and becomes separated from other contents of "Naming" section.
 * I don't see  changing anything.
 * Usage of  and   is not explained.


 * It's a mess, and I contributed to the mess when I merged Template:Infobox mountain range into this template. Here's what I've done to fix it (in the sandbox):
 * will always appear as a subheader: it's an alternative name for the mountain, in English (e.g., "Mount McKinley" for Denali)
 * now always appears in the Naming section. It's for when the name of the mountain is in English, but the local name is different.  will now appear in parentheses after the native name.
 * is when the name of the mountain is not English: it's the English translation of the name
 * is the language of the name of the mountain. Previously, it only appeared when  was provided, now it's a separate row in the infobox.
 * I updated the documentation to try to clarify all of these parameters.


 * My changes are relatively noticable, so they are not live yet. Please see the testcases for the effect of the changes:
 * Slieve Gallion shows the change for /
 * Ben Nevis is another example of the translation/language change.
 * Hauhungatahi is an example where  wasn't being displayed before.
 * Andes is an example where the  is moved down to the Naming section
 * Gagarin mountains is a new test for


 * Please take a look: I would love to get feedback before I make the changes go live. —hike395 (talk) 14:27, 11 February 2019 (UTC)


 * Haven't used this template before, so I think it's better to ask a more experienced editor. But if you ask me a separate row for  looks clumsy when   is not empty and it's pretty confusing since   serves almost the same purpose. I think it would look better if the name of the language was displayed in the left column (like Native name (Scottish Gaelic)) or, if it's hard to implement, just leave it after the name itself in parentheses (like Beinn Nibheis (Scottish Gaelic)). I'm not familiar how the template is used usually, but I'm afraid that editors might use   interchangeably with  . So, maybe both parameters should be treated the same, but the display should depend on contents of   (separate row if empty and parentheses if not)? --Qbli2mHd (talk) 16:17, 11 February 2019 (UTC)
 * Thanks for the suggestion! I updated the sandbox to implement it:
 * (other English name) will always appear as a subheader.
 * (non-English name) now always appears in the Naming section.
 * is the English translation of the name
 * is the language of the name of the mountain (a string that can contain arbitrary wikimarkup), and  is the ISO 639 code for that language. You can enter either one. If   is used, then the language name will appear after it in parentheses. If   is not used, you get a separate row labeled "Language of name".
 * Thanks again! —hike395 (talk) 03:47, 12 February 2019 (UTC)
 * Great. I'd only suggest to put the native name in italics. --Qbli2mHd (talk) 10:13, 12 February 2019 (UTC)
 * ✅ It's more than simply adding italics --- some languages (like Chinese) don't get italicized. I used a little code to figure out the ISO 639 code of the language, then applied that to the native_name. The formatting and language labeling should be correct now, even when  is used. —hike395 (talk) 15:54, 12 February 2019 (UTC)

Prominence from wikidata?
I noticed that Mount Everest currently has no figure for prominence. Apparently an explicit figure in the article because  is supposed to pull it from Wikidata. It evidently does so for elevation, but not prominence, even though it does use as you'd expect. Hairy Dude (talk) 21:48, 3 June 2019 (UTC)
 * convert gets confused when there are two values for prominence. Removed the imperial units, now it works. —hike395 (talk) 02:58, 4 June 2019 (UTC)

Map label blank if range coords are given
I added the range coordinates to the infobox for Mount Aylmer but now the map label is missing from the infobox. A bug or did I specify a wrong parameter for °N, °W ? RedWolf (talk) 17:11, 13 August 2019 (UTC)


 * It's not a bug, but it's a consequence of the merge between Infobox mountain range and Infobox mountain. Like Geobox, the old Infobox mountain range did not put labels next to the mark on the map, while Infobox mountain did. In order to do the merge and keep backwards compatibility, I had to make a guess at whether the article was about a single mountain or a whole mountain range. My assumption: if range coordinates were supplied, then it was about a range, otherwise a mountain. Thus, if range coordinates are supplied, the label is suppressed (to be backwards compatible with mountain ranges).


 * You're entering range_coordinates for single peaks, which I had never intended. Of course, the documentation is obscure and doesn't forbid this. But you're getting the mountain range formatting, which includes:
 * No label next to the mark on the map
 * Mark on map set to range_coordinates, not coordinates
 * Automatically computed dim: for geohack is applied to range_coordinates, not coordinates
 * You may find these surprising.


 * I think I should clarify the documentation to state that range_coordinates are intended only for mountain ranges, not for single peaks. I would suggest not adding them to articles like Mount Aylmer. —hike395 (talk) 07:04, 14 August 2019 (UTC)


 * Thanks for clearing up the mystery. I didn't want to dig into the infobox code given it uses IMHO the very distasteful template syntax rather than LUA. Yes, I agree that the documentation should be updated to match the behavior. I'm not sure what the rationale was for not including a label on maps for mountain ranges. I looked at a few other infoboxes and some have the labels and some don't. Perhaps it comes down to a personal preference among the leading editors that use the infobox. For the record, I prefer the labels. I've commented out the range coords from Mt. Aylmer to restore the map label. RedWolf (talk) 18:37, 14 August 2019 (UTC)

Template-protected edit request on 10 October 2019
Please change template call ifempty to if empty to avoid the redirect. The call to that template is transcluded in nearly 24,000 articles through being called in this template, so that unnecessary redirect has to be followed every time one of those articles is viewed. Colonies Chris (talk) 15:43, 10 October 2019 (UTC)
 * Red information icon with gradient background.svg Not done for now: please establish a consensus for this alteration before using the template. For further discussion see User talk:Colonies Chris. --Trialpears (talk) 16:31, 10 October 2019 (UTC)

grid_ref_Ireland
Something seems to have gone wrong with the "grid_ref_Ireland" item in the infobox. Now giving an error of "Malformed OS grid ref: Malformed NGR" in all Irish mountain infoboxes (examples at Ben Lugmore and Mweelrea). Any idea what has happened? thanks. Britishfinance (talk) 09:35, 19 August 2019 (UTC)
 * The same error of "Malformed OS grid ref: Malformed NGR" is also appearing on the template page of "infobox mountain" under "OSI/OSNI grid" and "OS grid". Britishfinance (talk) 11:17, 19 August 2019 (UTC)
 * I notice that someone seems to have dynamically linked the grid ref to GeoHack maps (which is a good thing); however, where a reference was added for the grid ref, this is causing a problem and the error. I have deleted the refs for Ben Lugmore and Mweelrea above and it works now, however, there are lots of other Irish mountains with this problem that will need to be adjusted. Britishfinance (talk) 13:12, 19 August 2019 (UTC)
 * Britishfinance, it looks like may be able to help.  I put some experimental code to split the references from the text in Module:OS coordinates/sandbox, and it kind of works, but someone like  could probably make it actually work.  the other issue is that the text is passed twice by gbm4ibx and iem4ibx, so we may only want to put something like   in gbm4ibx and iem4ibx and then have the ref splitting only on the link text? Frietjes (talk) 14:46, 19 August 2019 (UTC)
 * I could look at this in a couple of days if it's still a problem. A short test case showing the problem would be good. Johnuniq (talk) 00:13, 20 August 2019 (UTC)
 * It seems like this field was dormant (not dynamically linked to GeoHack), but has been able to link it.  This is a nice upgrade, however, there are many infoboxes where the grid_ref field contains the grid_ref plus a citation (from where the ref came), which is causing an error (e.g. Lugduff).  However, it will be worth fixing this up if the update by Frietjes works? Perhaps if in the absence of a valid grid_ref, the system would avoid printing an error message and just leave the text? Britishfinance (talk) 00:17, 20 August 2019 (UTC)

Sorry for the inconvenience. For now, I will just have Module:OS coordinates produce unlinked text if it cannot parse the OS grid ref. I'll leave the error tracking category in place. —hike395 (talk) 02:10, 20 August 2019 (UTC)
 * Great, thanks, that works. Britishfinance (talk) 09:16, 20 August 2019 (UTC)
 * Also, I think it would be worth adding to the infobox template guide in the grid_ref section, to only insert gridrefs into those infobox fields and not any references? Britishfinance (talk) 09:19, 20 August 2019 (UTC)
 * I think is on the right track here. I don't see a way to fix this from within Lua (because by the time the reference has reach Lua, it's munged beyond recognition). What we need to do is add two new parameters to the infobox, grid_ref_UK_note and grid_ref_Ireland_note, and then move the references into the corresponding new parameter. Someone could run AWB to do a mass split. Unfortunately, my Windows computer is busted right now, so I can't run AWB. —hike395 (talk) 12:03, 20 August 2019 (UTC)

✅ --- added grid_ref_UK_note and grid_ref_Ireland_note. The problem doesn't show up on all Irish mountains, just the ones with references in the field. A brief spot check shows that this isn't terribly common --- you might be the only editor who is doing this? Could you possibly go back and split out the references into the new note fields on the mountains that you've edited? That would be a lot of help! —hike395 (talk) 12:36, 20 August 2019 (UTC)
 * Thanks, I will do that on the Irish ones for sure as it is a good improvement overall (and a critical data item). thanks again. Britishfinance (talk) 13:01, 20 August 2019 (UTC)
 * Was away and only getting back to my list and have seen that you had already sorted this for me – huge thanks for that! Britishfinance (talk) 09:02, 17 October 2019 (UTC)

foot_montage font size
The font size in the caption produced by the  parameter is too small and contradicts MOS:FONTSIZE. See Sparrow Hills for an example. Please correct (unfortunately, I don't know how, since this is not even mentioned in the documentation, neither present in the source code). — Mikhail Ryazanov (talk) 10:38, 20 November 2019 (UTC)
 * Red information icon with gradient background.svg Not done: This parameter is in Template:Photomontage. I found and fixed some 80% text in this template, however, so your request was not for naught. – Jonesey95 (talk) 15:33, 20 November 2019 (UTC)
 * I have also adjusted the font size in Template:Photomontage, so Sparrow Hills looks more reasonable now. – Jonesey95 (talk) 15:41, 20 November 2019 (UTC)
 * as a general rule, it's better to [//en.wikipedia.org/w/index.php?title=Sparrow_Hills&type=revision&diff=927147675&oldid=927105499 move the caption] to the caption parameter provided by the infobox since you will get the same font-size as the font-size used by non-montage images. also, I find that [//en.wikipedia.org/w/index.php?title=Sparrow_Hills&diff=next&oldid=927147675 multiple image] does a better job of sizing the images to reduce non-uniform whitespace between the images.  Frietjes (talk) 17:25, 20 November 2019 (UTC)

Parameter use stats
There's a lot to read up there and I may have missed something. The monthly report on parameters used by this template is can be found here. Plantdrew (talk) 19:06, 6 May 2020 (UTC)


 * Thanks, Plantdrew, for posting this! I found that site a long while back, but then forgot to bookmark it, and couldn't find it again. Very handy!


 * I'm sorry the discussion is such a mess --- we're discussing a lot of things in parallel. Feel free to comment on anything you wish, or ask clarifying questions. — hike395 (talk) 07:04, 7 May 2020 (UTC)


 * I'm struck by how "clean" the parameter list is. If nobody is monitoring the template parameter report, infoboxes can accumulate hundreds of bogus parameters; miscapitalizations and misspellings of valid parameters, garbage text vandalism, unsupported parameters wishfully added by somebody, etc. I monitor the Taxobox template for bogus parameters; every month there are a dozen new ones (mostly typos of valid parameters), and it took me about 2 months to fix the bad parameters when I first started monitoring it. Somebody (Rehman?) has been putting some effort into eliminating bogus parameters from Infobox mountain. Plantdrew (talk) 17:56, 7 May 2020 (UTC)


 * Module:Check for unknown parameters is used by this template and is quite nice. Errors are placed into Category:Pages using infobox mountain with unknown parameters. I sometimes check that category to fix it --- I bet other Mountain editors do, too. — hike395 (talk) 09:41, 8 May 2020 (UTC)

Bugs introduced by May 26 edits
I think your last batch of edits has introduced at least one bug in the infobox. See "Area" under San Gabriel Mountains live article and under the Template:Infobox mountain/testcases testcase. I'll roll back (temporarily)

Would you mind putting the edits into a sandbox so we can test them? I can write a new testcase page that compares a sandbox (how about sandbox4?) against the behavior of the template before all of the latest edits started. That way, we can make sure that wikidata-fication isn't introducing any problems. — hike395 (talk) 03:26, 1 June 2020 (UTC)


 * I did the following actions
 * Reverted the May 26 batch of edits.
 * Copied the May 26 edits into Template:Infobox mountain/sandbox4
 * Created Template:Infobox mountain/test versus status quo ante which compares the current version of the infobox to the version before all of the wikidata editing started. You can see the bug in the Catskill Mountains testcase. (There's also spacing differences which makes it difficult to compare: I'll chase that down).
 * — hike395 (talk) 03:42, 1 June 2020 (UTC)


 * Later --- I found the difference in style:  was edited out. I restored it to sandbox4, so now it will be easy to compare. I would recommend editing in sandbox4 until all of the testcases in the new test cases look the same, then pushing to the live template. — hike395 (talk) 03:51, 1 June 2020 (UTC)


 * Can you be more specific please? It seems like you have reverted more than just the area parameter, FYI. Previewing San Gabriel Mountains using Template:Infobox mountain/sandbox does not show anything odd in the area parameter, and nor do I see anything odd in your links. Reh  man  04:20, 1 June 2020 (UTC)


 * The error still occurs in the Catskill Mountains test case --- shows up as literal text after the area data. I don't know whether this problem is limited to , or whether it might be common to the other dimensional parameters: for safety, I undid all of the edits, but maybe you can debug, compare to the new testcases, and then restore working code for all of the parameters? — hike395 (talk) 04:26, 1 June 2020 (UTC)


 * Okay, now it makes sense. That parameter was not tested in the sandbox as it is pending rename (after you complete the Wikidata copying). I've spot the missing pipe in the particular support parameter, and will recheck such for other pending-rename parameters, add them back. Thanks, Reh  man  04:49, 1 June 2020 (UTC)
 * Done. Reh  man  04:56, 1 June 2020 (UTC)

July 17 reverts
User:Hike395, can you please give an example for Special:Diff/968084259, so I can check what happened? Reh man  16:29, 17 July 2020 (UTC)


 * Sure. This was triggered when I saw . There was only one country ("United States") showing up under Rocky Mountains. If you look at Template:Infobox mountain/test versus status quo ante 2, you'll see that sandbox1 code only shows the first country of large mountain ranges (see, e.g., the Appalachian Mountains test case, the Alps test case, and Andes test case. Before my edit, the current infobox behaved in the same way as the current sandbox does. My fix was to keep the infoboxes correct until the bot runs. After the bot runs, the first if statement will always evaluate to false, so all of the Collapsible list and Enum code will off. This is not a revert (per se), but fixing a bug in your previous edit.


 * Your code may have assumed that infoboxes either use country or country1, country2, country3, etc. Instead, editors use country for the first country, country1 for the second one, etc. — hike395 (talk) 18:59, 17 July 2020 (UTC)


 * Thank for the fix Hike. You are correct, I think I have assumed country or country1 here. As it works now, I'll leave it at that till the bot runs. The interim code to support both the old values and the new values can be quite complex :( Please excuse my language brevity (i.e. "revert"); juggling work and wiki. Cheers, Reh  man  07:15, 21 July 2020 (UTC)

Destroyed Mountain?
Should we add a date destroyed to the template? I can only find like two pages that this would apply to, but it seems like a fact about a mountain that would be major enough to include in its infobox. LizzieMack (talk) 19:48, 21 July 2020 (UTC)
 * I think you've just answered your own question: only relevant to two mountains? Nope - no need for it whatsoever. Just put it in the article. (Krakatoa, I assume?) Nick Moyes (talk) 00:47, 22 July 2020 (UTC)