Template talk:Infobox mountain

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)

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)

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)

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)

Infobox cleanup

Hello. I'm attempting to amend and clean-up the template code so as to achieve the below:

1. Enable Wikidata values when no local value is present.
2. Add non-static interactive map support (example)
3. Clean up duplicate parameters (random example: range_coordinates and range_coords ) - to be done only together with another edit
4. Remove redundant parameters (random example: state1 through state18) which can be instead included as a UBL in a single parameter - to be done only together with another edit
5. Update documentation

As part of #1, I have added the Wikidata support codes at Template:Infobox mountain/sandbox for most critical parameters, with the documentation being drafted at Template:Infobox mountain/sandbox/doc. The code will be moved to live after another review, and after the documentation of Wikidata properties is complete. There should be no visual difference during this change, and no functional change to existing usages. Hence if there are any issues, please do raise it up here, and I'll get to it right away. At the same time, if anyone has any comments or suggestion, please do state here, and I will do my best to incorporate it. Best wishes! Rehman 11:53, 29 March 2020 (UTC)

@Rehman: I noticed that you deleted the bodystyle, labelstyle, datastyle, imagestyle and captionstyle in Template:Infobox mountain/sandbox, which does cause a visual difference. Can you kindly revert those deletions? I'm happy to discuss the formatting of the infobox, but that should be separate from the major edit that enables using Wikidata. — hike395 (talk) 06:10, 30 March 2020 (UTC)

Hi Hike395. That's just in the sandbox environment - I've trimmed it for my convenience of handling the code. The live edit will not have those changes. Rehman 06:39, 30 March 2020 (UTC)

@Rehman: I would find it easier to look through the Template:Infobox mountain/testcases if the formatting in the sandbox was the proposed formatting. May I restore them in the sandbox? I like having the sandbox be the exact proposal for the edit, rather than relying on a possible error-prone future edit. — hike395 (talk) 06:54, 30 March 2020 (UTC)

Sure, that makes sense. I will restore shortly. Rehman 07:48, 30 March 2020 (UTC)

Done. Rehman 03:32, 31 March 2020 (UTC)

Hi Plastikspork. Would you be able to assist in running your bot through articles using {{Infobox mountain}}, to make the following changes please?

Rename duplicate parameters

From	To
coords	coordinates
type	mountain_type
topo	topo_map
relief	map_relief
part_type	subdivision_type
parent	range
language	native_name_lang

Consolidate values through {{Convert}}

Parameter to clear	Destination
area_km2	Move to area, within {{Convert}}
area_mi2
elevation_m	Move to elevation, within {{Convert}}
elevation_ft
isolation_km	Move to isolation, within {{Convert}}
isolation_mi
length_km	Move to length, within {{Convert}}
length_mi
prominence_m	Move to prominence, within {{Convert}}
prominence_ft
width_km	Move to width, within {{Convert}}
width_mi
*If "destination" is already filled, then the other parameters can simply be deleted.

Convert to footnote and append output in the "misc" parameter

Parameter to clear	Move to suffix of
area_note	area
coordinates_note	coordinates
coordinates_ref
coords_ref
range_coordinates_note	range_coordinates
elevation_ref	elevation
elevation_note
grid_ref_Ireland_note	grid_ref_Ireland
grid_ref_UK_note	grid_ref_UK
isolation_ref	isolation
length_note	length
width_note	width

Consolidate parameter series using {{Unbulleted list}}

Parameter to clear	Replacement action
border	Move contents to border, in the same order, using {{Unbulleted list}}
border1
border2
border3
border4
border5
border6
border7
border8
city	Move contents to city, in the same order, using {{Unbulleted list}}
city1
city2
city3
city4
city5
city6
city7
city8
city9
city10
city11
city12
city13
city14
city15
city16
country	Move contents to country, in the same order, using {{Unbulleted list}}
country1
country2
country3
country4
country5
country6
country7
country8
district	Move contents to district, in the same order, using {{Unbulleted list}}
district1
district2
district3
district4
district5
district6
district7
district8
district9
geology	Move contents to geology, in the same order, using {{Unbulleted list}}
geology1
geology2
geology3
geology4
geology5
rock
part	Move contents to subdivision, in the same order, using {{Unbulleted list}}
part1
part2
part3
part4
part5
part6
part7
part8
part9
part10
part11
part12
part13
part14
part15
part16
age	Move contents to age, in the same order, using {{Unbulleted list}}
period
period1
period2
period3
period4
region	Move contents to region, in the same order, using {{Unbulleted list}}
region1
region2
region3
region4
region5
region6
region7
region8
region9
region10
region11
region12
region13
region14
region15
region16
region17
region18
region19
region20
region21
region22
region23
settlement	Move contents to settlement, in the same order, using {{Unbulleted list}}
settlement1
settlement2
state	Move contents to state, in the same order, using {{Unbulleted list}}
state1
state2
state3
state4
state5
state6
state7
state8
volcanic_arc/belt	Move contents to volcanic_region, in the same order, using {{Unbulleted list}}
volcanic_arc
volcanic_belt
volcanic_field

Uses of {{Infobox mountain range}} should be changed to {{Infobox mountain}} to avoid redirect.

I have manually fixed erroneous usages based on the previous parameter scan. Once the above changes are done, would you be able to run one final scan please?

Thank you so much! Rehman 05:34, 30 March 2020 (UTC)

@Plastikspork and Rehman: Please hold off on running the bot. We should come to a consensus of whether we want to drop these parameters. Some of them are convenient for editors. — hike395 (talk) 06:14, 30 March 2020 (UTC)

Hi Hike395. These are all duplicate parameters. None of the changes would remove/disable/change any output in live articles. Which parameter are you referring to, so that I may have a look? Rehman 06:39, 30 March 2020 (UTC)

@Rehman: See below. — hike395 (talk) 06:50, 30 March 2020 (UTC)

Plastikspork, sorry for the pings. Please hold the bot run pending below discussion. Rehman 07:48, 30 March 2020 (UTC)

I have added sub-heading for each discussion area, for easier navigation and reading. Rehman 03:38, 6 April 2020 (UTC)

Discussions

Volcano parameters

Resolved

@Rehman: The merging of volcanic_arc/belt, volcanic_arc, volcanic_belt and volcanic_field to volcanic_region sounds like a good idea and it is something I have been thinking about for some time. There is something else I have thought about and that is stratigraphic units. It is not uncommon for mountains made of volcanic or sedimentary rocks to be part of groups or formations. However, there seems to be no parameter for such features. I am not sure what the best code name would be, perhaps stratigraphic_unit? Volcanoguy 22:46, 31 March 2020 (UTC)

I would also like to note that last_eruption should probably be renamed to last_known_eruption since it is commonly used for the youngest dated eruptions using, radiocarbon, potassium-argon and other methods. There is always the possibility of there being younger eruptions that have not been dated/witnessed, especially volcanoes in remote locations. Volcanoguy 23:37, 31 March 2020 (UTC)

Thanks for the feedback, User:Volcanoguy. Noted on the volcanic_xxx parameters. I went ahead and added stratigraphic_unit to the sandbox (pending live edit, together with the others). Do you have a couple of examples I could look at (i.e. the types of values that may be added to this parameter), so I can work on the Wikidata data model and also update the documentation? Cheers, Rehman 03:46, 1 April 2020 (UTC)

Brown Bluff currently has James Ross Island Volcanic Group in volcanic_field and Mount Erebus has McMurdo Volcanic Group in volcanic_belt but both should be moved to stratigraphic_unit once it becomes available. Volcanoguy 05:46, 1 April 2020 (UTC)

User:Volcanoguy, thanks! On a separate note, when volcanic_arc/belt, volcanic_arc, volcanic_belt, and volcanic_field, is renamed to volcanic_region, would contents of the new stratigraphic_unit also fit into volcanic_region? Or would you still prefer the separate parameter? Rehman 07:12, 1 April 2020 (UTC)

Stratigraphic units and volcanic regions are two different things, not to mention stratigraphic units are not limited only to volcanoes. I was the one who added the volcanic groups in the volcanic_field and volcanic_belt parameters, simply because there isn't an appropriate parameter to add them in. So yes stratigraphic_unit and volcanic_region would be better off as separate parameters. Volcanoguy 18:36, 1 April 2020 (UTC)

Noted, and thanks for the clarification. Rehman 02:17, 2 April 2020 (UTC)

Regarding last_eruption, changing the label to "Last known eruption" would widen the infobox or drop text to the next line. Would it suffice mentioning it in the documentation (as is the case now)? Rehman 04:11, 1 April 2020 (UTC)

Yes. Volcanoguy 05:46, 1 April 2020 (UTC)

@Rehman: I'm curious as to why you list coords and range_coordinates as duplicate parameters. coords is intended for individual mountains while range_coordinates is intended only for mountain ranges. Volcanoguy 01:15, 2 April 2020 (UTC)

User:Volcanoguy, range_coordinates was basically the generic coordinates parameter for the former {{Infobox mountain range}}. When that infobox was merged in to this sometime back, the parameter was added as an additional parameter instead of merging into this infobox's coordinates parameter, while only the documentation was updated as "range coordinates".

Ignoring the above for arguments sake, having two separate parameters still does not make sense because if a mountain-article states the coordinates of the mountain, that coordinates is valid for the mountain range as well. And if a mountain-range article states the coordinates for the range, that is still the only default coordinates for the article. What I'm trying to say is, the two parameters would not clash, and should have been maintained as a single parameter. Rehman 02:17, 2 April 2020 (UTC)

Good catch, Volcanoguy. coords and range_coordinates are not duplicates! coords are the coordinates of the highest peak or summit of a range, while range_coordinates are for the centroid of the range. range_coordinates center the range on the geohack map, are zoomed out, and appear in the title, while coords are zoomed in to the highest peak, and are inline only (if both are supplied). This allows readers to see both a contextual map of the entire mountain range, or a detailed map of the highest peak. — hike395 (talk) 02:23, 2 April 2020 (UTC)

Adding two coordinates should not be a problem. And I can also add Wikidata support for both, using qualifiers. But the newer version of geohack does not need two coordinates saved in order to pan or alter zoom. In fact if I'm not mistaken, the newer maps can geomask the whole mountain range, while also adding a placemark for the summit. I'll check on the latter and comment again, but I'm certain about not requiring two coordinates for map adjustment. Rehman 02:48, 2 April 2020 (UTC)

Sorry, perhaps I wasn't clear. For a concrete example, take a look at Rocky Mountains. coords makes a link under the "Highest Point" section: when you click on it, you get taken to a geohack map of Mount Elbert. range_coordinates makes a link under the Geography section, and when you click on it, you get taken to a zoomed-out geohack map of the entire range. The latter gets used as the title coordinates. For ranges, you want two coordinates in case the highest peak is not near the center of the range. — hike395 (talk) 03:02, 2 April 2020 (UTC)

Right, okay now it makes sense. Sorry I misunderstood your comment as something to do with adjusting the maps. I've updated the table above, and will model the same for Wikidata as well. Cheers, Rehman 03:24, 2 April 2020 (UTC)

Maybe coords should be renamed to peak_coordinates or something similar to avoid confusion? Volcanoguy 03:39, 2 April 2020 (UTC)

User:Volcanoguy, yes that would. I went ahead and updated the sandbox, but had to revert again after realising that coordinates has to be a standard, in compliance with WP:MOSINFOBOX. Rehman 11:45, 3 April 2020 (UTC)

Combining parameter series

@Rehman: The parameters that you are proposing to delete are not redundant. The proposed change would affect the appearance and functionality of the infobox. Namely:

• country*, state*, region*, district*, settlement*, city*, border*, and part* do not currently behave as {{unbulleted list}}. Instead, if 5 or more entries are provided, the infobox uses {{collapsible list}}, if fewer than 5, it uses {{enum}} While a bot can certainly perform this logic once, future editors probably will not realize that they should be using {{collapsible list}} for long entries in the infobox and {{enum}} for short. By removing these parameters, we are encouraging future sprawl of the infobox.
• period* and geology* are similar, in that they use {{enum}} for formatting. {{enum}} is more compact than {{unbulleted list}}. Deleting these parameters would have a similar effect as deleting the other parameters: it would encourage sprawl and non-uniformity of infoboxes.
• elevation_*, prominence_*, isolation_*, length_*, width_*, area_*, volume_* are convenient shortcuts for editors. It seems like a shame to force future editors to use {{convert}} when the infobox used to do the conversion for them. The current infobox code also enforces unit conversion, while future editors can use whatever units they wish (e.g, furlongs).

It seems that you've proposed multiple major edits to the template at once. I'd recommend breaking the discussion and editing into three phases:

1. Using Wikidata
2. Deleting parameters
3. Changing the formatting

Can we defer deciding on whether to delete the parameters until we've decided on whether to pull data from Wikidata? — hike395 (talk) 06:48, 30 March 2020 (UTC)

Thank you for the feedback.

• #1 is complex, and requires the duplicate parameters to be cleared first, before we can fully integrate it. Most of the code is already prepared though. I'd like to reiterate that is only as a fallback - if a local value is present, wikidata value will not be shown. Hence we're only adding information on the infobox, not removing. If you have any concerns here, we could discuss, but otherwise I don't think this is a topic that requires discussion.
• For #2, I'd like to emphasise that we are not deleting parameters, but instead removing duplicates and redundancy (most of which were results of a previous merger).
• There is no #3 at this point.
• Thanks for raising the concern regarding the listing style/conversion. I can most certainly change from UBL to prose style, but this is something I'd like to discuss further. I will comment again here shortly (I'm working from home, and wiki-ing at the same time, hence excuse me if I take a bit to reply).

Cheers, Rehman 07:48, 30 March 2020 (UTC)

@Rehman: I'm afraid I don't understand why these (non-redundant, IMO) parameters need to be deleted before Wikidata is used as a fallback. Could you explain? — hike395 (talk) 08:10, 30 March 2020 (UTC)

To put is simply, to make the code as neat and simple as possible for future editors. Those parameters would not only make my work now many times harder, but would also discourage future editors to attempt improving the template, because the code would look so much more complicated with those parameters. Rehman 08:36, 30 March 2020 (UTC)

That does not sounds like a necessity to me: that sounds like a preference. Let's separate the two discussions. — hike395 (talk) 14:33, 30 March 2020 (UTC)

Idea: It just occurred to me that I can eliminate a lot of the code complexity in the infobox by writing a small amount of Lua to parse multiple arguments (like city_*) and produce the {{collapsible list}}/{{enum}} hybrid. This should answer Rehman's objection to having these parameters, and make other editors (like RedWolf) happy also. I'll do that! — hike395 (talk) 14:52, 30 March 2020 (UTC)

(replying while at work) I think it is better we not use custom lua, for the sake of keeping the code neat and understandable for future editors, with the only lua used being WikidataIB - which is already a standard. For conversation sake, why do we need to keep those repetitive parameters? IMHO, it is unsustainable and quite manual, not to mention bloating articles that use it. For instance, if a new article need another slot for say - city, do we just keep creating?

Following standard infobox usages, I strongly suggest we take the sustainable/neater approach, and use one parameter per criteria. The articles which has so many to list in that (a very small subset), can easily add br tags or use the more standard UBL lists. The vast majority in the thousands or tens of thousands, don't need those repetitive parameters. Thoughts welcome. Rehman 15:23, 30 March 2020 (UTC)

Pinging the next 10 active talkpage participants to get more opinions: User:Droll, User:RedWolf, User:Volcanoguy, User:Pigsonthewing, User:MSGJ, User:Frietjes, User:Chris.urs-o, User:Bermicourt, User:Wwoods, User:Britishfinance. Participation is of course, voluntary. :) Rehman 15:37, 30 March 2020 (UTC)

Hike395, following my previous reply, I got some interesting stats. Less than 1% of all articles using this infobox, use the first parameter of the series:

• border1 = 146 (0.60%)
• city1 = 73 (0.30%)
• country1 = 234 (0.96%)
• district1 = 82 (0.34%)
• geology1= 86 (0.35%)
• part1 = 45 (0.18%)
• period1 = 43 (0.18%)
• region1 = 292 (1.20%)
• settlement1 = 4 (0.02%)
• state1 = 214 (0.88%)

Further in the series (2, 3, etc) are almost 0% - used by only a very tiny amount of articles. Hence, I strongly feel we should not bloat the template just for those handful of uses. Rehman 06:02, 31 March 2020 (UTC)

@Rehman: Even if small in number, those are high-traffic pages, like Himalayas, Appalachian Mountains, Alps, Andes, and Catskill Mountains. When I finish my Lua, it won't be bloated. One field will look like {{#invoke:Compact list|main|border}}, and that's it. The Lua should be simple, too. Give me a couple of days to put it together. Thanks! — hike395 (talk) 02:32, 1 April 2020 (UTC)

Hike395, high-traffic pages should have no issue using a single parameter, and only indicates that more experienced editors would be around - so using UBLs or br tags would be more convenient on those pages. There would also be no visual difference anyway. Can we please gain consensus before we add custom Lua to this template? Considering that this infobox is quite straightforward (i.e. no complicated functions or features), I don't see a need to add separate Lua code, considering that it only complicates things for future editors. Let me crosspost this discussion on WP:Mountains and see if we can get more opinions on this. Cheers, Rehman 03:35, 1 April 2020 (UTC)

@Rehman: Don't worry, I won't make any changes to the live template without discussion. Conversely, if you want to change the automated use of collapsible lists and enum to manually-specified UBL, I would also bring that up at WT:MOUNTAINS. But if you could please wait until I have a prototype, because it may change the outcome of the discussion. — hike395 (talk) 04:18, 1 April 2020 (UTC)

Hike395. Further re my reply immediately above 18 days ago, and my response to your note on my talkpage regarding why changing the coding language for these parameters is not ideal, do you have any other concerns against combining the above set of parameters? If not, I'd like to close this subsection as resolved, and move on with combining the same, per above. Rehman 04:52, 19 April 2020 (UTC)

Automatic conversion

I'm not an expert on template coding but as a user, I want templates to be simple to understand and use. In particular, I don't want to have to manually add 'convert' templates. Also I suspect the shims used to very neatly convert infoboxes from other Wikis rely on being able to point e.g. at the elevation in metres (which is what everyone bar a couple of English-speaking countries use, otherwise we wouldn't need conversion at all). What I have spotted though is that the copy and past template example in the documentation (under Standard Usage) omits several of the parameters anyway and that certainly needs fixing. Finally I would say please don't roll out major changes without giving editors a chance to view, trial and comment on the changes first. This recently happened with Template:Sfn and that caused a huge number of spurious red links and lots of angry responses. Bermicourt (talk) 18:32, 30 March 2020 (UTC)

Hi Bermicourt. Thanks for the feedback!

• For simplicity, the vast number of infoboxes simply let the user decide what unit to use, or if to use convert at all (random example: Template:Infobox comet). But that being said, would adding the convert code within the copy-paste section help (like Template:Infobox docks)? This saves editors the time in looking for the code.
• The documentation has already been outdated for quite some time. The page is currently undergoing revamping, so you should be able to see the updated code soon :)

Looking forward to your comments. Rehman 04:12, 31 March 2020 (UTC)

@Rehman: I think that the automatic conversions should not be removed. When the infobox is supplied with dimensions for a mountain or range, it automatically figures out the correct scaling for the geohack map (via a call to {{infobox dim}}). Check out the code at |data9= in the infobox. If we delete |length_*=, |width_*=, or |area_*=, we lose this nice feature. — hike395 (talk) 06:19, 8 April 2020 (UTC)

{{Coordinates}} already has a default feature type:mountain used for scaling, which is for peaks, mountain ranges, hills, submerged reefs, and seamounts, and takes away the need of that chunk of code and complexity, and standardises all geohack maps even if length or width is not provided. For some reason, this infobox has implemented an override, which is now used by 1.3% of articles, or a maximum of 328 articles only. Is there a particular problem we are trying to solve by overriding the default? Rehman 04:50, 9 April 2020 (UTC)

Hello again Bermicourt. Would the above alternative solve the issue regarding the conversion? Rehman 05:10, 19 April 2020 (UTC)

The template in question that has been used a thousand times and will continue to be used is Template:Infobox mountain/Berg. This converts the German infobox to our infobox when mountain and hill articles are imported. Looking at its parameters, the height is always in metres so it will currently point to elevation_m. The same applies to isolation and dominance. If we remove elevation_m etc. then someone needs to ensure that Template:Infobox mountain/Berg is tweaked to convert that data correctly. I don't think that's difficult, but it's not something I could attempt with any confidence. Bermicourt (talk) 07:14, 19 April 2020 (UTC)

Bermicourt, thanks for the speedy reply and pointing me to {{Infobox mountain/Berg}}. On a quick look, it seems possible. I will assess further and comment again. Cheers, Rehman 08:30, 19 April 2020 (UTC)

Zoom calculation

@Rehman: I want to keep automatic conversion also. The current template calls {{infobox dim}} to determine the zoom level of the geohack map, using any one of the |length_*=, |width_*=, or |area_*= parameters. If we remove these, then the geohack map will default to be very zoomed-in, which is not appropriate for mountain ranges. I don't know of a way to extract the size of the mountain range from a free-form text field that would be in |length=, |width=, or |area=. Please don't remove this feature. — hike395 (talk) 14:07, 19 April 2020 (UTC)

Please see my reply above. Is there a particular problem we are trying to solve by overriding the well established default? Or, is there an instance where the correct Coordinate syntax caused a bad output, and this manual override solved the issue? Rehman 14:37, 19 April 2020 (UTC)

Wikidata

I'm sorry, Rehman, but we also need to discuss the implementation of Wikidata fallback.

In general, I'm a big fan of Wikidata fallbacks --- it allows centralized data to be shared consistently across wikis from all languages. That is a good thing. But, one issue that has come up in other Wikidata discussions: most editors do not know how or where to edit the data that comes from Wikidata. When you use default Wikidata, you should supply an editing icon that allows editors to change the field. Such an editing icon is created using the {{EditOnWikidata}} template. Could you add this template to the infobox when Wikidata default data is used?

One more comment and a question:

• The downside of using Wikidata is that the watchlist of an en user does not get updated when data is changed. I've seen ignorant users change the elevation of mountains to be the "well-known" (but inaccurate) values. For example, many people believe that Mount Whitney is 14494', but it is really 14505' according to the latest measurements. I guess we'll need to keep common mountain data on en in order to keep an eye on it.
• The new code that you've added to the infobox defines |qid=, |fetchwikidata=, |suppressfields=, and |onlysourced=. Would you like to explain what they do? — hike395 (talk) 08:08, 30 March 2020 (UTC)

No need to apologise; discussions make things clearer for everyone :) I'm glad you started this thread. Yes, "edit on wikidata" link will be shown. This is an example of a fully Wikidata supported infobox. And this is a random example of an article that uses Wikidata - notice the edit link.

Wikidata edits does of course show up on the local watchlist. That is, as long as the local article is on your watchlist. Have a look at Special:Preferences#mw-prefsection-watchlist, and tick "Show Wikidata edits in your watchlist". That should be default if I'm not mistaken.

The additional wikidata parameters are not directly relating to mountains, but rather are for more advanced testing and use cases. Those parameters are present in almost all Wikidata-supported infoboxes, and should not cause any issue.

Hope I answered your questions? Rehman 08:36, 30 March 2020 (UTC)

@Rehman: That's a great tip for the "Show Wikidata edits in your watchlist" preference! I didn't know about it, and it was off for me (probably because my preferences are very old). That makes Wikidata fallbacks even better!

The new parameters are not well-explained --- do we need them? I know we need |qid= for testing, do we need the other ones, or can they be removed? Each call to Module:WikidataIB has a very large number of parameters. Are these parameters changing the default? Can we eliminate many of them?

Adding Wikidata edit links will change the functionality and layout of the infobox. Can you finish implementing the proposal in the sandbox so that other editors can see what it entails? Can you add the Wikidata edit links (which adds icons)? Otherwise, we don't know what we're supporting or objecting to. — hike395 (talk) 14:47, 30 March 2020 (UTC)

Hike395: Glad it worked :) I went ahead and added the Wikidata edit link to the sandbox. What do you think? Regarding the new parameters, those are standardised params supported from WikidataIB mainly for user's preference (it is not something only created in this infobox). I personally prefer to keep it simple and to remove them, but there has been cases where issues were raised due to no way for suppressing certain calls or due to sourcing issues. Hence these standard calls are maintained for all Wikidata-based infoboxes (you'd see them in other wd infoboxes too, sometimes not necessarily documented). Rehman 03:54, 31 March 2020 (UTC)

@Rehman: The last RfC to discuss Wikidata use in infoboxes was contentious: there was a lot of concern about the accuracy of the information in Wikidata. I think we need to follow the lead of {{Infobox telescope}} and allow editors to edit each field, individually. I think most Wikipedia editors and readers don't know how to navigate Wikidata: the pen icon will help anyone to edit Wikidata (which supports the "the encyclopedia anyone can edit" philosophy).

Now, I think the icons may make the infobox look crowded. I will create a sandbox version that /only/ implements the Wikidata change, and we can look at it and decide. I will not implement any of the other parameter changes, yet. I believe we should have one discussion at a time, because all of these issues are separable. — hike395 (talk) 06:44, 8 April 2020 (UTC)

Yes, it is via comments mentioned in the RFC that parameters such as |fetchwikidata=, |suppressfields=, and |onlysourced= which you questioned earlier, were implemented. The pen icon is rather cosmetic, and can be switched anytime with a minor tweak in the code. We could keep the pen icon now, and discuss it later perhaps? The point of this discussion is to include Wikidata support, which I think is not a problem now? Rehman 04:59, 9 April 2020 (UTC)

@Rehman: The point of any Template discussion is whether to promote a proposed sandbox candidate to the main template. We shouldn't have abstract discussions about features: editors from WT:MOUNTAINS should be able to look at the code and set of testcases, and decide whether to accept it. I'm currently trying to figure out your proposed code, and make a "clean" sandbox where only wikidata fallback is added, but nothing else has changed. You've made many simultaneous changes to the code, and I'm trying to figure it all out. For example, your proposed code changes the way the infobox photo size is computed.

I'm sorry that I'm not responding rapidly: COVID-19 has turned my life upside-down. I'll work through this over the next few days. Fortunately, there is no deadline to Wikipedia. — hike395 (talk) 16:07, 9 April 2020 (UTC)

I think you're mixing up the discussion threads, or I'm confused. We're now discussing about the wikidata pen icon issue which you raised, right? I ask this because I don't see what your last response refer to? The other changes are all discussed in the other sub-threads, so let's only discuss Wikidata in this one please. I also don't see how creating a separate sandbox to showcase only the wikidata code will help? If there are no concerns about adding wd-support itself (as I see is the case, from your responses above), then we should simply start working on it parameter-by-parameter, and improve over it live, as every such implementation is done. Waiting for the perfect version to be ready in order to roll out, would be very slow and unnecessarily time consuming, not to mention it would have no impact on live articles anyway since they all currently have local values. That's like copying an article to a sandbox, working on it to FA, and then pasting back in a single edit.

I've also changed the new "Step by step" topic which you opened, as a subtopic of this subtopic, as that's Wikidata related as well. Rehman 06:14, 14 April 2020 (UTC)

@Rehman: When I proposed making a full pen icon mock-up, I thought that Wikidata was already filled with most or all of the fields that you enabled. But, from your comment on April 14, below, I realized that Wikidata was mostly empty, so any such pen-filled infobox is far into the future. I retract the suggestion of making a full mock-up, since it won't reflect what our users will experience any time in the near future.

I do have concerns about adding WD support (see below). After reading the RfC and the template docs, there's a lot of mistrust of the quality of data in WD. To follow the weak consensus around WD, I want to carefully expose information from WD to this template, and not leave it wide open for low quality data, especially in currently unpopulated or non-existent fields.

I very much like your idea of going through parameter-by-parameter, gradually transforming the infobox to use Wikidata fallback. That's better than my idea, below. I like making small incremental changes that we can carefully check. I would modify your idea slightly. For each parameter where we want a fallback, let's first add a tracking category to count the number of times it is used. If it is never used, let's skip the parameter for now (because we're just adding unneeded complexity to the template, and we're opening up for poor-quality data in the future). If it is used, then we can manually check the data added with the tracking category. If the fallback for a parameter is used on a lot of articles, we can announce that we're adding fallback to that parameter at WT:MOUNTAINS, to see if other editors can help with the manual checking.

Let's get started! I'll modify the sandbox to put tracking onto the following parameters:

• name: I think we should use {{#invoke:WikidataIB|getLabel}} which doesn't allow for a pen icon widget. That widget would be super ugly, anyway, so let's just leave it out.
• photo: There isn't a good place for a pen icon here, either.
• photo_caption: N There's a problem with the code in the first sandbox. If you dig through the Lua, {{#invoke:Wikidata|getImageLegend}} is not guaranteed to return the caption for the same image that {{#invoke:WikidataIB|getValue|P18|name=photo}} returns. That means we could be putting a caption for a different image! Let's just leave this off for now.

Let's just do name and photo for now, then we can keep doing small batches of parameters until we're done (again, not implementing fallback unless the code is actually used). Does that sound good, Rehman? — hike395 (talk) 14:48, 19 April 2020 (UTC)

Step by step

@Rehman: As I'm reading the documentation and the RfC, I'm finding a lot of skepticism about widespread unchecked use of Wikidata in infoboxes. For example, the documentation for upgrading existing infoboxes guides that Wikidata is off by default (and only gets turned on manually), and the documentation regarding verifiability recommends against using |onlysourced=false. If we follow this guidance, I think that the Wikidata fallback will never get used.

Instead, I'd like to propose a careful staging of the Wikidata fallback, to ensure that we're showing reliable data:

1. Modify the infobox to add tracking categories for each field where Wikidata has valid fallback data
2. We alert editors at WT:MOUNTAINS what we're doing, and let them know they should check the "Show Wikidata edits in your watchlist" box.
3. Depending on the number of articles that use each fallback:
   1. If the fallback never gets used, we don't add it to the infobox.
   2. If a small number of articles use the fallback, we can manually check them.
   3. If a large number of articles use the fallback, perhaps we can set |onlysourced=true and manually check only those?
4. When we're done checking a field, we turn it on in the live infobox.
5. Future changes in Wikidata will be tracked by editors in WikiProject Mountains, so they should be reliable.

What do editors think of this plan? — hike395 (talk) 06:14, 13 April 2020 (UTC)

I don't think this is necessary considering that I've only recently just started working on the ontology at Template:Infobox mountain/sandbox/doc. Meaning, prior to this, there was no official ontology on how to store this data on Wikidata. That essentially means the vast majority of mountain Q-items would not have any/most other data other than basic parameters like location, height, and identifiers. Thus, when we say an article falls back to Wikidata (when no local parameter is present), in most cases all the parameters would still remain blank as there is no data on Wikidata. And for arguments sake, if there is data on Wikidata, those would still not be displayed for any existing article, because we're obviously not going to blank the local parameters in current articles. What we're trying to do here is first bridging Wikidata and this infobox, and then separately/eventually getting Wikidata items populated with mountain data. Rehman 06:14, 14 April 2020 (UTC)

@Rehman: I didn't realize that most of the fields you were proposing are new and unpopulated. That's good to know. Maybe we can follow the steps above for factual fields (i.e., the image of a mountain doesn't need to be checked).

What is your proposal for populating the new and unpopulated fields? — hike395 (talk) 14:26, 15 April 2020 (UTC)

User:Hike395, populating Wikidata with values en masse is a project to be conducted at Wikidata separately in the future, hence lets not discuss it here for the sake of being on topic. Do you have any other concerns against adding Wikidata support? Rehman 05:17, 19 April 2020 (UTC)