Template talk:Infobox mountain/Archive 5

With single parameter and CSV
With single parameter and CSV
Geography
Settlement	A, B, C

With numbered parameters
With numbered parameters
Geography
Settlements	A, B and C

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Infobox cleanup

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

Enable Wikidata values when no local value is present.
Add non-static interactive map support (example)
Clean up duplicate parameters (random example: range_coordinates and range_coords ) - to be done only together with another edit
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
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! Reh man 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. Reh man 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. Reh man 07:48, 30 March 2020 (UTC)

Done. Reh man 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 parameters (updated)
From	To
Duplicates
`photo_width`	`photo_size`
`coords`	`coordinates`
`topo`	`topo_map`
`relief`	`map_relief`
`parent`	`range`
`image_map`	`map_image`
`coords_ref`	`coordinates_ref`
`coordinates_note`	`coordinates_ref`
`elevation_note`	`elevation_ref`
`city_type`	`settlement_type`
Renames
`type`	`mountain_type`
`state_type`	`subdivision1_type`
`region_type`	`subdivision2_type`
`district_type`	`subdivision3_type`
`part_type`	`subdivision4_type`
`range_coordinates_note`	`range_coordinates_ref`
`grid_ref_Ireland_note`	`grid_ref_Ireland_ref`
`grid_ref_UK_note`	`grid_ref_UK_ref`
`length_note`	`length_ref`
`width_note`	`width_ref`
`area_note`	`area_ref`
`volume_note`	`volume_ref`

Consolidate parameters (updated)
Source (in order)	Destination
`bordering_range`	Move contents to `bordering_range`, in the same order.
`border`
`border1`
`border2`
`border3`
`border4`
`border5`
`border6`
`border7`
`border8`
`volcanic_region`	Move contents to `volcanic_region`, in the same order.
`volcanic_arc/belt`
`volcanic_arc`
`volcanic_belt`
`volcanic_field`
`geology`	Move contents to `geology`, in the same order.
`geology1`
`geology2`
`geology3`
`geology4`
`geology5`
`rock`
`age`	Move contents to `age`, in the same order.
`period`
`period1`
`period2`
`period3`
`period4`
`country`	Move contents to `country`, in the same order. For articles that used `country1`, please append the additional parameter `\|country_type=Countries`.
`country1`
`country2`
`country3`
`country4`
`country5`
`country6`
`country7`
`country8`
`settlement`	Move contents to `settlement`, in the same order. For articles that used `settlement1` or `city1`, please append the additional parameter `\|settlement_type=Settlements`.
`settlement1`
`settlement2`
`city`
`city1`
`city2`
`city3`
`city4`
`city5`
`city6`
`city7`
`city8`
`city9`
`city10`
`city11`
`city12`
`city13`
`city14`
`city15`
`city16`
`subdivision1`	Move contents to `subdivision1`, in the same order. • For articles that use `state`, please append the additional parameter `\|subdivision1_type=State`. • For articles that use `state1`, please append the additional parameter `\|subdivision1_type=States`.
`state`
`state1`
`state2`
`state3`
`state4`
`state5`
`state6`
`state7`
`state8`
`subdivision2`	Move contents to `subdivision2`, in the same order. For articles that use `region1`, please append the additional parameter `\|subdivision2_type=Regions`.
`region`
`region1`
`region2`
`region3`
`region4`
`region5`
`region6`
`region7`
`region8`
`region9`
`region10`
`region11`
`region12`
`region13`
`region14`
`region15`
`region16`
`region17`
`region18`
`region19`
`region20`
`region21`
`region22`
`region23`
`subdivision3`	Move contents to `subdivision3`, in the same order. For articles that use `district1`, please append the additional parameter `\|subdivision3_type=Districts`.
`district`
`district1`
`district2`
`district3`
`district4`
`district5`
`district6`
`district7`
`district8`
`district9`
`subdivision4`	Move contents to `subdivision4`, in the same order. For articles that use `part1`, please append the additional parameter `\|subdivision4_type=Subdivisions`.
`part`
`part1`
`part2`
`part3`
`part4`
`part5`
`part6`
`part7`
`part8`
`part9`
`part10`
`part11`
`part12`
`part13`
`part14`
`part15`
`part16`
`language`	Convert the language name to it's ISO 639-3 code and move to `native_name_lang`.

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! Reh man 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? Reh man 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. Reh man 07:48, 30 March 2020 (UTC)

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

I have updated the above table based on the consensus below and removed those that failed consensus. The first table lists direct hardcoded duplicate parameters and parameters that will be renamed in the backend (the displayed labels will remain the same). The second table consists of the parameters that are to be combined. If there are any questions or clarifications, please comment in the section(s) below. Once #Combining parameter series concludes, I intend to go ahead with the above. Cheers, Reh man 15:30, 17 May 2020 (UTC)

Hello Plastikspork. Hope you are well. The above [collapsed] tables are now updated based on the below discussions. Would you be able to run your bot for the above two tables please? Reh man 05:57, 1 July 2020 (UTC)

@Rehman, Hike395, and Volcanoguy: BRFA filed here. Plastikspork _―Œ^(talk) 14:39, 14 July 2020 (UTC)

Many thanks, Plastikspork. Cheers, Reh man 14:52, 14 July 2020 (UTC)

Hi Plastikspork. Hope you are well. Please do let us know when you plan to run the bot, just so we could keep an eye to action any odd cases. Even though I may look inactive these days, I'm online. Just working on something at another wiki. Cheers, Reh man 03:03, 12 August 2020 (UTC)

Hi Rehman, thank you for letting me know. I haven't been on WP very much over the past two weeks, so I missed the fact that the bot had been approved. I should have time to finish writing the bot code this weekend and try it on a few articles. Thanks! Plastikspork _―Œ^(talk) 21:05, 14 August 2020 (UTC)

Thank you, Plastikspork. I too have been extremely busy in RL and other wiki projects. Looking forward to this :) Reh man 04:34, 5 October 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, Reh man 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? Reh man 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. Reh man 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)? Reh man 04:11, 1 April 2020 (UTC)

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

User:Hike395. Care to explain this and this please? These were discussed months in advance. Reh man 14:33, 17 July 2020 (UTC)

@Rehman: When I did my first edit, I had forgotten about this discussion. In between the two edits, I went back and read this section, realized that |volcanic_region= was going to be the new parameter. Then I went back and fixed it so that when the bot changes to |volcanic_region=, it would override the label and the data and give the desired result. Until the bot runs, the current infobox code will preserve the content/layout of the previous infobox, per our discussion of not changing the layout of the infobox. I apologize for edit summary of the first edit --- once I hit "publish changes", I couldn't go back and change the edit summary. — hike395 (talk) 18:21, 17 July 2020 (UTC)

No worries. I will leave that part as it is until the bot run is finished, per above. Cheers, Reh man 06:35, 21 July 2020 (UTC)

Range coordinates

@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. Reh man 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. Reh man 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, Reh man 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. Reh man 11:45, 3 April 2020 (UTC)

User:Hike395, User:Volcanoguy: I fully understand the reason for having two coordinates, but I'd like to make a suggestion. The infobox currently displays two coordinates. I'd like to change this so that it displays a single coordinate, but allows both the coordinates as it currently supports. The difference would be: Clicking on the coordinates would show a full zoomed out version of the mountain range (if range coords are added) and also has a placemark of the highest summit on the same map (if the same is provided). Thoughts? Reh man 09:37, 3 May 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:

Using Wikidata
Deleting parameters
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, Reh man 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. Reh man 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. Reh man 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. :) Reh man 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. Reh man 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, Reh man 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. Reh man 04:52, 19 April 2020 (UTC)

Following the above 2nd ping 13 days ago pointing to my reply above a month ago, and my response to the note on my talkpage, I'm proceeding to merge the redundant parameter series per WP:SILENCE and to the fact no one else objected. I will now mark this section as resolved. Reh man 08:50, 2 May 2020 (UTC)

@Rehman: I'm marking this as unresolved. I still object to removing the parameters: no new arguments have been provided to remove them. I attempted a compromise to keep the parameters, which you have rejected. We are at an impasse: I don't see a strong argument for removing the parameters. There is no consensus for removing the parameters. We must take this to WT:MOUNTAINS. Please do not "resolve" discussions where there is clearly a lack of consensus. Please do not merge: I strongly object. — hike395 (talk) 12:58, 3 May 2020 (UTC)

I've only marked this as resolved as there wasn't a counter-argument from you against the merge for at least a month. I am now pinging members of WT:Mountains (those that edited that talkpage, and those that edited this template). If you wish, you can crosspost there again (as I have done so already earlier), but the discussion should be continued here, as the changes are relating to this template. Reh man 14:45, 3 May 2020 (UTC)

Break 1

@Droll, WOSlinker, Pigsonthewing, RedWolf, Mikeblas, Bermicourt, Buaidh, and Frietjes: I had proposed to merge the following manual parameter series into a single {{Unbulleted list}}-based parameter, as the parameters are barely used and unnecessarily clogs the template skeleton on articles.

border1 to border8 → border
city1 to city16 → city
country1 to country8 → country
district1 to district9 → district
rock, geology1 to geology5 → geology
period, period1 to period4 → age
region1 to region23 → region
settlement1 to settlement2 → settlement
state1 to state8 → state

The first series (xxx1) are barely used (see above for numbers), the rest are mostly unused. Unfortunately, there's only two users active in this discussion, and we cannot come to an agreement. Hence your opinion would certainly help in consensus on the next step. Thank you, Reh man 14:45, 3 May 2020 (UTC)

Rehman All previous discussions of major edits to this infobox have occurred at WT:MOUNTAINS. I think we should have a discussion there, because we may be excluding interested editors.

I think we should Keep the features. Right now, the infobox has a nice functionality of handling lists of parameters (e.g., cities, countries, state, geology). If there are fewer then 5 entries, it uses prose, e.g., A, B, C and D. If 5 or more, it created a collapsible list to keep the infobox from growing. Pppery had previously thanked me for putting this functionality into Module:Compact list.

There are two problems with Rehman's proposal:

Forcing editors to manually use unbulletted lists will cause those infoboxes to expand vertically. We're already having problems on short mountain articles where the infoboxes are longer than the articles. Let's not cause layout problems to get worse.
The problem that Rehman states as motivation (that the skeleton of the infobox is too long) doesn't appear to exist. The skeleton of the infobox at Template:Infobox mountain/doc doesn't list these numbered parameters. The TemplateData doesn't list them. There's no evidence that we have large unused skeletons in the article namespace.

I think we should not remove a stable and useful feature from the infobox, for no valid reason as far as I can see. Let's keep this feature. — hike395 (talk) 15:52, 3 May 2020 (UTC)

In order to decide my viewpoint on this, please can you give a concrete example of how border1, ... border8 would be combined in the border parameter. By unbulleted list, do you just means comma-separated values? — Martin (MSGJ · talk) 08:54, 4 May 2020 (UTC)

Thanks for participating, MSGJ. Considering the fact that very few articles use it beyond series 2 (as explained above), the values can simply be added as a CSV as you mentioned (FA example: Hoover Dam), or by manually passing through {{Unbulleted list}} if required (FA example: Apollo 11) - it's ultimately the editors choice. The difference here is that this infobox have separate hardcoded parameters for each value, which seems redundant and adds unnecessary complexity and clutter. This is like adding purpose1 through purpose5 in the Hoover Dam example, or crew_callsign1 to crew_callsign3 in the Apollo 11 example. Again, this is considering the fact that less than 1% of articles currently even use the first in the series. Reh man 13:57, 4 May 2020 (UTC)

Let me demonstrate the difference on mountain-related lists. These are two examples taken from the Andes test case:

CSV	Unbulleted list	Current infobox behavior
Argentina, Bolivia, Chile, Colombia	Argentina Bolivia Chile Colombia	Argentina, Bolivia, Chile and Colombia
Bogotá, Santiago, Medellín, La Paz, Cali, Quito, Pasto, Mérida, Arequipa, Mendoza, Cuenca, Cochabamba, Pereira, Ibagué, Salta, Manizales, Cúcuta, Cusco, Bucaramanga	Bogotá Santiago Medellín La Paz Cali Quito Pasto Mérida Arequipa Mendoza Cuenca Cochabamba Pereira Ibagué Salta Manizales Cúcuta Cusco Bucaramanga	List Bogotá Santiago Medellín La Paz Cali Quito Pasto Mérida Arequipa Mendoza Cuenca Cochabamba Pereira Ibagué Salta Manizales Cúcuta Cusco Bucaramanga

— hike395 (talk) 17:53, 4 May 2020 (UTC)

So the potential difference in appearance is "and" in the first example and the option to use a collapsed list in the second example. I believe that both of these things could easily be achieved by using one parameter, and just including the extra word "and" or the structure that is required. This is a bit more manual for editors, but the added simplicity of fewer parameters may be a reasonable trade-off for that. It seems to me that this is a rather minor issue to disagree over, but in general I support the initiative to simplify parameters which are mainly unused. I have a question about data structure: would it be harder to parse a parameter with unbulleted list or collapsed list, and would this impede Microformats? — Martin (MSGJ · talk) 20:09, 4 May 2020 (UTC)

Microformats are not impacted by either, but as expected with any template-within-template functions, the collapsed list would not function on most mobile versions (en.m.wikipedia.org) and would simply output as an Unbulleted list. Echoing further to what you said, I would suggest Unbulleted list as the default (which parses using simple html br tags), and csv for the few articles that has more longer lists. Again, this is ultimately the editors choice, and nothing that could be enforced from this infobox template. We'll simply have one open parameter. Reh man 04:31, 5 May 2020 (UTC)

@Rehman: --- what is the source of these statistics? I'd like to get a list of these articles. I want to understand the amount of AWB work required is we want to have one parameter per field, but keep the current formatting. — hike395 (talk) 04:57, 5 May 2020 (UTC)

If the consensus is to eliminate these parameters in the infobox call, I can do an AWB run to put the formatting back into existing infoboxes. It'll be a bit time-consuming, but doable. — hike395 (talk) 05:02, 5 May 2020 (UTC)

Please don't comment in the middle of discussions, as you did here. It is hard to follow for anyone else reading. The source is a bot scan done at the time I started this discussion. The stats were parked at User_talk:Rehman#Infobox_mountain. As discussed earlier, please avoid making any edits until the discussions are over. A single bot run to make all the changes in a single edit is much easier. Manual AWB work is not needed in this case. Reh man 05:11, 5 May 2020 (UTC)

Rehman: could the template take a simple CSV list and output an unbulleted list? Ideally we want the formatting on articles using this template to be consistent and it is less editor friendly to direct them to use templates inside other templates. What is actually the benefit of an unbulleted list - why not use a CSV list and allow the browser to decide where to insert line breaks? — Martin (MSGJ · talk) 07:14, 5 May 2020 (UTC)

I personally prefer CSV (and encourage users to use CSV via the doc page), as we can see above - that is the neatest and simplest approach, and also avoids the infobox being unnecessarily long. I've only mentioned UBL as a direct replacement to what is there now, as Hike wanted minimal visual/formatting changes. The template can easily take in CSV, as that is directly what the user types in. If we can agree on that formatting change, I believe csv is the best way to go. Reh man 07:48, 5 May 2020 (UTC)

In general it is better to let the browser sort the formatting when possible, as this avoids forcing a layout that was designed for one particular device/display configuration on all readers. However this approach will allow editors to fine tune the formatting when needed. — Martin (MSGJ · talk) 11:45, 5 May 2020 (UTC)

I wish I could help, but I don't think I know what "template sekeltons" are, or why they're bad. Lots of articles have ordinal5=parameters, even cite web itself, so I also don't know how those cause a problem. I can say for sure, though, that I like th right most column most in the example that hike395 gives. That ain't much, but it's what I've got. -- Mikeblas (talk) 17:52, 5 May 2020 (UTC)

Mikeblas As far as I understand them, template skeletons are the example empty skeletons in template documentation, e.g., the one shown in the left side at Template:Infobox mountain/doc#Usage.

My interpretation of what you're saying, above, is that you're mildly in favor of keeping the parameters that are like |paramNumber= and that you mildly prefer the existing formatting? Not sure if that's the right interpretation. — hike395 (talk) 05:47, 6 May 2020 (UTC)

@MSGJ: I have a clarifying question for you, Martin --- when you suggest having an editor enter a list as a CSV, and then display it as an unbulleted list, are you expecting the template (or Lua) to parse the CSV? Because, in general, that's very difficult. The list entries themselves can have commas, "and", and even quotes inside of them. Parsing editor-generated CSV is certainly beyond my skill. That's why Geobox originally used |parameterNNNN= to enter each list entry separately. If you're going to ask editors to enter CSV, you're going to have to display it as-written.

I think my current preference is to display it as typed, and recommend to editors that a simple CSV is best. I don't think the infobox should take up an undue amount of space and in general I am in favour of letting the browser decide where to put the line breaks. — Martin (MSGJ · talk) 10:57, 6 May 2020 (UTC)

Martin: More factors for your consideration ---

As currently implemented in the live infobox, editors may use CSV to enter lists. They can use, e.g., |city=A, B, C, D, E. The current formatting is an option that editors can choose to use.
Right now, whether to use singular or plural labels is also based on parameters like |city1=. As an example, see the two infoboxes to the right:

I don't know of a way to determine singular/plural from an unformatted CSV (because one of the entities could contain a comma, like "Telluride, Colorado". The only way I know how to do this automatically is to ask people to use |city1=. We can have two different parameters |city= and |cities= for manual labeling, but in my experience, editors ignore that.

One (minor) issue with CSV is that the browser can put a line wrap in the middle of an entity. In my browser, in the example table above, La Paz has a line break. Someone could mistake this for "La" and "Paz". While this unlikely for La Paz, there are some complex named entities that may be difficult to read.

We could fix this by putting a div with "style=white-space:nowrap" around each entity, but without numbered parameters, the software wouldn't know where the entities are.

By removing the numbered parameters, we are closing the door on any future formatting of these lists, which seems like a shame. I had previous offered two compromises to simplify the infobox: I made a simple Lua module to parse arbitrarily-numbered parameter lists: this means it's one line of code in the Template to implement this feature for a parameter. This was rejected by Rehman. I also suggested that each major parameter (like "city" or "border") can have a single line in the "template skeleton" (the documentation), and that we can put the ability to use numbered parameters in the notes. This compromise was ignored (AFAICT).

Martin, let me offer another compromise. If you and Rehman prefer the CSV to the collapsed or unbulleted list, I can easily modify Module:Compact list to produce a CSV with "white-space:nowrap" that prevents line wrap within each entity. I'm completely happy to do that. We would keep the numbered parameters, leave the numbered parameters out of the "template skeleton" (only keeping it in the documentation notes), have a nice CSV with correct line wrap, have correct singular/plurals. This compromise seems to satisfy all objections raised so far.

What do you think? Thanks for your consideration. — hike395 (talk) 15:46, 6 May 2020 (UTC)

{{Nowrap}} is a very common template to fix line break issues, such as the La Paz example. Infobox editors decide whether to use all singular or all plural labels (depending on context); we can see this in most infoboxes on such topics. If we go to address that, we'd have more parameters to deal with than just the ones we're discussing above. I think we should stop going in circles as Martin has already stated his preference as CSV (twice), and I'm fine with either CSV or UBL. I'll let Martin reply to your post above, and perhaps we can close this then. Reh man 04:25, 7 May 2020 (UTC)

User:MSGJ, would you have anything to add? If not, I'd like to close this subthread and move on. Reh man 16:18, 8 May 2020 (UTC)

hike395: It the skeleton size an urgent problem? Seems like docs get long when templates get complicated, and there's not much we can do about it. One solution might be what we see in other templates like Template:Infobox language, where template parameters with ordinals have comments that say the range of the ordinal. Check out " glotto2 = " over there, for example.

Indeed, I guess I just want the articles to be usable. To me, the right column does that the best. If that means the implementation needs to be fixed, then let's fix the implementation ... but the output, the usability, the content are all more important than ease of implementation. Right? -- Mikeblas (talk) 16:34, 8 May 2020 (UTC)

@Mikeblas: To clarify --- the right column is the existing infobox implementation. Any such automatic formatting requires parameters like |city3=. The existing infobox code handles such parameters. Rehman and MSGJ want to remove the code that handles these parameters. I agree with you (Mikeblas) and want to keep these parameters to allow automatic formatting. I'm happy to discuss any formatting changes.

Further, I'd like to propose using Module:Compact list to implement this in the infobox. This removes the need for a maximum number of parameters: any parameter that matches the regexp |city_?\d+= will be handled correctly. It only requires one line of code per parameter: {{#invoke:Compact list|main|city}}. So implementation is trivially easy.

@Rehman: Please don't close this sub-discussion. It appears that Mikeblas is in favor of keeping the numbered parameters. We still have not reached consensus.

Also: to respond to Rehman's comment, above, editors can already manually add {{nowrap}}, but why are we forcing them to do it when we can add it automatically in the template? It seems friendlier to the editors to do it for them (and make the formatting more consistent). — hike395 (talk) 05:03, 9 May 2020 (UTC)

Broad off-topic discussion

Mikeblas clearly said they don't know in their first comment, but you quite literally put the words in their mouth with this response. I'd like User:Mikeblas to read the full discussion above, and independently comment their thoughts and the reasoning behind the same (even if it is "mildly"), or simply state that they don't have an opinion. To not waste time, if there is no response from Mikeblas by Sunday, I am closing this thread. Courtesy ping to User:MSGJ. Reh man 05:18, 9 May 2020 (UTC)

@Rehman: I strongly object to your fixing an arbitrary and fast deadline while Mikeblas is still asking questions and trying to understand what's going on. I strongly object to your characterization of my response to Mike as "putting words in his mouth". I told everyone my interpretation of what he was saying, and asking him if that was correct.

This is the second time in this discussion where you've tried to close a discussion when there is an impasse or no clear consensus, in favor of your own opinion. To ask a clarifying question: are you using your position as an administrator to close these discussions? If so, I think you qualify as an WP:INVOLVED admin and should not be closing these discussions at all. Please clarify the basis upon which you get to decide when and whether to close these discussion, and their outcome. — hike395 (talk) 05:44, 9 May 2020 (UTC)

What does me being an admin got to do with this? MSGJ stated their opinion twice, and you still kept pushing. I wanted to take these much slower, but you are the one who wanted to make the changes "now" (in the Wikidata section). At another section, my suggestion did not gain support, and I swiftly backed off. I don't see that happening here? From what I see, you only want things to go your way. I will wait for MSGJ or Mikeblas to comment, if that's what makes you happy - no Sunday deadline. Reh man 06:03, 9 May 2020 (UTC)

I have not closed any discussions, being involved. You have closed discussions and placed (and then retracted) deadlines. You are involved. On what basis are you closing discussions and setting deadlines and making decisions, even though you're involved? At this point, I don't trust that you are being dispassionate about making these closing decisions. I want a third party to figure out whether we have consensus and what it is. Not me and not you. I'm tired of begging you not to close discussions.

I didn't want to make all decisions now! From the beginning, I was begging you to not engage in a massive parallel discussion about many aspects of the infobox design. It's made an intimidating and confusing mass of discussion, and I'm deeply worried that we're not getting input from the Mountain editors who might care about one particular aspect.

I want to work on Wikidata fallback! I want to verify the data, and understand your code (so I can help maintain the infobox). I haven't been able to do any of that, because I'm spending hours and hours in many parallel discussions that you're closing if I lose track and don't respond!

I really liked your suggestion about turning on wikidata parameter-by-parameter. We can work on adding wikidata fallback in stages, like Martin did back in 2016 when he turned on fallback for 3 parameters. The parameters are separable --- we can work on them in small groups. And we can discuss the functionality of each small group of parameters when we add the fallback. That will allow for much calmer and more reasoned discussion than trying to decide everything about the entire infobox all at once. I believe that MSGJ also suggested this to you.

As I have said before, I have a big problem with the way you structured this whole discussion and have approached updating the infobox. There has been a lot of work and thought put into this infobox over the last 17 years. You came in and started changing things and deleting code. I don't think there's any consensus for a gigantic change to the infobox.

I believe we can reach a happy working collaboration by working step-by-step on small groups of parameters, adding fallback, and carefully considering the behavior and layout of each parameter. I'm happy to have all of these discussions, just not all at once. Please please please¹⁰⁰ let's pause this gigantic broad discussion that is making both of us miserable.

At this point, let's pick a part of the infobox that is non-contentious and work on that, making edits to a sandbox and test cases, and not making edits to the live infobox. Let's make editing the infobox fun again. — hike395 (talk) 06:42, 9 May 2020 (UTC)

Please stick to the topic. You are now bringing Wikidata into a discussion about parameter series. Initially there were only a handful of very particular topics, and then you opened ambiguous sections (such as "Step by step" etc) which I tried hard to move to the correct place, and you then even continued discussing back in the previous sections. There were also cases where you had posted in the middle of threads, and I had to move your comment. The state of the thread is not because of me. I wanted to work with minimal number of edits, and make the changes only after all discussions conclude, but then you wanted some parts done "now", and now when I'm working parts, you post on my talkpage separately asking me to make a limited number of edits per day, with you having to approve them? I don't see how this can be productive when you act like this. Regarding closing discussions, the first instance was when you didn't respond to it (even after pings) for a whole month. And this instance is because you kept pushing even after consensus was clear, before Mikeblas joined. So don't you accuse me of mishandling. I will not comment here further for anything not related to the parameter series. Reh man 07:00, 9 May 2020 (UTC)

You are misrepresenting my editing history. As you can see from above (all times UTC):

Rehman invited a number of editors to comment, and made a case to remove on 3 May, 14:45
I made my case on to keep on 3 May, 15:50
Martin asked for specific example on 4 May, 08:54
Rehman and I both responded with specific examples on 4 May from 13:57 to 17:43
Martin came out in favor of "remove" on 4 May, 20:09
I offered to run AWB if the consensus went against me on 5 May, 05:02
Mikeblas made his first comment that may have been in favor of "keep" on 5 May, 17:52
I responded to Mikeblas' question re skeletons, and tried to test whether he was in favor of "keep" on 6 May, 05:47
I offered a possible compromise on "keep" on 6 May, 15:46
Rehman said that the discussion would get closed on 8 May, 16:18
Mikeblas made a somewhat stronger statement on 8 May, 16:34
I asked that the discussion not get closed on 9 May, 05:03
Rehman said that the discussion would get closed with a 2-day deadline on 9 May, 05:18

I think it's plain from the order that I only made my suggestion for a compromise after Mikeblas spoke up. I was fully prepared to give up before then (as can be seen from my offer to run AWB). My compromise was trying to probe whether editors were unhappy about the current formatting, or about the parameters. I find it very distressing that this is the second time I've been accused of being unconstructive by an involved administrator: is offering a compromise now considered bad form?

I apologized before if I've hurt Rehman's feelings. I'm sorry (again) if I've made him angry, and I apologize if my edits have been off-topic or in the wrong section or place. I'll try to do better. But this situation is now a terrible mess: Rehman has been editing the live template and I feel completely shut out of the process. I feel like my voice is not being heard. This is especially painful considering that I've helped to maintain this template for 16 years (since before it was an Infobox). I'd really like to try to find a path forward with some sort of non-controversial non-confrontational edits. But that has been rejected out-of-hand.

I'm sorry if this is in the wrong section. At this point, I don't know what section to write this in. @MSGJ and Mikeblas: do you have any suggestions or ideas of how to move forward? — hike395 (talk) 09:05, 9 May 2020 (UTC)

I'm not angry at all, and I'm sorry if you felt so. I just find the latter part of this thread a waste of time. While I absolutely respect the fact that you've been here for a long time, things like how long you've been editing this template, or how long this template survived without overhaul, or even my account having an admin flag, is completely irrelevant and bloats this thread for no reason. The live edits I do are clearly as discussed in the Wikidata sections, why do you claim here that you are being shut out? Unless you simply don't want anyone else editing the template? Let us both stop this side-discussion right now, and focus on the parameter series, please. I'm hoping User:MSGJ and User:Mikeblas can comment sooner, so that we can close this once and for all. Reh man 09:41, 9 May 2020 (UTC)\

Rehman I have been objectively shut out. I've followed the standard procedure of proposing an edit in sandbox2. Martin looked at it and thought it was good. Martin and I had to convince you that it was a good idea, and you then went ahead and ignored my code and just started editing the live template, introducing some bugs, which I noticed and you fixed. That's ok, but I thought it would be better if we worked together (somehow) and didn't thrash the live template.

I had proposed doing code review, which is quite standard in open-source software development. You could write and I can review and post to the live template. But it's symmetric --- I can write, and you can review and post! I had simply proposed a daily rhythm because we are probably 12 time zones apart. I also thought it would be faster and more productive if you and I reviewed each others' code, rather than trying to get a third editor or the community involved. My original proposal was a proposal. It wasn't a "demand" (as you have characterized it). So now you're editing the live template and I'm frozen out and can't get my sandbox proposals considered or looked at. I don't understand any of the code. I can't participate in building the Wikidata fallback at all --- you previously told me not to edit the live template until we finished all of the discussions. The absolute last thing I want to do is get into an edit war on a 25,000 article template.

Do not discount the fact that you're an admin and I'm not. You've said I'm being unconstructive. You're closing discussions. These are things that admins do, right? I feel like I can't get you to listen to me, because of this asymmetry of power. You go ahead and do live edits to the template without any discussion or checking, and when I ask for feature discussions not to be closed, you start to throw deadlines around. And you still haven't explained why you get to do these things.

And when I finally reach my breaking point and bring this all up, you say it's a "waste of time". I'll refrain from expressing how I feel when I hear that. — hike395 (talk) 10:29, 9 May 2020 (UTC)

The above response has nothing to do with parameter series, again.

When I first started the discussions and proposed the changes under sandbox1, you swiftly chose the parts of the proposal you like before any discussion concluded, and proposed sandbox2. I did not say anything about that, or claimed of being shut out, did I?
I genuinely can't understand if you are being sarcastic or not. Do you really think only admins close discussions? We both have the same abilities when it comes to improving this infobox. How am I overpowering you (or whatever you meant by "asymmetry of power")? If you want to be taken seriously, please stop making claims such as this.
Every single edit to the live template was done as agreed, and as reiterated. If you have a problem with them, I really suggest you raise it up in the appropriate way, in the appropriate thread. As I said before, I welcome genuine feedback on my edits.

I will repeat once more, please leave this thread for discussions on the parameter series. I'm not going to harass them by pinging over and over, but I really do hope MSGJ or Mikeblas will respond to put an end to this. Reh man 11:04, 9 May 2020 (UTC)

I don't know what to say, Rehman. You ask me questions and I answer them right below, and then you criticize me for being off-topic. You criticize me when I go out of order. I don't want to refactor our discussion, because there seems to be a loss of good faith (per WP:RTP). I guess I'll answer here and you can keep criticizing me for being off-topic and that will be ok.

I did not agree to have you edit the live template directly. That is nowhere in our agreement. I had assumed (perhaps foolishly) that you were going to test your code in a sandbox and then let people look at it and promote it. You agreed to not change the visual appearance of the infobox, but then you deleted "datastyle" and "labelstyle" in the live template, which changes the layout of every single field. You're changing the parameter handling logic around. Is this affecting the visual appearance or introducing bugs? I don't know --- we're not using the usual sandbox-test-post route, so maybe things are breaking or changing, and we have no idea. I'd just like to double-check to catch any bugs that you might be introducing into the live template (like |isolation_m=). But I don't know how to check without testcases and spot-checking and coordination. You don't want to do code review, that's fine. It would be really nice to make sure we're not spreading bugs throughout the mountain article. If you don't want to work with me at all, could you perhaps find another template editor who can double-check to make sure that everything is being held constant and nothing is breaking? It would be nice to keep the mountain infobox tidy and bug-free. — hike395 (talk) 11:38, 9 May 2020 (UTC)

I have not once told that I don't want to work with you. We have come this far after discussing so much, didn't we? I criticise you for going off topic, because after I posted this, you started pulling the irrelevant admin strings with this reply, and when I responded to that, you posted a large reply which barely had any relevance to the original topic nor the admin-response.

Please read WP:BOLD. We don't need someone to review every single edit. That is not how Wikipedia works. If something goes wrong (which happens to anyone on any page), anyone is free to fix it directly or ping the person making the edit. That is how every aspect of this encyclopedia works, including templates used by much more than 25,000 articles.

Hike, I have absolutely no hard feelings towards you now, and will most probably not have such feelings in the future. I'd like to suggest you rest for the day (I don't know your timezone), and come back to the topics at hand. You didn't want me to close this thread by Sunday, and I already said I'm fine with that. Until then, let's please wait for a comment from MSGJ or Mikeblas. Reh man 12:09, 9 May 2020 (UTC)

Holy smokes. Ya'll have pinged me 6 times in the last 12 hours. Was it really necessary?

I like the right-hand layout. If that can be implemented (as Hike395 seems to be saying) while also making the parameter list a little less unruly, then I'm for it. Really, that's all I can offer the conversation. Note that I'm not offering any binding or prescriptive advice. I'm just offering the opinion that was solicited from me. -- Mikeblas (talk) 19:16, 9 May 2020 (UTC)

Break 2

Following this agreement (from this discussion), I believe we can now conclude with this and proceed with merging the parameters. User:Hike395, I will ping here again when the ontology is updated so that you could use HarvestTemplates before the merge is done. Cheers, Reh man 13:07, 17 May 2020 (UTC)

Update: Wikidata has a single unified parameter located in the administrative territorial entity (P131), thus it seems like it would make more sense if the content is sourced from the most used/largest subdivision only - the state parameters. I.e. not all of the numbered parameters. What do you think? If you're fine with that, you can go ahead and add a tracker to the state parameters and proceed with the copying. Cheers, Reh man 15:21, 17 May 2020 (UTC)

@Rehman: I may not be understanding what you're saying. Many mountain ranges span more than one state/administrative region. Is the idea to only save one state in located in the administrative territorial entity (P131)? Is it not list-valued? That's going to be a problem, I think. If I'm understanding correctly, is there any way to make the property be multi-valued? — hike395 (talk) 13:22, 18 May 2020 (UTC)

P131 is multi-value. You can save all states to that. Reh man 13:24, 18 May 2020 (UTC)

And country. I just saw you added trackers for that. Forgot to mention to you earlier. country (P17). Cheers, Reh man 13:31, 18 May 2020 (UTC)

Thanks, yes, I saw country (P17), was planning on starting with Countries first, because that seemed straightforward.

located in the administrative territorial entity (P131) seems a bit problematic for automatic copying to Wikidata. It's hierarchical: the instructions at located in the administrative territorial entity (P131) say that you should only put a item in the "lowest" (smallest) administrative region. For example, Seattle (a city) has P131 = King County, Washington (a county: a sub-provincial entity). King County has P131 = Washington (state) (a state/province of the US).

If I automatically write state, region, district, and part into Wikidata, I very well may violate this (implicit, unchecked) constraint. One possibility is to write state into located in the administrative territorial entity (P131), region and district into location (P276) (because they might not be administrative). What do you think of that?

Note that part shouldn't be converted to simply subdivision4. If you look at the usage link that Plantdrew gave us, you'll see that sometimes part is used to refer to a higher-level geographical region (e.g., a larger mountain range, which should be part of <range>), or sometimes a geographical sub-feature (such as a river in a mountain range). I would suggest changing part to something like feature. Someone (probably me) will have to go through and clean up the usage. At that point, we can copy into Wikidata (presumably using has part(s) (P527)).

Speaking of parts: I'm thinking that listing shouldn't be part of (P361). These listings (like the Munross) are not a physical object that the mountain is part of (like ear is part of a head). Instead, those listings are classes of mountains (for the Munros, it's all mountains in Scotland with height over 3000'). I think instance of (P31) would be more appropriate. What do you think? — hike395 (talk) 14:54, 18 May 2020 (UTC)

Thanks for the feedbacks Replying from work:

Yes, P131 can only take one. Hence I suggested to only copy <state> parameters in my initial comment, as that is the most widely used of all the types. Of course, you can decide what you want to copy, but clearly it can only be one (not all of those - state, district, etc), and that too if a smaller subdivision is not already stated. This can also be done as a separate Wikidata project afterwards; by having bot programmed to do this even after the lists are flattened. So I wouldn't worry too much about it.
The part/subdivision change is only a backend parameter rename - it will still have the same label and contents in articles. This is because the word "part" is ambiguous. The rename is also a part of synchronising the regional parameter names, which allows for a more flexible use. For instance, using provinces without having to make-do with the state parameter, etc. The parameter is not documented until now, but as per the source code it is "Subdivisions". So it is probably that "part" automatically evolved into another use (for cases such as Filefjell). Have a look at the updated rename table above, you will get an idea. This run also solves the "Country/Countries" problem you stated before. So those that currently uses many parameters, will still have plural labels. What it is eventually used for this parameter is flexible, and a decision you can probably make later. For now though, it will simply retain the same labels and data.
I will comment on the Wikidata ontology part for others later, as it is not related to this. But I've noted your point, and will bring it up separately soon.

Thoughts welcome. Cheers, Reh man 15:32, 18 May 2020 (UTC)

User:Hike395. Can I move on? Reh man 05:56, 21 May 2020 (UTC)

I'm sorry -- I've run into an issue with HarvestTemplates. As far as I can tell, it refuses to write a wikidata property if that property is already defined. That is, it doesn't want to write a second P131 if there already is one. I either have to enter these lists manually, or find another tool. I'll update as soon as I learn more. — hike395 (talk) 07:51, 21 May 2020 (UTC)

Later: I figured it out---- I'm using a combination of HarvestTemplates and QuickStatements. It's ugly and slow-going, though. I'll update when I'm done with the currently tracked parameters. — hike395 (talk) 09:22, 21 May 2020 (UTC)

No worries. Let me know. Cheers, Reh man 10:45, 21 May 2020 (UTC)

Good to go? Reh man 04:57, 1 June 2020 (UTC)

Okay, considering that this is a project for Wikidata and not enwiki (as explained earlier), I'm going ahead. Per above, extracting the data after the parameters are flattened is still very much possible. So you are free to do this anytime, either with the help of a bot, or other means. Cheers, Reh man 04:48, 4 June 2020 (UTC)

@Rehman: Extracting the data after parameters are flattened will be effectively impossible. I won't be able to use HarvestTemplates at all, so I'll be stuck. What's been slowing me down is that the infoboxes are very messy -- e.g., many people use |region= to represent "state". There are hundreds of infoboxes that I need to cleanup: about 300 more that I need to check and cleanup. It's incredibly tedious and slow work. And that's just |region=, let alone |district=. (This, by the way, is a good reason to support using neutral parameter names like "subdivision1", as you proposed).

Is there a big rush to convert over? I really would like to save the data, if at all possible. — hike395 (talk) 18:40, 4 June 2020 (UTC)

Later -- one other tack is to just abandon region/district/whatever, and go on to other fields. — hike395 (talk) 18:43, 4 June 2020 (UTC)

User:Hike395, it's almost a month hence I'd like to move ahead with this please. You can still propose a bot task later if you like to work on this. Like I said above, it is definitely not impossible to do this after the list is flattened. This task is anyway nothing to do with enwiki, but purely a project for Wikidata. Reh man 07:13, 24 June 2020 (UTC)

Please give me until 00:00 UTC on 29 June. I'll just abandon region (because it's far too messy) and finish up the rest of the fields.

What's your next step? Are you planning on promoting the sandbox to the main template? If so, I'd like to check the test cases to make sure that the formatting hasn't changed. I can do that by 00:00 UTC on 29 June, also. — hike395 (talk) 04:02, 25 June 2020 (UTC)

Ok, I will proceed with the collapsing after that time. As discussed in depth in this sub-section, that is my next step. Reh man 05:36, 25 June 2020 (UTC)

I'm done with exporting to Wikidata (except for |region=, which is hopelessly messy). — hike395 (talk) 04:36, 29 June 2020 (UTC)

Many thanks! Cheers, Reh man 04:59, 29 June 2020 (UTC)

Break 3

User:Hike395, these discussions were left open literally for months (mostly to allow time for you to share your thoughts). I don't mean to sound rude, but it's quite disruptive of you to wait literally till the very last moment until the BRFA is opened, and then continue template-related discussion on the BRFA. Consensus is supposed to be raised prior to that, and that is why I've waited for as long as you wanted. Please continue the discussion here so things are centralised. Anyway, what's done is done. I'd like to continue discussing here on the 3 points you raised, and then resume that BRFA.

As I explained before, the current template code reads "Bordering ranges". And because whoever added that parameter did not document that properly, there are now varying uses for that parameter, but still with the label "Bordering ranges". To ensure we don't create new confusion by naming the parameter "borders" while the label reads "Bordering ranges", I'd prefer we don't use the bot to make an alteration of the nature you propose. Although we could of course do that separately. Or maybe you'd be ok with "bordering_ranges" instead of "border_ranges"? All that being said, if you insist, I'm ok with going ahead as long as you understand point I'm trying to highlight.
This make sense, and should be fine.
The two language parameters, although expects different types of inputs, works for the same reason. Wouldn't using only the language code suffice? Considering the low usage, I was hoping to manually action them once they are combined. Thoughts welcome.

--Reh man 16:23, 17 July 2020 (UTC)

I'm sorry, I don't understand the point you're trying to highlight? The current template code reads "Bordering ranges" because you made this change on July 1 (about two weeks ago). Before then, the template itself had a label "Borders on", since 2015. The template was stable for 5 years with "Borders on", and editors seemed to have relied on the "Borders on" label to enter valleys, deserts, etc., despite the documentation saying it was only for ranges. If we change the label away from "Borders on" and rename the parameter |bordering_range=, then we are causing many infoboxes to be inconsistent. I don't see why we are doing this --- why can't we fix the documentation to match the reasonable edits that editors are making, instead of forcing the infobox to match the documentation?
Thanks!
I wouldn't oppose folding together |language= and |native_name_lang=. But simply taking the parameter from |language= and copying it into |native_name_lang= won't work correctly. For example, Iinstead of "El Capitan (Spanish)" it will produce "El Capitan". Instead, |language=XXX might be converted to be |native_name_lang={{subst:ISO 639 code-3|XXX}}. I'm concerned that we won't be able to easily find the errors where this fails, because there are no tracking categories involved.

Hope this helps. — hike395 (talk) 03:13, 18 July 2020 (UTC)

Many thanks for the detailed replies (here and other sections), it is very helpful. I will reply once I get back to my computer. Cheers, Reh man 03:19, 19 July 2020 (UTC)

User:Hike395. Apologies for the late reply, work got in the way. Thanks for pointing out bordering_ranges vs borders_on, I intended to mean borders_on all these while; I got it mixed up. My intention was to preserve the original label. Consider that, would you be fine changing the parameter to borders_on instead of the current ambiguous borders?

I missed adding a line in the table stating the bot to do the conversion. Sorry for the confusion. I will add that in now. Basically, the bot should detect the language in language, and append the corresponding language code in native_name_lang.

Based on your replies on the above, I will update the BRFA. Cheers, Reh man 07:10, 21 July 2020 (UTC)

Sure, |borders_on= is clearer than |borders=, so that's a good change. I'll change the current infobox to reflect the change of future parameter and keep the original label.

It sounds like everything is resolved now! Thanks!! (I'll triple-check the BRFA, because I'm very cautious about mass edits). — hike395 (talk) 03:10, 22 July 2020 (UTC)

Nice! Many thanks. Reh man 04:09, 22 July 2020 (UTC)

@Rehman: Oops, I just found another problem in the specification of the bot run. Many articles have |state_type=, |district_type=, |region_type=, or |city_type= already specified (to be correct for the country that the mountain or range lies in). As previously specified, Plastikspork's bot would stomp on those parameters. They should be copied over to |subdivision1_type=, etc. I went ahead and edited the BRFA. I'll keep checking --- it's quite tricky to get all of the edge cases right. — hike395 (talk) 07:00, 22 July 2020 (UTC)

Replied to your comment at BRFA. AFAIK, the bot would not overwrite unless specifically requested to. So I believe this shouldn't be a problem. Reh man 08:42, 22 July 2020 (UTC)

German infobox translation

Resolved

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. Reh man 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? Reh man 04:50, 9 April 2020 (UTC)

Hello again Bermicourt. Would the above alternative solve the issue regarding the conversion? Reh man 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, Reh man 08:30, 19 April 2020 (UTC)

Hello Bermicourt. I've looked at the code, but it does not seem like it is pointed to the specific metric/imperial parameters, but rightly points to the generic parameter (i.e. prominence instead of prominence_m) via a convert template. Is that right? Do you have an example where it is not the case? If this is known/expected, then there shouldn't be any issues with {{Infobox mountain/Berg}} when it comes to the template cleanup. Reh man 08:55, 3 May 2020 (UTC)

The de.wiki data will just be a number because it assumes metres. So I guess that {{Infobox mountain/Berg}} must convert it to metres before it's substituted, in which case it should continue to work. Bermicourt (talk) 11:41, 3 May 2020 (UTC)

That's great! Thanks for confirming. Cheers, Reh man 11:47, 3 May 2020 (UTC)

Automatic conversion and zoom

@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? Reh man 14:37, 19 April 2020 (UTC)

@Rehman: The geohack default for "mountain" is scale 1:100,000. This is adequate for viewing individual mountains. But, this infobox is also used for massifs and mountain ranges. Those kinds of features can be anywhere from 10 to 1000km long. For |range_coordinates=, the default "mountain" scale is too small, and the user is given a zoomed-in map that doesn't really show anything. If any of the length or area parameters is given, {{Infobox dim}} estimates the size of the map that encompasses the whole range. To see this working, click on the "range coordinates" for, e.g., Alps. The default zoom would show a few towns in Switzerland.

This functionality has been in the infobox since 2012. The code has been stable, and the feature works well. If anything can be said to be a "well-established default", I would think it would be this feature. I really want to keep it in. — hike395 (talk) 15:31, 19 April 2020 (UTC)

@Rehman: I'd also like to note that {{Infobox mapframe}} accepts |length_km=, |length_mi=, and similar, to perform a similar zoom computation. {{Infobox protected area}}, {{Infobox ecoregion}}, {{Infobox valley}}, and {{Infobox biogeographic region}} all use {{Infobox dim}} for a similar reason as this one. It seems to be a widespread pattern. — hike395 (talk) 17:30, 19 April 2020 (UTC)

I'm afraid I'm still not convinced in keeping these separate parameters for the sake of just a handful of articles (i.e. there are only so many mountain ranges so large in existence). By removing these parallel parameters, we can cut down the template skeleton for these parameters from 18 to just 6 (66% cut) - taking a lot of clutter off tens of thousands of article pages.

{{Coord}} clearly documents peaks, mountain ranges, hills, submerged reefs, and seamounts for type:mountain. Are there meaningful number of instances where the default Coordinate syntax caused a bad output, and the manual override solved the issue?
Is there a reason why we cannot simply use {{Coord|46|30|N|09|19|E|format=dms|dim:400km|display=inline,title}} (notice dim:400km) for those handful of rare cases, instead of taking the long-route in manually channelling the figures across a number of template/parameters (at the expense of bloating all other articles' template code)?

Hope to discuss and conclude this soon. Cheers, Reh man 08:09, 3 May 2020 (UTC)

{{ping}Rehman}} If the objection is to the size of the empty skeleton infobox, then let's discuss that and come up with a solution. One possible solution is to only use metric in the skeleton, e.g., length_km and area_km2. Or, if we cannot gain consensus around metric-only, use both metric and imperial.

I object to the removal of the metric/imperial parameters such as length_km or area_mi2 for several reasons:

The code works well, is not complex, and has been stable for years.
The feature is useful for editors: automatic conversion prevents errors in the use of {{convert}}
The feature enables the use of automatic zoom
- The automatic zoom feature is also stable, simple, and helpful, even if it is only used on hundreds of articles.
- Most editors don't realize that a zoom can be specified. I don't believe that future edits will add many of these.
- Writing and running a bot to simply fill-in dim: in coords, to replace code that is working, seems like a lot of (possibly error-prone) work for no gain.

To be clear, I believe that we do not yet have consensus for this change: we are at an impasse here, also. Per WP:NOCON, please do not remove these parameters until you have a consensus for change (i.e., having some editors actively assent to this change, overriding my objection). Please do not invoke WP:SILENCE to "resolve" this. We need to hear from other editors.

I would recommend going to WT:MOUNTAINS and make separate proposals for each of the changes Rehman wishes to make. I would recommend spacing them out in time: if you overwhelm editors with many changes at once, you're not going to get a signal on what the editing consensus truly is. My overall recommendation (which I've repeated before) is --- let's just work on Wikidata integration, and then resolve this after we're done with that. I'm eagerly waiting to see Rehman's Wikidata edits. — hike395 (talk) 14:10, 3 May 2020 (UTC)

Break 1

I will try and comment here to help break the deadlock, but I do not yet understand the issue. What is automatic conversion and zoom, and can you give me an example of it? — Martin (MSGJ · talk) 20:11, 4 May 2020 (UTC)

@MSGJ: What's under discussion: there are a number of parameters with associated units. For example: |length_km=, |width_mi=, |area_km2=. They accept numeric values and the value is automatically converted into metric/imperial, and both metric and imperial are shown. Rehman wants to eliminate all such parameters, replacing them with single parameters, e.g., |length=, |width=, |area=. These parameters already exist and are free fields. Eliminating these parameters would force editors to use {{convert}} in the free fields.

I want to keep these parameters, for three reasons:

They are quite convenient for editors who don't have to think about {{convert}}
Forcing editors to always use {{convert}} makes the template calls larger (which appears to be the reasoning for deleting the numbered parameters, above)
When |length_*=, |width_*=, or |area_*= are used, then the template calls {{infobox dim}} to estimate the dimension of the object. This dimension is passed to the geohack link (e.g., when {{coord}} is used) to get a correctly-zoomed-in map. This is valuable for mountain ranges, which can have lengths anywhere from 10km to 1000+km.

— hike395 (talk) 04:50, 5 May 2020 (UTC)

(edit conflict) Thanks Martin, I appreciate you taking the time. To explain; for each parameter with a measurable value (there are currently 6), we have 3 separate parameters. For example, for elevation, we have: elevation (if you want to use your own formats), elevation_m if you want to add the value in metres but want the infobox to auto-convert to feet, and elevation_ft if you want to add the value in feet, but want the infobox to auto-convert to metres. My suggestion again is to use only one parameter for one purpose, using {{Convert}} if necessary.

On the other hand, this infobox currently uses the metric values (i.e. width_m), to determine the 2D size of the region, in order to zoom-out the map seen when clicking the coords. My argument to drop this manually-derived function is due to the fact that Template:Coord#type:T already defines the scale for mountain ranges. The counter argument by Hike for that is it is still too zoomed in for the larger mountain ranges. In response to that, I pointed out to Template:Coord#dim:D which could be used for those extremely rare cases (there are only so many ranges so large on Earth). All that aside, it is important to also note that only 0.013% of articles use this manual feature (i.e. those that has width_km and length_km defined). Reh man 04:59, 5 May 2020 (UTC)

Rehman --- It'd be nice get the query that you're using to find the list of articles that use these features. How are you getting the data? — hike395 (talk) 05:06, 5 May 2020 (UTC)

Responded in this edit. Reh man 05:16, 5 May 2020 (UTC)

Note: The 0.013% number Rehman is quoting for use of the zoom feature is not accurate. The total number of mountain articles that use length_km is 544 and length_mi is 310. Combined that is 854 articles, which is about 3.5% of the total number of articles. All of those use automatic zoom. The number of articles which use automatic zoom could be as high as 272+328+544+73+211+310=1738, or 7% of the articles. This is a relatively common feature. — hike395 (talk) 05:59, 5 May 2020 (UTC)

Note: The automatic zoom feature is used when |length_*= or |width_*= or |area_*= is used. Any one of them trigger the feature. — hike395 (talk) 06:01, 5 May 2020 (UTC)

Thank you for correcting my math, and for this note. My argument above still stands though. It is an unnecessary manual feature, that could be achieved in a much simpler approach, with the trade-off being in a 66% drop in parameters. The majority of those articles ("7%") could easily use the default zoom. Just because the parameter is filled, does not mean it is giving a useful output. Reh man 06:26, 5 May 2020 (UTC)

Even if we ignore automatic zoom, your data shows that automatic unit conversion is an incredibly popular feature. Right now, users can choose to either use {{convert}} or to use the automatic unit conversion. Here's a table of usage of each dimensional parameter. Parameters are rows, and the columns show the number of articles that have the parameter entered in metric, imperial, or unitless (unitless = e.g., |length=). The fraction column shows the fraction of articles where an editor has decided to use automatic conversion.

Parameter	Metric	Imperial	Unitless	Fraction of automatic conversion
elevation	16852	3990	2500	89%
prominence	5731	2435	1082	88%
length	544	310	2	99.8%
isolation	210	369	362	62%
width	328	211	1	99.8%
area	272	73	11	97%

As you can see, in vast majority of articles, editors have chosen to enter the data in a simple and uncluttered format (as a numerical value), letting the infobox do the conversion. |elevation_m= is the fifth-most-popular parameter. Why are we getting rid of such a useful and popular feature?

The existence of these features have very low cost. The code works and has been stable for a long time. The parameters don't cost anything. If you're worried about too many parameters in the empty infobox skeleton, why not just drop the unitless parameters from the skeleton? Those are the least-used.

I think that if we dropped parameters like |elevation_m= or |prominence_ft= that we would be causing a lot of extra work for ourselves and mountain article editors, for essentially no gain. I think dropping the parameters would be unwise. — hike395 (talk) 06:52, 5 May 2020 (UTC)

Okay I now understand the issue of automatic conversion (but not yet the zoom issue). I think a template's purpose is to make the editors life as easy as possible. If this feature is being well used (as the data above suggests) then it should be kept. If this makes the template coding or conversion to wikidata a bit harder, then I'm not concerned because that is a one-off task and yet editors are using these templates every day. So we should cater for them as much as possible. It is much simpler and neater to write |elevation_m=5678 rather than |elevation={{convert|5678|m}}. This system is also well used in other templates (I am somewhat familiar with Template:Infobox river). — Martin (MSGJ · talk) 07:10, 5 May 2020 (UTC)

The main issue is whether to keep automatic conversion or remove it. The zoom is one possible reason to keep automatic conversion. But it really isn't the main argument. It sounds like you're recommending keeping automatic conversion, so we can simply ignore zoom. — hike395 (talk) 07:47, 5 May 2020 (UTC)

My reasoning to remove those parameters is to shrink the size of the infobox skeleton one copies to a new article (2/3 less parameters). High usage in itself should not hinder the change, as a bot will anyway run through all articles for the other changes, and can easily amend the usages together with the other changes, in the same edit. It is the very reason I suggested to hold all live edits till all discussions conclude. I like to suggest adding the convert code within the template syntax (like Template:Infobox docks - but less messy), so editors can simply copy it together. High indicator of metric or imperial uses is not an indicator of usefulness in this case, as for example, when users from US see an imperial parameter, they will fill that parameter. In other words, they will fill what they see. Similarly, if the convert code is provided upfront, users will use it accordingly. Reh man 08:22, 5 May 2020 (UTC)

I understand your reasoning and, from a template coding point of view, that would indeed be the cleanest solution. But we have to bear in mind what other editors find useful, and I can't support removing functionality which is so well used. I personally would not (although others might) oppose a bot run to replace |elevation_m=5678 with |elevation={{convert|5678|m}}. But to insist that all editors use the latter syntax is not reasonable, when they have grown used to convenience of the former syntax. I might also gently suggest that your insistence on this matter (and perceived intransigence) might derail some of the other great improvements that you are proposing for this template. — Martin (MSGJ · talk) 11:39, 5 May 2020 (UTC)

Not at all, Martin. We wanted a third view, and after re-reading above, it is now clearer to me that you are vouching to keep the separate parameters. Hence that is perfectly fine, and let's keep them. Regarding the zoom though, are we retaining those as well, or can we simply use the defaults already with Coord, as discussed above? Reh man 13:07, 5 May 2020 (UTC)

I brought up the zoom feature in a discussion about keeping the |length_*=, |width_*=, and |area_*= parameters. If we're going to keep those parameters, what policy is enforced or reader benefit is gained by removing the zoom feature?

To explain to Martin and any other editors:

This infobox is used in articles for mountains and mountain ranges.
For the geohack links generated from the coordinates in the infobox (e.g., 36°34′43″N 118°17′31″W / 36.578580925°N 118.29199495°W / 36.578580925; -118.29199495), the geohack page would use 1:100000 scale maps by default. This is appropriate for articles with single mountains (which are roughly ~1km wide)
Mountain ranges can be anywhere from 10km to 1000+ km long. I converted about 2000 mountain range articles to use this infobox, so I can attest to the wide variety of scales of the ranges.
If the infobox is called with any of the metric or imperial parameters |length_*=, |width_*=, or |area_*=, then the infobox will automatically compute a scale for the geohack map that will show the mountain or mountain range with a comfortable margin around it.
This feature was created in 2012, and has been stable for 8 years. No one has previously complained or wanted to remove the feature.
The logic for computing the map scale is encapsulated in {{Infobox dim}}. That logic is used by multiple infoboxes (e.g., {{Infobox protected area}}). It is currently transcluded on 5354 articles.
The zoom feature is currently used on somewhere between 3.5 and 7% (800-1700) mountain articles, so it is not a rarely-used feature.
You can see the feature in use at Sierra Nevada or Zambales Mountains (if you click on the coordinates at the top of the page)
The automatic zoom can be overriden if an editor specifies a dimension or scale (see, e.g., Cotswolds)

I don't understand why a beneficial and stable feature like this is being discussed for removal. — hike395 (talk) 15:07, 5 May 2020 (UTC)

The main reason I'd like to discuss this is for the sake of standardisation. You mention this works only for the metric or imperial parameters, so it does not work for the generic parameters? If a user decides to use the generic parameter because they want add a reference or a note (i.e. anything instead of just a number), or simply prefers the generic parameter, this would not work. I stand by my recent comment and previous points on using the existing defaults, and would like to see consensus before concluding this discussion. I hope that is fine with you. Reh man 04:12, 6 May 2020 (UTC)

There are two issues here:

Standardization --- I don't understand this argument at all. The default for {{coord}} with no specified type is 1:300,000. Mountains use 1:100,000 by default. Mountain passes use 1:10,000 by default. What is the standard zoom? You could argue that the infobox using 1:100,000 is "not standard" because it doesn't use the geohack default, or that Mountain Passes are not "standard" because mountains are 1:100,000 and passes should be, also. In reality, the zoom is chosen to best match the object. By knowing the size of the object, we have the perfect opportunity to tune the map to the object. I don't see how this is "not standard" any more than these other cases.
Reference or note --- This is unrelated to the zoom functionality, but seems to be an argument against |elevation_ft= and the like. I'd like to point out that |elevation_ref=, |prominence_ref=, |isolation_ref=, |length_note=, |width_note=, and |area_note= already exist and fulfill your request for references or notes.

Re: consensus --- I'd like to remind you of WP:NOCON. Automatic zooming is a long-established feature that you're proposing to remove. In case of no consensus to remove, the feature should remain active. We can leave the discussion open, but so far, you're the only editor that is objecting to this functionality. At some point, we may need to close the discussion as "no consensus to remove". — hike395 (talk) 06:41, 6 May 2020 (UTC)

This was my last comment on this thread (directed to Martin), before I started seeing unconstructive comments like "I don't understand this argument at all" or "we may need to close the discussion as no consensus to remove" from you. It was clear the separate parameters stays, and I've swiftly accepted that fact even though I disagree. I gain nothing personally if we keep or remove the zoom, but I see my suggestion on the Coords function as a path to simplicity and improvement, and I'd like you to also respect consensus and allow at least the other existing participant to have their say instead of you shooting down my comments with the same remarks. Reh man 03:56, 7 May 2020 (UTC)

@Rehman: I'm sorry if my comments upset or offended you. That wasn't my intent. I apologize for any bad feelings that I may have accidentally caused. I try hard not to dismiss arguments out of hand --- if I don't understand why someone is making an argument, I'm not assuming or stating that the argument is wrong. I'm just expressing my confusion at trying to understand.

When I said that we may need to close the zoom discussion as "no consensus to remove" at some point in time --- I want to avoid having a discussion die off with no consensus, then having my lack of response (because I missed a ping in a gigantic thread) taken as silent assent. This has happened previously. If the discussion about zoom dies off with no more voices, please take it as "no consensus", not as "resolved to remove". At the risk of possibly offending you again, I don't see how expressing my concern about this is unproductive. I'm not trying to shut you down. — hike395 (talk) 06:42, 7 May 2020 (UTC)

Thank you for apologising, it is fine. I will not close if there is no participation, you have my word. Reh man 06:58, 7 May 2020 (UTC)

Wikidata

Resolved - Full Wikidata support code will be added, but will be enabled in a separate discussion

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? Reh man 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). Reh man 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? Reh man 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. Reh man 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)

@Rehman: The sandbox is ready to go with tracking categories for name and photo. It doesn't change the output of the infobox at all. If you agree, I'll promote it to the main template. — hike395 (talk) 15:37, 19 April 2020 (UTC)

I believe you misunderstood my previous response. As most of the data is not populated on Wikidata, the idea is to enable all parameters on the live template, so interested editors can start populating Wikidata at their convenience. The RFC issues with Wikidata mostly revolved around more sensitive topics like BLPs. Mountains are...uncontroversial natural geological features, which in most cases have no issues when it comes to factual data. I'm not sure what do you mean by low quality data? Wikidata may even host data on the number of rocks on a mountain (if that's what you mean by low quality data), but regardless, we decide what we want to fetch from there, should a local value be missing, and should that value even be there on Wikidata.

Manually checking each of the upto-25000 articles via tracking categories is also out of the question. To echo what I said earlier, the local parameters will not be blanked under any circumstance, so adding Wikidata support does not necessarily mean Wikidata values will be shown (the little data that is there anyway). Hence why should we be fact checking this? If at all, fact checking is a project at WT:Mountains, not part of this template's discussions. Reh man 05:44, 22 April 2020 (UTC)

@Rehman: Low-quality data is data that isn't supported by reliable sources or that is impossible to verify. That seems to be the main concern about importing Wikidata expressed at the RfC. RexxS, the author of Module:WikidataIB, wrote in the documentation that he expects

"Each article using the new infobox can later be enabled by supplying |fetchwikidata=ALL

(i.e., that each article will be individually vetted before accepting Wikidata), and

"Where it will always be essential for a particular field to only contain values that are referenced, use getValue, making sure that |onlysourced is not set to 'false', '0' or 'no'. By default it will exclude values that are unsourced or only sourced to a Wikipedia, thus making the job of checking easier at the article level."

(again, expecting per-article checking), and

"If unsourced data is acceptable (!), set |onlysourced=no

(notice RexxS's astonishment that someone would find unsourced data acceptable).

Rehman, the code that you're proposing (setting |onlysourced=no and |fetchwikidata=ALL by default), and not talking about the plan to where the future Wikidata fields come from is not OK with me. There are not that many of us active Mountain article maintainers left. If we simply opened the infobox to import all possible current future data, it would be a maintenance nightmare for us article maintainers. I've been looking for a compromise that preserves your enthusiasm for Wikidata (which I share) with upholding the core pillars of Wikipedia (WP:RS and WP:V). So far, we haven't reached such a compromise --- do you have any ideas?

This infobox is the main vehicle for maintaining Mountain articles. I think the use of tracking categories will minimize the work done to verify imported Wikidata (when it exists): we'll be looking at many fewer than 25,000 articles. I do want to avoid importing new fields into the infobox. I also want to get specific feedback at WT:MOUNTAINS, because other maintainers may not realize what this entails. It took me a bit of digging to fully understand what you were proposing. — hike395 (talk) 05:23, 23 April 2020 (UTC)

User:Hike395, if you want to set onlysourced=true, I'm completely fine with it. I don't think you've stated that before? That is the very reason I want to keep that parameter (which you had questioned before). What I'm against in the heaps of tracking categories to manually check already existing parameters within articles. That is out of scope of this discussion. If you're happy with onlysourced being true, I'd be happy to continue the work I started last month, on this path. Let me know. Reh man 05:37, 23 April 2020 (UTC)

@Rehman: Perhaps you misunderstood. The tracking categories are only filled with articles which are missing local parameters, but have Wikidata fallback. For example, the name fallback category has the 174 article where |name= is empty, but have an en label in Wikidata. the photo fallback category has 1318 articles with |photo= is empty, but have at least one image in Wikidata. I've done some spot-checking and I'd love to talk about these in more detail, but it sounds like we're still disagreeing on the strategy, so let's put that discussion off for a while.

I did talk about |onlysourced=yes, below. While using |onlysourced=yes is better, it doesn't remove the need for checking. To quote RexxS again from Module:WikidataIB/doc:

"As it is beyond my wit to produce an automated mechanism that knows whether an existing source is reliable or not in a given context, that job must still be performed at the article level by an editor familiar with the subject. It should always be done when first enabling Wikidata for that article."

We could set |onlysourced=yes and |fetchwikidata=no, but then we will add a lot of complexity to the infobox for essentially no gain. I don't want to go through article-by-article and check all imported wikidata. This is why I was delighted by (what I thought was) your idea of turning it on parameter-by-parameter, and only checking the articles where data was actually imported from Wikidata. That's conceptually much easier, and could gradually be done over a number of weeks.

My other concern, below, was that |onlysourced=yes would be very rare in Wikidata. If we're going to go through the pain of parameter-by-parameter or article-by-article checking, we might as well keep |onlysourced=no. Other editors may disagree with this.

I guess I don't understand your objection to tracking categories. I'd like to be able to focus article checking only where it is necessary. I'd like to only add those parameters that actually get used in infoboxes (delaying unused parameters until those get populated in Wikidata by mass-importing data from reliable sources). If I can't use tracking categories, I have no idea how to proceed. Do you want to do article-by-article checking with |onlysourced=yes and |fetchwikidata=no?

I also don't understand your objection to incrementally improving the infobox. Cloud providers charge a few cents per hour per core. Every edit might take a few minutes of computation. If you wish, I can make an extra donation of $25 to the WMF, in order to (more than) cover the cost of our infobox editing. Trying a gigantic major change will cause me more than $25 of work in article maintenance. Can we please find a way to do all of these changes incrementally? — hike395 (talk) 07:23, 23 April 2020 (UTC)

Alright. How about this, I'll go ahead with adding the Wikidata code, but will set onlysourced=yes and fetchwikidata=none for all parameters. Essentially nothing from wd will be used. Then from there, we could handle parameter-by-parameter by adding tracking category for one parameter at a time, process/verify the uses, and then remove the tracker and change onlysourced and fetchwikidata accordingly, and then move to the next, and so on. That still allows full control to enable parameter-by-parameter, but also allows me to work on the ontology and fine tuning of the code as we move along. What do you think? It's essentially what we both need, in a different approach, I think. Reh man 07:54, 23 April 2020 (UTC)

@Rehman: As long as we're not yet changing the formatting or removing any parameters, that sounds like a good plan! I have a few implementation suggestions:

Let's use Module:Wd (or {{Wd}}) instead of Module:Wikidata, which is marked as deprecated
You may wish to use {{wdib}} or {{wd}}, which is more compact than the full Module invoke.

Looking forward to your code update! — hike395 (talk) 04:55, 24 April 2020 (UTC)

Fantastic. Yes there won't be any visual changes. If any does slip through, feel free to let me know, as you did before. Once the coding is done, we can start a separate discussion to enable them. For now, they'd simply be code on standby - without active function, as agreed. Regarding the other parameters, let's continue the discussions in the related sections. Cheers, Reh man 05:06, 24 April 2020 (UTC)

I've been on a mini-break and while I was aware of this discussion for a while, I was finding it hard to keep track of all the discussion threads so was reluctant to comment. Both of you have done an exemplary job of talking through ideas in trying to reach a solid go-forward point. I like the idea of using Wikidata but its current shortcomings (limited, reliably sourced data) gives me pause. Also, I have tried to add stuff to Wikidata but haven't gotten the hang of it yet. I like the latest proposal by Rehman with adding the Wikidata hooks but not initially using anything. Then incrementally adding full support parameter by parameter with tracking categories and analysis. RedWolf (talk) 20:27, 25 April 2020 (UTC)

Thanks RedWolf. Yes adding data is a bit of a challenge at the moment, as the ontology is still being work on. Once that is done, it should be fairly easy to do it. Cheers, Reh man 03:51, 27 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:

Modify the infobox to add tracking categories for each field where Wikidata has valid fallback data
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.
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?
When we're done checking a field, we turn it on in the live infobox.
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. Reh man 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? Reh man 05:17, 19 April 2020 (UTC)

@Rehman: sandbox2 only adds tracking categories, and does not affect readers or editors in any way. I'll promote it to the main template so we can take some measurements. I can revert if there's a problem or any objections. — hike395 (talk) 15:47, 21 April 2020 (UTC)

Considering the template is used by nearly 25,000 articles, please try to avoid making changes to the live template for those that are still being discussed. This is only so we don't unnecessarily modify/revert over it, and is the very reason we're discussing different topics simultaneously, so that the changes can be done in the least number of edits to both the template, and the corresponding articles. As you've responded to two sections regarding the same topic, I'll respond above. Reh man 05:44, 22 April 2020 (UTC)

Elevation from where?

I just added the infobox for Albis. I didn't provide a name or elevation of the highest point yet the infobox is showing elevation and isolation. Why? Is it mysteriously being grabbed from Wikidata? RedWolf (talk)

Hi RedWolf. Good spot. Yes, it seems like the original code has some parameters that are fetching from Wikidata, when the local parameter is blank. Reh man 03:45, 27 April 2020 (UTC)

Thanks for the reply. I think that if a value has been pulled from Wikidata it should be linked to avoid this mystery as well as make it easier for someone to verify the Wikidata value. I vaguely recall something about a "pen" icon being discussed in the Wikidata infobox changes. RedWolf (talk) 09:53, 30 April 2020 (UTC)

Hopefully these will be clearer once the documentation is updated. Reh man 11:31, 30 April 2020 (UTC)

@RedWolf: Back in 2016, MSGJ added fetching |elevation=, |prominence=, and |isolation= from Wikidata with these edits: [1]. I didn't even notice these edits!

@MSGJ: --- Rehman and I have had a lengthy discussion about adding Wikidata to the infobox, above (not realizing it was done 4 years ago). Two issues have come up: the editability and reliability of data in Wikidata. Since 2016, there are a number of tools to allow readers to edit relevant Wikidata (e.g., the pen icon supplied by {{Wdib}}). What do you think of this? Would you like to help upgrade the infobox to use {{Wdib}}?

@Rehman: --- Can we pause the arguing over removing parameters, so that we can upgrade the three fields that are already importing Wikidata? I'd love to get started on this. — hike395 (talk) 14:30, 3 May 2020 (UTC)

I don't believe we were arguing? As I stated before as the person who started this process, let's wait till all discussions conclude before starting on anything significant. It's already a month since the first thread, and I really don't mind waiting another, if that's what's needed to come to a consensus. Relating to the parameters added by MSGJ, as they have been active for so long without issue, those can remain active. There is no point disabling them, only to discuss to enable them again. Reh man 14:56, 3 May 2020 (UTC)

@RedWolf, MSGJ, and Rehman: I agree with Rehman: let's not disable them. But, per RedWolf, let's add a pen icon to edit them, and per our discussion above of validating the data when enabled, let's add a tracking category so that we can validate the imported data.

To be concrete, I have modified a version of the sandbox to add a pen editing icon and a tracking category to |elevation=, |prominence=, and |isolation=. You can see the pen editing icon in action at the Albis and Brienzer Rothorn testcases. I think they look quite reasonable and have a good functionality.

What do other editors think? We are very far from consensus on the major edit. I'd like to respond to RedWolf's suggestion of modifying the infobox, without having to wait for an indefinite amount of time until we agree on the major edit. — hike395 (talk) 15:34, 3 May 2020 (UTC)

Sandbox looks great. Thanks Hike395. One thing that confuses me though: {{infobox mountain}} is fetching this information from Wikidata but on the testcases it appears not to? — Martin (MSGJ · talk) 15:50, 3 May 2020 (UTC)

One feature that {{wdib}} has that {{convert}} doesn't: for testing, it accepts |qid= to force a qid. If you look at the source code Template:Infobox mountain/testcases2, you'll see that I specified |qid= for the test cases. Otherwise, the template uses the qid for the current page (which is empty for the testcases page), if you see what I mean. — hike395 (talk) 16:26, 3 May 2020 (UTC)

I added elevation, prominence and elevation after proposing them in 2016. I made some further suggestions then about other Wikidata fields we could make use of in this infobox template — Martin (MSGJ · talk) 15:58, 3 May 2020 (UTC)

Martin Thanks for adding it back in 2016! I'm even more enthusiastic to add Wikidata fields than I was back in 2016. I would love to add all of the fields you suggested back then, with editing pen icons and tracking categories. Per the discussion Rehman and I were having, above, we would first add the tracking category, then check the quality of the data, then enable it in the infobox. Does that sound good? — hike395 (talk) 16:26, 3 May 2020 (UTC)

Sounds good. There is probably a lot more that Wikidata can do now, than it could it 2016. Storing references for the data is one example, which helps to maintain confidence in reliability. And there are likely to be new properties now that weren't available then. — Martin (MSGJ · talk) 19:24, 3 May 2020 (UTC)

One question for Martin and RedWolf --- how do you feel about importing unreferenced data from Wikidata? {{Wdib}} can either import anything (|osd=no), or import only those fields with external references (|osd=yes). My concern about the latter is that data imported from other-language Wikipedias doesn't count as externally referenced, so there is very little Wikidata that has external references. Rehman and I came to a conclusion that it's better to consider importing everything, but check it all (which is a lot of work). That's the tentative consensus (from two editors), but if you feel otherwise, please say something. — hike395 (talk) 22:34, 3 May 2020 (UTC)

Actually my original personal preference is to import the values simply on the basis that if it is there, and a local value is missing, then we show it - regardless if it is referenced at wikidata or not, and deal with bad data as and when we come across; the benefits far outweigh any isolated issues. While Hike395's points against adding unreferenced data are valid, I personally feel that not adding them if a local value is missing, is similar to not linking to another article because it has unreferenced statements. I won't weight in further on the fact that we already had a lengthy discussion (see "Wikidata" subsection above), and I was willing to compromise on that. But of course another discussion with more opinions won't hurt. Cheers, Reh man 03:05, 4 May 2020 (UTC)

I think you should adopt a similar policy to how you would treat a locally-entered unreferenced value — Martin (MSGJ · talk) 08:41, 4 May 2020 (UTC)

Why is Wikidata allowing parameters to be populated without an external source? Is there an option to mandate sources for particular parameters? It's a sad state that many of the countries geography databases don't store (or don't make available) the elevation of mountains, Canada included unfortunately. Whenever I go to add or sync a mountain with mountains on other Wikis, more often that not, neither the elevation nor the coordinates are sourced but I'll usually add them to the English Wiki with some reluctance. Generally speaking I would agree with Hike395 not to add unreferenced Wikidata but elevation and coordinates are two of the most important parameters IMHO so I would be inclined to allow it for those two parameters. What has the general consensus been on the other projects regarding this or are there any established guidelines? RedWolf (talk) 23:09, 4 May 2020 (UTC)

I agree it is quite unfortunate. It is also important to note that in the early days of Wikidata, most of the data were in fact directly imported from English Wikipedia (with the source simply stating "English Wikipedia). Currently, I believe all we can do is to manually add the real sources to Wikidata. I try to do this as much as I can, and it seems fairly easy. Pidurutalagala (Q1146327) is an example where I cited a book for elevation, but URLs are more easier IMO. There are basic parameters that doesn't necessarily need to be sourced, and that includes the coordinates (and name, image, country, etc), as the sharpest and most ideal coordinates are often never found mentioned in a source, but rather derived by Wikimedians. Of the hundreds of coordinates I've added to various articles, 100% of them were derived from Google Earth/Maps, by cross checking with other static maps and information.

In terms of general consensus, sensitive topics such as BLP usually block all unsourced content, while non-political geography/nature related content aren't as strict, as the data are mostly undisputed and widely agreed. Reh man 04:08, 5 May 2020 (UTC)

@MSGJ: As far as I can tell, there isn't a strong consensus documented anywhere. The 2018 RfC on Wikidata in infoboxes has a sizable minority (~30%) of editors who didn't want to have any Wikidata in infoboxes. The documentation for the Wikidata Infobox module directs us to leave Wikidata off, then manually turn it on one article at a time. Both Rehman and I thought that was too inefficient, and we should do it one parameter at a time. Rehman: where are you seeing geography/nature wikidata fields being less strict? It would be handy to have other discussions to refer to.

For U.S. mountain coordinates, I almost always use a reliable source to get coordinates and elevation. The National Geodetic Survey appears to be the most reliable. GNIS uses USGS topo maps, which is less reliable. Other mountain editors use CGNDB, Peakbagger, Bivouac, Summitpost, Smithsonian Global Volcano Program to get coordinates and elevations from outside of the U.S. — hike395 (talk) 05:44, 5 May 2020 (UTC)

Re geography/nature wikidata, that is my general assumption; I should have clarified that. For example there's far less controversy in elevation or area of a mountain, when compared to say, a BLP's primary occupation, religion, income source, height, or whatever. Re coordinate source, I guess that depends on the source/country. For instance, coords for Sri Lanka are always way off the mark, and mostly unknown. Most of the data that's currently online/published is at some point taken from Wikipedia itself. Reh man 06:02, 5 May 2020 (UTC)

I was looking at deploying Hike's sandbox2 to add the pencil links to the template, but there seem to be other changes in there which I don't fully understand, e.g. the image parameter, and the above parameter. — Martin (MSGJ · talk) 20:23, 4 May 2020 (UTC)

As discussed in the previous "Wikidata" section with Hike, the pencil icon is mostly cosmetic, and can be added with a minor switch in the code. The image parameter works the same as others - show wikidata value when local is missing. Reh man 04:08, 5 May 2020 (UTC)

@MSGJ: The {{Track fallback}} template is a simple hack to track when Wikidata fallback is used. It does not affect the display of the infobox at all. It only populates a tracking category if fallback is available. In a previous fit of enthusiasm, I added two tracking categories for "above" and "image". Rehman had objected to adding these tracking categories, so I thought we could just drop them for now, and start working on your fields.

If you like, I can modify sandbox2 to be based off the current live infobox, rather than reverting my tracking categories for "above" and "image". Let me know. — hike395 (talk) 05:18, 5 May 2020 (UTC)

@Rehman: are you happy to deploy Template:Infobox mountain/sandbox2 for now, while other changes are discussed? Hike: if Rehman is happy with that version then let's just deploy it. I don't think the pencil links is at all controversial. — Martin (MSGJ · talk) 11:46, 5 May 2020 (UTC)

Considering the high number of articles linked to this infobox, I'd prefer if we wait till everything is discussed to see what we have on our plate, before implementing any part of this discussion. This is only to minimise repetitive mass changes, as I mentioned to Hike before. Considering I've already started on these since early March at Template:Infobox mountain/sandbox and the first mountain ontology for Wikidata at Template:Infobox mountain/sandbox/doc, I'll be happy to keep those changes ready with the others, and implement it once the threads conclude. The new sandbox2 are only for {{Track fallback}} usages on the current Wikidata enabled parameters, am I correct? Reh man 13:42, 5 May 2020 (UTC)

I am keen to get the pencil links implemented for the data which is pulled from Wikidata, as I think we all agree that is needed. In general, it might be easier to make a series of incremental changes rather than wait for everything to be settled before changing anything? — Martin (MSGJ · talk) 13:49, 5 May 2020 (UTC)

Sandbox2 starts with the version of the infobox as of March 4, 2020 (before discussion began) and changes the way Wikidata is fetched. Martin previously used {{convert}} to implement Wikidata fallback for |elevation=, |prominence=, and isolation. Sandbox2 uses {{wdib}} and so implements the pen icon editing feature (that was requested by RedWolf). It also adds tracking categories for these three parameters (so that we can check on the quality of the imported data). Per our discussion above, sandbox2 also imports all data for these parameters, without filtering, because that is what the current infobox is doing. You can see the results of the changes at the testcases.

I'm also keen to get the pencil links implemented, and agree with Martin that a series of incremental changes is better for widely-used templates. Changes that touch large parts of the code tend to introduce bugs and errors that could be difficult to detect. If we go step-by-step, we can carefully make test cases and (at least) spot-check the effects of the changes. — hike395 (talk) 15:26, 5 May 2020 (UTC)

Hike, we have already agreed on the Wikidata implementation. I'd also like to note your comment regarding not adding the pen icon. Is that discussion no longer valid?

Martin, sorry I wasn't clear. Implementation will be done in phases, but it is better to start working on the code once the discussions conclude, as many are related. I've already discussed this with Hike, in #Wikidata (a collapsed section). A random simple example, we don't have to work on the wd code for say each of the series of region parameters, as consensus now is to have a single parameter. Similarly, I could have started work on the single elevation parameter, but consensus now is to have separate parameters. And then, we also have duplicate parameters such as coords and coordinates, and getting those out of the way first would make following work slightly simpler. Things like that. Nevertheless, I will continue the work I started for those that are with a clearer approach. Reh man 04:37, 6 May 2020 (UTC)

Re: pen icons --- Rehman may be misremembering my previous comment. When Rehman proposed adding wikidata, I thought that wikidata would be filled with many fields that would fill in the infobox. If the fallback was activated for many fields with pen icons, it might look odd (e.g., Arecibo Observatory). I wanted to show the editors at WT:MOUNTAINS a mock-up with many pen icons. I started to work on that, but then Rehman said that Wikidata was mostly empty of mountain-related data. So I then stopped, because any such pen-filled infobox would be far in the future and I didn't want to slow down our progress. I've wanted to add pen icons since the beginning: [2]. RedWolf wants them, MSGJ wants them. Rehman didn't seem to object, before? — hike395 (talk) 05:41, 6 May 2020 (UTC)

At this point, I'm confused about why we need to wait for all parameters to be defined and all ontologies to be worked out before adding pen icons and tracking categories for the three fields that are already being imported.

Parameters are independent, both in Wikidata and in the infobox. For example, P2044 (elevation) is independent of P613 (OS grid reference), so we can presumably improve the existing implementation of P2044 fallback while Rehman figures out everything else
It seems to me that there doesn't have to be a 1:1 relationship between Wikidata properties and infobox parameters (which Rehman may be assuming?). For example, in the live infobox, there are |elevation_ft= and |elevation_m= parameters, yet only one Wikidata property P2044 as fallback. The two parameters are for convenience. Similarly, there's a single property P47 ("shares borders with") that is list-valued, but there could be parameters |borderNNN= where editors can enter the values one at a time. So the discussion of parameters could be decoupled from the decisions/discussions about ontology.

It seems to me that for Wikidata properties that have been stable over the last 4 years and that are already being imported in the live infobox, that it's completely safe to improve their editability and also verify their quality. Why must we wait? Martin, RedWolf (presumably?), and I would like to implement it now. — hike395 (talk) 06:20, 6 May 2020 (UTC)

Right. I can't understand why the sudden rush, but to avoid going in circles I went ahead and added the code for the 3 existing wikidata parameters. Usages are tracked here, here, here, and here. You may wish to create the categories if you like. I have concerns regarding actioning on the tracking results, but I'll raise that at a later time. If there are any concerns for those 3 (actually 4, as there are two fields in one parameter, for elevation), please let me know here, and I'll work on it accordingly.

Regarding the pen icons, I believe you are aware they are only active for each parameter if Wikidata values are used. Thus, in instances where some parameters use Wikidata and some use local values, the infobox will be pegged with random pen icons in seemingly random parameters. That is clearly confusing even to the most experienced editors who are unaware of complex Wikidata functions - you yourself have also only become aware of key Wikidata functions in this very discussion. Thus I'd like to suggest we simply include a single "Edit on Wikidata" button (example). I'd like to hear MSGJ's or another third-party's comment on this, before closing the case on the pen icon. That being said, I have included the pen icon in the above 3 parameters, with the hopes that we can continue a constructive conversation.

For the rest of the Wikidata parameters, I will continue working on those as agreed. Reh man 03:48, 7 May 2020 (UTC)

@Rehman: There seems to be a bug in the live infobox code: the fields in Aira Caldera are empty. I'm going to rollback your code (sorry for that), and make a test case. I'm afraid I don't understand your added code, so it's difficult for me to debug. — hike395 (talk) 07:24, 7 May 2020 (UTC)

Thanks for that. It was caused by exposed includeonly tags. I've now fixed it. Strangely it didn't show in my tests; probably because it takes time to propagate due to the high uses. It will take about 15-30 minutes for the changes to start showing on the tracking categories. In the mean time, feel free to raise any issues. Cheers, Reh man 07:49, 7 May 2020 (UTC)

Argh! The test case doesn't reproduce the bug. You saw it, right? I've had this problem with Wikidata importing before.. it's very difficult to test. — hike395 (talk) 07:48, 7 May 2020 (UTC)

Yes, I did see. Thanks for raising. Changes must be done slow, and it takes time to propagate. Reh man 07:51, 7 May 2020 (UTC)

Okay, changes seems to be getting updated now. I had to create those categories as they must be marked as tracking categories. There are a few more articles to be purged from the cache, but most of what you see now are actual Wikidata uses. The rest (those that are in the category, but not so if you open the article) will automatically get updated in a couple of hours. Let me know if anything. Reh man 10:21, 7 May 2020 (UTC)

Processing tracked articles

Hello. There has been some upgrades at Module:Infobox and Module:WikidataIB, hence the tracking code here is now much simpler. I have added instructions in Category:Wikidata value to be checked for Infobox mountain, on how to go about reviewing the tracked articles; comments welcome. Some points to note:

I did not add the trackers for the Wikidata properties that are already enabled (elevation, prominence, isolation). Since those has been enabled for years and there had been no issues with bad data being imported, I felt there is no need to clog the tracker with those entries and bloat the review process. If you wish to have them included, let me know, and I'll add them right away. But since those are key parameters, I suspect the majority of entries in the tracker will be from them if we are going to enable trackers for those.
Per the instructions in the above category, a single tracking category is used. This is to reduce the number of times we need to visit an article (for each parameter).

Thoughts welcome. Reh man 11:10, 17 May 2020 (UTC)

Part parameter refers to subfeatures, not superfeatures

@Rehman: I just finished transferring the data for |part= to Wikidata. I looked at what that contains: it has subfeatures of mountain ranges, such as individual peaks, subranges, or rivers. Thus, I don't think it should be renamed to |subdivision4=, because that implies an administrative division that the range belongs to. How about just leaving it at |part=? (You can, of course, collapse the numbered parameters to a CSV string at |part=.)

I believe that this maps to the Wikidata property has part(s) (P527), and I exported the data to that property. — hike395 (talk) 09:39, 28 June 2020 (UTC)

The original label for part is "Subdivisions" (see source code). Whoever added this parameter did not document it, and hence there are now various different uses of this parameter. To make sure that the incorrect uses are not messed up, the label for that parameter will be carried forward via subdivision4_type; so whatever it is used for, would remain valid. Reh man 12:53, 28 June 2020 (UTC)

@Rehman: I think it's great that you will carry the label forward.

There are two separate issues, here:

Should we have |parts= parameter in addition to having a number of |subdivision= parameters?
If yes, sould we use existing |part= to populate the new |parts= parameter?

I would suggest that, for the first issue, there are two arguments in favor of having |parts=:

Consistency: {{Infobox settlement}} has |subdivision1= through |subdivision6= to express "is a part of" relationships. In addition, it has |parts= to express "has part" relationship. Since {{Infobox settlement}} is commonly used, this should be familiar to editors.
Future-proofing P527: If we ever want to import "has part(s) (P527)", then we'll need to set aside a parameter today. If we let editors to place "has part" information into |subdivision=, then it will be impossible to know exactly they will place it. Thus, we won't be able to correctly fallback to wikidata P527 import -- we may both have "has part" information entered, and also duplicatively import P527 information.

If other editors agree that |parts= is useful to have, then the question arises: should we move the current contents of |part= into |parts=? As Rehman correctly points out, the documentation for |part= isn't currently clear. However, if we look at actual usage, it seems that editors have been consistent in the practical usage of |part=. Please see here to see how |part= is used in the 847 articles in Category:Pages using infobox mountain with multiple parameters. I've looked through these --- they all seem to be sub-features of a mountain or range. Usually, this is a river or sub-range, but sometimes there are other features.

I think it would be safe to condense all of the |part*= numeric arguments into a single |parts= parameter, making it consistent with {{Infobox settlement}} and allowing has part(s) (P527) fallback. What do others think? — hike395 (talk) 05:16, 29 June 2020 (UTC)

To be honest, I am not a fan of keeping that parameter. Infoboxes should contain only a summary of key facts - WP:INFOBOXPURPOSE. Taking the random example Khangai Mountains, from this page which you created, it has been "customised" such that the parameter is used to define rivers in the mountain range. I think this is absurd, and the parameter can be used for almost anything if so - which is against the purpose/consistency of infoboxes. Facts such as those, should be moved to article text, and removed from the infobox, IMHO.

That being said, my main target is to clean up what is already on the plate. Hence I'm not pushing it either way until the cleanup is done. I'll probably weight in afterwards. Cheers, Reh man 05:34, 29 June 2020 (UTC)

Should border be P47 or P4777

I'm just about to export the data associated with |border= to Wikidata, but I think I may have found a better property. Rehman's proposal will import shares border with (P47) into |border=. But, the description of P47 implies that it was designed for administrative regions. has boundary (P4777) looks like it is more general and does not enforce symmetry.

Before I export the border data, I wanted to bring this up so we're consistent across export and import. What do editors think? — hike395 (talk) 09:57, 28 June 2020 (UTC)

Thanks, P4777 is a better option. I have updated the sandbox doc draft, and will use that when coding. Cheers, Reh man 12:59, 28 June 2020 (UTC)

_ref/_note parameters

Resolved - ref parameters will be retained

In the initial proposal, Rehman suggested remove parameters for references and appending the reference to parameter value for which it was used as a source. I don't think this is a good idea. I would expect that data for elevation and coordinates should have a reference to a gazetteer somewhere in the article. From the articles I've sampled, the references in the infobox are the only places in the article where coordinates and elevation are referenced. Checking whether any reference is given is far more feasible (but still not easy (but see my comment below)) if a separate parameter for the reference is maintained. The reference parameters are fairly widely specified. 20435 articles have |coordinates= specified, 6023 have a reference (29%). 23393 articles have an elevation specified, 9645 have a reference (41%). 976 articles have isolation specified, 640 have a reference (65%). I would guess that there are also a substantial number of articles that have a reference appended (as Rehman suggested), rather than occupying a separate parameter.

From what I've seen of Wikidata, elevation/coordinates aren't often referenced to a gazetteer, but are often imported from a Wikipedia. While pulling from Wikidata is certainly better than nothing, it isn't better than actually having a link to a gazetteer that can confirm elevation/coordinates.

I don't think there is any good reason to maintain |coordinates_note=, |coordinates_ref= and |coords_ref=. These can be consolidated to a single parameter. Some of the parameters have only a *_note version and no *_ref version. *_ref parameters are far more populated than *_note, so if it desirable to have the parameters named consistently, it would take less work to standardize on _ref than _note. — Preceding unsigned comment added by Plantdrew (talk • contribs) 18:45, 7 May 2020 (UTC)

There is a feature request for ParameterData to allow parameters to be "linked" to each other. If this is ever implemented, it would be easy to search for missing references if the ref parameter is linked to the parameter it sources (could also link a caption parameter to an image parameter to find images that don't have captions, etc.). Plantdrew (talk) 18:55, 7 May 2020 (UTC)

Thanks for the feedback, Plantdrew. I'm neutral on keeping the ref parameters, hence if anyone wants to keep it, that's perfectly fine (the code I'm working on already includes those). The duplicate parameters (note/ref) will of course be fixed. Cheers, Reh man 01:07, 8 May 2020 (UTC)

Template documentation

Hello. Can someone tell me what is supposed to go in isolation_parent? It is not documented, but exists in this template, within the isolation parameter. I know it'll be a name of a mountain, but a clear definition would help. Next tallest mountain? Reh man 15:04, 8 May 2020 (UTC)

Rehman: As far as I know, |isolation_parent= is the name of the nearest peak whose summit is higher than the topic of the article. |isolation_mi= (and similar) is the distance to the nearest spot that is higher than the summit. See Topographic isolation. Notice that the isolation distance isn't a summit-to-summit distance. I guess there could be a weird case where the isolation distance point isn't part of the isolation parent? That would be very rare.

Pinging Buaidh, who is the deep expert on this, and can correct me if I'm wrong. — hike395 (talk) 05:09, 9 May 2020 (UTC)

Makes sense, thanks! Reh man 07:39, 9 May 2020 (UTC)

One more. Are the parameters isolation_parent and parent_peak for the same thing? If not, how do they differ? Reh man 09:57, 13 May 2020 (UTC)

They're different. isolation_parent is the peak that defines Topographic isolation. parent_peak is the peak that defines Topographic prominence, which is a different concept. — hike395 (talk) 11:58, 14 May 2020 (UTC)

Thanks! I'll update the doc accordingly. Reh man 14:30, 14 May 2020 (UTC)

I've moved parent_peak directly under prominence since they are related, and to avoid confusion. Let me know if you think this is a bad move. Reh man 13:45, 17 May 2020 (UTC)

Infobox cleanup

Discussions

Volcano parameters

Range coordinates

Combining parameter series

Break 1

Break 2

Break 3

German infobox translation

Automatic conversion and zoom

Break 1

Wikidata

Step by step

Elevation from where?

Processing tracked articles

Part parameter refers to subfeatures, not superfeatures

Should border be P47 or P4777

*_ref/*_note parameters

Template documentation

_ref/_note parameters