Jump to content

Template talk:Infobox landform

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:Infobox cape)

Documentation is messed up

[edit]

Lots of missing parameters and old parameters in the documentation. I'm trying to clean out Category:Pages using infobox landform with unknown parameters (0)... Anyone willing to help me out by updating the documentation? --Zackmann (Talk to me/What I been doing) 09:22, 15 October 2025 (UTC)[reply]


Maps 2026

[edit]
This infobox has a very poor and buggy implementation of OSM maps. Can someone with template editing rights copy over all the mapping current code in {{infobox mountain}} which will sort. You can not even turn off the osm map. ChaseKiwi (talk) 23:46, 2 January 2026 (UTC)[reply]
In what way is it buggy? This template calls the same module as {{Infobox mountain}}, so I'm not sure why this one would be buggy and the other one wouldn't be. You can turn off the OSM map for an article using |mapframe=off. — hike395 (talk) 04:05, 3 January 2026 (UTC)[reply]
mapframe is not a recognised parameter. None of the other standard additional parameters in the template documentation work either. For example zoom adjustments can not be made. ChaseKiwi (talk) 05:10, 3 January 2026 (UTC)[reply]
@Zackmann08 and Joy: I'm not sure I understand what's going on. Joy and Zackmann have been successfully adding mapframe to hundreds of templates: perhaps they can figure this out? — hike395 (talk) 05:13, 3 January 2026 (UTC)[reply]
User:ChaseKiwi can you give me a sample page where you are seeing this issue? Consulting the template code, I don't see any issues. You might be calling it wrong? Give me a page link and I'll help ya out! (Thanks for the ping hike395!) Zackmann (Talk to me/What I been doing) 05:21, 3 January 2026 (UTC)[reply]
I had a look and I don't see any major difference between the implementations.
What are you specifically trying to do that is not working, can you give a more concrete example where it's failing?
As it happens, I recently converted Cape Horn and another few articles to use this, and I happened to actually test the mapframe options, and they behaved as they do elsewhere.
We recently had a bug report about a change in mapframe defaults where it effectively makes mapframe-wikidata=yes the default when no coordinates are specified in the article. Maybe you're hitting that case? --Joy (talk) 10:38, 3 January 2026 (UTC)[reply]
The issue has been resolved for me in the last 6 hours but definitely existed. If no one else found problems or changed the template configuration files it may have been a local browser cache issue. ChaseKiwi (talk) 11:40, 3 January 2026 (UTC)[reply]
If all is resolved then awesome! If you find any issues in the future, feel free to drop a message in my talk page and I'll help if I can! Zackmann (Talk to me/What I been doing) 16:24, 3 January 2026 (UTC)[reply]
Will do as OSM map improvement has come on leaps and bounds for wikipedia last year thanks to good work of yourself and others. Have a good new year. ChaseKiwi (talk) 09:11, 4 January 2026 (UTC)[reply]

Map zoom level from coordinates

[edit]

I noticed today that the map on Larsen Ice Shelf shows up very zoomed in, to the point where it appears blank. I tried tweaking the "scale" field on the "coord" argument to various different levels on my Sandbox, and it didn't seem to change the infobox map appearance at all. Is this a bug, or am I doing something wrong?

StereoFolic (talk) 22:10, 4 January 2026 (UTC)[reply]

The mapframe map doesn't parse the coordinates. You have to give it a hint: if you use |area_total_sq_mi= instead of |area=, it understands how large the landform is and (usually) sets the zoom appropriately. If you want to apply a zoom manually, you apply it via |mapframe-zoom= (using OSM zoom levels). I went ahead and fixed Larsen Ice Shelf. — hike395 (talk) 01:51, 5 January 2026 (UTC)[reply]
Ah got it, thank you! StereoFolic (talk) 05:41, 5 January 2026 (UTC)[reply]

Elevation parameters

[edit]

I think the elevation parameters in this infobox should be organized better than they currently are. Perhaps the "highest XXXX" parameters could be organized like those in the "Dimensions" section. Volcanoguy 03:43, 20 February 2026 (UTC)[reply]

@Hike395: what are your views on this? The "highest XXXX" parameters could be reorganized into a "Highest point" section like in {{Infobox mountain}}. Volcanoguy 19:15, 23 February 2026 (UTC)[reply]
27 days in and no response... Volcanoguy 00:16, 19 March 2026 (UTC)[reply]
I missed this ping while on wikibreak, then got distracted by the discussion (below).
We could make a "highest point" section as in {{Infobox mountain}}, but this infobox is a "catch-all" and is used for many types of landforms. Do we know that most of those kinds of landforms have sensible "highest points"? For example, {{Infobox beach}} and {{Infobox geologic feature}} redirect here. Does it make sense to make a "highest point" section for those? — hike395 (talk) 04:23, 19 March 2026 (UTC)[reply]
@Hike395: This infobox already has |elevation= so that parameter can be used if the highest point of a landform is not known. Landforms like plateaus and plains can definitely have "highest points". For example, Mount Edziza is the highest point of the Big Raven Plateau. Volcanoguy 16:26, 19 March 2026 (UTC)[reply]
|highest_point= and |highest_elevation= already exist in this infobox, although it seems |highest_coords= was either removed or forgotten to be included since it is listed in the infobox's doc. What I'm simply requesting is for these parameters to be arranged better so when they are used the layout is less cluttered, not to mention they cause other parameters in the infobox to break. I'm not sure what the best layout would be for {{Infobox landform}}, but if we use the same layout as that of "Dimensions", it would look something like this:
Highest point
  • Location
  • Elevation
  • Coordinates
There's probably a better word to use than "Location" but I can't think of one right now. Volcanoguy 18:56, 19 March 2026 (UTC)[reply]

Deprecating photo param in favor of image

[edit]

This Infobox is one of the few infoboxes that uses |photo= instead of the far more popular |image=. I am going to start the process of deprecating the use of |photo= in favor of the more common |image=. If anyone has any questions or concerns about this, let me know! Zackmann (Talk to me/What I been doing) 19:20, 22 February 2026 (UTC)[reply]

As part of this I will also be deprecating and cleaning up other parameters. For the full list see this diff. (@Gonnym: this should make you happy ). Zackmann (Talk to me/What I been doing) 19:36, 22 February 2026 (UTC)[reply]
Thanks for cleaning this one up, good to get rid of some of this stuff finally! One other parameter I wonder about is |water=, which in theory is supposed to change the banner from tan to blue for water-based landforms but from what I've seen doesn't actually change anything. Ideally I think it'd actually work as intended, but if that's no longer possible then maybe we need to look at removing it instead? Turnagra (talk) 07:47, 27 February 2026 (UTC)[reply]
I am not happy that from proposal (on 22 Feb) through finished implementation and removal of parameters (on 26 Feb) took only 4 days. I was on wikibreak and didn't even see this.
I would like to bring up |photo_width= vs |image_size=. While I am neutral about |image= vs |photo= (being a WP:COSMETIC edit), I think |image_width= is much friendlier and more descriptive than |image_size=, and would have proposed it if editing had proceeded on a more reasonable pace.
What do other editors think of allowing |image_width= and (slowly, carefully) deprecating |image_size=? — hike395 (talk) 21:45, 28 February 2026 (UTC)[reply]
I have already addressed the concerns about my poor behavior with plowing ahead too quickly on this here... So won't repeat that here.
Regarding the issue at hand of |image_size= vs |image_width= I will just say that my reasoning behind that was that the former is much more widely used and therefore (IMHO) the more standard parameter used by some of the most widely used Infoboxes on the English wiki, including {{Infobox settlement}}, {{Infobox person}} and {{Infobox officeholder}}. I felt it most appropriate to try to keep things consistent.
See these search results for a comparison:
Now that is not to say that every Infobox has to be the same... But part of the issue I am trying to address is making it so that people who are accustomed to using one parameter name don't have to adjust when using a different template. Obviously every template is different, but if numerous templates have a parameter that does the same thing (in this case determine the size/width of the image displayed), it seems logical to try to keep those parameters consistent wherever possible. Zackmann (Talk to me/What I been doing) 00:17, 1 March 2026 (UTC)[reply]
Consistency is good, but it isn't clear to me that the template editors thought about what would make friendly parameter names. I suspect they just copy-pasted from template to template. Now that you're cleaning up all of the parameters, can we consider a friendlier name? What do other editors think? — hike395 (talk) 03:47, 1 March 2026 (UTC)[reply]
So that is totally valid. My concern is that this an enormous uphill battle. While I don't necessarily disagree that |image_width= might be a better choice, the number of pages that would need this edit to unify the code is ENORMOUS compared to the changes required to get unified use of |image_size=. Talking on the order of over a million uses of |image_size= vs a few thousand of |image_width=. Zackmann (Talk to me/What I been doing) 03:53, 1 March 2026 (UTC)[reply]
Oh, sorry. I wasn't proposing changing all uses of |image_size=. Fundamentally, parameter names are WP:COSMETIC, and running a huge bot job to change them would fall under WP:COSMETICBOT --- the bot policy says that such edits are not worth the time to review. I was proposing that we keep "width" for both {{Infobox mountain}} and {{Infobox landform}} and not change them. (That's why I was sad when you changed things so rapidly --- changing {{Infobox landform}} to use "width" now via a bot or mass edit would be considered a WP:COSMETICREVERT, so we're stuck with the undiscussed new names, unless there is a consensus to revert. That's why I keep asking for more editor opinions). — hike395 (talk) 10:13, 1 March 2026 (UTC)[reply]
To be clear, not moving forward here until consensus is reached. My point is that if we are trying to get things consistent, why not go with the parameter name that is most widely used? You seem to agree that changing all uses of |image_size= would not be a good approach... So if we want to make things consistent across infoboxes, it would see that the best solution is to change the few uses of |image_width= that remain to |image_size=. Zackmann (Talk to me/What I been doing) 16:24, 1 March 2026 (UTC)[reply]
Per MOS:IMAGESIZE, |upright=scaling factor is preferred when it is desired to present an image at other than the default width. I don't see the point of trying to standardize on either size/width for scaling images by a fixed number of pixels, when scaling images by pixels is not preferred over scaling by an upright factor.
|image_upright= is less certainly friendly than either width or size, but it should be pretty rare to need to rescale images from the default display size (250px raised from 220px a few years ago)
I've worked on replacing |image_width= with |image_upright= in the taxobox family of templates, and in many cases the width value was the default value (220px at the time), or was so little different from the default (224px) to make no practical difference. In cases where there was a practical difference, it usually didn't seem to me to be an improvement over the default value.
With taxoboxes, almost all uses of |image_width= were either pointless or ill-considered, and had not been reviewed since default display size was changed. I would expect the situation to be similar with other infoboxes using image scaling by pixel count. Plantdrew (talk) 22:19, 1 March 2026 (UTC)[reply]
You make a good point about the preference for |upright= (which, itself, is a terrible name that we likely cannot change). But I would claim that make "size" even more confusing --- "size" could be confused for a scaling factor, or a width, or widthxheight. Now I don't think we're going to get a consensus to change Template:Infobox landform at this point, so per WP:COSMETICREVERT, I'll give up. But Template:Infobox mountain hasn't changed yet and the way I read WP:COSMETICBOT is that any bot run to change parameter names needs a positive consensus. I don't think we have a positive consensus to remove |image_width=? — hike395 (talk) 03:50, 2 March 2026 (UTC)[reply]
The thing is we are not just changing this one parameter but deprecating over a dozen parameters. hike395, I think you and I are in agreement about replacing |photo...= with |image...=. The only hangup seems to be the width vs size issue.
How about this as a compromise:
  • |photo_size= → |image_size=
  • |photo_width= → |image_width=
At least that way we get rid of the |photo...= situation?
Are there any other params of concern for you that I have currently listed as deprecated on {{Infobox mountain}}? Zackmann (Talk to me/What I been doing) 04:08, 2 March 2026 (UTC)[reply]
Yes, let's convert |photo_width= → |image_width=, and not convert |map_width=. Everything else I'm neutral on. Maybe we should move the discussion back there? — hike395 (talk) 09:53, 2 March 2026 (UTC)[reply]
Support the above! Zackmann (Talk to me/What I been doing) 14:51, 2 March 2026 (UTC)[reply]
@Hike395: just want to double check, are good now? Any further concerns or can we move forward with the current set of deprecated params? Just want to make sure we are in the same page. Zackmann (Talk to me/What I been doing) 05:48, 4 March 2026 (UTC)[reply]

Yes, everything is ok. — hike395 (talk) 04:23, 19 March 2026 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_landform&oldid=1347276352"