Template talk:Infobox body of water/Archive 3

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.

For reservoirs, it would be helpful to have a field available to add the name of the dam (I'd use "dam_name). -- User:Docu — Preceding unsigned comment added by Docu (talk • contribs) 19:16, 14 March 2009 (UTC)

{{Infobox body of water
| lake_name         = example one
| image_lake        = 
| caption_lake      = 
| image_bathymetry  = 
| caption_bathymetry= 
| location          = 
| coords            = {{coord|89|59|59|N|179|59|59|W|region:ZZ_type:waterbody|display=inline,title}}
| type              = 
| inflow            = 
| outflow           = 
| catchment         = 345
| basin_countries   = 
| length            = 1,234
| width             = 1,234
| area              = 134
| depth             = 12
| max-depth         = 34
| volume            = 234
| residence_time    = 
| shore             = 234
| elevation         = 234
| frozen            = 
| residence_time    = 6456
| islands           = 
| cities            = 
| reference         =
}}
{{Infobox body of water
| lake_name         = example two
| image_lake        = 
| caption_lake      = 
| image_bathymetry  = 
| caption_bathymetry= 
| location          = 
| coords            = {{coord|89|59|59|N|179|59|59|W|region:ZZ_type:waterbody|display=inline,title}}
| type              = 
| inflow            = 
| outflow           = 
| units             = US
| catchment         = 345
| basin_countries   = 
| length            = 1234
| width             = 1234
| area              = {{convert|134|acre|abbr=on}}
| depth             = 12
| max-depth         = 34
| volume            = 234
| residence_time    = 
| shore             = 234
| elevation         = 234
| frozen            = 
| residence_time    = 1
| islands           = 
| cities            = 
| reference         =
}}

More than just an interesting idea, autoconversion makes infoboxes a whole lot easier to use and can also help create a standardised look. Many infoboxes use autoconversion. I can't really think of anything wrong with autoconversion so I'm unsure as to why my addition of this feature was reverted. JIMp _talk·cont 10:33, 14 March 2009 (UTC)

The main problem is that it adds 34 additional fields to the infobox. If you don't use them yourself, there will be just 238,000 empty elements someone else needs to check (I'm doing it for many existing ones).

Do you plan to use or check the fields or convert the current elements to these new fields? How would you go about it? -- User:Docu

I'm not quite sure I follow. If the new fields are left empty, then the template would work just as it did without them. So what exactly do we need to check? (This question is a "Please fill me in." question not a challenge: I really don't know.) I was thinking that people could change over to the new parameters ... or not ... at their convenience. Am I missing something? I have never read anything to suggest that empty fields are a problem. JIMp _talk·cont 16:44, 15 March 2009 (UTC)

If you don't plan to use them, it's preferable to use the existing fields. Every additional field just complicates maintenance. You don't have to do any maintenance on infoboxes yourself, but it would be helpful to consider those who do. -- User:Docu

Yes, it complicates maintenance but I'd suggest that this complication here is more than balanced out by the simplification on the other end but, yes, only if the new capacity is used. I have used them, though, and was planning to use them again (which is why I'm back wondering what had been done with them). I will be using them if you allow me to put them back in. JIMp _talk·cont 08:05, 16 March 2009 (UTC)

How many lake articles do you intend to create? -- User:Docu

I'm more of a tidier up than a creator and I've been running across a number lake articles lately but I don't intend these parameters to be for my use only, I'd been hoping to make things easier for everyone. JIMp _talk·cont 00:03, 17 March 2009 (UTC)

A way to facilitate things could be a template that includes a default unit for the fields, applicable if the field is numeric, similar to other versions of this infobox (e.g. on it, de, fr). People could still enter another unit to which one would add {{convert}}. -- User:Docu

How about the version in the sandbox? It tests whether the input is numeric and if so converts it. If the input is not numeric it returns it as is. Only one new parameter need be added: a {{{units}}} parameter which will change the conversion from metric→imperial/US to imperial/US→metric. JIMp _talk·cont 12:05, 20 March 2009 (UTC)

I like it. It's concise and easy to use if one fills in all values at once.

As there are multiple contributors and generally not all information is available at once, it's probably risky to allow "unit" to change the values in the other fields. Imagine the difficulties we will have to trace that someone just changed "SI" to "US". Thus it's probably preferable to use only the one version (SI). -- User:Docu

Of course, this would mean the autoconversion can only go one way—not so good when we've got a US lake (i.e. with US customary units as primary). I've been giving this some thought and have come up with a few different ideas.

• Introduce a {{{country}}} parameter which would work like {{{units}}} changing the direction of the conversion if the country is USA & would also display as part of the location. This is probably not such a great solution bring much of the risk of the {{{units}}} it replaces and bring along a bunch of its own cumbersomeness too.
• Reintroduce {{{length_mi}}}, {{{depth_ft}}}, etc. but only for the imperial/US units metric to imperial/US simply uses the plain parameters. This brings back much of the original problem of the introduction of many extra parameters (only half as many). Also the asymmetry may be a cause of strife with editors wondering why {{{length_km}}} gives them nothing.
• Introduce {{{length_unit}}}, {{{depth_unit}}}, etc. to change from metric to imperial/US on a measurement by measurement basis. This is the solution that I'd favour, however, we are again adding a number of extra parameters.
• Settle for one-way-only conversions & recommend using {{convert}} within the template call for conversions. This is the least risky, easiest to maintain and least cluttered but this is no solution.

So there are a few thoughts. For the time being, though, let's go with the last idea (which I think we can both agree is an improvement). There's the updated version in the sandbox. JIMp _talk·cont 09:31, 28 March 2009 (UTC)

I like the last idea. I added two tests to the collection (

#Champagne Pool

).

Volume in the format "10,000" doesn't appear to convert, possibly it shouldn't. I'm hesitating about the units to use for volume, but m3 is probably suitable (the three languages listed above use each a different one). As all other fields have units, residence time should probably also have a default one (years), even if it needn't convert. For area and volume, is there a way to link to the order of magnitude page? -- User:Docu

No, "10,000" won't convert but that can be fixed. I can see the sense of the cubic kilometre but get the impression that the cubic metre would be the more common unit in English (except in Australia where we might use the megalitre), however, millions of cubic metres would make sense if we're up for numbers in engineering notation. Yes, a link to the order of magnitude page should be possible if we want it ... are we really still encouraging this? JIMp _talk·cont 08:12, 31 March 2009 (UTC)

Okay, it's done.

• "10,000" works.
• Residence time defaults to years.
• Area and volume link to the order of magnitude pages.

JIMp _talk·cont 12:12, 31 March 2009 (UTC)

Excellent! I will check how to convert the metric infoboxes to the new format. -- User:Docu

When cleaning up infoboxes, I often found values using "," instead of ".", frequent in other localizations. Except for volume, I think it would be risky to accept entries with commas and convert these automatically, especially since 2,34 can become 234. -- User:Docu

Yes, I've seen that too. I could get rid of the step which unformats the dates numbers (volume could be spared). JIMp _talk·cont 07:22, 2 April 2009 (UTC)

Let's spare volume, at least, if we keep it in cubic meters. -- User:Docu

Done. JIMp _talk·cont 08:42, 2 April 2009 (UTC) ... How about some sort of error message when comma laden numbers are input? JIMp _talk·cont 08:50, 2 April 2009 (UTC)

The recent version works fine. If you feel like adding an error message, ok for me. -- User:Docu

Please suggest any new fields here. -- User:Docu at 22:37, 9 August 2009 (UTC)

Please provide reference to a policy requiring such action. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:44, 9 August 2009 (UTC)

After mulling this over, I have decided to release the protection for now, as the protection was requested, rather inappropriately, in the middle of a dispute. That doesn't mean it's free to war over; I will protect it if that occurs. Discussion should continue, however. PeterSymonds (talk) 23:13, 9 August 2009 (UTC)

Thanks. I tried, but have had no response, in two weeks. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:15, 23 August 2009 (UTC)

In the absence of a proposal, there isn't really much we can discuss. Anyways, I don't think the field "flooded" is needed. -- User:Docu at 00:18, 24 August 2009 (UTC)

In the absence of any support, I removed it. The date built field was suggested earlier (discussion archived prematurely) -- User:Docu at 11:01, 21 September 2009 (UTC)

Reverted. There is no requirement for support to be voiced; and yours is the only opposition. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:42, 21 September 2009 (UTC)

There is no consensus for your addition. Please refrain from disrupting this part of the project too. -- User:Docu at 11:54, 21 September 2009 (UTC)

Me disrupting? It is you who is now edit warring over this. Your abusive call to protect the page in the midst of a content dispute has already been overturned by another admin. The only evidence of "lack of consensus" is your absurd behaviour. This has been raised at the project talk page, with no dissent. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:41, 21 September 2009 (UTC)

As the dissent was raised here and we don't agree on the addition of the second field, it was removed. The first field was brought up earlier and didn't rise any objections. You archived that discussion just before starting to post here in August though.-- User:Docu at 12:55, 21 September 2009 (UTC)

I archived that and all other discussion from 2008 on August 8. If you feel that this was in some way underhand, please raise the matter at

not thinking it is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits

13:01, 21 September 2009 (UTC)

(unindent) The previous discussion showed that we discussed and agreed on the addition of one of the fields (thanks for implementing it). You didn't explain why you wanted the other field. What is the advantage of having that other field? -- 签名 _sig at 13:14, 21 September 2009 (UTC)

For some reservoirs, the date of building (and is that the start, or completion? - you have changed the label from "Construction started" to "Built") is not available; but the date of first flooding is. You have not yet said why you do not think this is needed. And why have you hidden your name in your sig, mid-way though a discussion? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:19, 21 September 2009 (UTC)

The field name you used is "date-built". It seems asking for troubles if you expect this to be used for "date-construction-started". "Built" seems consistent we the proposal we agreed on earlier.

We could have additional fields for dams, e.g. date construction started, date it was flooded, date construction was completed, date it filled the first time, but these are all details about the lake's dam rather than the lake itself, thus they would better fit an infobox for dams.

BTW the signature changed in the mid-thread because signatures are set in Special:Preferences, not on a per thread basis. -- 签名 _sig at 13:59, 21 September 2009 (UTC)

If you have concerns about the name of the parameter (which is not shown to readers), you could have mentioned them instead of merely reverting (as you first did over a month ago), let alone edit-warring. The earlier discussion to which you refer, being a year old, had lapsed, and I was not even aware of it when I made the recent changes. As you well know, this infobox is used for reservoirs (which include, but are not solely dams), on articles about reservoirs, as well as about lakes in the natural sense. Besides, dams are not flooded; reservoirs are. I didn't ask how you had changes your sig, but why you had hidden your name in the middle of a thread (which makes your recent comments appear to be from a different editor to those made before the change). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:50, 21 September 2009 (UTC)

If we can't agree on a label for the first field, we would have to remove that too. Is "date built" now for "the date 'it' was built" or the date construction (of the dam) started? The initial suggestion made last year seems perfectly reasonable.

BTW, if you don't look at what you are archiving, you might as well set the bot to do this. Personally, I think it's helpful too keep suggestions around and archive primarily closed discussions (there aren't that many, so this can be done manually). -- 签名 _sig at 15:29, 21 September 2009 (UTC)

No, we wont have to remove it; we can seek wider opinion. There was no specific agreement a year ago. Indeed; further examination it shows that when you updated the template on 27 September last year, you ignored what had been discussed around dates just one week before. Any discussion unedited for a year can be regarded as closed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:02, 21 September 2009 (UTC)

Summary of comments since your last post: -. BTW the discussion about dates didn't really have anything to do with my edit. -- 签名 _sig at 23:24, 2 October 2009 (UTC)

Docu's obscure comment refers to the fact that he has returned, after two weeks, and again removed the "flooded" parameter, even though it is in use in infoboxes on articles about reservoirs, for which we have no date of building, but where the date of first-flooding is known. He appears to be unable to give any valid reason, why the parameter should not be used; and no-one else has objected to its use. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:12, 3 October 2009 (UTC)

This revert is unproductive - the changes made were simple cleanup which made the template code significantly more readable and easier to maintain, along with adjusting the font size to match that of {{infobox}} so that the text appears the same size in both Firefox and Internet Explorer. They should be re-done. Chris Cunningham (not at work) - talk 11:06, 2 December 2009 (UTC)

You also removed the alt text and left a general reference to

WP:ALT on my talk page. Do you want to add an additional field for the alt text or do you suggest a better default. Just removing it doesn't help. -- 签名 _sig

at 11:22, 2 December 2009 (UTC)

When I'm re-doing these changes I'll add new alt_lake and alt_bathymetry parameters for alt text, as neither the lake name nor the caption text are appropriate for alt text and indeed can do more harm than good. This is laid out on

WP:ALT, which is why I pointed you to it. For you to revert a bunch of uncontroversial changes in addition to the alt text change was still inappropriate. Chris Cunningham (not at work) - talk

11:30, 2 December 2009 (UTC)

Which part of "WP:ALT" are you referring to? I think

Wikipedia:ALT#Defaulting_to_caption is quite clear. -- 签名 _sig

at 11:34, 2 December 2009 (UTC)

That section describes a technical issue, not a solution. The lede makes the point clear:

Alt text is not the same as a caption. Alt text is meant for those who cannot see the image, whereas the caption is intended for all readers. In general, alt text summarizes the image's appearance, whereas the caption helps all readers interpret the image, to focus on its most essential elements and to connect it with the article text. A helpful way to think about alt text is to imagine that the web page is a script for an audio recording, and that the page's alt text is the part of the recording that describes the image to someone who cannot see the image.

The nutshell also contains a line proscribing the use of the caption for alt text:

[alt text] summarizes the image's appearance, not its meaning, and typically has little in common with the image's caption.

This is a basic point of Web accessibility; it would maybe be better for the MoS to be more explicit about why caption text shouldn't be used as alt text, but the page as it stands certainly implies this. Chris Cunningham (not at work) - talk 11:48, 2 December 2009 (UTC)

To improve the infobox in terms of accessibility, let's add a new field then to override the current default caption. We generally try to avoid images with no alt text at all. -- 签名 _sig at 11:55, 2 December 2009 (UTC)

Indeed. As I said before, I'll add alt_lake and alt_bathymetry parameters when I'm re-updating the code, unless there's anything else contentious to be discussed. Chris Cunningham (not at work) - talk 12:01, 2 December 2009 (UTC)

Can you do it in the sandbox first, so we can see it before? You didn't mention the override feature. There are quite a few test cases that allow to compare. -- 签名 _sig at 12:04, 2 December 2009 (UTC)

Done. The alt text is specified by alt_lake and alt_bathymetry respectively. Both fall back to blank if omitted for the previously-stated reason that neither the lake name nor the caption are useful alternative text. Chris Cunningham (not at work) - talk 12:12, 2 December 2009 (UTC)

I think we should use the solution of

WP:ALT instead. -- 签名 _sig

at 12:20, 2 December 2009 (UTC)

The paragraph in question contains the qualifier "when its caption is brief and adequate for alt text", and applies only to plain images (which are not normally accompanied by caption text). The use case given is a green check box (a simple geographic shape) it has nothing in common with the two images included in this infobox. The caption given for a map, or for an image of a lake, is by definition going to be unsuitable for alt text. Therefore it is both redundant (as screen readers will read the same text twice) and actively harmful (as it leads the reader into believing that the image has a useful alternative description where it does not). Chris Cunningham (not at work) - talk 12:40, 2 December 2009 (UTC)

I restored

Template:Infobox lake/testcases: they went missing earlier this year. They allow to compare the current version and new ones. You could file a bug if you think the current mediawiki solution is a problem. For this infobox, you could attempt to add maintenance categories to monitor missing alt texts and lengthy captions unsuitable for alt texts. -- 签名 _sig

at 07:42, 4 December 2009 (UTC)

The current MediaWiki "solution" is not a "problem" when it is used as described in that section. You are proposing that this "solution" be manually implemented in a place where it does not automatically happen, which I would suggest is deliberate. But to be honest I'd far rather do something more productive with my time, so I've restored the updated version of the codebase, added in your hack and pinged

WT:ALT in the hope that someone over there will be able to continue explaining why this "solution" is a bad idea. Chris Cunningham (not at work) - talk

09:41, 4 December 2009 (UTC)

If anyone is knowledgeable about templates or crater geology and wants to give a new crater Infobox template a look I would appreciate it. {{Infobox_crater}} --YakbutterT (talk) 23:07, 18 February 2010 (UTC)

Tempate was deleted per Wikipedia:Templates for discussion/Log/2010 March 7#Template:Infobox crater; but please see: Wikipedia:Village pump (miscellaneous)#Infobox for craters. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:42, 16 March 2010 (UTC)

Change sv:Mall:Infobox sjö to sv:Mall:Insjöfakta, thanks! -Josve05a (talk) 09:59, 4 November 2010 (UTC)

I want to add a pin map to the infobox of

09:32, 28 April 2011 (UTC)

Edit request from Lightmouse, 28 September 2011

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

This template apparently creates links to square kilometres and square metres. For an example, see Aliyar Reservoir. I'm sorry I can't be specific because I don't understand how it works. I think it's something to do with 'ordomag' but I'm not sure. Please can somebody find out where the setting is and change it.

Regards Lightmouse (talk) 16:54, 28 September 2011 (UTC)

I'm not sure what you are asking for or what is the problem? Aliyar Reservoir uses square kilometres and square miles for the catchment area and cubic metres and cubic feet for the water volume. I'm not seeing any square metres. — Martin (MSGJ · talk) 20:32, 28 September 2011 (UTC)

Are you asking about the link created by Template:Infobox lake/linkordomag? I suppose we could get rid of this link if there are no objections. Plastikspork _―Œ^(talk) 00:35, 29 September 2011 (UTC)

Aliyar Reservoir says:

• "Catchment area 468.8 km²". I see now this is a link to
  1 E+8 m²
  .
• "Water volume 109,416,297 m³. I see now this is a link to 1 E+8 m³.

Your responses made me look further. I was convinced they linked to unit articles. I now see they're easter egg links to order of magnitude. That makes the case for removal stronger. Lightmouse (talk) 09:29, 29 September 2011 (UTC)

Please can somebody remove the links to

1 E+8 m²? Lightmouse (talk

) 11:54, 30 September 2011 (UTC)

I will ask User:Jimp to attend to this request as he was the editor who created this subtemplate. — Martin (MSGJ · talk) 12:32, 30 September 2011 (UTC)

Thanks. Lightmouse (talk) 12:50, 30 September 2011 (UTC)

I have removed the code from the main template page which was sending those conversions to the linking subtemplate. I'm in the midst of cleaning up now. JIMp _talk·cont 00:57, 3 October 2011 (UTC)

It's all fixed. The code has been simplified and the labyrinth of subtemplates and redirects has been reduced to one. JIMp _talk·cont 04:58, 3 October 2011 (UTC)

Thank you for all your good work on this template. Lightmouse (talk) 07:42, 3 October 2011 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The |date-flooded= parameter, removed in this edit should be restored; it's needed for (and already used in) articles about reservoirs, in some cases for reservoirs where that date is known, but the construction date is not. See above discussion from October 2009, in which no cogent reason for its unilateral removal was given. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 13:14, 12 November 2011 (UTC)

As much as the 2009 revert seems unjustified from looking at it now, and the full protection of the template by an invonved editor was obnoxious, I don't really think "this was deployed on a few pages several years ago" is a greatly compelling argument. How about raising the matter with the lakes project to see if this is something that's generally needed? if so, that would also be a good place to coordinate wider rollout (as obviously there's been little point in doing so for the two years since it was removed). Chris Cunningham (user:thumperward) (talk) 13:17, 13 December 2011 (UTC)

It would have been deployed on many more pages by now, had the removal and involved-admin protection not happened. I'm also unsure how this unnecessary hoop aligns with

WP:BOLD, but I seem to have little choice but to do as you suggest. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

no objections; some support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:26, 16 December 2011 (UTC)

 Added — Martin (MSGJ · talk) 15:20, 16 December 2011 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:08, 16 December 2011 (UTC)

I have proposed that we delete {{geobox}}. That may effect this templates. You are invited to particiapte in the Geobox deletion dicussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 3 January 2012 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I've added a |website= parameter in the sandbox; please sync. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 18 August 2012 (UTC)

Question: Did you mean to put {{#if:{{{cities<includeonly>|</includeonly>}}}| or was that a copy/paste error for {{#if:{{{website<includeonly>|</includeonly>}}}|? --Redrose64 (talk) 22:01, 18 August 2012 (UTC)

The latter; I was fixing it as you wrote that. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 18 August 2012 (UTC)

Done --Redrose64 (talk) 10:09, 19 August 2012 (UTC)

Thank you. Seems to be working well. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:53, 19 August 2012 (UTC)

Please add an embed parameter so that {{

Nevermind. I see there is already a designation= parameter. Cacw (talk) 20:11, 13 April 2013 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

please add

{{Tfm/dated|page=Infobox lake|otherpage=Infobox ocean|link=Wikipedia:Templates for discussion/Log/2013 May 6#Template:Infobox ocean|type=sidebar}}

to the top of this template. Frietjes (talk) 16:18, 6 May 2013 (UTC)

Done --Redrose64 (talk) 16:28, 6 May 2013 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

This template needs an "other names" parameter, for lakes which have been renamed, or have colloquial or local names. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 20:45, 24 October 2011 (UTC)

I've added one in the sandbox; please sync the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:00, 29 April 2013 (UTC)

No opposition, so  Done. Please update the documentation! — Martin (MSGJ · talk) 09:28, 9 May 2013 (UTC)

Thank you. Once the current merger debate is resolved, we should probably also add |native_name=, like in {{Infobox settlement}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 10 May 2013 (UTC)

For man-made lakes, especially reservoirs, we could do with an |engineer= field. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:10, 29 April 2013 (UTC)

I can add it to the sandbox, labeled 'Construction engineer' or ....? Frietjes (talk) 22:51, 14 May 2013 (UTC)

Works for me. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:15, 14 May 2013 (UTC)

The |depth= parameter is labelled "Average depth". I wonder if that's how people are using it, or whether some are giving figures for maximum depth? Should we change the label, or add a |maximum_depth= field? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:07, 29 April 2013 (UTC)

there is a maximum depth parameter (|max-depth=). Frietjes (talk) 22:49, 14 May 2013 (UTC)

I don't know how I missed that. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:20, 14 May 2013 (UTC)

There is no provision of a native name of the waterbody within the infobox template. While there is provision from other name, the native names is important in cultures / countries where many water bodies have an indigenous name as well as a common name, plus variants. The use of native names exists in the river infobox template. Can it be added here? Rangasyd (talk) 14:52, 17 May 2013 (UTC)

both {{infobox body of water}} and {{infobox river}} have |other_name=. what, specifically, are you requesting? Frietjes (talk) 19:17, 17 May 2013 (UTC)

{{infobox river}} has |native_name=. This is missing on {{infobox body of water}}. Rangasyd (talk) 01:41, 18 May 2013 (UTC)

Correction. {{Geobox/type/river}} has |native_name=. Rangasyd (talk) 04:34, 18 May 2013 (UTC)

|native_name= should be paired with |native_name_lang=; see markup, for example in {{Infobox settlement}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:41, 18 May 2013 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

please update the main template to use this version of the sandbox. this completes the core part of the merger of {{

I support this request. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:29, 17 May 2013 (UTC)

Done! Plastikspork _―Œ^(talk) 03:14, 20 May 2013 (UTC)

|volume= is showing measurements in

@Rangasyd: I have moved your comment to this page, where more people will notice it hopefully. — Martin (MSGJ · talk) 14:28, 24 May 2013 (UTC)

the documentation of the functionality of the template is still lacking a bit, but you can actually use any units you wish by simply passing it to the volume parameter using {{convert}}. see the examples posted here. Frietjes (talk) 14:50, 24 May 2013 (UTC)

Thanks. Noted. Rangasyd (talk) 01:26, 25 May 2013 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

please update the template to use this version of the sandbox. this will accomplish two things, (1) it adds the requested native_name parameter (see #Additional of native name into template) and (2) it expands the tracking to check for duplicate parameters, which are silently ignored, and passing raw numbers to non-unit-specific parameters, which is an undocumented feature which is being phased out (see, e.g., {{infobox settlement}}, which uses area_km2 = instead of area = for area in square kilometers). no actual reduction in functionality or changes in appearance should result from this edit. just additional tracking and the additional native_name parameter. Frietjes (talk) 16:15, 24 May 2013 (UTC)

I support this request. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 24 May 2013 (UTC)

Done! Plastikspork _―Œ^(talk) 23:06, 27 May 2013 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:44, 28 May 2013 (UTC)

this template is to be merged with {{

1. both infobox ocean and the old infobox lake used |type=. I have added |lake_type= and |ocean_type= to generate more specific labels for this field. if the generic |type= is used, it still works, but the label links to the section in body of water.
2. the lake specific label link for residence time is only activated if you specify |lake_type=, otherwise you get more generic label links (e.g., Water cycle#Residence times vs Lake retention time)
3. the Category: Wikipedia infobox lake articles ... tracking categories will need to be renamed
4. some additional parameters have been added from {{
   infobox ocean
   }}
5. the |map_bay= parameter was omitted, since it wasn't clear how this is needed over |image_map=.

there are some comparisons in the testcases. let me know if you spot any issues. thank you. Frietjes (talk) 22:46, 14 May 2013 (UTC)

Good work; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:26, 14 May 2013 (UTC)

Leaves me a bit doubtful. This was a fairly stable infobox. How do we distinguish lakes from other "bodies of water" now? -- 签名 _sig at 20:06, 30 May 2013 (UTC)

use |lake_type= with a non-trivial value. Frietjes (talk) 20:10, 30 May 2013 (UTC)

Is there an actual benefit of doing that compared to having "infobox lake" call "infobox body of water"? -- 签名 _sig at 20:13, 30 May 2013 (UTC)

a single template vs. two templates? if you check what links to {{infobox lake}} you will find many things that are not lakes. and the distinction between a lake and a pond is fuzzy. Frietjes (talk) 20:18, 30 May 2013 (UTC)

Well, rivers are also "bodies of water" have a separate infoboxes, though common fields.

Including "bays" actually worries me more than oceans. Still, I'd leave these two separate from lakes, maybe in a common infobox.

I don't think pond/lake question is much of an issue. -- 签名 _sig at 20:53, 30 May 2013 (UTC)

the name "body of water" seemed to be the most obvious to reduce the number of template forks (the differences between infobox ocean, infobox bay, and infobox lake near zero, due to the forking). the

TFM was pretty unanimous concerning the merger of the bay, ocean, and lake infoboxes. everyone is, of course, welcome to continue using the redirect names. if you have a suggestion for a better merged name, please feel free to propose it. if you want to create a frontend for this template to distinguish between lakes and non-lakes, then please propose it. it seems like a can of worms, given the number of different types of bodies of water. interestingly, no ocean is using this template or was using the old ocean template. Frietjes (talk

) 21:17, 30 May 2013 (UTC)

As a native English speaker, I've never heard anyone refer to a river (or stream etc, or canal) as a "body of water". That phrase is used only for lakes, pools and seas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 30 May 2013 (UTC)

We can discuss the name. But I think the most important is to merge all infoboxes that share the same fields. -- Magioladitis (talk) 12:58, 31 May 2013 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

please change

| below      = {{#if:{{{shore|}}}|<sup>1</sup> Shore length is [[Coastline paradox|not a well-defined measure]].}}

to

| below      = {{#if:{{{shore_km|{{{shore|}}}}}}|<sup>1</sup> Shore length is [[Coastline paradox|not a well-defined measure]].}}

which will allow the footnote to appear when |shore_km= is used. Frietjes (talk) 19:54, 30 May 2013 (UTC)

Done, but with a slight change. {{#if:{{{shore_km|{{{shore|}}}}}}| would not have caught those cases when |shore= was specified, and |shore_km= was also present but blank. --Redrose64 (talk) 20:32, 30 May 2013 (UTC)

and did you check the other places in the template where those parameters are used? seems like there is now a problem with consistency which will cause the footnote to appear in cases where it shouldn't. better to just go with my version. Frietjes (talk) 17:42, 31 May 2013 (UTC)

please change

| below      = {{#if:{{{shore_km|}}}{{{shore|}}}|<sup>1</sup> Shore length is [[Coastline paradox|not a well-defined measure]].}}

to

| below      = {{#if:{{{shore_km|{{{shore|}}}}}}|<sup>1</sup> Shore length is [[Coastline paradox|not a well-defined measure]].}}

which will fix the newly introduced bug when |shore_km= is blank and |shore= is not blank. Frietjes (talk) 17:42, 31 May 2013 (UTC)

Done --Redrose64 (talk) 21:15, 31 May 2013 (UTC)

Hi everyone,

Recently I've been working on The Qattara Depression page. After adding this infobox to the page I tried to add a location map template into the box. It rendered correctly except for a line just above the image. When I looked into the template to see if I could modify it I stubled into a lot of technical stuff that I don't understand. My question is whether or not it is possible to add a function that prevents the line from showing up. [[file: |240px|alt=]]

Thanks,

This, like several other commonly used templates, is complicated within its own code and within the article implementation. As user:AlwaysUnite implies, it's taking freedom away from wysiwyg editing. It would be great if anyone could simplify it, perhaps by reducing unused options. Lightmouse (talk) 09:43, 29 September 2011 (UTC)

On the documentation page, it states that you should avoid adding maps. I have no idea why it says that. It sounds like you are asking for the addition of a "location map" feature to this template. I do not object, but it appears that someone did, or there wouldn't be a statement on the doc page saying we should avoid adding maps with the "image_lake" parameter. So, are there any objections to adding a "location map" feature like {{infobox building}}, {{infobox settlement}}, ... Until that happens, I moved the map in your example to just below the infobox. We can move it back up if there are no significant objections to adding a "location map" feature. Thanks! Plastikspork _―Œ^(talk) 01:18, 1 October 2011 (UTC)

Thanks for your replies. It seems indeed that I was warned. Nonetheless I believe this to be a usefull option as it gives greater informational quality to the content of the infobox. To clarify, the location map problem involves a nested template which causes the infobox to render wrong. I'm no expert here so until this is added I've put the temp image back where it was a few months ago.

talk

) 21:17, 3 October 2011 (UTC)

I support adding a location map capability to this template. It seems to be a common feature of many Infoboxes hence it does seem possible to add. Anyone bright enough to know how to do that? --papageno (talk) 16:26, 29 November 2013 (UTC)

The {{{native_name}}} parameter seems to be missing from this template and the {{{other_name}}} is not appropriate where a body of water may have an official name, a local or other name, and a native name. Is there consensus to add this parameter, as per {{Geobox}}? Rangasyd (talk) 02:53, 4 June 2014 (UTC)

|native_name= and |native_name_lang= are already in the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 26 June 2014 (UTC)

I would like to suggest a field called "parent" be added. This is used at {{Geobox/type/river}} (main Geobox page at {{Geobox}}) and adds the text "Part of" then the field content to the Infobox. I employ it regularly at when using Geobox for rivers to add a drainage basin; see, for example, Englehart River. --papageno (talk) 16:16, 30 May 2014 (UTC)

There appears to be no opposition. Can this field be added now? --papageno (talk) 19:27, 26 June 2014 (UTC)

I don't have a problem with that, but note that {{Infobox river}} exists for rivers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:02, 26 June 2014 (UTC)

added as |part_of= Frietjes (talk) 17:44, 29 June 2014 (UTC)

This template should have a {{Locator map}} and the associated full coordinates fields to support automatic location pins. Many geography templates including Geobox include a locator map, which means there is existing code that might be repurposed here. I regret I am not experienced enough to make the changes myself. --papageno (talk) 18:55, 15 May 2014 (UTC)

I can do it, but will wait a bit to see if there are any objections. Frietjes (talk) 20:18, 15 May 2014 (UTC)

Much obliged. Let's see what other comments turn up here.--papageno (talk) 00:32, 16 May 2014 (UTC)

It has been two weeks and there have been no further comments. May we move on to discussing what the change(s) specifically should be? --papageno (talk) 16:23, 30 May 2014 (UTC)

We should have a standard block of code for this (maybe invoking a lua module), that can be plugged into any relevant infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:33, 30 May 2014 (UTC)

added, mostly using the syntax from {{infobox settlement}}. will update the documentation if there are no issues. Frietjes (talk) 18:58, 30 May 2014 (UTC)

I have tried out the new functionality on a few articles with four different locator maps, for example at Sullivan Lake (Cochrane District), and it seems to be working. Besides the coordinates fields, I have used the coordinates_footnotes, coordinates_region, coordinates_display, pushpin_map and pushpin_map_caption fields. Leaving coordinates_type blank produces the desired waterbody parameter. --papageno (talk) 20:48, 1 June 2014 (UTC)

I think one additional parameter might be useful in support of adding locator maps. I thought I would try a one more test case, and saw the article Qattara Depression mentioned in the Talk above. It has: the Infobox body of water template; and a separate {{Location map Egypt}} template, the latter using the AlternativeMap parameter to employ a relief map image instead of a political map image. More on that parameter at the generic {{Location map}} template page. I think giving the option of using an alternative map is a useful tweak for our template here, which deals with geography. --papageno (talk) 16:13, 2 June 2014 (UTC)

Better to use the relief parameter. However, we may want to just make the relief map the default? Thanks! Plastikspork _―Œ^(talk) 04:22, 3 June 2014 (UTC)

yes, the pushpin_relief option is the best way to get a relief map. there is also |pushpin_image=, but |pushpin_relief=1 is more robust, since you don't need to know the alternative image name. Frietjes (talk) 12:48, 3 June 2014 (UTC)

This looks good as implemented right now. I see the map defaults back to the political map where no relief map exists, for example at

Lake of Bays (Muskoka District).--papageno (talk

) 22:42, 3 June 2014 (UTC)

Test in Australia on Lake Connewarre works well. Rangasyd (talk) 03:10, 4 June 2014 (UTC)

Looks great! Note: I updated Module:Infobox body of water tracking to check for |latd= and |longd= if it doesn't find |coords= and Category:Wikipedia infobox body of water articles without coordinates to reflect this change. —PC-XT+ 19:37, 19 July 2014 (UTC)

Shouldn't there be an etymology parameter in this infobox? --

Yes; done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 4 August 2014 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please have patience with errors in this request as I am entirely new to Wiki editing. I am trying to follow precedent as well as I can; I started an inquiry about this on my own help page and some helpful folks recommended I make a post on this page. I would like to propose a new parameter to add to the infoboxes for lakes in particular. The category I would like to add is a "lake age" field (myself and colleagues are working on a project related to lake ages, and the information may be of broad interest). Lakes range in age from millions of years old (e.g., ancient lakes) to recently established. Lake age has interesting implications for management, ecology, and evolution of taxa in these lakes. I could start adding lake age information to the main body text for certain lakes, but I thought it would make more sense to see if the community might agree to make this a standard category, which would encourage more people to add lake ages if they know or consider this feature in lakes. Awegalloway (talk) 17:41, 31 March 2015 (UTC)

Hello Awegalloway, thanks for your suggestion. We normally let proposals like this sit for a few days to see if anyone else has an opinion. So I've deactivated the template. If there is consensus for this change, or no comment after a few days, feel free to reactivate and I'll make the change. Regards — Martin (MSGJ · talk) 16:50, 1 April 2015 (UTC)

Hi all. Feel ambivalent about this. Makes sense for artificial lakes, but what about situations where a lake has, say, dried out for some historical period? Or natural and long-lived cases where a given depression has been occupied repeatedly by a succession of water bodies, but with gaps between? Or cases where we distinguish a modern lake from its historical ancestor? (e.g., Great Salt Lake/Lake Bonneville). An unrelated issue is that I suspect this information will be really quite hard to find in the literature for most natural lakes. I *think* this might still be manageable though, as long as it's clear how to deal with, e.g., prehistoric lakes that don't exist any more. Give an interval, not an "age"...? DanHobley (talk) 18:05, 1 April 2015 (UTC)

I think a parameter of this sort could be useful. I would prefer a field that gives the date of the lake's origin (as opposed to an "elapsed time" age). For old lakes, something like 100,000 years BP would fit either case, but for recent creations, 1926 is going to be easier to maintain than 89 years (as of 2015).

The Wikidata project is building a structured database of entities and claims (with sources) that is intended to feed infoboxes once it is sufficiently developed. I believe the property that would be most relevant would be "start time" [P580]. I ran a query for all entries that all have the value "lake" [Q23397] for the "instance of" property [P31]. Right now that produces only the Turtle-Flambeau Flowage which does indeed appear to have been created in 1926 as indicated by its Wikidata entry. Perhaps we can develop greater sophistication to deal with lakes that have come and gone over history, but {{{origin_date}}} would be a good start. Rupert Clayton (talk) 01:25, 2 April 2015 (UTC)

The body of water info box is often used for straits and other bodies of water where the minimum width is notable, not the maximum width. The available width parameter produces a Max. Width field in the info box, which is wrong. How would this be corrected? Fengshui~enwiki (talk) 23:00, 28 July 2016 (UTC)

Fengshui~enwiki, since there were no objections, I have added this optional parameter, |min_width=. Frietjes (talk) 12:27, 26 August 2016 (UTC)

This edit request to Template:Infobox body of water has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please change

Done Matt Fitzpatrick (talk) 04:56, 9 October 2016 (UTC)

Thanks, Matt Fitzpatick! Rtrust (talk) 02:13, 17 October 2016 (UTC)

Nice template! Would you mind adding functionality to change the image size, as on Template:Infobox river? Also, could you add functionality to allow the box to say "Cities/Towns/Ports" in addition to or instead of "Settlements"? For example, the river template uses subdivision_type for this. I'd like to expand the use of infoboxes on articles about bays, gulfs, sounds, straits, etc., because I think the quick organized overview of facts is useful for articles like that. Vejlenser (talk) 18:17, 8 November 2016 (UTC)

Hi Vejlenser, the documentation is loath to admit it, but |image_size= is supported. See Braddock Bay for an example. Can't help you with the rest of your concerns, although I sympathize. Antepenultimate (talk) 07:18, 3 December 2016 (UTC)

Thanks, Antepenultimate! Vejlenser (talk) 20:25, 3 December 2016 (UTC)

So a couple of things I noticed. First, is there a reason that only metric params are accepted for distances? For example, there is a {{{depth_m}}} but not a {{{depth_ft}}}? I know that metric is used much more than standard and even as an american I wish the whole world would just use the metric system.... But sadly here in the US, "standard" measurements are still the standard... Ha.. Pun.... Anyway back to seriousness. Secondly, the convention seems to be going away from having transclusions of templates use the {{convert}} templates. That is to say that instead of having | depth = {{convert|123|m|ft}} we would go with | depth_m = 123 even though these produce the same result.

So that brings me to my proposal, which I am more than happy to implement 100% on my own. I just want to make sure there are no objections. The proposal has two parts:

1. Add in "standard" equivalents for all measurements. {{{length_mi}}}, {{{depth_ft}}}, etc.
2. Deprecate ALL instances of params without a specific unit of measurement. So {{{length}}}, {{{depth}}}, etc. would all be added to Category:Wikipedia infobox body of water articles using deprecated parameters regardless of whether they are using {{convert}} or not. This would also include an update to the documentation that I would handle. :-)

Hoping to hear any and all feedback! --Zackmann08 (^{Talk to me}/_{What I been doing}) 20:29, 2 December 2016 (UTC)

The {{{depth_m}}}, {{{depth_ft}}}, etc. parameters were introduced in 2009 but were reverted on account of there (supposedly) being too many parameters as per this discussion. Anyway, that was seven years ago. Now we have Lua and can therefore read input units. For example, we don't need |depth_ft=123 since, instead, we can have |depth=123 ft, which Lua can recognise as 123 feet and then we can convert. For a more detailed idea of what I'm on about, have a look at Template:Infobox_person (which uses Template:Infobox person/length, Template:Infobox person/weight, etc.). Jimp 08:32, 29 January 2017 (UTC)

Jimp, I would support replacing uses of |depth_m=10 with |depth=10 m and using a system similar to the system used with Template:Infobox_person to automatically convert the input. for elevation, depth, and max-depth we can basically expect either m or ft. for volume, things become much more complicated. I have seen km3, acre.ft, m3, L, ML, GL, impgal, USgal, e6m3, e6L, ... I can see how we could pattern match to pass this to {{convert}}, but it would be nice if we could track unusual cases to check to see if there were any problems. for example, people copy stuff between wikis and switch the comma and the decimal, or use km2 for volume, or other nonsense. for now, I am tracking and changing transclusions without any unit conversions to use {{convert}} and visually checking the results as I change them. Frietjes (talk) 14:10, 29 January 2017 (UTC)

That sounds like a good plan. I might try and see what kind of error checking I can come up with in the sandbox. Jimp 02:13, 30 January 2017 (UTC)

To begin with, we must get rid of the _kms, _m2s, etc. & the _refs. Jimp 16:13, 8 February 2017 (UTC)

Jimp, all the old _kms, _m2s, ... _refs have been removed and cleared from the articles. any new ones will pop up in Category:Pages using infobox body of water with unknown parameters, sorted by parameter name. in the process of cleaning up all the old syntax, I removed the new unit conversion code that you had added. sorry about that. please feel free to add it back. I am currently (partially) tracking any unconverted measurements in Category:Wikipedia infobox body of water articles using deprecated parameters. false positives could start popping up in there if we support stuff like |length=10 km without any explicit unit conversion. however, I can adjust the tracking code if/when this happens. the fact that the Category:Wikipedia infobox body of water articles using deprecated parameters is empty right now means that we should have nearly 100 percent of all articles using {{convert}} or a hard-coded version for the measured parameters. thank you. Frietjes (talk) 15:41, 9 March 2017 (UTC)

@Frietjes: That new unit conversion code was only ever meant to be temporary. The main purpose was to find the pages using _kms, _m2s, ... _refs so we could get rid of them ... but, if that job's been done, great. Jimp 02:18, 11 March 2017 (UTC)

Hi fellow Wikipedians, is it possible to add a GB mapping property to the template, so the Template:Gbmapping can be added. Many, in fact all, seem to referenced by this standard, but there doesnt seem to be place for it. I have seen the template, in the lede, down near the categories, in the body of the aricle. There is no standard place for it. I know there is location property. I been using this for village, cities, counties or unitary athorities which have been close to the water, but it would be ideal if we had a standalone property. Looking at the data. Here is Loch Ard, and the Loch Ard on the British Lakes site. You can see that there is property, OS Grid Reference (lake centre) NN465016. That is Gbmapping property, and I would like it in the infobox, if its not the Location property. scope_creep (talk) 15:51, 13 May 2018 (UTC)

Unless I do not see it, there is no parameter to allow the addition of a map in existing template.--MONGO 16:05, 31 May 2018 (UTC)

I’m not sure the template I’m thinking of exists. Asking here in case it does. We have an article on the

I'm testing something out in the sandbox that would add location parameters and break them out in the fashion used by other such as{{Infobox valley}}. Anyone have any thoughts? --Zackmann (^{Talk to me}/_{What I been doing}) 04:07, 25 October 2018 (UTC)

• comment seems unnecessary. Frietjes (talk) 14:28, 25 October 2018 (UTC)

I propose adding a parameter for connected waterbody (E.g. connected_waterbody =). Applied for example for a strait: a strait is always connected to 2 seas / oceans. RScheiber (talk) 15:21, 10 February 2019 (UTC)

The Parameter "Group" is included in the template, but a corresponding definition of the parameter is missing. Would someone add that? Thank you.Wolfgang8741 says: If not you, then who? (talk) 00:06, 29 April 2019 (UTC)

 Done —hike395 (talk) 02:48, 29 April 2019 (UTC)

So, does this do what I asked about several sections up? Because that would be awesome.

talk

) 17:39, 29 April 2019 (UTC)

This edit request to Template:Infobox body of water has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please change template call {{

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. For further discussion see User talk:Colonies Chris. --Trialpears (talk) 16:29, 10 October 2019 (UTC)

The image field description states "Please avoid sunset pictures or maps (For maps, use image_bathymetry)" yet not every map is a bathymetry map which is a specific type of map of the underwater topography. We have a pushpin_map parameter, but that is another specific map. I've only seen a handful of cases, but it does raise the point that bathymetry are not general maps. I propose a new static_map be created if there are many cases of maps and only apply bathymetry maps in the image_bathymetry parameter. It doesn't make sense to make tracking which bodies of water do and do not have bathymetry images just to move the map from the main image parameter to another parameter where it does not fit as well. Is this revisiting an old discussion or something that should be proposed for discussion? Wolfgang8741 says: If not you, then who? (talk) 11:16, 13 April 2020 (UTC)

Hi, Has there been a discussion about adding an optional parameter for trophic status? Or is it preferred to add this info to lake type? Cheers, Uninspired Username (talk) 18:57, 3 June 2020 (UTC)

The parameters sections, trenches, and benches parameter does not have documentation. Can someone knowing how these were intended to be used please add an explanation in the doc. Thanks.Wolfgang8741 says: If not you, then who? (talk) 15:59, 16 June 2020 (UTC)

As WikiProject Lakes has had a boost in reviewing articles there are a handful that seem to recently as 2020 used the Infobox Lakes template for new articles instead of Infobox Body of Water. Would it make sense to add an automated template swap? I'm not sure if a tool or script is the reason for this. Wolfgang8741 says: If not you, then who? (talk) 13:00, 14 June 2020 (UTC)

I would support that - do you know where the lake template is coming from? Quickly searching I found a template named Infobox lake on the simple english wikipedia (https://simple.wikipedia.org/wiki/Template:Infobox_lake) but in the article the infobox is still called 'Infobox body of water'. By searching for '{{Infobox lake' in wikipedia I did find a few old edits (2010 and before) added by existing usernames (eg. Lake Karachay, Acquato Lake, Lake Rakshastal) Uninspired Username (talk) 17:24, 16 June 2020 (UTC)

WP:NOTBROKEN which talks about bypassing redirects but the same arguments generally apply to introducing them). It is also quite difficult to do the swap automatically if not all uses of the template should be changed. --Trialpears (talk

) 20:09, 20 June 2020 (UTC)

@Trialpears: Yes, I understand they're interchangeable, but I think some are applying parameters that are not equivalent so it is causing need for cleanup each time it is used. I don't have an example to link at the moment, but if another appears I'll post a link here. I was also thinking of the behavior of User:AnomieBOT/docs/TemplateSubster, but would need mapping of the parameters for cleanup mapping too. I may have caught all there were for now. Wolfgang8741 says: If not you, then who? (talk) 21:09, 24 June 2020 (UTC)

The new pushpin map parameter is fantastic, it seems prime for a maintenance category and that is what I'm requesting be created as I have not figured out how to make them yet. For consistency also a category for missing the bathymetry image. Functionally these are the same as coord and photos. In WikiProject Lakes it has been helpful in improving the infobox presentation where images are not yet available and in correctly identifying article information and naming. Wolfgang8741 says: If not you, then who? (talk) 06:58, 9 June 2020 (UTC)

@Frietjes: Since you did some fantastic work previously on Module:Infobox body of water tracking do you think you could find some time to add these two maintenance categories for the pushpin map and bathymetry fields? It will probably be faster than my learning the syntax. Wolfgang8741 says: If not you, then who? (talk) 05:00, 9 July 2020 (UTC)

User:Wolfgang8741, so what do you want to track? All pages with |pushpin_map= or all pages without |pushpin_map= or all pages with both |pushpin_map= and |image_bathymetry= or all pages missing both |pushpin_map= and |image_bathymetry=? Frietjes (talk) 16:40, 9 July 2020 (UTC)

@Frietjes: I'm approaching this from a completeness and validation perspective, three categories now I think about it, first category pages without |pushpin_map= and second category pages without |image_bathymetry= and a third pages with |image=, |image_bathymetry=, or |pushpin_map= AND is missing one or more of |alt=, |image_bathymetry_alt=, or |pushpin_map_alt= possibly named "Infobox body of water missing alt text" or something like that. There is more opportunity, but these will have largest impact for the readers. Wolfgang8741 says: If not you, then who? (talk) 17:22, 9 July 2020 (UTC)

User:Wolfgang8741 see the list in Module:Infobox body of water tracking. it will take some time for the server to populate the categories. Frietjes (talk) 18:05, 9 July 2020 (UTC)

To help get a better idea of consistency across infoboxes and articles I propose we create tracking categories for media fields used in the Infobox. It only requires adding a tracking category to list the files such as used by

The first two are straightforward to track: |image= and |image_bathymetry= in their own respective category in something like Infobox Body of Water image field Images and Infobox Body of Water bathymetry image field Images, if possible ordered by newest image. These would allow building intersects with other categories and templates too. It will also reveal the extent which image_bathymetry is conflated with non bathymetry images as the prompt for adding a map parameter discussion above.

The third and harder one I'd think would be building the gallery for the |pushpin map= since it may require splitting and collecting multiple images often separated by #. Across the articles there are different styles of pushpin maps being used. Having a category of what is being used will allow us to assess how the experience is across infobox and take the next steps in looking to bringing more consistency across the body of water infobox experience.

I don't think anyone will object to adding tracking categories, but wanted to get feedback before these are added. Wolfgang8741 says: If not you, then who? (talk) 06:54, 17 July 2020 (UTC)

This template currently has a slot for the countries making up the drainage basin of a body of water, but none for the bordering countries. For lakes, the drainage basin makes some sense, but in many cases it would make more sense to list subnational units (states or provinces or oblasts) in the drainage basin, not the countries (consider, for example, Lake Erie or Lake Baikal). For large bodies of water, like the Mediterranean Sea and the Atlantic Ocean, I'm not sure I see the value of listing all the countries of the drainage basin. In any case, it would be useful to have a slot for bordering countries. See Talk:Atlantic Ocean#Drainage basin and Talk:Mediterranean Sea#Drainage basin. --Macrakis (talk) 22:58, 14 July 2020 (UTC)

Thanks for bringing this to the template discussion, but I would be against the practice of listing "subnational units" for the drainage basin as it would grossly increase the number of items to be listed and wouldn't provide more value than the country level. How would listing subnational units improve the reader experience and why can this not be managed within the body of the article since any information provided in an infobox should already exist in the body of the article. The information in the infobox should act like a snapshot and the pushpin map should assist with identifying the sub-units visually. Countries make sense from geopolitical relations and further subunits could be discussed in the body. In the terms of listing a long list it might be better suited to skip the parameter in the infobox as you point out on the Ocean and Seas. I don't think bordering countries solves the too many to list in these cases. This may be one where WikiProject convention could be established instead of a technical change to the infobox. Wolfgang8741 says: If not you, then who? (talk) 18:07, 15 July 2020 (UTC)

Certainly we shouldn't be listing subnational units when there are too many of them (Danube, Mississippi), but for cases where there are few national units and a reasonable number of subnational ones, it might make more sense (Hudson River: New York State, Vermont (minor), New Jersey (minor), Connecticut (trivial)). But as that example shows, there's also the question of small parts of the drainage basin. --Macrakis (talk) 17:52, 17 July 2020 (UTC)

It appears that the parameter check for coordinates is insufficient to handle if there are multiple infoboxes on an article which has a coordinate and does not populate Category:Articles using infobox body of water without pushpin map. An example how some rivers are listing the lakes: Fish River (Maine). The article had a coordinate and that was merged to the river infobox, but the three infobox bodies of water defaulted to the river mouth coordinate instead of flagging the infobox lacked the coordinate parameter being empty. I think the behavior to be added to the category should be more strict to the infobox parameter being present or absent to help catch situations like this. Wolfgang8741 says: If not you, then who? (talk) 12:52, 20 September 2020 (UTC)

Does the recent maintenance category Category:Articles using infobox body of water without pushpin map mean that pushpin maps are now required for all instances of the Infobox? In many cases, articles already had a map image, such as Gulf of Finland, Gulf of California, Gulf of Mexico, Gulf of Aqaba. Or Bermuda Triangle! Or a bathymetry image as at Celtic Sea. For Atlantic Ocean, there's now a pin between Brazil and Africa where there is already a more useful map image above showing extent and indicating the North and South Atlantic. I don't see the addition of pushpin maps in these articles as an improvement and the above examples are looking cluttered with their now multiple maps. Map images often convey much more information than a pushpin map can. Infoboxes should have some map but hopefully the objective of the maintenance category is to list articles for review, not necessarily that the category be empty. Thanks Declangi (talk) 18:04, 10 October 2020 (UTC)

@Declangi: No, the pushpin map is not Required and thank you for raising these valid points which as I was working through the backlog also began to notice. We could tweak the tracking category if we add a custom map parameter as I previously suggested. It would check if custom map is present in the "custom_map" parameter then not add the page to the "body of water without pushpin map" category. This way when a better map is available we would be able to know a map is present, but this doesn't provide the consistent experience across articles though would handles these special cases for larger features. The intention of the tracking category was to bring visibility to articles without a map in the infobox as the infoboxes are added and make an automated way nudge for consistency across the infoboxes and articles to orient readers to the location of the feature. In a majority of cases custom maps aren't available a point orientation is sufficient. As you point out its not the best for very large features with nicer maps. This tracking category came about as I've been working on overhauling the Lakes project which relies on the Infobox body of water. There are many more tracking categories to add to the infobox with simple rules to nudge for adding information, this could be applied conditionally where parameters don't apply to a specify "type" or other field. That is a longer term vision for the infobox, but for now we should fix the pushpin listing for those with custom maps. The current suggestion - (For maps, use image_bathymetry) is not a clean data practice as bathymetry images are a specific type of images and shouldn't be a catch all for maps. What do you think about adding the "custom_map" parameter in the map section and display the custom_map instead of pushpin when both are present? Wolfgang8741 says: If not you, then who? (talk) 23:08, 26 October 2020 (UTC)

Hello Wolfgang8741, many thanks for your detailed response. I entirely understand the nudge function of the maintenance categories. I agree also that image_bathymetry is unsuitable in the long term for general custom images. Your idea of a custom_map parameter sounds like the way to go (and prioritising custom when both custom and pushpin map parameters are in use). Custom maps should of course still be subject to qualitative review, demonstrated by a recent example at Talk:Ionian_Sea#Map_with_"Macedonia" where the custom map includes the old and controversial name. But yes I think your idea would improve the Infobox in the long run. Not being a project member, I might not be familiar with other consequences of these kinds of changes, so my opinion should be taken with a "grain of salt". My initial interest in the Infobox was through editing articles on Irish lakes. Declangi (talk) 03:29, 27 October 2020 (UTC)

Page watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles Izno (talk) 00:22, 29 April 2021 (UTC)