This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 | Archive 6 |
Hello. I'm attempting to amend and clean-up the template code so as to achieve the below:
range_coordinates
and range_coords
) - to be done only together with another editstate1
through state18
) which can be instead included as a UBL in a single parameter - to be done only together with another editAs 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)
Hi Plastikspork. Would you be able to assist in running your bot through articles using {{ Infobox mountain}}, to make the following changes please?
From | To |
---|---|
Duplicates | |
photo_width |
photo_size
|
coords |
coordinates
|
topo |
topo_map
|
relief |
map_relief
|
parent |
range
|
image_map |
map_image
|
coords_ref |
coordinates_ref
|
coordinates_note
| |
elevation_note |
elevation_ref
|
city_type |
settlement_type
|
Renames | |
type |
mountain_type
|
state_type |
subdivision1_type
|
region_type |
subdivision2_type
|
district_type |
subdivision3_type
|
part_type |
subdivision4_type
|
range_coordinates_note |
range_coordinates_ref
|
grid_ref_Ireland_note |
grid_ref_Ireland_ref
|
grid_ref_UK_note |
grid_ref_UK_ref
|
length_note |
length_ref
|
width_note |
width_ref
|
area_note |
area_ref
|
volume_note |
volume_ref
|
Source (in order) | Destination |
---|---|
bordering_range |
Move contents to bordering_range , in the same order.
|
border
| |
border1
| |
border2
| |
border3
| |
border4
| |
border5
| |
border6
| |
border7
| |
border8
| |
volcanic_region |
Move contents to volcanic_region , in the same order.
|
volcanic_arc/belt
| |
volcanic_arc
| |
volcanic_belt
| |
volcanic_field
| |
geology |
Move contents to geology , in the same order.
|
geology1
| |
geology2
| |
geology3
| |
geology4
| |
geology5
| |
rock
| |
age |
Move contents to age , in the same order.
|
period
| |
period1
| |
period2
| |
period3
| |
period4
| |
country |
Move contents to country , in the same order.For articles that used country1 , please append the additional parameter |country_type=Countries .
|
country1
| |
country2
| |
country3
| |
country4
| |
country5
| |
country6
| |
country7
| |
country8
| |
settlement |
Move contents to settlement , in the same order.For articles that used settlement1 or city1 , please append the additional parameter |settlement_type=Settlements .
|
settlement1
| |
settlement2
| |
city
| |
city1
| |
city2
| |
city3
| |
city4
| |
city5
| |
city6
| |
city7
| |
city8
| |
city9
| |
city10
| |
city11
| |
city12
| |
city13
| |
city14
| |
city15
| |
city16
| |
subdivision1 |
Move contents to subdivision1 , in the same order.• For articles that use state , please append the additional parameter |subdivision1_type=State .• For articles that use state1 , please append the additional parameter |subdivision1_type=States .
|
state
| |
state1
| |
state2
| |
state3
| |
state4
| |
state5
| |
state6
| |
state7
| |
state8
| |
subdivision2 |
Move contents to subdivision2 , in the same order.For articles that use region1 , please append the additional parameter |subdivision2_type=Regions .
|
region
| |
region1
| |
region2
| |
region3
| |
region4
| |
region5
| |
region6
| |
region7
| |
region8
| |
region9
| |
region10
| |
region11
| |
region12
| |
region13
| |
region14
| |
region15
| |
region16
| |
region17
| |
region18
| |
region19
| |
region20
| |
region21
| |
region22
| |
region23
| |
subdivision3 |
Move contents to subdivision3 , in the same order.For articles that use district1 , please append the additional parameter |subdivision3_type=Districts .
|
district
| |
district1
| |
district2
| |
district3
| |
district4
| |
district5
| |
district6
| |
district7
| |
district8
| |
district9
| |
subdivision4 |
Move contents to subdivision4 , in the same order.For articles that use part1 , please append the additional parameter |subdivision4_type=Subdivisions .
|
part
| |
part1
| |
part2
| |
part3
| |
part4
| |
part5
| |
part6
| |
part7
| |
part8
| |
part9
| |
part10
| |
part11
| |
part12
| |
part13
| |
part14
| |
part15
| |
part16
| |
language |
Convert the language name to it's
ISO 639-3 code and move to native_name_lang .
|
Uses of {{ Infobox mountain range}} should be changed to {{ Infobox mountain}} to avoid redirect.
I have manually fixed erroneous usages based on the previous parameter scan. Once the above changes are done, would you be able to run one final scan please?
Thank you so much! Reh man 05:34, 30 March 2020 (UTC)
I have updated the above table based on the consensus below and removed those that failed consensus. The first table lists direct hardcoded duplicate parameters and parameters that will be renamed in the backend (the displayed labels will remain the same). The second table consists of the parameters that are to be combined. If there are any questions or clarifications, please comment in the section(s) below. Once #Combining parameter series concludes, I intend to go ahead with the above. Cheers, Reh man 15:30, 17 May 2020 (UTC)
@
Rehman: The merging of volcanic_arc/belt
, volcanic_arc
, volcanic_belt
and volcanic_field
to volcanic_region
sounds like a good idea and it is something I have been thinking about for some time. There is something else I have thought about and that is
stratigraphic units. It is not uncommon for mountains made of volcanic or sedimentary rocks to be part of
groups or
formations. However, there seems to be no parameter for such features. I am not sure what the best code name would be, perhaps stratigraphic_unit
?
Volcano
guy 22:46, 31 March 2020 (UTC)
I would also like to note that last_eruption
should probably be renamed to last_known_eruption
since it is commonly used for the youngest dated eruptions using, radiocarbon, potassium-argon and other methods. There is always the possibility of there being younger eruptions that have not been dated/witnessed, especially volcanoes in remote locations.
Volcano
guy 23:37, 31 March 2020 (UTC)
volcanic_xxx
parameters. I went ahead and added stratigraphic_unit
to the sandbox (pending live edit, together with the others). Do you have a couple of examples I could look at (i.e. the types of values that may be added to this parameter), so I can work on the Wikidata data model and also update the documentation? Cheers,
Reh
man 03:46, 1 April 2020 (UTC)
volcanic_field
and
Mount Erebus has
McMurdo Volcanic Group in volcanic_belt
but both should be moved to stratigraphic_unit
once it becomes available.
Volcano
guy 05:46, 1 April 2020 (UTC)
volcanic_arc/belt
, volcanic_arc
, volcanic_belt
, and volcanic_field
, is renamed to volcanic_region
, would contents of the new stratigraphic_unit
also fit into volcanic_region
? Or would you still prefer the separate parameter?
Reh
man 07:12, 1 April 2020 (UTC)
volcanic_field
and volcanic_belt
parameters, simply because there isn't an appropriate parameter to add them in. So yes stratigraphic_unit
and volcanic_region
would be better off as separate parameters.
Volcano
guy 18:36, 1 April 2020 (UTC)
last_eruption
, changing the label to "Last known eruption" would widen the infobox or drop text to the next line. Would it suffice mentioning it in the documentation (as is the case now)?
Reh
man 04:11, 1 April 2020 (UTC)
User:Hike395. Care to explain this and this please? These were discussed months in advance. Reh man 14:33, 17 July 2020 (UTC)
|volcanic_region=
was going to be the new parameter. Then I went back and fixed it so that when the bot changes to |volcanic_region=
, it would override the label and the data and give the desired result. Until the bot runs, the current infobox code will preserve the content/layout of the previous infobox, per our discussion of not changing the layout of the infobox. I apologize for edit summary of the first edit --- once I hit "publish changes", I couldn't go back and change the edit summary. —
hike395 (
talk) 18:21, 17 July 2020 (UTC)@
Rehman: I'm curious as to why you list coords
and range_coordinates
as duplicate parameters. coords
is intended for individual mountains while range_coordinates
is intended only for mountain ranges.
Volcano
guy 01:15, 2 April 2020 (UTC)
range_coordinates
was basically the generic coordinates parameter for the former {{
Infobox mountain range}}. When that infobox was merged in to this sometime back, the parameter was added as an additional parameter instead of merging into this infobox's coordinates parameter, while only the documentation was updated as "range coordinates".coords
and range_coordinates
are not duplicates! coords
are the coordinates of the highest peak or summit of a range, while range_coordinates
are for the centroid of the range. range_coordinates
center the range on the geohack map, are zoomed out, and appear in the title, while coords
are zoomed in to the highest peak, and are inline only (if both are supplied). This allows readers to see both a contextual map of the entire mountain range, or a detailed map of the highest peak. —
hike395 (
talk) 02:23, 2 April 2020 (UTC)
coords
makes a link under the "Highest Point" section: when you click on it, you get taken to a geohack map of
Mount Elbert. range_coordinates
makes a link under the Geography section, and when you click on it, you get taken to a zoomed-out geohack map of the entire range. The latter gets used as the title coordinates. For ranges, you want two coordinates in case the highest peak is not near the center of the range. —
hike395 (
talk) 03:02, 2 April 2020 (UTC)
coords
should be renamed to peak_coordinates
or something similar to avoid confusion?
Volcano
guy 03:39, 2 April 2020 (UTC)
coordinates
has to be a standard, in compliance with
WP:MOSINFOBOX.
Reh
man 11:45, 3 April 2020 (UTC)User:Hike395, User:Volcanoguy: I fully understand the reason for having two coordinates, but I'd like to make a suggestion. The infobox currently displays two coordinates. I'd like to change this so that it displays a single coordinate, but allows both the coordinates as it currently supports. The difference would be: Clicking on the coordinates would show a full zoomed out version of the mountain range (if range coords are added) and also has a placemark of the highest summit on the same map (if the same is provided). Thoughts? Reh man 09:37, 3 May 2020 (UTC)
@ Rehman: The parameters that you are proposing to delete are not redundant. The proposed change would affect the appearance and functionality of the infobox. Namely:
country*
, state*
, region*
, district*
, settlement*
, city*
, border*
, and part*
do not currently behave as {{
unbulleted list}}. Instead, if 5 or more entries are provided, the infobox uses {{
collapsible list}}, if fewer than 5, it uses {{
enum}} While a bot can certainly perform this logic once, future editors probably will not realize that they should be using {{
collapsible list}} for long entries in the infobox and {{
enum}} for short. By removing these parameters, we are encouraging future sprawl of the infobox.period*
and geology*
are similar, in that they use {{
enum}} for formatting. {{
enum}} is more compact than {{
unbulleted list}}. Deleting these parameters would have a similar effect as deleting the other parameters: it would encourage sprawl and non-uniformity of infoboxes.elevation_*
, prominence_*
, isolation_*
, length_*
, width_*
, area_*
, volume_*
are convenient shortcuts for editors. It seems like a shame to force future editors to use {{
convert}} when the infobox used to do the conversion for them. The current infobox code also enforces unit conversion, while future editors can use whatever units they wish (e.g, furlongs).It seems that you've proposed multiple major edits to the template at once. I'd recommend breaking the discussion and editing into three phases:
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)
city_*
) and produce the {{
collapsible list}}/{{
enum}} hybrid. This should answer
Rehman's objection to having these parameters, and make other editors (like
RedWolf) happy also. I'll do that! —
hike395 (
talk) 14:52, 30 March 2020 (UTC)
@ Rehman: I'm marking this as unresolved. I still object to removing the parameters: no new arguments have been provided to remove them. I attempted a compromise to keep the parameters, which you have rejected. We are at an impasse: I don't see a strong argument for removing the parameters. There is no consensus for removing the parameters. We must take this to WT:MOUNTAINS. Please do not "resolve" discussions where there is clearly a lack of consensus. Please do not merge: I strongly object. — hike395 ( talk) 12:58, 3 May 2020 (UTC)
@ Droll, WOSlinker, Pigsonthewing, RedWolf, Mikeblas, Bermicourt, Buaidh, and Frietjes: I had proposed to merge the following manual parameter series into a single {{ Unbulleted list}}-based parameter, as the parameters are barely used and unnecessarily clogs the template skeleton on articles.
border1
to border8
→ border
city1
to city16
→ city
country1
to country8
→ country
district1
to district9
→ district
rock
, geology1
to geology5
→ geology
period
, period1
to period4
→ age
region1
to region23
→ region
settlement1
to settlement2
→ settlement
state1
to state8
→ state
The first series (xxx1) are barely used (see above for numbers), the rest are mostly unused. Unfortunately, there's only two users active in this discussion, and we cannot come to an agreement. Hence your opinion would certainly help in consensus on the next step. Thank you, Reh man 14:45, 3 May 2020 (UTC)
purpose1
through purpose5
in the Hoover Dam example, or crew_callsign1
to crew_callsign3
in the Apollo 11 example. Again, this is considering the fact that less than 1% of articles currently even use the first in the series.
Reh
man 13:57, 4 May 2020 (UTC)
CSV | Unbulleted list | Current infobox behavior |
---|---|---|
Argentina, Bolivia, Chile, Colombia |
|
Argentina, Bolivia, Chile and Colombia |
Bogotá, Santiago, Medellín, La Paz, Cali, Quito, Pasto, Mérida, Arequipa, Mendoza, Cuenca, Cochabamba, Pereira, Ibagué, Salta, Manizales, Cúcuta, Cusco, Bucaramanga |
Rehman: could the template take a simple CSV list and output an unbulleted list? Ideally we want the formatting on articles using this template to be consistent and it is less editor friendly to direct them to use templates inside other templates. What is actually the benefit of an unbulleted list - why not use a CSV list and allow the browser to decide where to insert line breaks? — Martin ( MSGJ · talk) 07:14, 5 May 2020 (UTC)
|paramNumber=
and that you mildly prefer the existing formatting? Not sure if that's the right interpretation. —
hike395 (
talk) 05:47, 6 May 2020 (UTC)@
MSGJ: I have a clarifying question for you, Martin --- when you suggest having an editor enter a list as a CSV, and then display it as an unbulleted list, are you expecting the template (or Lua) to parse the CSV? Because, in general, that's very difficult. The list entries themselves can have commas, "and", and even quotes inside of them. Parsing editor-generated CSV is certainly beyond my skill. That's why Geobox originally used |parameterNNNN=
to enter each list entry separately. If you're going to ask editors to enter CSV, you're going to have to display it as-written.
|city=A, B, C, D, E
. The current formatting is an option that editors can choose to use.|city1=
. As an example, see the two infoboxes to the right:With numbered parameters | |
---|---|
Geography | |
Settlements | A, B and C |
With single parameter and CSV | |
---|---|
Geography | |
Settlement | A, B, C |
|city1=
. We can have two different parameters |city=
and |cities=
for manual labeling, but in my experience, editors ignore that.
glotto2 =
" over there, for example.|city3=
. The existing infobox code handles such parameters.
Rehman and
MSGJ want to remove the code that handles these parameters. I agree with you (Mikeblas) and want to keep these parameters to allow automatic formatting. I'm happy to discuss any formatting changes.|city_?\d+=
will be handled correctly. It only requires one line of code per parameter: {{#invoke:Compact list|main|city}}
. So implementation is trivially easy.Mikeblas clearly said they don't know in their first comment, but you quite literally put the words in their mouth with this response. I'd like User:Mikeblas to read the full discussion above, and independently comment their thoughts and the reasoning behind the same (even if it is "mildly"), or simply state that they don't have an opinion. To not waste time, if there is no response from Mikeblas by Sunday, I am closing this thread. Courtesy ping to User:MSGJ. Reh man 05:18, 9 May 2020 (UTC)
I had proposed doing code review, which is quite standard in open-source software development. You could write and I can review and post to the live template. But it's symmetric --- I can write, and you can review and post! I had simply proposed a daily rhythm because we are probably 12 time zones apart. I also thought it would be faster and more productive if you and I reviewed each others' code, rather than trying to get a third editor or the community involved. My original proposal was a proposal. It wasn't a "demand" (as you have characterized it). So now you're editing the live template and I'm frozen out and can't get my sandbox proposals considered or looked at. I don't understand any of the code. I can't participate in building the Wikidata fallback at all --- you previously told me not to edit the live template until we finished all of the discussions. The absolute last thing I want to do is get into an edit war on a 25,000 article template.
Do not discount the fact that you're an admin and I'm not. You've said I'm being unconstructive. You're closing discussions. These are things that admins do, right? I feel like I can't get you to listen to me, because of this asymmetry of power. You go ahead and do live edits to the template without any discussion or checking, and when I ask for feature discussions not to be closed, you start to throw deadlines around. And you still haven't explained why you get to do these things.
And when I finally reach my breaking point and bring this all up, you say it's a "waste of time". I'll refrain from expressing how I feel when I hear that. — hike395 ( talk) 10:29, 9 May 2020 (UTC)
|isolation_m=
). But I don't know how to check without testcases and spot-checking and coordination. You don't want to do code review, that's fine. It would be really nice to make sure we're not spreading bugs throughout the mountain article. If you don't want to work with me at all, could you perhaps find another template editor who can double-check to make sure that everything is being held constant and nothing is breaking? It would be nice to keep the mountain infobox tidy and bug-free. —
hike395 (
talk) 11:38, 9 May 2020 (UTC)Following this agreement (from this discussion), I believe we can now conclude with this and proceed with merging the parameters. User:Hike395, I will ping here again when the ontology is updated so that you could use HarvestTemplates before the merge is done. Cheers, Reh man 13:07, 17 May 2020 (UTC)
Update: Wikidata has a single unified parameter
located in the administrative territorial entity (P131), thus it seems like it would make more sense if the content is sourced from the most used/largest subdivision only - the state
parameters. I.e. not all of the numbered parameters. What do you think? If you're fine with that, you can go ahead and add a tracker to the state
parameters and proceed with the copying. Cheers,
Reh
man 15:21, 17 May 2020 (UTC)
state
, region
, district
, and part
into Wikidata, I very well may violate this (implicit, unchecked) constraint. One possibility is to write state
into
located in the administrative territorial entity (P131), region
and district
into
location (P276) (because they might not be administrative). What do you think of that?part
shouldn't be converted to simply subdivision4
. If you look at
the usage link that Plantdrew gave us, you'll see that sometimes part
is used to refer to a higher-level geographical region (e.g., a larger mountain range, which should be part of <range>), or sometimes a geographical sub-feature (such as a river in a mountain range). I would suggest changing part
to something like feature
. Someone (probably me) will have to go through and clean up the usage. At that point, we can copy into Wikidata (presumably using
has part(s) (P527)).listing
shouldn't be
part of (P361). These listings (like the
Munross) are not a physical object that the mountain is part of (like
ear is part of a
head). Instead, those listings are classes of mountains (for the
Munros, it's all mountains in Scotland with height over 3000'). I think
instance of (P31) would be more appropriate. What do you think? —
hike395 (
talk) 14:54, 18 May 2020 (UTC)@
Rehman: Extracting the data after parameters are flattened will be effectively impossible. I won't be able to use HarvestTemplates at all, so I'll be stuck. What's been slowing me down is that the infoboxes are very messy -- e.g., many people use |region=
to represent "state". There are hundreds of infoboxes that I need to cleanup: about 300 more that I need to check and cleanup. It's incredibly tedious and slow work. And that's just |region=
, let alone |district=
. (This, by the way, is a good reason to support using neutral parameter names like "subdivision1", as you proposed).
Is there a big rush to convert over? I really would like to save the data, if at all possible. — hike395 ( talk) 18:40, 4 June 2020 (UTC)
region
(because it's far too messy) and finish up the rest of the fields.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.
-- Reh man 16:23, 17 July 2020 (UTC)
|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?|language=
and |native_name_lang=
. But simply taking the parameter from |language=
and copying it into |native_name_lang=
won't work correctly. For example, Iinstead of "El Capitan (
Spanish)" it will produce "El Capitan". Instead, |language=XXX
might be converted to be |native_name_lang={{subst:ISO 639 code-3|XXX}}
. I'm concerned that we won't be able to easily find the errors where this fails, because there are no tracking categories involved.borders_on
instead of the current ambiguous borders
?language
, and append the corresponding language code in native_name_lang
.|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.@
Rehman: Oops, I just found another problem in the specification of the bot run. Many articles have |state_type=
, |district_type=
, |region_type=
, or |city_type=
already specified (to be correct for the country that the mountain or range lies in). As previously specified,
Plastikspork's bot would stomp on those parameters. They should be copied over to |subdivision1_type=
, etc. I went ahead and edited the BRFA. I'll keep checking --- it's quite tricky to get all of the edge cases right. —
hike395 (
talk) 07:00, 22 July 2020 (UTC)
I'm not an expert on template coding but as a user, I want templates to be simple to understand and use. In particular, I don't want to have to manually add 'convert' templates. Also I suspect the shims used to very neatly convert infoboxes from other Wikis rely on being able to point e.g. at the elevation in metres (which is what everyone bar a couple of English-speaking countries use, otherwise we wouldn't need conversion at all). What I have spotted though is that the copy and past template example in the documentation (under Standard Usage) omits several of the parameters anyway and that certainly needs fixing. Finally I would say please don't roll out major changes without giving editors a chance to view, trial and comment on the changes first. This recently happened with Template:Sfn and that caused a huge number of spurious red links and lots of angry responses. Bermicourt ( talk) 18:32, 30 March 2020 (UTC)
|data9=
in the infobox. If we delete |length_*=
, |width_*=
, or |area_*=
, we lose this nice feature. —
hike395 (
talk) 06:19, 8 April 2020 (UTC)
type:mountain
used for scaling, which is for peaks, mountain ranges, hills, submerged reefs, and seamounts
, and takes away the need of that chunk of code and complexity, and standardises all geohack maps even if length or width is not provided. For some reason, this infobox has implemented an override, which is now used by 1.3% of articles, or a maximum of 328 articles only. Is there a particular problem we are trying to solve by overriding the default?
Reh
man 04:50, 9 April 2020 (UTC)
prominence
instead of prominence_m
) via a convert template. Is that right? Do you have an example where it is not the case? If this is known/expected, then there shouldn't be any issues with {{
Infobox mountain/Berg}} when it comes to the template cleanup.
Reh
man 08:55, 3 May 2020 (UTC)
@
Rehman: I want to keep automatic conversion also. The current template calls {{
infobox dim}} to determine the zoom level of the geohack map, using any one of the |length_*=
, |width_*=
, or |area_*=
parameters. If we remove these, then the geohack map will default to be very zoomed-in, which is not appropriate for mountain ranges. I don't know of a way to extract the size of the mountain range from a free-form text field that would be in |length=
, |width=
, or |area=
. Please don't remove this feature. —
hike395 (
talk) 14:07, 19 April 2020 (UTC)
|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.|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)
peaks, mountain ranges, hills, submerged reefs, and seamounts
for type:mountain
. Are there meaningful number of instances where the default Coordinate syntax caused a bad output, and the manual override solved the issue?{{Coord|46|30|N|09|19|E|format=dms|dim:400km|display=inline,title}}
(notice dim:400km
) for those handful of rare cases, instead of taking the long-route in manually channelling the figures across a number of template/parameters (at the expense of bloating all other articles' template code)? {{ping}Rehman}} If the objection is to the size of the empty skeleton infobox, then let's discuss that and come up with a solution. One possible solution is to only use metric in the skeleton, e.g., length_km
and area_km2
. Or, if we cannot gain consensus around metric-only, use both metric and imperial.
I object to the removal of the metric/imperial parameters such as length_km
or area_mi2
for several reasons:
dim:
in coords, to replace code that is working, seems like a lot of (possibly error-prone) work for no gain.To be clear, I believe that we do not yet have consensus for this change: we are at an impasse here, also. Per WP:NOCON, please do not remove these parameters until you have a consensus for change (i.e., having some editors actively assent to this change, overriding my objection). Please do not invoke WP:SILENCE to "resolve" this. We need to hear from other editors.
I would recommend going to WT:MOUNTAINS and make separate proposals for each of the changes Rehman wishes to make. I would recommend spacing them out in time: if you overwhelm editors with many changes at once, you're not going to get a signal on what the editing consensus truly is. My overall recommendation (which I've repeated before) is --- let's just work on Wikidata integration, and then resolve this after we're done with that. I'm eagerly waiting to see Rehman's Wikidata edits. — hike395 ( talk) 14:10, 3 May 2020 (UTC)
|length_km=
, |width_mi=
, |area_km2=
. They accept numeric values and the value is automatically converted into metric/imperial, and both metric and imperial are shown.
Rehman wants to eliminate all such parameters, replacing them with single parameters, e.g., |length=
, |width=
, |area=
. These parameters already exist and are free fields. Eliminating these parameters would force editors to use {{
convert}} in the free fields.|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.elevation
, we have: elevation
(if you want to use your own formats), elevation_m
if you want to add the value in metres but want the infobox to auto-convert to feet, and elevation_ft
if you want to add the value in feet, but want the infobox to auto-convert to metres. My suggestion again is to use only one parameter for one purpose, using {{
Convert}} if necessary.width_m
), to determine the 2D size of the region, in order to zoom-out the map seen when clicking the coords. My argument to drop this manually-derived function is due to the fact that
Template:Coord#type:T already defines the scale for mountain ranges. The counter argument by Hike for that is it is still too zoomed in for the larger mountain ranges. In response to that, I pointed out to
Template:Coord#dim:D which could be used for those extremely rare cases (there are only so many ranges so large on Earth). All that aside, it is important to also note that only 0.013% of articles use this manual feature (i.e. those that has width_km
and length_km
defined).
Reh
man 04:59, 5 May 2020 (UTC)
|length_*=
or |width_*=
or |area_*=
is used. Any one of them trigger the feature. —
hike395 (
talk) 06:01, 5 May 2020 (UTC)
Even if we ignore automatic zoom, your data shows that automatic unit conversion is an incredibly popular feature. Right now, users can choose to either use {{
convert}} or to use the automatic unit conversion. Here's a table of usage of each dimensional parameter. Parameters are rows, and the columns show the number of articles that have the parameter entered in metric, imperial, or unitless (unitless = e.g., |length=
). The fraction column shows the fraction of articles where an editor has decided to use automatic conversion.
Parameter | Metric | Imperial | Unitless | Fraction of automatic conversion |
---|---|---|---|---|
elevation | 16852 | 3990 | 2500 | 89% |
prominence | 5731 | 2435 | 1082 | 88% |
length | 544 | 310 | 2 | 99.8% |
isolation | 210 | 369 | 362 | 62% |
width | 328 | 211 | 1 | 99.8% |
area | 272 | 73 | 11 | 97% |
As you can see, in vast majority of articles, editors have chosen to enter the data in a simple and uncluttered format (as a numerical value), letting the infobox do the conversion. |elevation_m=
is the fifth-most-popular parameter. Why are we getting rid of such a useful and popular feature?
The existence of these features have very low cost. The code works and has been stable for a long time. The parameters don't cost anything. If you're worried about too many parameters in the empty infobox skeleton, why not just drop the unitless parameters from the skeleton? Those are the least-used.
I think that if we dropped parameters like |elevation_m=
or |prominence_ft=
that we would be causing a lot of extra work for ourselves and mountain article editors, for essentially no gain. I think dropping the parameters would be unwise. —
hike395 (
talk) 06:52, 5 May 2020 (UTC)
|elevation_m=5678
rather than |elevation={{
convert|5678|m}}
. This system is also well used in other templates (I am somewhat familiar with
Template:Infobox river). — Martin (
MSGJ ·
talk) 07:10, 5 May 2020 (UTC)
|elevation_m=5678
with |elevation={{
convert|5678|m}}
. But to insist that all editors use the latter syntax is not reasonable, when they have grown used to convenience of the former syntax. I might also gently suggest that your insistence on this matter (and perceived intransigence) might derail some of the other great improvements that you are proposing for this template. — Martin (
MSGJ ·
talk) 11:39, 5 May 2020 (UTC)
I brought up the zoom feature in a discussion about keeping the |length_*=
, |width_*=
, and |area_*=
parameters. If we're going to keep those parameters, what policy is enforced or reader benefit is gained by removing the zoom feature?
To explain to Martin and any other editors:
|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.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)
|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.I'm sorry, Rehman, but we also need to discuss the implementation of Wikidata fallback.
In general, I'm a big fan of Wikidata fallbacks --- it allows centralized data to be shared consistently across wikis from all languages. That is a good thing. But, one issue that has come up in other Wikidata discussions: most editors do not know how or where to edit the data that comes from Wikidata. When you use default Wikidata, you should supply an editing icon that allows editors to change the field. Such an editing icon is created using the {{ EditOnWikidata}} template. Could you add this template to the infobox when Wikidata default data is used?
One more comment and a question:
|qid=
, |fetchwikidata=
, |suppressfields=
, and |onlysourced=
. Would you like to explain what they do? —
hike395 (
talk) 08:08, 30 March 2020 (UTC)|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?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)
|fetchwikidata=
, |suppressfields=
, and |onlysourced=
which you questioned earlier, were implemented. The pen icon is rather cosmetic, and can be switched anytime with a minor tweak in the code. We could keep the pen icon now, and discuss it later perhaps? The point of this discussion is to include Wikidata support, which I think is not a problem now?
Reh
man 04:59, 9 April 2020 (UTC){{#invoke:WikidataIB|getLabel}}
which doesn't allow for a pen icon widget. That widget would be super ugly, anyway, so let's just leave it out.{{#invoke:Wikidata|getImageLegend}}
is not guaranteed to return the caption for the same image that {{#invoke:WikidataIB|getValue|P18|name=photo}}
returns. That means we could be putting a caption for a different image! Let's just leave this off for now.|fetchwikidata=ALL
|onlysourced
is not set to 'false', '0' or 'no'. By default it will exclude values that are unsourced or only sourced to a Wikipedia, thus making the job of checking easier at the article level."|onlysourced=no
|onlysourced=no
and |fetchwikidata=ALL
by default), and not talking about the plan to where the future Wikidata fields come from is not OK with me. There are not that many of us active Mountain article maintainers left. If we simply opened the infobox to import all possible current future data, it would be a maintenance nightmare for us article maintainers. I've been looking for a compromise that preserves your enthusiasm for Wikidata (which I share) with upholding the core pillars of Wikipedia (
WP:RS and
WP:V). So far, we haven't reached such a compromise --- do you have any ideas?onlysourced=true
, I'm completely fine with it. I don't think you've stated that before? That is the very reason I want to keep that parameter (which you had questioned before). What I'm against in the heaps of tracking categories to manually check already existing parameters within articles. That is out of scope of this discussion. If you're happy with onlysourced
being true, I'd be happy to continue the work I started last month, on this path. Let me know.
Reh
man 05:37, 23 April 2020 (UTC)|name=
is empty, but have an en label in Wikidata.
the photo fallback category has 1318 articles with |photo=
is empty, but have at least one image in Wikidata. I've done some spot-checking and I'd love to talk about these in more detail, but it sounds like we're still disagreeing on the strategy, so let's put that discussion off for a while.|onlysourced=yes
,
below. While using |onlysourced=yes
is better, it doesn't remove the need for checking. To quote
RexxS again from
Module:WikidataIB/doc:
|onlysourced=yes
and |fetchwikidata=no
, but then we will add a lot of complexity to the infobox for essentially no gain. I don't want to go through article-by-article and check all imported wikidata. This is why I was delighted by (what I thought was) your idea of turning it on parameter-by-parameter, and only checking the articles where data was actually imported from Wikidata. That's conceptually much easier, and could gradually be done over a number of weeks.|onlysourced=yes
would be very rare in Wikidata. If we're going to go through the pain of parameter-by-parameter or article-by-article checking, we might as well keep |onlysourced=no
. Other editors may disagree with this.|onlysourced=yes
and |fetchwikidata=no
?
@
Rehman: As I'm reading the documentation and the RfC, I'm finding a lot of skepticism about widespread unchecked use of Wikidata in infoboxes. For example, the
documentation for upgrading existing infoboxes guides that Wikidata is off by default (and only gets turned on manually), and the
documentation regarding verifiability recommends against using |onlysourced=false
. If we follow this guidance, I think that the Wikidata fallback will never get used.
Instead, I'd like to propose a careful staging of the Wikidata fallback, to ensure that we're showing reliable data:
|onlysourced=true
and manually check only those?What do editors think of this plan? — hike395 ( talk) 06:14, 13 April 2020 (UTC)
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)
@
RedWolf: Back in 2016,
MSGJ added fetching |elevation=
, |prominence=
, and |isolation=
from Wikidata with these edits:
[1]. I didn't even notice these edits!
@ MSGJ: --- Rehman and I have had a lengthy discussion about adding Wikidata to the infobox, above (not realizing it was done 4 years ago). Two issues have come up: the editability and reliability of data in Wikidata. Since 2016, there are a number of tools to allow readers to edit relevant Wikidata (e.g., the pen icon supplied by {{ Wdib}}). What do you think of this? Would you like to help upgrade the infobox to use {{ Wdib}}?
@ Rehman: --- Can we pause the arguing over removing parameters, so that we can upgrade the three fields that are already importing Wikidata? I'd love to get started on this. — hike395 ( talk) 14:30, 3 May 2020 (UTC)
|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.|qid=
to force a qid. If you look at the source code
Template:Infobox mountain/testcases2, you'll see that I specified |qid=
for the test cases. Otherwise, the template uses the qid for the current page (which is empty for the testcases page), if you see what I mean. —
hike395 (
talk) 16:26, 3 May 2020 (UTC)I added elevation, prominence and elevation after proposing them in 2016. I made some further suggestions then about other Wikidata fields we could make use of in this infobox template — Martin ( MSGJ · talk) 15:58, 3 May 2020 (UTC)
|osd=no
), or import only those fields with external references (|osd=yes
). My concern about the latter is that data imported from other-language Wikipedias doesn't count as externally referenced, so there is very little Wikidata that has external references.
Rehman and I came to a conclusion that it's better to consider importing everything, but check it all (which is a lot of work). That's the tentative consensus (from two editors), but if you feel otherwise, please say something. —
hike395 (
talk) 22:34, 3 May 2020 (UTC)
I was looking at deploying Hike's sandbox2 to add the pencil links to the template, but there seem to be other changes in there which I don't fully understand, e.g. the image parameter, and the above parameter. — Martin ( MSGJ · talk) 20:23, 4 May 2020 (UTC)
|elevation=
, |prominence=
, and isolation. Sandbox2 uses {{
wdib}} and so implements the pen icon editing feature (that was requested by
RedWolf). It also adds tracking categories for these three parameters (so that we can check on the quality of the imported data). Per our discussion above, sandbox2 also imports all data for these parameters, without filtering, because that is what the current infobox is doing. You can see the results of the changes at
the testcases.Re: pen icons --- Rehman may be misremembering my previous comment. When Rehman proposed adding wikidata, I thought that wikidata would be filled with many fields that would fill in the infobox. If the fallback was activated for many fields with pen icons, it might look odd (e.g., Arecibo Observatory). I wanted to show the editors at WT:MOUNTAINS a mock-up with many pen icons. I started to work on that, but then Rehman said that Wikidata was mostly empty of mountain-related data. So I then stopped, because any such pen-filled infobox would be far in the future and I didn't want to slow down our progress. I've wanted to add pen icons since the beginning: [2]. RedWolf wants them, MSGJ wants them. Rehman didn't seem to object, before? — hike395 ( talk) 05:41, 6 May 2020 (UTC)
At this point, I'm confused about why we need to wait for all parameters to be defined and all ontologies to be worked out before adding pen icons and tracking categories for the three fields that are already being imported.
|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)
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)
@
Rehman: I just finished transferring the data for |part=
to Wikidata. I looked at what that contains: it has subfeatures of mountain ranges, such as individual peaks, subranges, or rivers. Thus, I don't think it should be renamed to |subdivision4=
, because that implies an administrative division that the range belongs to. How about just leaving it at |part=
? (You can, of course, collapse the numbered parameters to a CSV string at |part=
.)
I believe that this maps to the Wikidata property has part(s) (P527), and I exported the data to that property. — hike395 ( talk) 09:39, 28 June 2020 (UTC)
part
is "Subdivisions" (see source code). Whoever added this parameter did not document it, and hence there are now various different uses of this parameter. To make sure that the incorrect uses are not messed up, the label for that parameter will be carried forward via subdivision4_type
; so whatever it is used for, would remain valid.
Reh
man 12:53, 28 June 2020 (UTC)|parts=
parameter in addition to having a number of |subdivision=
parameters?|part=
to populate the new |parts=
parameter?|parts=
:
|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.|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.|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.|part*=
numeric arguments into a single |parts=
parameter, making it consistent with {{
Infobox settlement}} and allowing
has part(s) (P527) fallback. What do others think? —
hike395 (
talk) 05:16, 29 June 2020 (UTC)I'm just about to export the data associated with |border=
to Wikidata, but I think I may have found a better property.
Rehman's
proposal will import
shares border with (P47) into |border=
. But, the description of P47 implies that it was designed for administrative regions.
has boundary (P4777) looks like it is more general and does not enforce symmetry.
Before I export the border data, I wanted to bring this up so we're consistent across export and import. What do editors think? — hike395 ( talk) 09:57, 28 June 2020 (UTC)
In the initial proposal, Rehman suggested remove parameters for references and appending the reference to parameter value for which it was used as a source. I don't think this is a good idea. I would expect that data for elevation and coordinates should have a reference to a gazetteer somewhere in the article. From the articles I've sampled, the references in the infobox are the only places in the article where coordinates and elevation are referenced. Checking whether any reference is given is far more feasible (but still not easy (but see my comment below)) if a separate parameter for the reference is maintained. The reference parameters are fairly widely specified. 20435 articles have |coordinates=
specified, 6023 have a reference (29%). 23393 articles have an elevation specified, 9645 have a reference (41%). 976 articles have isolation specified, 640 have a reference (65%). I would guess that there are also a substantial number of articles that have a reference appended (as Rehman suggested), rather than occupying a separate parameter.
From what I've seen of Wikidata, elevation/coordinates aren't often referenced to a gazetteer, but are often imported from a Wikipedia. While pulling from Wikidata is certainly better than nothing, it isn't better than actually having a link to a gazetteer that can confirm elevation/coordinates.
I don't think there is any good reason to maintain |coordinates_note=
, |coordinates_ref=
and |coords_ref=
. These can be consolidated to a single parameter. Some of the parameters have only a *_note version and no *_ref version. *_ref parameters are far more populated than *_note, so if it desirable to have the parameters named consistently, it would take less work to standardize on _ref than _note. — Preceding
unsigned comment added by
Plantdrew (
talk •
contribs) 18:45, 7 May 2020 (UTC)
Hello. Can someone tell me what is supposed to go in isolation_parent
? It is not documented, but exists in this template, within the isolation parameter. I know it'll be a name of a mountain, but a clear definition would help. Next tallest mountain?
Reh
man 15:04, 8 May 2020 (UTC)
|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.One more. Are the parameters isolation_parent
and parent_peak
for the same thing? If not, how do they differ?
Reh
man 09:57, 13 May 2020 (UTC)
isolation_parent
is the peak that defines
Topographic isolation. parent_peak
is the peak that defines
Topographic prominence, which is a different concept. —
hike395 (
talk) 11:58, 14 May 2020 (UTC)This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | ← | Archive 3 | Archive 4 | Archive 5 | Archive 6 |
Hello. I'm attempting to amend and clean-up the template code so as to achieve the below:
range_coordinates
and range_coords
) - to be done only together with another editstate1
through state18
) which can be instead included as a UBL in a single parameter - to be done only together with another editAs 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)
Hi Plastikspork. Would you be able to assist in running your bot through articles using {{ Infobox mountain}}, to make the following changes please?
From | To |
---|---|
Duplicates | |
photo_width |
photo_size
|
coords |
coordinates
|
topo |
topo_map
|
relief |
map_relief
|
parent |
range
|
image_map |
map_image
|
coords_ref |
coordinates_ref
|
coordinates_note
| |
elevation_note |
elevation_ref
|
city_type |
settlement_type
|
Renames | |
type |
mountain_type
|
state_type |
subdivision1_type
|
region_type |
subdivision2_type
|
district_type |
subdivision3_type
|
part_type |
subdivision4_type
|
range_coordinates_note |
range_coordinates_ref
|
grid_ref_Ireland_note |
grid_ref_Ireland_ref
|
grid_ref_UK_note |
grid_ref_UK_ref
|
length_note |
length_ref
|
width_note |
width_ref
|
area_note |
area_ref
|
volume_note |
volume_ref
|
Source (in order) | Destination |
---|---|
bordering_range |
Move contents to bordering_range , in the same order.
|
border
| |
border1
| |
border2
| |
border3
| |
border4
| |
border5
| |
border6
| |
border7
| |
border8
| |
volcanic_region |
Move contents to volcanic_region , in the same order.
|
volcanic_arc/belt
| |
volcanic_arc
| |
volcanic_belt
| |
volcanic_field
| |
geology |
Move contents to geology , in the same order.
|
geology1
| |
geology2
| |
geology3
| |
geology4
| |
geology5
| |
rock
| |
age |
Move contents to age , in the same order.
|
period
| |
period1
| |
period2
| |
period3
| |
period4
| |
country |
Move contents to country , in the same order.For articles that used country1 , please append the additional parameter |country_type=Countries .
|
country1
| |
country2
| |
country3
| |
country4
| |
country5
| |
country6
| |
country7
| |
country8
| |
settlement |
Move contents to settlement , in the same order.For articles that used settlement1 or city1 , please append the additional parameter |settlement_type=Settlements .
|
settlement1
| |
settlement2
| |
city
| |
city1
| |
city2
| |
city3
| |
city4
| |
city5
| |
city6
| |
city7
| |
city8
| |
city9
| |
city10
| |
city11
| |
city12
| |
city13
| |
city14
| |
city15
| |
city16
| |
subdivision1 |
Move contents to subdivision1 , in the same order.• For articles that use state , please append the additional parameter |subdivision1_type=State .• For articles that use state1 , please append the additional parameter |subdivision1_type=States .
|
state
| |
state1
| |
state2
| |
state3
| |
state4
| |
state5
| |
state6
| |
state7
| |
state8
| |
subdivision2 |
Move contents to subdivision2 , in the same order.For articles that use region1 , please append the additional parameter |subdivision2_type=Regions .
|
region
| |
region1
| |
region2
| |
region3
| |
region4
| |
region5
| |
region6
| |
region7
| |
region8
| |
region9
| |
region10
| |
region11
| |
region12
| |
region13
| |
region14
| |
region15
| |
region16
| |
region17
| |
region18
| |
region19
| |
region20
| |
region21
| |
region22
| |
region23
| |
subdivision3 |
Move contents to subdivision3 , in the same order.For articles that use district1 , please append the additional parameter |subdivision3_type=Districts .
|
district
| |
district1
| |
district2
| |
district3
| |
district4
| |
district5
| |
district6
| |
district7
| |
district8
| |
district9
| |
subdivision4 |
Move contents to subdivision4 , in the same order.For articles that use part1 , please append the additional parameter |subdivision4_type=Subdivisions .
|
part
| |
part1
| |
part2
| |
part3
| |
part4
| |
part5
| |
part6
| |
part7
| |
part8
| |
part9
| |
part10
| |
part11
| |
part12
| |
part13
| |
part14
| |
part15
| |
part16
| |
language |
Convert the language name to it's
ISO 639-3 code and move to native_name_lang .
|
Uses of {{ Infobox mountain range}} should be changed to {{ Infobox mountain}} to avoid redirect.
I have manually fixed erroneous usages based on the previous parameter scan. Once the above changes are done, would you be able to run one final scan please?
Thank you so much! Reh man 05:34, 30 March 2020 (UTC)
I have updated the above table based on the consensus below and removed those that failed consensus. The first table lists direct hardcoded duplicate parameters and parameters that will be renamed in the backend (the displayed labels will remain the same). The second table consists of the parameters that are to be combined. If there are any questions or clarifications, please comment in the section(s) below. Once #Combining parameter series concludes, I intend to go ahead with the above. Cheers, Reh man 15:30, 17 May 2020 (UTC)
@
Rehman: The merging of volcanic_arc/belt
, volcanic_arc
, volcanic_belt
and volcanic_field
to volcanic_region
sounds like a good idea and it is something I have been thinking about for some time. There is something else I have thought about and that is
stratigraphic units. It is not uncommon for mountains made of volcanic or sedimentary rocks to be part of
groups or
formations. However, there seems to be no parameter for such features. I am not sure what the best code name would be, perhaps stratigraphic_unit
?
Volcano
guy 22:46, 31 March 2020 (UTC)
I would also like to note that last_eruption
should probably be renamed to last_known_eruption
since it is commonly used for the youngest dated eruptions using, radiocarbon, potassium-argon and other methods. There is always the possibility of there being younger eruptions that have not been dated/witnessed, especially volcanoes in remote locations.
Volcano
guy 23:37, 31 March 2020 (UTC)
volcanic_xxx
parameters. I went ahead and added stratigraphic_unit
to the sandbox (pending live edit, together with the others). Do you have a couple of examples I could look at (i.e. the types of values that may be added to this parameter), so I can work on the Wikidata data model and also update the documentation? Cheers,
Reh
man 03:46, 1 April 2020 (UTC)
volcanic_field
and
Mount Erebus has
McMurdo Volcanic Group in volcanic_belt
but both should be moved to stratigraphic_unit
once it becomes available.
Volcano
guy 05:46, 1 April 2020 (UTC)
volcanic_arc/belt
, volcanic_arc
, volcanic_belt
, and volcanic_field
, is renamed to volcanic_region
, would contents of the new stratigraphic_unit
also fit into volcanic_region
? Or would you still prefer the separate parameter?
Reh
man 07:12, 1 April 2020 (UTC)
volcanic_field
and volcanic_belt
parameters, simply because there isn't an appropriate parameter to add them in. So yes stratigraphic_unit
and volcanic_region
would be better off as separate parameters.
Volcano
guy 18:36, 1 April 2020 (UTC)
last_eruption
, changing the label to "Last known eruption" would widen the infobox or drop text to the next line. Would it suffice mentioning it in the documentation (as is the case now)?
Reh
man 04:11, 1 April 2020 (UTC)
User:Hike395. Care to explain this and this please? These were discussed months in advance. Reh man 14:33, 17 July 2020 (UTC)
|volcanic_region=
was going to be the new parameter. Then I went back and fixed it so that when the bot changes to |volcanic_region=
, it would override the label and the data and give the desired result. Until the bot runs, the current infobox code will preserve the content/layout of the previous infobox, per our discussion of not changing the layout of the infobox. I apologize for edit summary of the first edit --- once I hit "publish changes", I couldn't go back and change the edit summary. —
hike395 (
talk) 18:21, 17 July 2020 (UTC)@
Rehman: I'm curious as to why you list coords
and range_coordinates
as duplicate parameters. coords
is intended for individual mountains while range_coordinates
is intended only for mountain ranges.
Volcano
guy 01:15, 2 April 2020 (UTC)
range_coordinates
was basically the generic coordinates parameter for the former {{
Infobox mountain range}}. When that infobox was merged in to this sometime back, the parameter was added as an additional parameter instead of merging into this infobox's coordinates parameter, while only the documentation was updated as "range coordinates".coords
and range_coordinates
are not duplicates! coords
are the coordinates of the highest peak or summit of a range, while range_coordinates
are for the centroid of the range. range_coordinates
center the range on the geohack map, are zoomed out, and appear in the title, while coords
are zoomed in to the highest peak, and are inline only (if both are supplied). This allows readers to see both a contextual map of the entire mountain range, or a detailed map of the highest peak. —
hike395 (
talk) 02:23, 2 April 2020 (UTC)
coords
makes a link under the "Highest Point" section: when you click on it, you get taken to a geohack map of
Mount Elbert. range_coordinates
makes a link under the Geography section, and when you click on it, you get taken to a zoomed-out geohack map of the entire range. The latter gets used as the title coordinates. For ranges, you want two coordinates in case the highest peak is not near the center of the range. —
hike395 (
talk) 03:02, 2 April 2020 (UTC)
coords
should be renamed to peak_coordinates
or something similar to avoid confusion?
Volcano
guy 03:39, 2 April 2020 (UTC)
coordinates
has to be a standard, in compliance with
WP:MOSINFOBOX.
Reh
man 11:45, 3 April 2020 (UTC)User:Hike395, User:Volcanoguy: I fully understand the reason for having two coordinates, but I'd like to make a suggestion. The infobox currently displays two coordinates. I'd like to change this so that it displays a single coordinate, but allows both the coordinates as it currently supports. The difference would be: Clicking on the coordinates would show a full zoomed out version of the mountain range (if range coords are added) and also has a placemark of the highest summit on the same map (if the same is provided). Thoughts? Reh man 09:37, 3 May 2020 (UTC)
@ Rehman: The parameters that you are proposing to delete are not redundant. The proposed change would affect the appearance and functionality of the infobox. Namely:
country*
, state*
, region*
, district*
, settlement*
, city*
, border*
, and part*
do not currently behave as {{
unbulleted list}}. Instead, if 5 or more entries are provided, the infobox uses {{
collapsible list}}, if fewer than 5, it uses {{
enum}} While a bot can certainly perform this logic once, future editors probably will not realize that they should be using {{
collapsible list}} for long entries in the infobox and {{
enum}} for short. By removing these parameters, we are encouraging future sprawl of the infobox.period*
and geology*
are similar, in that they use {{
enum}} for formatting. {{
enum}} is more compact than {{
unbulleted list}}. Deleting these parameters would have a similar effect as deleting the other parameters: it would encourage sprawl and non-uniformity of infoboxes.elevation_*
, prominence_*
, isolation_*
, length_*
, width_*
, area_*
, volume_*
are convenient shortcuts for editors. It seems like a shame to force future editors to use {{
convert}} when the infobox used to do the conversion for them. The current infobox code also enforces unit conversion, while future editors can use whatever units they wish (e.g, furlongs).It seems that you've proposed multiple major edits to the template at once. I'd recommend breaking the discussion and editing into three phases:
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)
city_*
) and produce the {{
collapsible list}}/{{
enum}} hybrid. This should answer
Rehman's objection to having these parameters, and make other editors (like
RedWolf) happy also. I'll do that! —
hike395 (
talk) 14:52, 30 March 2020 (UTC)
@ Rehman: I'm marking this as unresolved. I still object to removing the parameters: no new arguments have been provided to remove them. I attempted a compromise to keep the parameters, which you have rejected. We are at an impasse: I don't see a strong argument for removing the parameters. There is no consensus for removing the parameters. We must take this to WT:MOUNTAINS. Please do not "resolve" discussions where there is clearly a lack of consensus. Please do not merge: I strongly object. — hike395 ( talk) 12:58, 3 May 2020 (UTC)
@ Droll, WOSlinker, Pigsonthewing, RedWolf, Mikeblas, Bermicourt, Buaidh, and Frietjes: I had proposed to merge the following manual parameter series into a single {{ Unbulleted list}}-based parameter, as the parameters are barely used and unnecessarily clogs the template skeleton on articles.
border1
to border8
→ border
city1
to city16
→ city
country1
to country8
→ country
district1
to district9
→ district
rock
, geology1
to geology5
→ geology
period
, period1
to period4
→ age
region1
to region23
→ region
settlement1
to settlement2
→ settlement
state1
to state8
→ state
The first series (xxx1) are barely used (see above for numbers), the rest are mostly unused. Unfortunately, there's only two users active in this discussion, and we cannot come to an agreement. Hence your opinion would certainly help in consensus on the next step. Thank you, Reh man 14:45, 3 May 2020 (UTC)
purpose1
through purpose5
in the Hoover Dam example, or crew_callsign1
to crew_callsign3
in the Apollo 11 example. Again, this is considering the fact that less than 1% of articles currently even use the first in the series.
Reh
man 13:57, 4 May 2020 (UTC)
CSV | Unbulleted list | Current infobox behavior |
---|---|---|
Argentina, Bolivia, Chile, Colombia |
|
Argentina, Bolivia, Chile and Colombia |
Bogotá, Santiago, Medellín, La Paz, Cali, Quito, Pasto, Mérida, Arequipa, Mendoza, Cuenca, Cochabamba, Pereira, Ibagué, Salta, Manizales, Cúcuta, Cusco, Bucaramanga |
Rehman: could the template take a simple CSV list and output an unbulleted list? Ideally we want the formatting on articles using this template to be consistent and it is less editor friendly to direct them to use templates inside other templates. What is actually the benefit of an unbulleted list - why not use a CSV list and allow the browser to decide where to insert line breaks? — Martin ( MSGJ · talk) 07:14, 5 May 2020 (UTC)
|paramNumber=
and that you mildly prefer the existing formatting? Not sure if that's the right interpretation. —
hike395 (
talk) 05:47, 6 May 2020 (UTC)@
MSGJ: I have a clarifying question for you, Martin --- when you suggest having an editor enter a list as a CSV, and then display it as an unbulleted list, are you expecting the template (or Lua) to parse the CSV? Because, in general, that's very difficult. The list entries themselves can have commas, "and", and even quotes inside of them. Parsing editor-generated CSV is certainly beyond my skill. That's why Geobox originally used |parameterNNNN=
to enter each list entry separately. If you're going to ask editors to enter CSV, you're going to have to display it as-written.
|city=A, B, C, D, E
. The current formatting is an option that editors can choose to use.|city1=
. As an example, see the two infoboxes to the right:With numbered parameters | |
---|---|
Geography | |
Settlements | A, B and C |
With single parameter and CSV | |
---|---|
Geography | |
Settlement | A, B, C |
|city1=
. We can have two different parameters |city=
and |cities=
for manual labeling, but in my experience, editors ignore that.
glotto2 =
" over there, for example.|city3=
. The existing infobox code handles such parameters.
Rehman and
MSGJ want to remove the code that handles these parameters. I agree with you (Mikeblas) and want to keep these parameters to allow automatic formatting. I'm happy to discuss any formatting changes.|city_?\d+=
will be handled correctly. It only requires one line of code per parameter: {{#invoke:Compact list|main|city}}
. So implementation is trivially easy.Mikeblas clearly said they don't know in their first comment, but you quite literally put the words in their mouth with this response. I'd like User:Mikeblas to read the full discussion above, and independently comment their thoughts and the reasoning behind the same (even if it is "mildly"), or simply state that they don't have an opinion. To not waste time, if there is no response from Mikeblas by Sunday, I am closing this thread. Courtesy ping to User:MSGJ. Reh man 05:18, 9 May 2020 (UTC)
I had proposed doing code review, which is quite standard in open-source software development. You could write and I can review and post to the live template. But it's symmetric --- I can write, and you can review and post! I had simply proposed a daily rhythm because we are probably 12 time zones apart. I also thought it would be faster and more productive if you and I reviewed each others' code, rather than trying to get a third editor or the community involved. My original proposal was a proposal. It wasn't a "demand" (as you have characterized it). So now you're editing the live template and I'm frozen out and can't get my sandbox proposals considered or looked at. I don't understand any of the code. I can't participate in building the Wikidata fallback at all --- you previously told me not to edit the live template until we finished all of the discussions. The absolute last thing I want to do is get into an edit war on a 25,000 article template.
Do not discount the fact that you're an admin and I'm not. You've said I'm being unconstructive. You're closing discussions. These are things that admins do, right? I feel like I can't get you to listen to me, because of this asymmetry of power. You go ahead and do live edits to the template without any discussion or checking, and when I ask for feature discussions not to be closed, you start to throw deadlines around. And you still haven't explained why you get to do these things.
And when I finally reach my breaking point and bring this all up, you say it's a "waste of time". I'll refrain from expressing how I feel when I hear that. — hike395 ( talk) 10:29, 9 May 2020 (UTC)
|isolation_m=
). But I don't know how to check without testcases and spot-checking and coordination. You don't want to do code review, that's fine. It would be really nice to make sure we're not spreading bugs throughout the mountain article. If you don't want to work with me at all, could you perhaps find another template editor who can double-check to make sure that everything is being held constant and nothing is breaking? It would be nice to keep the mountain infobox tidy and bug-free. —
hike395 (
talk) 11:38, 9 May 2020 (UTC)Following this agreement (from this discussion), I believe we can now conclude with this and proceed with merging the parameters. User:Hike395, I will ping here again when the ontology is updated so that you could use HarvestTemplates before the merge is done. Cheers, Reh man 13:07, 17 May 2020 (UTC)
Update: Wikidata has a single unified parameter
located in the administrative territorial entity (P131), thus it seems like it would make more sense if the content is sourced from the most used/largest subdivision only - the state
parameters. I.e. not all of the numbered parameters. What do you think? If you're fine with that, you can go ahead and add a tracker to the state
parameters and proceed with the copying. Cheers,
Reh
man 15:21, 17 May 2020 (UTC)
state
, region
, district
, and part
into Wikidata, I very well may violate this (implicit, unchecked) constraint. One possibility is to write state
into
located in the administrative territorial entity (P131), region
and district
into
location (P276) (because they might not be administrative). What do you think of that?part
shouldn't be converted to simply subdivision4
. If you look at
the usage link that Plantdrew gave us, you'll see that sometimes part
is used to refer to a higher-level geographical region (e.g., a larger mountain range, which should be part of <range>), or sometimes a geographical sub-feature (such as a river in a mountain range). I would suggest changing part
to something like feature
. Someone (probably me) will have to go through and clean up the usage. At that point, we can copy into Wikidata (presumably using
has part(s) (P527)).listing
shouldn't be
part of (P361). These listings (like the
Munross) are not a physical object that the mountain is part of (like
ear is part of a
head). Instead, those listings are classes of mountains (for the
Munros, it's all mountains in Scotland with height over 3000'). I think
instance of (P31) would be more appropriate. What do you think? —
hike395 (
talk) 14:54, 18 May 2020 (UTC)@
Rehman: Extracting the data after parameters are flattened will be effectively impossible. I won't be able to use HarvestTemplates at all, so I'll be stuck. What's been slowing me down is that the infoboxes are very messy -- e.g., many people use |region=
to represent "state". There are hundreds of infoboxes that I need to cleanup: about 300 more that I need to check and cleanup. It's incredibly tedious and slow work. And that's just |region=
, let alone |district=
. (This, by the way, is a good reason to support using neutral parameter names like "subdivision1", as you proposed).
Is there a big rush to convert over? I really would like to save the data, if at all possible. — hike395 ( talk) 18:40, 4 June 2020 (UTC)
region
(because it's far too messy) and finish up the rest of the fields.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.
-- Reh man 16:23, 17 July 2020 (UTC)
|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?|language=
and |native_name_lang=
. But simply taking the parameter from |language=
and copying it into |native_name_lang=
won't work correctly. For example, Iinstead of "El Capitan (
Spanish)" it will produce "El Capitan". Instead, |language=XXX
might be converted to be |native_name_lang={{subst:ISO 639 code-3|XXX}}
. I'm concerned that we won't be able to easily find the errors where this fails, because there are no tracking categories involved.borders_on
instead of the current ambiguous borders
?language
, and append the corresponding language code in native_name_lang
.|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.@
Rehman: Oops, I just found another problem in the specification of the bot run. Many articles have |state_type=
, |district_type=
, |region_type=
, or |city_type=
already specified (to be correct for the country that the mountain or range lies in). As previously specified,
Plastikspork's bot would stomp on those parameters. They should be copied over to |subdivision1_type=
, etc. I went ahead and edited the BRFA. I'll keep checking --- it's quite tricky to get all of the edge cases right. —
hike395 (
talk) 07:00, 22 July 2020 (UTC)
I'm not an expert on template coding but as a user, I want templates to be simple to understand and use. In particular, I don't want to have to manually add 'convert' templates. Also I suspect the shims used to very neatly convert infoboxes from other Wikis rely on being able to point e.g. at the elevation in metres (which is what everyone bar a couple of English-speaking countries use, otherwise we wouldn't need conversion at all). What I have spotted though is that the copy and past template example in the documentation (under Standard Usage) omits several of the parameters anyway and that certainly needs fixing. Finally I would say please don't roll out major changes without giving editors a chance to view, trial and comment on the changes first. This recently happened with Template:Sfn and that caused a huge number of spurious red links and lots of angry responses. Bermicourt ( talk) 18:32, 30 March 2020 (UTC)
|data9=
in the infobox. If we delete |length_*=
, |width_*=
, or |area_*=
, we lose this nice feature. —
hike395 (
talk) 06:19, 8 April 2020 (UTC)
type:mountain
used for scaling, which is for peaks, mountain ranges, hills, submerged reefs, and seamounts
, and takes away the need of that chunk of code and complexity, and standardises all geohack maps even if length or width is not provided. For some reason, this infobox has implemented an override, which is now used by 1.3% of articles, or a maximum of 328 articles only. Is there a particular problem we are trying to solve by overriding the default?
Reh
man 04:50, 9 April 2020 (UTC)
prominence
instead of prominence_m
) via a convert template. Is that right? Do you have an example where it is not the case? If this is known/expected, then there shouldn't be any issues with {{
Infobox mountain/Berg}} when it comes to the template cleanup.
Reh
man 08:55, 3 May 2020 (UTC)
@
Rehman: I want to keep automatic conversion also. The current template calls {{
infobox dim}} to determine the zoom level of the geohack map, using any one of the |length_*=
, |width_*=
, or |area_*=
parameters. If we remove these, then the geohack map will default to be very zoomed-in, which is not appropriate for mountain ranges. I don't know of a way to extract the size of the mountain range from a free-form text field that would be in |length=
, |width=
, or |area=
. Please don't remove this feature. —
hike395 (
talk) 14:07, 19 April 2020 (UTC)
|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.|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)
peaks, mountain ranges, hills, submerged reefs, and seamounts
for type:mountain
. Are there meaningful number of instances where the default Coordinate syntax caused a bad output, and the manual override solved the issue?{{Coord|46|30|N|09|19|E|format=dms|dim:400km|display=inline,title}}
(notice dim:400km
) for those handful of rare cases, instead of taking the long-route in manually channelling the figures across a number of template/parameters (at the expense of bloating all other articles' template code)? {{ping}Rehman}} If the objection is to the size of the empty skeleton infobox, then let's discuss that and come up with a solution. One possible solution is to only use metric in the skeleton, e.g., length_km
and area_km2
. Or, if we cannot gain consensus around metric-only, use both metric and imperial.
I object to the removal of the metric/imperial parameters such as length_km
or area_mi2
for several reasons:
dim:
in coords, to replace code that is working, seems like a lot of (possibly error-prone) work for no gain.To be clear, I believe that we do not yet have consensus for this change: we are at an impasse here, also. Per WP:NOCON, please do not remove these parameters until you have a consensus for change (i.e., having some editors actively assent to this change, overriding my objection). Please do not invoke WP:SILENCE to "resolve" this. We need to hear from other editors.
I would recommend going to WT:MOUNTAINS and make separate proposals for each of the changes Rehman wishes to make. I would recommend spacing them out in time: if you overwhelm editors with many changes at once, you're not going to get a signal on what the editing consensus truly is. My overall recommendation (which I've repeated before) is --- let's just work on Wikidata integration, and then resolve this after we're done with that. I'm eagerly waiting to see Rehman's Wikidata edits. — hike395 ( talk) 14:10, 3 May 2020 (UTC)
|length_km=
, |width_mi=
, |area_km2=
. They accept numeric values and the value is automatically converted into metric/imperial, and both metric and imperial are shown.
Rehman wants to eliminate all such parameters, replacing them with single parameters, e.g., |length=
, |width=
, |area=
. These parameters already exist and are free fields. Eliminating these parameters would force editors to use {{
convert}} in the free fields.|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.elevation
, we have: elevation
(if you want to use your own formats), elevation_m
if you want to add the value in metres but want the infobox to auto-convert to feet, and elevation_ft
if you want to add the value in feet, but want the infobox to auto-convert to metres. My suggestion again is to use only one parameter for one purpose, using {{
Convert}} if necessary.width_m
), to determine the 2D size of the region, in order to zoom-out the map seen when clicking the coords. My argument to drop this manually-derived function is due to the fact that
Template:Coord#type:T already defines the scale for mountain ranges. The counter argument by Hike for that is it is still too zoomed in for the larger mountain ranges. In response to that, I pointed out to
Template:Coord#dim:D which could be used for those extremely rare cases (there are only so many ranges so large on Earth). All that aside, it is important to also note that only 0.013% of articles use this manual feature (i.e. those that has width_km
and length_km
defined).
Reh
man 04:59, 5 May 2020 (UTC)
|length_*=
or |width_*=
or |area_*=
is used. Any one of them trigger the feature. —
hike395 (
talk) 06:01, 5 May 2020 (UTC)
Even if we ignore automatic zoom, your data shows that automatic unit conversion is an incredibly popular feature. Right now, users can choose to either use {{
convert}} or to use the automatic unit conversion. Here's a table of usage of each dimensional parameter. Parameters are rows, and the columns show the number of articles that have the parameter entered in metric, imperial, or unitless (unitless = e.g., |length=
). The fraction column shows the fraction of articles where an editor has decided to use automatic conversion.
Parameter | Metric | Imperial | Unitless | Fraction of automatic conversion |
---|---|---|---|---|
elevation | 16852 | 3990 | 2500 | 89% |
prominence | 5731 | 2435 | 1082 | 88% |
length | 544 | 310 | 2 | 99.8% |
isolation | 210 | 369 | 362 | 62% |
width | 328 | 211 | 1 | 99.8% |
area | 272 | 73 | 11 | 97% |
As you can see, in vast majority of articles, editors have chosen to enter the data in a simple and uncluttered format (as a numerical value), letting the infobox do the conversion. |elevation_m=
is the fifth-most-popular parameter. Why are we getting rid of such a useful and popular feature?
The existence of these features have very low cost. The code works and has been stable for a long time. The parameters don't cost anything. If you're worried about too many parameters in the empty infobox skeleton, why not just drop the unitless parameters from the skeleton? Those are the least-used.
I think that if we dropped parameters like |elevation_m=
or |prominence_ft=
that we would be causing a lot of extra work for ourselves and mountain article editors, for essentially no gain. I think dropping the parameters would be unwise. —
hike395 (
talk) 06:52, 5 May 2020 (UTC)
|elevation_m=5678
rather than |elevation={{
convert|5678|m}}
. This system is also well used in other templates (I am somewhat familiar with
Template:Infobox river). — Martin (
MSGJ ·
talk) 07:10, 5 May 2020 (UTC)
|elevation_m=5678
with |elevation={{
convert|5678|m}}
. But to insist that all editors use the latter syntax is not reasonable, when they have grown used to convenience of the former syntax. I might also gently suggest that your insistence on this matter (and perceived intransigence) might derail some of the other great improvements that you are proposing for this template. — Martin (
MSGJ ·
talk) 11:39, 5 May 2020 (UTC)
I brought up the zoom feature in a discussion about keeping the |length_*=
, |width_*=
, and |area_*=
parameters. If we're going to keep those parameters, what policy is enforced or reader benefit is gained by removing the zoom feature?
To explain to Martin and any other editors:
|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.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)
|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.I'm sorry, Rehman, but we also need to discuss the implementation of Wikidata fallback.
In general, I'm a big fan of Wikidata fallbacks --- it allows centralized data to be shared consistently across wikis from all languages. That is a good thing. But, one issue that has come up in other Wikidata discussions: most editors do not know how or where to edit the data that comes from Wikidata. When you use default Wikidata, you should supply an editing icon that allows editors to change the field. Such an editing icon is created using the {{ EditOnWikidata}} template. Could you add this template to the infobox when Wikidata default data is used?
One more comment and a question:
|qid=
, |fetchwikidata=
, |suppressfields=
, and |onlysourced=
. Would you like to explain what they do? —
hike395 (
talk) 08:08, 30 March 2020 (UTC)|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?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)
|fetchwikidata=
, |suppressfields=
, and |onlysourced=
which you questioned earlier, were implemented. The pen icon is rather cosmetic, and can be switched anytime with a minor tweak in the code. We could keep the pen icon now, and discuss it later perhaps? The point of this discussion is to include Wikidata support, which I think is not a problem now?
Reh
man 04:59, 9 April 2020 (UTC){{#invoke:WikidataIB|getLabel}}
which doesn't allow for a pen icon widget. That widget would be super ugly, anyway, so let's just leave it out.{{#invoke:Wikidata|getImageLegend}}
is not guaranteed to return the caption for the same image that {{#invoke:WikidataIB|getValue|P18|name=photo}}
returns. That means we could be putting a caption for a different image! Let's just leave this off for now.|fetchwikidata=ALL
|onlysourced
is not set to 'false', '0' or 'no'. By default it will exclude values that are unsourced or only sourced to a Wikipedia, thus making the job of checking easier at the article level."|onlysourced=no
|onlysourced=no
and |fetchwikidata=ALL
by default), and not talking about the plan to where the future Wikidata fields come from is not OK with me. There are not that many of us active Mountain article maintainers left. If we simply opened the infobox to import all possible current future data, it would be a maintenance nightmare for us article maintainers. I've been looking for a compromise that preserves your enthusiasm for Wikidata (which I share) with upholding the core pillars of Wikipedia (
WP:RS and
WP:V). So far, we haven't reached such a compromise --- do you have any ideas?onlysourced=true
, I'm completely fine with it. I don't think you've stated that before? That is the very reason I want to keep that parameter (which you had questioned before). What I'm against in the heaps of tracking categories to manually check already existing parameters within articles. That is out of scope of this discussion. If you're happy with onlysourced
being true, I'd be happy to continue the work I started last month, on this path. Let me know.
Reh
man 05:37, 23 April 2020 (UTC)|name=
is empty, but have an en label in Wikidata.
the photo fallback category has 1318 articles with |photo=
is empty, but have at least one image in Wikidata. I've done some spot-checking and I'd love to talk about these in more detail, but it sounds like we're still disagreeing on the strategy, so let's put that discussion off for a while.|onlysourced=yes
,
below. While using |onlysourced=yes
is better, it doesn't remove the need for checking. To quote
RexxS again from
Module:WikidataIB/doc:
|onlysourced=yes
and |fetchwikidata=no
, but then we will add a lot of complexity to the infobox for essentially no gain. I don't want to go through article-by-article and check all imported wikidata. This is why I was delighted by (what I thought was) your idea of turning it on parameter-by-parameter, and only checking the articles where data was actually imported from Wikidata. That's conceptually much easier, and could gradually be done over a number of weeks.|onlysourced=yes
would be very rare in Wikidata. If we're going to go through the pain of parameter-by-parameter or article-by-article checking, we might as well keep |onlysourced=no
. Other editors may disagree with this.|onlysourced=yes
and |fetchwikidata=no
?
@
Rehman: As I'm reading the documentation and the RfC, I'm finding a lot of skepticism about widespread unchecked use of Wikidata in infoboxes. For example, the
documentation for upgrading existing infoboxes guides that Wikidata is off by default (and only gets turned on manually), and the
documentation regarding verifiability recommends against using |onlysourced=false
. If we follow this guidance, I think that the Wikidata fallback will never get used.
Instead, I'd like to propose a careful staging of the Wikidata fallback, to ensure that we're showing reliable data:
|onlysourced=true
and manually check only those?What do editors think of this plan? — hike395 ( talk) 06:14, 13 April 2020 (UTC)
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)
@
RedWolf: Back in 2016,
MSGJ added fetching |elevation=
, |prominence=
, and |isolation=
from Wikidata with these edits:
[1]. I didn't even notice these edits!
@ MSGJ: --- Rehman and I have had a lengthy discussion about adding Wikidata to the infobox, above (not realizing it was done 4 years ago). Two issues have come up: the editability and reliability of data in Wikidata. Since 2016, there are a number of tools to allow readers to edit relevant Wikidata (e.g., the pen icon supplied by {{ Wdib}}). What do you think of this? Would you like to help upgrade the infobox to use {{ Wdib}}?
@ Rehman: --- Can we pause the arguing over removing parameters, so that we can upgrade the three fields that are already importing Wikidata? I'd love to get started on this. — hike395 ( talk) 14:30, 3 May 2020 (UTC)
|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.|qid=
to force a qid. If you look at the source code
Template:Infobox mountain/testcases2, you'll see that I specified |qid=
for the test cases. Otherwise, the template uses the qid for the current page (which is empty for the testcases page), if you see what I mean. —
hike395 (
talk) 16:26, 3 May 2020 (UTC)I added elevation, prominence and elevation after proposing them in 2016. I made some further suggestions then about other Wikidata fields we could make use of in this infobox template — Martin ( MSGJ · talk) 15:58, 3 May 2020 (UTC)
|osd=no
), or import only those fields with external references (|osd=yes
). My concern about the latter is that data imported from other-language Wikipedias doesn't count as externally referenced, so there is very little Wikidata that has external references.
Rehman and I came to a conclusion that it's better to consider importing everything, but check it all (which is a lot of work). That's the tentative consensus (from two editors), but if you feel otherwise, please say something. —
hike395 (
talk) 22:34, 3 May 2020 (UTC)
I was looking at deploying Hike's sandbox2 to add the pencil links to the template, but there seem to be other changes in there which I don't fully understand, e.g. the image parameter, and the above parameter. — Martin ( MSGJ · talk) 20:23, 4 May 2020 (UTC)
|elevation=
, |prominence=
, and isolation. Sandbox2 uses {{
wdib}} and so implements the pen icon editing feature (that was requested by
RedWolf). It also adds tracking categories for these three parameters (so that we can check on the quality of the imported data). Per our discussion above, sandbox2 also imports all data for these parameters, without filtering, because that is what the current infobox is doing. You can see the results of the changes at
the testcases.Re: pen icons --- Rehman may be misremembering my previous comment. When Rehman proposed adding wikidata, I thought that wikidata would be filled with many fields that would fill in the infobox. If the fallback was activated for many fields with pen icons, it might look odd (e.g., Arecibo Observatory). I wanted to show the editors at WT:MOUNTAINS a mock-up with many pen icons. I started to work on that, but then Rehman said that Wikidata was mostly empty of mountain-related data. So I then stopped, because any such pen-filled infobox would be far in the future and I didn't want to slow down our progress. I've wanted to add pen icons since the beginning: [2]. RedWolf wants them, MSGJ wants them. Rehman didn't seem to object, before? — hike395 ( talk) 05:41, 6 May 2020 (UTC)
At this point, I'm confused about why we need to wait for all parameters to be defined and all ontologies to be worked out before adding pen icons and tracking categories for the three fields that are already being imported.
|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)
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)
@
Rehman: I just finished transferring the data for |part=
to Wikidata. I looked at what that contains: it has subfeatures of mountain ranges, such as individual peaks, subranges, or rivers. Thus, I don't think it should be renamed to |subdivision4=
, because that implies an administrative division that the range belongs to. How about just leaving it at |part=
? (You can, of course, collapse the numbered parameters to a CSV string at |part=
.)
I believe that this maps to the Wikidata property has part(s) (P527), and I exported the data to that property. — hike395 ( talk) 09:39, 28 June 2020 (UTC)
part
is "Subdivisions" (see source code). Whoever added this parameter did not document it, and hence there are now various different uses of this parameter. To make sure that the incorrect uses are not messed up, the label for that parameter will be carried forward via subdivision4_type
; so whatever it is used for, would remain valid.
Reh
man 12:53, 28 June 2020 (UTC)|parts=
parameter in addition to having a number of |subdivision=
parameters?|part=
to populate the new |parts=
parameter?|parts=
:
|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.|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.|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.|part*=
numeric arguments into a single |parts=
parameter, making it consistent with {{
Infobox settlement}} and allowing
has part(s) (P527) fallback. What do others think? —
hike395 (
talk) 05:16, 29 June 2020 (UTC)I'm just about to export the data associated with |border=
to Wikidata, but I think I may have found a better property.
Rehman's
proposal will import
shares border with (P47) into |border=
. But, the description of P47 implies that it was designed for administrative regions.
has boundary (P4777) looks like it is more general and does not enforce symmetry.
Before I export the border data, I wanted to bring this up so we're consistent across export and import. What do editors think? — hike395 ( talk) 09:57, 28 June 2020 (UTC)
In the initial proposal, Rehman suggested remove parameters for references and appending the reference to parameter value for which it was used as a source. I don't think this is a good idea. I would expect that data for elevation and coordinates should have a reference to a gazetteer somewhere in the article. From the articles I've sampled, the references in the infobox are the only places in the article where coordinates and elevation are referenced. Checking whether any reference is given is far more feasible (but still not easy (but see my comment below)) if a separate parameter for the reference is maintained. The reference parameters are fairly widely specified. 20435 articles have |coordinates=
specified, 6023 have a reference (29%). 23393 articles have an elevation specified, 9645 have a reference (41%). 976 articles have isolation specified, 640 have a reference (65%). I would guess that there are also a substantial number of articles that have a reference appended (as Rehman suggested), rather than occupying a separate parameter.
From what I've seen of Wikidata, elevation/coordinates aren't often referenced to a gazetteer, but are often imported from a Wikipedia. While pulling from Wikidata is certainly better than nothing, it isn't better than actually having a link to a gazetteer that can confirm elevation/coordinates.
I don't think there is any good reason to maintain |coordinates_note=
, |coordinates_ref=
and |coords_ref=
. These can be consolidated to a single parameter. Some of the parameters have only a *_note version and no *_ref version. *_ref parameters are far more populated than *_note, so if it desirable to have the parameters named consistently, it would take less work to standardize on _ref than _note. — Preceding
unsigned comment added by
Plantdrew (
talk •
contribs) 18:45, 7 May 2020 (UTC)
Hello. Can someone tell me what is supposed to go in isolation_parent
? It is not documented, but exists in this template, within the isolation parameter. I know it'll be a name of a mountain, but a clear definition would help. Next tallest mountain?
Reh
man 15:04, 8 May 2020 (UTC)
|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.One more. Are the parameters isolation_parent
and parent_peak
for the same thing? If not, how do they differ?
Reh
man 09:57, 13 May 2020 (UTC)
isolation_parent
is the peak that defines
Topographic isolation. parent_peak
is the peak that defines
Topographic prominence, which is a different concept. —
hike395 (
talk) 11:58, 14 May 2020 (UTC)