Template talk:Infobox seamount

Proposed change to layout
Discussion at WT:WikiProject_Seamounts. —hike395 (talk) 05:33, 16 May 2010 (UTC)

template name
Shouldn't this be Infobox seamount? --Stepheng3 (talk) 18:40, 15 August 2010 (UTC)

Latest edits?
Could you explain your latest edits? I'm not sure why module is named the way it is, nor what it's supposed to do. I'm also curious why the width of the infobox needs to change from article to article? —hike395 (talk) 10:12, 15 February 2019 (UTC)
 * At Featured article candidates/Allison Guyot/archive1, it was suggested that the location map should be moved into the infobox as a surrogate for an image. In other infoboxes, such as Infobox person we include other templates using the module parameter, and I saw no reason for using a different parameter name in this case. As far as I know, it was originally called 'module' because the included templates were often a kind of module (things like the player for audio clips).
 * The default width of location map is noticeably less than the default size of this infobox – actually one is in pixels and the other in ems. So to make a visually pleasing fit, I wanted to give editors the option of either narrowing this infobox or widening the location map. At present, the infobox at Allison Guyot is using the latter option, but I would have thought that allowing editors the flexibility would be an improvement. Does that help? --RexxS (talk) 11:28, 15 February 2019 (UTC)
 * The default width of location map is noticeably less than the default size of this infobox – actually one is in pixels and the other in ems. So to make a visually pleasing fit, I wanted to give editors the option of either narrowing this infobox or widening the location map. At present, the infobox at Allison Guyot is using the latter option, but I would have thought that allowing editors the flexibility would be an improvement. Does that help? --RexxS (talk) 11:28, 15 February 2019 (UTC)


 * Thanks for explaining.
 * For geographic infoboxes, e.g., Infobox protected area, Infobox waterfall, Infobox mountain, or Infobox mountain pass, use a standard set of parameters, like map to get parameters for Location map. The infobox calls Location map itself: each infobox exposes a set of parameters to control the look of the map. Would you mind if I updated Infobox seamount to match the other infoboxes? I will gladly change Allison Guyot to use those parameters.
 * Later --- I'm starting to work on a version that is consistent with other geographic infoboxes. I notice that map is already taken to mean an image map (which is probably more common for seamounts). In this case, like in Infobox river, the parameter is called pushpin_map. Not the nicest name, but we may need to bow to consistency. —hike395 (talk) 16:29, 15 February 2019 (UTC)
 * As for the width of the infobox in Allison Guyot: I don't see where boxwidth is used? I would prefer to control the width of the infobox within the template. Usually geographic infoboxes control their own width, for consistency and to prevent inexperienced editors from squeezing the text of the article. The width of the map and photographs are limited. Since you're not using boxwidth in Allison Guyot, may I remove the parameter?
 * Thanks for working on Allison Guyot! —hike395 (talk) 15:02, 15 February 2019 (UTC)

Unfortunately, the documentation of this template gives no indication of how location map can be called from this template. I can't see how it will work from inspecting Module:Infobox, so I have to ask if you're sure that you can display it using the  parameter? Perhaps you can use this demo infobox to show how it's done before editing a Featured Article candidate.

If an editor supplies a location map using its default width (i.e. omits the  parameter), then they get a wide left margin on the map. That will be similar for any other embedded modules that don't have the same default width as Template:Infobox seamount. In addition, you'll see mismatches in different skins between any embedded object whose width is in pixels and this template, which has a default width of 23.5em. Although it is generally best practice to set sizes in ems, the exception comes when you are trying to match sizes with elements that are specified in pixels (like images). In order to overcome these sort of problems, I recommend that you retain the option of allowing this infobox to have its width set on a per-article basis. I understand your desire to lock-down templates against unwarranted changes, but unfortunately an infobox width needs flexibility in the units used as well as the values. --RexxS (talk) 17:48, 15 February 2019 (UTC)


 * I've modified the sandbox to add pushpin_map, and have also added a test case for Allison Guyot, reproduced here:

As you might see, calling Location map from inside the infobox produces a nicely centered map, with no need to set the width of the infobox. This is consistent with the behavior of the other geographic infoboxes --= I've not encountered an off-center map, even though the map or photo widths are specified in px and the infobox width is specified in em. I suspect that the problem you're encountering is due some subtle order of evaluation of the templates.

The pushpin_map seems to work well --- I think it's ok to promote the sandbox to the main template. What do you think? —hike395 (talk) 21:26, 15 February 2019 (UTC)


 * That's works fine, although – as you can see –  with the map at default size, the infobox is widened from 255px to 270px with the map present. That does contradict any argument for consistent size for the infobox. You only should supply coordinates once in the example. The right shift of a module happens because it uses a |dataN field in Infobox which is the right-hand cell of a table. Of course it could be wrapped in a div and centred, but your approach of using an image field (which is centred by default) works just as well.
 * My only objection to the sandbox version is the overcomplication used to support unnecessary parameters. All capitalised parameters are deprecated in all infoboxes and have been for years. See Manual of Style/Infoboxes : "Parameter names should use lower-case unless they are proper nouns."; and " Infoboxes using geographical coordinates should use coordinates as the parameter name, with the coord template in the parameter's value." Sorry, but the current sandbox is a step backward in compliance with MOS. --RexxS (talk) 22:14, 15 February 2019 (UTC)
 * Re: MOS ---As I was editing the sandbox, I found using maintaining the old parameter names to be annoying. In order not to break articles using old parameters, I was planning to perform the following steps:
 * Remove the capitalized parameters from the parameter name checking. I can also remove coord, per your suggestion.
 * Copy the sandbox version to the main template
 * Let the template propagate and fill the "incorrect parameter" category, while not affecting the content of the seamount articles
 * Run WP:AWB to replace the deprecated parameter names
 * Delete the deprecated parameters from the template.
 * If there's a problem with this, let me know.
 * Re: consistent infobox size -- I wasn't claiming that all instances of this infobox should be the same width. I wanted to avoid having inexperienced editors (or vandals) put odd widths into the infobox and squash the article text. The widths of the map and the photo are both limited (in px). I don't know an easy way to limit the CSS widths provided to boxwidth, because it can take so many forms (some of which are context-dependent, like "25%"). We can bring this up at WT:WikiProject Mountains and see if other editors have opinions/suggestions. —hike395 (talk) 22:40, 15 February 2019 (UTC)
 * Sorry I wasn't clearer: I don't have a problem with the infobox changing size slightly, and you've sensibly set a maximum width for the embedded location map. If you think it's a good idea to set a maximum size for an infobox (and I would agree with you!), then that would best be implemented by a max-width parameter in Infobox, which would limit the width no matter how that's specified. But that's a crusade for another day.
 * As for your workflow for removing deprecated parameters, you've got that right. I recently did a similar job for Infobox medical condition (new), and I think that this template should be relatively easy to clean. You can get a idea of the size of the problem with an insource search: I just ran an example search on, which shows 132 articles with capitalised Name. Let me know if you run into any problems. Cheers --RexxS (talk) 23:22, 15 February 2019 (UTC)
 * As for your workflow for removing deprecated parameters, you've got that right. I recently did a similar job for Infobox medical condition (new), and I think that this template should be relatively easy to clean. You can get a idea of the size of the problem with an insource search: I just ran an example search on, which shows 132 articles with capitalised Name. Let me know if you run into any problems. Cheers --RexxS (talk) 23:22, 15 February 2019 (UTC)

|mapframe=no parameter undocumented
Where does one have to edit the template so that it doesn't throw an "undocumented parameter" error when using |mapframe=no? Such as on Protector Shoal. Putting an edit request here since I know nothing about this particular bit of template formatting. Jo-Jo Eumerus (talk) 07:51, 22 November 2023 (UTC)
 * ✅ – Jonesey95 (talk) 15:37, 22 November 2023 (UTC)

Getting maplink to show inside the infobox?
Related to 's question above, in Protector Shoal, how do we get the maplink to show inside the infobox, like it does in the example on Template:Infobox seamount? RoySmith (talk) 15:47, 22 November 2023 (UTC)
 * You set yes and set other parameters (that I see are undocumented). I updated Protector Shoal and will update the doc page. — hike395 (talk) 17:37, 22 November 2023 (UTC)
 * I found that the implementation of mapframe was somewhat broken, so I fixed it so that mapframe is on by default unless map or pushpin_map are present. You would get mapframe for Protector Shoal by default. — hike395 (talk) 20:03, 22 November 2023 (UTC)