Template talk:Infobox mountain/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Municipalities and cities?

A while back, Frietjes 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)

Frietjes --- 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 |city_type=Municipalities or |city_type=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)

Frietjes --- 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 |city_type=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 |settlement_type=Municipality or |settlement_type=Municipalities (depending on if there is more than one listed). I have added the alternative syntax. Frietjes (talk) 18:01, 21 October 2018 (UTC)

@Frietjes: 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 |settlement_type=Municipality when the entry is classified as a municipality. if it's a county, then that usually goes in |district= with |district_type=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.

• native_name takes place of other_name if the latter is empty, and becomes separated from other contents of "Naming" section.
• I don't see native_name_lang changing anything.
• Usage of translation and language is not explained.

--Qbli2mHd (talk) 10:58, 11 February 2019 (UTC)

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

• other_name will always appear as a subheader: it's an alternative name for the mountain, in English (e.g., "Mount McKinley" for Denali)
• native_name 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. native_name_lang will now appear in parentheses after the native name.
• translation is when the name of the mountain is not English: it's the English translation of the name
• language is the language of the name of the mountain. Previously, it only appeared when translation 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 translation/language
• Ben Nevis is another example of the translation/language change.
• Hauhungatahi is an example where language wasn't being displayed before.
• Andes is an example where the native_name is moved down to the Naming section
• Gagarin mountains is a new test for native_name_lang

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 language looks clumsy when native_name is not empty and it's pretty confusing since native_name_lang 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 native_name_lang interchangeably with language. So, maybe both parameters should be treated the same, but the display should depend on contents of native_name (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_name (other English name) will always appear as a subheader.
• native_name (non-English name) now always appears in the Naming section.
• translation is the English translation of the name
• language is the language of the name of the mountain (a string that can contain arbitrary wikimarkup), and native_name_lang is the ISO 639 code for that language. You can enter either one. If native_name is used, then the language name will appear after it in parentheses. If native_name 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)

 Done 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 language 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 was removed because {{Infobox mountain}} is supposed to pull it from Wikidata. It evidently does so for elevation, but not prominence, even though it does use {{convert|input=P2660}} as you'd expect. Hairy Dude (talk) 21:48, 3 June 2019 (UTC)

 Fixed {{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 {{coord}}? RedWolf (talk) 17:11, 13 August 2019 (UTC)

@RedWolf: 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)

• @Hike395: 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)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} 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 Hike395 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 Johnuniq 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 {{#invoke:Plain text|main| }} 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 Frietjes 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 Britishfinance 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)

 Done --- added |grid_ref_UK_note= and |grid_ref_Ireland_note=. @Britishfinance: 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 Hike395, 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)

@Hike395: 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 foot_montage 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)

 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)

@Jonesey95 and Mikhail Ryazanov: as a general rule, it's better to 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 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)

@Plantdrew: 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

@Rehman: 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#Catskill Mountains 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: bodystyle 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. Rehman 04:20, 1 June 2020 (UTC)

The error still occurs in the Catskill Mountains test case --- {{{area_note}}} shows up as literal text after the area data. I don't know whether this problem is limited to area_note, 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, Rehman 04:49, 1 June 2020 (UTC)

Done. Rehman 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? Rehman 16:29, 17 July 2020 (UTC)

@Rehman: Sure. This was triggered when I saw this edit. 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, Rehman 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)