Template talk:Infobox mountain/Archive 5

Infobox cleanup
Hello. I'm attempting to amend and clean-up the template code so as to achieve the below:
 * 1) Enable Wikidata values when no local value is present.
 * 2) Add non-static interactive map support (example)
 * 3) Clean up duplicate parameters (random example:   and  ) - to be done only together with another edit
 * 4) Remove redundant parameters (random example:   through  ) which can be instead included as a UBL in a single parameter - to be done only together with another edit
 * 5) Update documentation

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


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


 * 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?

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)


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


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

Range coordinates
I'm curious as to why you list  and   as duplicate parameters. is intended for individual mountains while  is intended only for mountain ranges. Volcanoguy 01:15, 2 April 2020 (UTC)
 * User:Volcanoguy,  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, .  and   are not duplicates!   are the coordinates of the highest peak or summit of a range, while   are for the centroid of the range.   center the range on the geohack map, are zoomed out, and appear in the title, while   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.  makes a link under the "Highest Point" section: when you click on it, you get taken to a geohack map of Mount Elbert.   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  should be renamed to   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  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
The parameters that you are proposing to delete are not redundant. The proposed change would affect the appearance and functionality of the infobox. Namely:
 * ,,  ,  ,  ,  ,  , and   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.
 * and  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.
 * ,,  ,  ,  ,  ,   are convenient shortcuts for editors. It seems like a shame to force future editors to use convert when the infobox used to do the conversion for them. The current infobox code also enforces unit conversion, while future editors can use whatever units they wish (e.g, furlongs).

It seems that you've proposed multiple major edits to the template at once. I'd recommend breaking the discussion and editing into three phases:
 * 1) Using Wikidata
 * 2) Deleting parameters
 * 3) Changing the formatting

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


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


 * 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)
 * 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 ) and produce the collapsible list/enum hybrid. This should answer 's objection to having these parameters, and make other editors (like ) 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)
 * 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, 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)
 * 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)

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
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. 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)
 * to  →
 * to  →
 * to  →
 * to  →
 * ,  to   →
 * ,  to   →
 * to  →
 * to  →
 * to  →


 * 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., . If 5 or more, it created a collapsible list to keep the infobox from growing. had previously thanked me for putting this functionality into Module:Compact list.
 * There are two problems with '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 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? &mdash; 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  through   in the Hoover Dam example, or   to   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:


 * — 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? &mdash; 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)


 * --- 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. 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? &mdash; 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. &mdash; 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)
 * 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.
 * 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)

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. &mdash; Martin (MSGJ · talk) 10:57, 6 May 2020 (UTC)


 * More factors for your consideration ---
 * As currently implemented in the live infobox, editors may use CSV to enter lists. They can use, e.g., 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).


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


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


 * 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. and  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: . So implementation is trivially easy.


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


 * 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, thus it seems like it would make more sense if the content is sourced from the most used/largest subdivision only - the  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  parameters and proceed with the copying. Cheers, Reh  man  15:21, 17 May 2020 (UTC)


 * 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 ? 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. . Cheers, Reh  man  13:31, 18 May 2020 (UTC)


 * Thanks, yes, I saw, was planning on starting with Countries first, because that seemed straightforward.


 * seems a bit problematic for automatic copying to Wikidata. It's hierarchical: the instructions at 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,  ,  , and   into Wikidata, I very well may violate this (implicit, unchecked) constraint. One possibility is to write   into ,   and   into  (because they might not be administrative). What do you think of that?


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


 * Speaking of parts: I'm thinking that  shouldn't be . 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  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 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)

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  (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.


 * 1) 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.
 * 2) This make sense, and should be fine.
 * 3) 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 on July 1 (about two weeks ago). Before then, the template itself had a label "Borders on", . 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" it will produce "El Capitan". Instead, XXX might be converted to be 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  instead of the current ambiguous  ?
 * 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, and append the corresponding language code in.
 * 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)

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

Automatic conversion and zoom
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)
 * 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)
 * 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  for  . 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  (notice  ) 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.,  and. 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  or   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  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 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 '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? &mdash; Martin (MSGJ · talk) 20:11, 4 May 2020 (UTC)
 * 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. 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)


 * 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, we have:   (if you want to use your own formats),   if you want to add the value in metres but want the infobox to auto-convert to feet, and   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. ), 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 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 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   and   defined).  Reh  man  04:59, 5 May 2020 (UTC)
 * --- 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. 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 5678 rather than elevation. This system is also well used in other templates (I am somewhat familiar with Template:Infobox river). &mdash; 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 5678 with elevation. 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. &mdash; 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 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.57858°N, -118.29199°W), 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)


 * 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
{{Hidden|1=Resolved - Full Wikidata support code will be added, but will be enabled in a separate discussion|2= I'm sorry, {{U|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 {{tl|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 {{para|qid}}, {{para|fetchwikidata}}, {{para|suppressfields}}, and {{para|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, 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)


 * {{ping|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 {{para|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)

{{od|3}} {{ping|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 {{tl|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 {{para|fetchwikidata}}, {{para|suppressfields}}, and {{para|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)


 * {{ping|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)


 * {{ping|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  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: {{cross}} There's a problem with the code in the first sandbox. If you dig through the Lua,  is not guaranteed to return the caption for the same image that   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, {{U|Rehman}}? — hike395 (talk) 14:48, 19 April 2020 (UTC)


 * {{ping|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)


 * {{ping|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. {{U|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  
 * (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  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
 * (notice {{U|RexxS}}'s astonishment that someone would find unsourced data acceptable).
 * {{U|Rehman}}, the code that you're proposing (setting {{para|onlysourced|no}} and {{para|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, 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   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)


 * {{ping|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 {{para|name}} is empty, but have an en label in Wikidata. the photo fallback category has 1318 articles with {{para|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 {{para|onlysourced|yes}}, {{Diff||950659419|949975826|below}}. While using {{para|onlysourced|yes}} is better, it doesn't remove the need for checking. To quote {{U|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 {{para|onlysourced|yes}} and {{para|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, {{Diff||950659419|949975826|below}}, was that {{para|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 {{para|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 {{para|onlysourced|yes}} and {{para|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)

{{OD|::::::::}} 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)


 * {{ping|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 {{tl|Wd}}) instead of Module:Wikidata, which is marked as deprecated
 * You may wish to use {{tl|wdib}} or {{tl|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
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 false. If we follow this guidance, I think that the Wikidata fallback will never get used.

Instead, I'd like to propose a careful staging of the Wikidata fallback, to ensure that we're showing reliable data:
 * 1)  Modify the infobox to add tracking categories for each field where Wikidata has valid fallback data
 * 2)  We alert editors at WT:MOUNTAINS what we're doing, and let them know they should check the "Show Wikidata edits in your watchlist" box.
 * 3)  Depending on the number of articles that use each fallback:
 * 4) If the fallback never gets used, we don't add it to the infobox.
 * 5) If a small number of articles use the fallback, we can manually check them.
 * 6) If a large number of articles use the fallback, perhaps we can set true and manually check only those?
 * 7) When we're done checking a field, we turn it on in the live infobox.
 * 8) 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)


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


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

Back in 2016, added fetching elevation, prominence, and isolation from Wikidata with these edits:. I didn't even notice these edits!

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

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


 * I agree with : let's not disable them. But, per, 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 '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? &mdash; 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 &mdash; Martin (MSGJ · talk) 15:58, 3 May 2020 (UTC)


 * 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 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. &mdash; Martin (MSGJ · talk) 19:24, 3 May 2020 (UTC)


 * One question for and  --- how do you feel about importing unreferenced data from Wikidata? Wdib can either import anything (no), or import only those fields with external references (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.  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 &mdash; 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. 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)
 * 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. &mdash; 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)
 * 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". 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)
 * 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. &mdash; 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? &mdash; 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 ). 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 (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 that Wikidata was mostly empty of mountain-related data. So I then, 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:. 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.
 * 1) 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
 * 2) 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)


 * 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: Thoughts welcome. Reh man  11:10, 17 May 2020 (UTC)
 * 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).

Part parameter refers to subfeatures, not superfeatures
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, and I exported the data to that property. — hike395 (talk) 09:39, 28 June 2020 (UTC)


 * The original label for  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  ; so whatever it is used for, would remain valid.  Reh  man  12:53, 28 June 2020 (UTC)


 * 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 "", 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 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. 's proposal will import into border. But, the description of P47 implies that it was designed for administrative regions. 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)

Template documentation
Hello. Can someone tell me what is supposed to go in ? 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, 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  and   for the same thing? If not, how do they differ? Reh man  09:57, 13 May 2020 (UTC)


 * They're different.  is the peak that defines Topographic isolation.   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  directly under   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)