Template talk:Infobox river/Archive 1

I modified this template to use a new CSS style that hides table rows if the corresponding parameters are left blank. This system also means we no longer need to call a sub-template, eliminating any conflict with

Note: The original Template river has been deleted and that name is now used for the WikiProject talk page template. Rmhermen 18:03, 24 August 2006 (UTC)[reply]

I've redirected "basin" to watershed, as that is the most reasonable option on the disambig page - but that makes two links to watershed in this article, so you may wish to find an alternative expression. BD2412 T 01:16, 6 December 2005 (UTC)[reply]

I don't know anything about the creation of templates, but I've noticed that the static descriptors (Origin, Length, Basin countries, etc.) have disappeared from the finished infobox, so that now there's just a list of countries and numbers with no information about what they refer to. See the Volga example at top. What happened? Can anybody fix it?

• The change was reverted and it's fine now, so... thanks! --
  Malepheasant 06:43, 23 April 2006 (UTC)[reply
  ]
• Sorry about that. A new feature, '#if:' (see m:ParserFunctions), was built into the MediaWiki software by the developers to replace 'hiddenStructure' and 'qif'. I was converting this to that new format so it will be ready when those older methods are removed. I made a mistake in the line spacing which caused the problem, but it should be corrected now. Please let me know if there are other issues. --CBDunkerson 13:10, 23 April 2006 (UTC)[reply]

I realize many major rivers flow into the sea, but many rivers flow into other rivers. It seems that it would be useful to include the elevation of the river at the mouth. If it is sea level, this could be left blank or entered as "sea level" (or whatever the accepted term is). Thanks, Ruhrfisch 04:25, 25 July 2006 (UTC)[reply]

• I agree that this would be a useful addition.
  Malepheasant 03:39, 26 July 2006 (UTC)[reply
  ]
• I agree as well. This would also help us identify rivers that are essentially at risk of sea level rise vs. those that are less threatened. MCalamari 18:24, 26 October 2006 (UTC)[reply]

In addition to talking about river discharge as a flowrate (cfs), for water supply purposes US engineers look to the annual volume of water without any time reference. The common unit of discharge is acre-feet or thousands of acre-feet. Could we add a second discharge box called "discharge volume" to supplement the "discharge flowrate"? Discharge volumes are also very important on rivers that are dammed, as any reservoir storage volume or capacity is somewhat related (based on the design needs of the structure) to the annual discharge volume. (Flood pools will still be set to discharge flowrates, but storage pools will tend to focus on the longer time averaged volume.) MCalamari 18:30, 26 October 2006 (UTC)[reply]

If anybody is interested in working examples, check out

I like the inclusion of source and mouth coordinates. Since there are already many rivers with infoboxes, I suggest using parameters with the same name as in the present infobox. Markussep 21:38, 26 December 2006 (UTC)[reply]

I see the point and I've given it a thought when working on the new template but it contains (resp. can contain) much more data and so some field cannot be simply reused. Take elevation, in the old template it's used for the mouth elevation, the new template has fields for both source elevation and mouth elevation. The same applies , e.g., for caption as in the new template there can be a caption for both the map and the image. Nonetheless, some field names remain the same, 'e.g.' length, watershed.

Did you announce your new template at Wikipedia talk:WikiProject Rivers already? Markussep 11:59, 27 December 2006 (UTC)[reply]

Would it be possible to include a completed sample of the visual presentation of the new version for discussion (or a link to a page on which it is being used)? My first thought is that a photograph at the top might make for a more inviting (and varied) introduction to an article than a map (as with Infobox city). --

Okay, now I see that examples are linked from the bottom of the

Malepheasant 00:53, 16 January 2007 (UTC)[reply

]

I'm afraid this isn't possible, the new infobox acts rather like a database, so the input fields need to be just plain numeric or textual values. I haven't encountered this when creating the new infobox. It might be possible to include say source_location_citation (etc.) fields if required. – Caroig 06:54, 16 January 2007 (UTC)[reply]

There is at least one Featured Article,

Malepheasant 19:41, 16 January 2007 (UTC)[reply

]

I like the new infobox, but agree with Malepheasant that a picture would better first. The MOS says to start the article with a right aligned image, and while a map is certainly an image, I think a photograph is generally better. It is also easier for most editors to take a photo than to make a map, so the first image should be the one that is easier to obtain. I also think that most readers will get a better first idea of the river by seeing a picture of it than by seeing a map.

Despite the labels, I suppose there is nothing to stop someone from using a photo first, then putting the map in second (any image could go in either place, with a proper caption, just the labels would be "wrong"). Would it make sense to label the fields Image One and Image Two (and Caption One and Caption Two)? Then the "directions" could explain one is for a map and the other a photo, and give a preferred order but leave it up to the editor?

Last question: Is there an easy way to translate old river infoboxes to the new one, or do we just have to paste in the old data by hand? I would like to update some articles' boxes, but also want to wait until the new box is the final version. Thanks for doing this! Ruhrfisch 15:55, 16 January 2007 (UTC)[reply]

First, thanks for the feedback. Before I reply let me say a few words about why I created this template. It's not so much about the graphic style but rather about the information it contains, what purpose the infobox serves. In my view, the role of infoboxes is to summarize the important data in a uniform way so no matter what the article is about, the reader should find the information (such as country, region, map, length, height etc.) in the same place. There are, as I see it, too many articles (not only about rivers), where I am rather surprised what data find in the infobox and also many others where the infoboxes contain short stories (like the stream lies some km northest from the village center) which I think belong to the article. I got inspired by the

Template:Infobox City which too are rather strict concerning the data they can contain and don't allow for stories in them. I'm not saying this is the right view, it's how I see it and therefore I decided to rather create a new infobox from scratch than to change the current template. (I created two more templates using the same style and syntax Template:Infobox Mountain Range and Template:Infobox Mountain Summit

).

I suggest moving this discussion to Infobox_River_Geography where it might be more appropriate. – Caroig 20:17, 16 January 2007 (UTC)[reply]

I went and upgraded the template so that it would convert to and from imperial/US and SI. I hadn't realised that it was being replaced with a new version. I'll document the upgrade but put a depreciated tag on the page. JЇѦρ 05:37, 15 April 2008 (UTC)[reply]

The discussion page notes the default image size of 288px. This is great for horizontal images, but too big (in my opinion) for tall ones. Any way to override the default? See my problem at: St. Croix River (Nova Scotia) Verne Equinox (talk) 00:30, 11 September 2008 (UTC)[reply]

• I concur. This box is usefull but size is distracting. It dominates some articles I'm working on. My contributions
  Can one of you infobox gurus please add the operator: width= to control box size.
  

Also same request for

German Wikipedia has its own equivalent of this infobox (but with a few more parameters). It would considerably aid the transfer of articles from de.wiki if there was an infobox on en.wiki which recognised the German field names and automatically translated them into English and I could quite easily create this. However that would mean a second infobox (called Infobox Fluss) with a similar purpose. However it should be possible to expand this one to cope with the German fields by using a redirect and adding the extra coding required. Obviously the German coding would not be noticed by articles created in English from scratch. Is there merit in doing this (I might need some help) or should I create a separate template? --Bermicourt (talk) 15:52, 22 March 2009 (UTC)[reply]

It is possible to modify the Infobox River in order to use German infobox information. The same has been done for town infoboxes ({{

Infobox Fluss}} can be a redirect to Infobox River. I see the German infobox has more fields than the English one, I'm not sure we need all that information. Markussep ^Talk 15:08, 23 March 2009 (UTC)[reply

]

Sounds cool! Although the German infobox does have more fields, in some cases they display two fields as one e.g. source name and coords are separated in the infobox but display together, whereas the English infobox sticks all the data in one field. The end effect is similar. --Bermicourt (talk) 20:55, 23 March 2009 (UTC)[reply]

Let me see which fields could be merged:

• NAME = river_name
• BILD = image_name
• EINZUGSGEBIET = watershed
• LÄNGE = length
• QUELLE = origin
• QUELLHÖHE = elevation_m
• MÜNDUNG = mouth
• MÜNDUNGSHÖHE = mouth_elevation_m
• ABFLUSSMENGE = discharge

The other fields can't be used directly, but have to be translated or converted. Markussep ^Talk 18:11, 24 March 2009 (UTC)[reply]

I've added a "progression" parameter; which can be seen in use on River Penk to describe the path taken by the waters of a river which is a tributary of one or more other rivers, and does not empty directly into a sea or lake. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:26, 21 September 2009 (UTC)[reply]

I've added a "river system" parameter, corresponding to the de.wiki "Flusssystem" one. So now German rivers at least can be easily updated. --Bermicourt (talk) 12:06, 6 October 2009 (UTC)[reply]

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:56, 3 January 2012 (UTC)[reply]

Could a field be added to give the coordinates of the mouth, perhaps using the {coord} template? A field could also be added for the source coordinates using coord, useful if the source were not some other geographic feature already tagged with coordinates (EG not a lake). papageno 01:28, 3 November 2007 (UTC)[reply]

Good idea! Markussep ^Talk 09:08, 3 November 2007 (UTC)[reply]

The other river infobox {{Geobox River}} has fields for source and mouth coordinates. You might consider converting the infobox for rivers you want to add coordinates to, to this other template. Markussep ^Talk 15:24, 30 November 2007 (UTC)[reply]

Please see discussion of coordinates at WikiProject Rivers. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:06, 9 September 2008 (UTC)[reply]

The above linked discussion is now archived here. related discussions are at Wikipedia talk:WikiProject Rivers/Archive 2#Geographical coordinates and Wikipedia talk:WikiProject Rivers/Archive 2#Use of Co-ordinates on river pages. --AussieLegend (talk) 11:38, 22 September 2012 (UTC)[reply]

It seems, from comparing the before and after version of this edit, that {{Geobox}} has more features for rivers than this template. I propose that we improve this template to match, then deprecate the river-specific instances of Geobox. Thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 30 June 2013 (UTC)[reply]

Strongly oppose - what is the basis for deleting this functionality of Geobox (and I presume eventually the whole template)? What policy or even guideline says Wikipedia cannot have two similar but not identical templates? Why spend all the time and effort to change this template and then to replace Geoboxes in river articles, when we have a Geobox that already works well and (as you admit) does more than Infobox:River? By the way, glad to see that you are feeling better and back on WP Andy. Ruhrfisch _><>°^° 15:03, 30 June 2013 (UTC)[reply]

I seem to recall answering this question more than once previously. Perhaps you weren't one of those participating at the time. The rationale is to reduce the long-term maintenance overhead; unify the appearance and location of information in related articles for the convenience of our readers and data re-users, and to minimise confusion for editors. Conversely, what is the rationale for having two, different, templates for the same function? As for the work involved, feel free not to do any of it. Thank you for your kind words about my health. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:45, 30 June 2013 (UTC)[reply]

Oh wait, you were involved. Here's what you said: "if you want to get rid of Geobox, then 1) fix the infoboxes so they can do everything Geobox can, and 2) make sure it is as easy as possible to convert from one to the other, then ask again". That's exactly what I'm doing. It's already been done for mountains and mountain ranges, without fuss. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 30 June 2013 (UTC)[reply]

Thanks for your reply. I have changed my mind (especially as I would have to do the work of updating the river articles I am the chief contributor to if this comes to pass). Wikipedia allows editors fairly wide leeway on how they do many different things here (please see

WP:IAR

). One example is that there are at least three different ways to cite references (with many similar but not identical templates). Are you going to "unify" those too?

Also, could you please answer my question "What policy or even guideline says Wikipedia cannot have two similar but not identical templates?" While you're at it, what policy or guideline says that we need to make life easier for our data re-users? This is a persistent theme in your posts Andy - do you have a conflict of interest? Are you being paid by any of these data re-users? Are you being paid to make things on WP more convenient? I am going to post about your proposal on the Geobox and Wikiproject Rivers talk pages (which I think you should have done already). Ruhrfisch _><>°^° 17:38, 30 June 2013 (UTC)[reply]

Your assertion that you would have to do any work in this regard is false; I even said as much above. My declaration of interests is available from my user page. I shan't be wasting time, attempting to answer rhetorical questions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 30 June 2013 (UTC)[reply]

Andy, when it says here (about you) that "His advice has been sought recently by organisations including Google and FourSquare (on their use of Wikipedia data); and The BBC, Facebook and the London Assembly (on microformats)." was that paid advice? Do you have a

COI

? Are you being paid to edit and/or get rid of templates that Google, Facebook, the BBC and other re-users do not like? These are serious questions, not rhetorical.

I ask again (and not rhetorically), could you please answer my question "What policy or even guideline says Wikipedia cannot have two similar but not identical templates?" While you're at it, what policy or guideline says that we need to make life easier for our data re-users? I will add a question - where are there examples (on talk pages or elsewhere on WP) of users or editors confused by this template? Ruhrfisch _><>°^° 18:04, 30 June 2013 (UTC)[reply]

I refer you to my earlier answer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:15, 30 June 2013 (UTC)[reply]

RE "what policy or guideline says that we need to make life easier for our data re-users", uhm, let's see, we what to make things harders for editors and readers so the site is used less and we have fewer editors helping, yeah right. I don't think so! PumpkinSky talk 18:30, 30 June 2013 (UTC)[reply]

PumpkinSky - do we write Wikipedia for general readers or to make it easier for Google, etc. to mine the data? The latter is what I am asking about re data re-users (as far as I know, we have very few corporations who are editors). I am also not aware of any complaints about information presented in any Geobox by general readers. Ruhrfisch _><>°^° 20:35, 30 June 2013 (UTC)[reply]

My impression is that this represents a huge amount of labor work that won't really add or subtract anything of value to existing river articles. I'm neutral about this change, but as an editor I'd rather spend my time on actually writing articles. Shannon 20:46, 30 June 2013 (UTC)[reply]

I often disagree with Andy's position on deleting templates but sometimes he does have good ideas and I do believe that this template could do with some changes to enhance its functionality. I've tried using it in a number of Australian river articles and always found it to be lacking, so I've had to use Geobox. Geobox has its place, so I wouldn't support deletion. --AussieLegend (✉) 23:42, 30 June 2013 (UTC)[reply]

As an example, I've created a testcase here. --AussieLegend (✉) 01:38, 1 July 2013 (UTC)[reply]

Useful, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 1 July 2013 (UTC)[reply]

"I'd rather spend my time on actually writing articles" No-one is stopping you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 1 July 2013 (UTC)[reply]

Strongly oppose. I donate my time and skills to the general public, not to for-profit data re-users who might wish me to edit as they see fit rather than as I see fit. I doubt that many Wikipedia editors want to work for free for Google or any other outside entity. Finetooth (talk) 00:04, 1 July 2013 (UTC)[reply]

If you don't want data re-users - many of whom are members of the general public, or not-for-profit organisations - to reuse your work on Wikipedia - which is perfectly acceptable under the licence you grant - then why are you editing? In any case, ease of data reuse is just one, small, part of the rationale for this change. Do feel free to address the suggestions I've made, to improve this template, though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 1 July 2013 (UTC)[reply]

Unfortunately, I have to have emergency eye surgery tomorrow, and after that won't be able to edit Wikipedia for a week or two. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 1 July 2013 (UTC)[reply]

Andy, the issue that concerns me here is editorial control, which should never be ceded to a subset of the whole collective. By consensus, the collective has already rejected your proposal to eliminate geoboxes entirely. Your proposal to deprecate geoboxes is essentially the same proposal. The English Wikipedia and the Commons are parts of a commons managed collectively; anyone, including Google, may reuse the product (encyclopedia articles, data, images) under the terms of the GFDL and other licenses and may participate in seeking changes to existing policies and guidelines. However, participating in policy discussions is not the same as setting policy. That power should remain in the hands of the collective, which has already spoken on this matter.

I wish you a speedy recovery from the eye surgery. Finetooth (talk) 15:53, 1 July 2013 (UTC)[reply]

Strongly support improving this template. Why wouldn't we want it to be as comprehensive as possible? The issue seems to be whether we then remove functionality from geobox. Personally I find that template confusing, unwieldy, and, often, less comprehensive. Frequently my question has been "which parameters do I need to extract for an article on rivers/mountains/islands/lakes?". But there seems to be divergence on that, so why don't we improve this template and then discuss the nature of geobox separately at that talkpage? Bermicourt (talk) 15:39, 1 July 2013 (UTC)[reply]

I don't think anyone opposes improving the infoboxes or, for that matter, the geoboxes. Andy's suggestion, however, is to replace geoboxes with infoboxes. That's the idea that has already been rejected. As it stands, editors who prefer infoboxes to geoboxes are free to use infoboxes. Finetooth (talk) 16:06, 1 July 2013 (UTC)[reply]

Andy's suggestion is "that we improve this template to match, then deprecate the river-specific instances of Geobox". There's no reason why we can't say yes to the first part and no to the second. It doesn't have to be an all-out oppose or support. I agree that editors should be free to use either infobox or geobox. --AussieLegend (✉) 17:55, 1 July 2013 (UTC)[reply]

Strongly oppose - I made that edit to the Tame, and did it to improve the article, both in terms of information and as the Geobox has a better format and looks more professional. There are two other reasons I oppose this, one is that nearly 4 years have passed since someone asked for the Infobox ‘origin’ to be changed to ‘source’, yet nothing has happened. I can use the Geobox, with its extra functions and neater format today, and do not have to wait for some Infobox 2 to come around. The other reason is found at Category:Geobox usage tracking for river type which lists over 13,000 uses of the Geobox: river template, it would take forever to alter (and check) those articles for a new box. Jokulhlaup (talk) 17:04, 1 July 2013 (UTC)[reply]

Comment just to be clear, I do not oppose improving any template. What I strongly oppose is removing River (or any more) functionality from Geobox, in what I suspect is a very clever and patient and stealthy way of deleting the Geobox template (remove almost all the functionalities one by one, then say - "look at this poor thing, hardly used and doesn't do much, let's delete it"). I wish Andy a speedy recovery and all the best. Ruhrfisch _><>°^° 03:16, 2 July 2013 (UTC)[reply]

Alternate proposal

Since the above doesn't seem to have gained any support, I'd like to propose an alternative, based on comments above. As User:Pigsonthewing has noted, {{Geobox}} has more features for rivers than this template. I propose that we improve this template to match the functionality of {{Geobox}}, or as much of the functionality as determined by consensus, to provide a simpler alternative to the more complex Geobox. Obviously, there are situations where Geobox may be more suitable, so it should remain unaltered for those occasions. --AussieLegend (✉) 03:11, 10 July 2013 (UTC)[reply]

Fully support and would be grateful if my request above were taken into consideration as part of the improvement drive. --Bermicourt (talk) 07:38, 10 July 2013 (UTC)[reply]

Can I suggest a simpler alternative, would it not be easier to create blank templates for {{Geobox}} rivers at different levels of complexity. You could have a Starter version for simple streams, a Mid level for larger/complex rivers, and a Full version for complex situations such as dual sources etc. It is similar to the idea used in Infobox Mountains, where they have created blank templates for different parts of the world. The unneeded commands could be removed for the simpler versions, which would remove the size and complexity issues. There would need to be some explanantion/links from the WP:Rivers page so that they could be found easily. Jokulhlaup (talk) 16:52, 13 July 2013 (UTC)[reply]

{{

Infobox Mountain}} was split out from Geobox; we can make various blank versions of Infobox river, once it's improved. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 13 July 2013 (UTC)[reply

]

Not trying to reignite any old arguments, but what's the current best practice on adding geographical coordinates (source and/or mouth) to a river article using this template? (I'm contemplating trying to add some new fields to this template for that if necessary, but if someone else already has a plan for that I don't want to step on toes / duplicate effort.) —Steve Summit (talk) 23:29, 8 February 2014 (UTC)[reply]

sounds like a good idea, since {{geobox}} supports this. what parameters would you like to add? just |mouth_coordinates= and |source_coordinates=? Frietjes (talk) 14:50, 9 February 2014 (UTC)[reply]

I was thinking of source_lat_d, source_lat_NS, mouth_long_d, mouth_long_EW, etc. —Steve Summit (talk) 11:51, 10 February 2014 (UTC)[reply]

I've taken a stab at this. See below. —Steve Summit (talk) 05:45, 21 February 2014 (UTC)[reply]

Okay, I'm adding several new parameters to make coordinate display and entry possible. For the moment I've made the changes to a sandbox copy of the template, but if there are no objections, and if no one finds any serious problems, I'll propagate the changes to the real template in a few days.

I'll describe the new coordinate syntax and template usage, but then I have a couple of questions I'd appreciate people's opinions on.

coordinate syntax

There are basically four ways to enter origin and mouth coordinates: as degrees, minutes, and seconds, as decimal degrees N/S/E/W, as signed decimal degrees, and with the {{Coord}} template. I'll illustrate each of these with an example:

degrees, minutes, and seconds:

| origin_lat_d = 42

| origin_lat_m = 30

| origin_lat_s = 40

| origin_lat_NS = N

| origin_long_d = 73

| origin_long_m = 12

| origin_long_s = 00

| origin_long_EW = W

| mouth_lat_d = 42

| mouth_lat_m = 55

| mouth_lat_s = 39

| mouth_lat_NS = N

| mouth_long_d = 73

| mouth_long_m = 39

| mouth_long_s = 35

| mouth_long_EW = W

decimal degrees:

| origin_lat_d = 42.5539

| origin_lat_NS = N

| origin_long_d = 71.1441

| origin_long_EW = W

| mouth_lat_d = 42.693

| mouth_lat_NS = N

| mouth_long_d = 70.790

| mouth_long_EW = W

signed decimal degrees:

| origin_lat_d = 42.1807

| origin_long_d = -72.3654

| mouth_lat_d = 42.1482

| mouth_long_d = -72.6217

{{Coord}} template:

| origin_coordinates = {{Coord|42.4654|N|71.3580|W|type:river|display=inline}}

| mouth_coordinates = {{Coord|42.6465|N|71.3025|W|type:river|display=inline,title}}

These examples are from the Hoosic, Ipswich, Chicopee, and Concord River articles, respectively, so you can see these new template invocations in action there.

usage

The template puts the mouth (as opposed to the origin) coordinates at the top of the article, because that seems to be the consensus.

questions

Personally, I think it's silly to have Geobox/type/river distinct from Infobox river, and ideally I'd hope one day we could settle on one and migrate to it. You may disagree, and I'm not trying to raise that issue today anyway, but your opinion on that question will probably influence your answer(s) to the two questions I do have:

1. What should the origin coordinate parameters be called? Originally I was planning on calling them source_lat_d, source_long_d, etc., for compatibility with Geobox/type/river. But in the end I decided to name them origin_lat_d, origin_long_d, etc., since "origin" is what Infobox river uses for the source, and having parameters with two different naming conventions would be confusing. (Using parameter names identical to Geobox/type/river would seem to make converting from one to the other easier, but actually, any conversion from one to the other is going to involve renaming a bunch of other parameters anyway, so what's a few more?)
2. Do we really need or want the third option, using the origin_coordinates and mouth_coordinates parameters? Some people seem to like this style, and it's supported by e.g. Infobox school. But Geobox/type/river does not support this style of coordinate entry, so any invocations of the new Infobox river that use that style would be that much harder to convert to Geobox/type/river later, if that should ever be necessary.

Anyway, please comment below and let me know what you think. As I said, I expect to make the changes to the official template soon. —Steve Summit (talk) 05:45, 21 February 2014 (UTC)[reply]

comments

Having used both Geobox and the individual infoboxes such as this one I prefer the latter. I found Geobox very unwieldy and difficult to use. Turning to your actual questions:

• We need the ability to display either "source" or "origin" to take account of the fact that some rivers are viewed as beginning at a source and some at e.g. the confluence of two headstreams each of which has its own name.
• It is useful to be able to input the coordinates using the {{coord}} format, especially e.g. when translating articles as this is often how it will come across. So both are useful.

--Bermicourt (talk) 09:07, 21 February 2014 (UTC)[reply]

Making the label changeable would be straightforward with an origin_label parameter. You want me to add that while I'm at it? (I wonder what the default should be -- "source" or "origin"?) —Steve Summit (talk) 14:10, 22 February 2014 (UTC)[reply]

We should definitely deprecate the use of geobox for rivers; add any necessary features from it to this infobox, have a bot make replacements, then permanently remove river features from geobox. This is (has?) been done for mountains in Geobox. We most certainly do not need to worry about making conversions in the reverse direction. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 21 February 2014 (UTC)[reply]

GNIS entries (such as this one: 649969) express decimal coordinates as positive/negative numbers, instead of specifying NSEW. Would there be a way to accommodate that method? It would make it speedier to copy-paste from GNIS entries.

(Separately, I do have opinions regarding geoboxes vs infoboxes, and I won't share them here.) --

talk) 16:16, 22 February 2014 (UTC)[reply

]

Yup, ±decimal works, too. (The {{Coord}} template, which all of this is built on, is pretty amazing.) —Steve Summit (talk) 17:17, 22 February 2014 (UTC)[reply]

Hmm, if I just use ±decimals in the | origin_lat_d and | origin_long_d fields (without specifying NSEW in the corresponding NS and EW fields), it breaks the template. (And it breaks doubly if I try combining ±decimals with NSEW designations.) Do I have to paste in the {{

talk) 18:02, 22 February 2014 (UTC)[reply

]

Well, I thought it worked, and I thought I'd tested it. Let me play with it and see. —Steve Summit (talk) 20:04, 22 February 2014 (UTC)[reply]

Okay. Sorry for the false start. I thought I'd tested it, but obviously I didn't, because you're right, it didn't work. (I guess the {{

Geobox coor}} instead, although it's got some issues of its own (like, evidently display= is different). Anyway, please give it another try. See Chicopee River for an example. —Steve Summit (talk) 21:45, 22 February 2014 (UTC)[reply

]

It's working for me now, too, thanks! --

talk) 23:08, 22 February 2014 (UTC)[reply

]

Okay, I've deployed the changes.[1]. The new coordinates parameters are already in use on five pages: Chicopee River, Concord River, Ipswich River, Little Bighorn River, and River Manifold. I'll update the template documentation next. There's now the task of migrating coordinates out of the random places they're in now into the template; I'll start a thread on that over on Wikipedia talk:WikiProject Rivers. Thanks for everybody's input here. —Steve Summit (talk) 13:29, 23 February 2014 (UTC)[reply]

As discussed above, we should improve this template by importing any beneficial (if not all) river features from {{Geobox}}. I intend to start doing so shortly; does anyone have any views as to what should or should not, be imported, and how? Parameters in geobox, with with no equivalent here, include:

• |category=
• |country=
• |state=
• |region=
• |district=
• |municipality=
• |parent=
• |city=
• |landmark=
• |source_location=
• |source_region=
• |source_country=
• |source_lat_d=
• |source_lat_m=
• |source_lat_s=
• |source_lat_NS=
• |source_long_d=
• |source_long_m=
• |source_long_s=
• |source_long_EW=
• |source1=
• |source1_location=
• |source1_region=
• |source1_country=
• |source1_elevation=
• |source1_lat_d=
• |source1_lat_m=
• |source1_lat_s=
• |source1_lat_NS=
• |source1_long_d=
• |source1_long_m=
• |source1_long_s=
• |source1_long_EW=
• |source_confluence=
• |source_confluence_location=
• |source_confluence_region=
• |source_confluence_country=
• |source_confluence_elevation=
• |source_confluence_lat_d=
• |source_confluence_lat_m=
• |source_confluence_lat_s=
• |source_confluence_lat_NS=
• |source_confluence_long_d=
• |source_confluence_long_m=
• |source_confluence_long_s=
• |source_confluence_long_EW=
• |mouth_location=
• |mouth_region=
• |mouth_country=
• |mouth_elevation=
• |mouth_lat_d=
• |mouth_lat_m=
• |mouth_lat_s=
• |mouth_lat_NS=
• |mouth_long_d=
• |mouth_long_m=
• |mouth_long_s=
• |mouth_long_EW=
• |width=
• |depth=
• |volume=
• |discharge_location=
• |discharge_max=
• |discharge_min=
• |map_background=
• |map_locator=
• |map_locator_x=
• |map_locator_y=
• |website=
• |commons=
• |footnotes=

plus imperial equivalents. It might be worth testing to see whether some of those (e.g. |category=, |landmark=, |width=, |website=, |commons=) are used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 26 March 2014 (UTC)[reply]

seems like the list should be revised, given the recent edit history. Frietjes (talk) 16:54, 26 March 2014 (UTC)[reply]

Oop, after posting at the Rivers Wikiproject talk page I found this. Give me a day or two and I'll respond with some detailed comments about what I'd like to see in a river infobox. Pfly (talk) 03:14, 5 April 2014 (UTC)[reply]

Okay, I said I'd post something, but looking at Infobox River and comparing it to Geobox River I find so much troublesome I can't address all of it. But here's some (for Geobox examples, see pages like Rogue River (Oregon) and Columbia River). I like how the Geobox groups similar things together and uses fine lines to organize information. So you get, for example, the parameter name Source in bold, then whatever other parameters relate to it below, like "location", "elevation", "coordinates", etc. In the Infobox information about similar things do not always appear together, like "Mouth" and "Mouth elevation". The organization of information in Geobox seems much more readable.

Also in the Infobox you get longer parameter names, which frequently wrap, making things harder to read, like "Mouth" and "Mouth elevation". Or "Left tributaries" and "Right tributaries" instead of a simple "Tributaries" field with "left" and "right" subfields. Same thing with "Basin countries" and "Basin area". At least the mouth coordinates are kept with the Mouth parameter in the Infobox. On the other hand there's "Origin", which can have coordinates just like "Mouth", but the related elevation parameter is not origin_elevation but source_elevation. More confusing is that both "Origin" and "Source elevation" are linked to the page River source.

Also confusing is the way footnoting works. I like how in Geobox if you want a footnote you add a parameter with _note appended for it. So "length" and "length_note". Or a slightly less obvious one, after specifying coords with "mouth_lat_d", "mouth_lat_m", etc, you can add a footnote with "mouth_coordinates_note". I don't see how to add a footnote to coords specified in this way in Infobox. Adding footnotes to things like "length" seems weird. Maybe I'm not understanding but it seems Infobox gives you a "length" parameter in which you use a "Full-text length of the river, using {{convert}} template if necessary". And you can append a footnote reference. But if you use length_mi or length_km and want a footnote, you put it under the length parameter? That's....counter-intuitive. "length_note" makes more sense.

I'm not completely happy with the way discharge data is handled by either template, but find Geobox better. The Infobox seems to assume you want to specify "average discharge" for an unspecified location—presumably the mouth. Usually discharge data is calculated at stream gauges that are often not at the mouth. It is important to be able to say where the discharge data is being calculated. Geobox has a "discharge_location" location parameter where you can say things like "for river mile 13", or "for Gage 04j, above Foo Creek", etc. Geobox also gives you fields for average, max, and min discharge stats. Max and min values are commonly cited and important. The Infobox example somehow gives us subfields with "annual average", "June", and "December". That might be useful in addition to max and min. Ideally one could cite various discharge stats easily. Neither template has an easy way to do that. The subfields in the Infobox are not explained—apparently you have to edit the page and examine the code? As with other parameters I found that footnotes for discharge data go under the "discharge" parameter, which is weird.

Also confusing about the Infobox is the parameter names regarding pictures and maps. If you want a picture you use image_name for the file, but when you want a map you don't give the file with map_name but rather image_map?? This is particularly confusing since it clearly doesn't mean an

imagemap

. Also, you use caption for your image (picture) but map_caption for your map. It all seems rather inconsistent.

Another apparently inconsistent thing is "elevation". It appeared Infobox provided mouth_elevation fields but not source_elevation. It does provide elevation fields. I didn't see how a river could have a single elevation. I guessed the idea was to use the convert template with a range of values. However when I tried it out the elevation fields are displayed as "Source elevation".

Finally, reading the list of Infobox parameters I saw native_name and native_name_lang. But the native_name_lang wants an ISO code? It took me a bit to figure this out. I tried it with the ISO code for the Quinault language, which according to Ethnologue is "qun". But nothing displays in the Infobox. I also could not get "other_name" to display anyway. (edit: Oops, it did work, displaying "Other name" like any other parameter; I guess I expected something in the box's header, near where the main name is shown) I put my pretend Infobox at User:Pfly/tests.

There are other things I could point to, but this seems plenty for now! Sorry for being so critical. One Infobox thing I did like is the "progression" parameter. Pfly (talk) 05:50, 13 April 2014 (UTC)[reply]

The ISO code of the native language is used in the lang attribute of the underlying HTML. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:02, 14 April 2014 (UTC)[reply]

Moved from "Template cleanup and improvements" section. Rehman 13:39, 29 January 2016 (UTC) [reply]

Navigability. The examples from German Wiki that I can find have the following text: "only during the rainy season" and "394 km from Koblenz to Neuves-Maisons". I'm not hard over on this as I can see pros and cons.

Discharge data. Again the German Wiki template has provision for 6 pieces of data at the source and at named gauges using parameters like "source_discharge", "source_discharge_period" (e.g. 1960/2005), "source_discharge_reference", "gauge1", "gauge1_discharge", "gauge1_discharge_period" and "gauge1_discharge_reference". The 10 sub-parameters of "gaugeX_discharge" are the name, distance from the mouth, size of the catchment (at that point), lowest discharge rate, date of the lowest discharge rate, average discharge rate, date of the average discharge rate, highest discharge rate, date of the highest discharge rate.

HTH. Cheers. Bermicourt (talk) 21:30, 27 January 2016 (UTC)[reply]

Hi Bermicourt. Noted on the Navigability; I guess we'll leave that out for now. For discharge data, how about something like this: We create an entirely new header (like "Physiognomy") and allow that section to have from something like gauge1 to gauge10 (similar to the source1... parameters), which can have additional parameters to display location, coord, period, and min-avg-max values. Is that good? Rehman 14:54, 28 January 2016 (UTC)[reply]

Sounds fine to me. I'll also have to look at whether Infobox:Fluss can be amended to automatically display the gauge and discharge info. Bermicourt (talk) 08:38, 29 January 2016 (UTC)[reply]

Update: Added as discharge1.... Pending period and coord params. Rehman 15:34, 12 February 2016 (UTC)[reply]

Scan results

Tasks

Rename

• origin_long_s → source1_long_s
• origin_lat_s → source1_lat_s
• origin_long_m → source1_long_m
• origin_lat_m → source1_lat_m
• lakes → waterbodies
• origin_long_EW → source1_long_EW
• origin_lat_NS → source1_lat_NS
• origin_lat_d → source1_lat_d
• origin_long_d → source1_long_d
• native_name_lang → name_native_lang
• native_name → name_native
• blank_name → custom_label
• blank_info → custom_data
• other_name → name_other
• image_map → map
• right_tribs → tributaries_right
• left_tribs → tributaries_left
• discharge → discharge1_avg
• watershed → basin_size
• elevation → source1_elevation

Rename (with template conversion)

• discharge_cuft/s → discharge1_avg
• elevation_ft → source1_elevation
• discharge_m3/s → discharge1_avg
• mouth_elevation_m → mouth_elevation
• elevation_m → source1_elevation
• watershed_sqmi → basin_size
• watershed_km2 → basin_size
• origin_coordinates → disperse this over source1 coordinates
• mouth_coordinates → disperse this over mouth coordinates
• length_mi → length
• mouth_elevation_ft → mouth_elevation
• length_km → length

Rename (only if simultaneous with any of above)

• caption → image_caption
• location → basin_cities
• image_name → image
• mouth → mouth_location
• origin → source1_location
• river_name → name

Discussion

Hi. As some of you may already be aware, I have been working on a revamped version of this infobox here. Since it is now almost complete, I would like to bring it up here for further discussions/improvements before we roll it to the main template space. To summarize, some of the main changes are as follows:

1. New parameters has been added to enable a more detailed infobox. You can see the full skeleton (with dummy details) in the link above.
2. Looking at the existing doc page, you will notice that it is extremely long, mostly because conversions are hardcoded into the template. Infoboxes should not have hardcoded parameters with a specific format to use (i.e. km or mi). The user should be the one deciding on the preferred unit depending on the article/subject (or the doc page should state so). Having these separate parameters also make the whole skeleton unnecessarily large. The best option is to simply move the fields to a more generic parameter (example: length_km → length), and use the {{Convert}} template. To fix this:
   (a) The parameters are changed to a more generic parameter (example: length_km → length), with the use the {{Convert}} encouraged. But of course;
   (b) The old parameters will be simultaneously functioning (still working on it), while in the mean time, a bot will sweep through articles to
   (c) Scan for incorrect parameter usages (i.e errors), usages of non-existing parameters, and also to standardize parameter usage.
3. The bot sweep will be done in one go, and hence will give us a good opportunity to tidy-up and stylize the parameters simultaneously, even if the changes are trivial. If you look closer at the new template skeleton listed on the sandbox-doc page, changes like native_name → name_native and left_tribs → tributaries_left makes the overall skeleton look much neater thanks to the ordered prefix.
4. The template also supports additional fields such as up to five sources and mouths, waterbodies, waterfalls, bridges, custom labels, free-form bottom section, etc. See the link above.

Please share your views if you think there is something we could do better. I will keep this thread open for about a week so we have time to discuss before rolling the new version, while looking at the bot results to determine the best way forward. Cheers, Rehman 15:49, 26 January 2016 (UTC)[reply]

Looks pretty impressive overall!

I think I spotted a typo in one of the parameters: shouldn't "basis_cities" be "basin_cities"? Also some additional river-specific parameters that would be useful are:

• "river system" i.e. the parent river system that the river is part of
• "index number" i.e. the official (usually national) hydrographic index number for the river. Used in the USA, Canada, Germany, Austria, France, Russia, etc.
• "navigability" i.e. when and where the river is navigable
• "ports" i.e. inland ports along the river
• It might also be good if the discharge and water levels could be associated with a location e.g. one or more named river gauges along the river. If that's difficult, it could be added at a subsequent stage

Hope that helps. Bermicourt (talk) 17:26, 26 January 2016 (UTC)[reply]

Thank you. :) Yes, basis should be basin, good spotting. I agree with your points 1, 2, 4, and will add them soon. Would you be able to provide an example on the type of content that should go in navigability? While it sounds like a good addition, sentences/longer text are

not allowed in infoboxes (the same reason I am thinking of starting a discussion regarding the etymology field, after this cleanup). For your last point, do you mean to add something like a location field for the depth and discharge sections (similar to the source1 section)? I'm off to work now, will look into it deeper when I reach back home (in about 12hrs), or if I can sneak in while in office. Regards, Rehman 00:00, 27 January 2016 (UTC)[reply

]

@Bermicourt: I went ahead and added river system and ports. For index numbers, it can be slotted into the custom_label/custom_data fields for now, as only a limited number of articles have such information... Waiting for your reply on "navigability" and "discharge location". Rehman 14:18, 27 January 2016 (UTC)[reply]

I have moved further replies regarding discharge data to new section "Discharge data" below, as it involved adding/improving additional fields. Rehman 13:39, 29 January 2016 (UTC) [reply]

Rehman, can you provide an example of a river with more than one mouth? from what I have read, a river can have many sources, but only one mouth, but I could be wrong. if there are no articles about rivers with more than one mouth, we should probably remove the numeric suffix from the mouth parameters. Frietjes (talk) 22:55, 2 February 2016 (UTC)[reply]

Frietjes: I think you are right. I did a search and did not find any river that has two or more mouths. And even if there is, I'm quite positive that there would not be more than a dozen at max. I will remove the multiple-mouth parameters shortly. Thanks for pointing out! Rehman 14:08, 3 February 2016 (UTC)[reply]

infobox lake}}). Frietjes (talk) 00:59, 11 February 2016 (UTC)[reply

]

Hmm... Do we have a template somewhere that could auto-convert and generate the region code from the basin_country parameter? Either way, I agree with you that we need to include the region code. But I am leaning towards not having an inline ref for the coord, as that is something that is very rarely available (most of the coords on wiki are manually derived by editors, and not stated on a source itself), and in my personal opinion, clutters the infobox. Rehman 16:01, 12 February 2016 (UTC)[reply]

There are certainly rivers with multiple mouths. The Grand Calumet River, arguably the Chicago River, the Amazon. Rmhermen (talk) 03:44, 11 February 2016 (UTC)[reply]

I see. in that case, we should probably default to |mouth_location=, but allow for |mouth2_location= as the need arises. In the case of Amazon River, it seems like it's more of a Delta region, since there are so many. Frietjes (talk)

Yes, the Amazon River case is a delta. Also, those examples doesn't seems to be valid as those are more or less due to human-modifications of the mouths. And even if an "all natural" dual-mouth river exist, I'm quite certain that there would be less than, say 5? I dont think we should include parameters that will be used just for a very few articles. For those cases mentioned above, we could simply include the main mouth, or use </br>.

If for any reason, we do add support for multiple mouths, I strongly suggest we add the mouth1 prefix. That gives the editor an easy understanding that multiple entries are supported, and makes the skeleton look neat. Rehman 16:01, 12 February 2016 (UTC)[reply]

the right/left tributaries look pretty bad in Speyerbach, with text overlapping on my browser. would be better to just use two fields, rather than a table. Frietjes (talk) 21:00, 19 February 2016 (UTC)[reply]

May I suggest some minor revisions to the template:

• Change "origin" to "source" since that is the generally accepted term for the start of a river
• Change "watershed" to "catchment area" or "drainage area", since watershed means different things to US and non-US geographers
• Change "basin countries" to "location" since, for large countries like USA, Russia or Germany, it is too vague. "Lower Saxony and Hesse, Germany" is a good location descriptor but they are not basin countries.
• Slightly increase the field name column, so that names with 2 words can still fit on one line and don't unduly extend the table
• Slightly increase the data column, so that a full coord can display on one line (see problem at Gerdau (river))
• Consider tweaking the format to include lines (as at de:Böhme (Fluss)) - looks neater IMHO.

--Bermicourt (talk) 12:06, 6 October 2009 (UTC)[reply]

Suggest that we harmonize the display order of Imperial versus SI units. I just spent more time than I'd like to admit in trying to figure out why the Niagara River apparently had less flow than the Colorado River, despite draining an almost equal area in a wetter location, until I realized the display order was reversed in the two pages so the Niagara does indeed have the greater flow. Now, the Colorado River page uses Geobox, but apparently the River template has options for changing the display order, which is confusing, in my opinion.74.235.210.32 (talk) 21:55, 2 November 2014 (UTC)[reply]

Is there a reason why river classification (ie. blackwater, etc.) is not included in the template? I think this is a good idea Valerie (talk) 20:12, 8 April 2016 (UTC)[reply]

Also, why is the template not a Geobox? Valerie (talk) 21:45, 8 April 2016 (UTC)[reply]

Like other templates that accept geographic coordinates, this one needs a way to "turn off" the title display (of the mouth coordinates, in this case) to avoid overlapping coordinates in the title position when more than one infobox is used in an article. See Big Sandy Creek (Illinois), for example. I know little about template coding, but there has to be a way of overriding the "title=y" for the mouth coordinates. Deor (talk) 12:11, 21 April 2016 (UTC)[reply]

Hi Deor. The template is currently undergoing some maintenance. I'll definitely add this along with the other updates (which is pending a bot sweep). Rehman 14:57, 21 April 2016 (UTC)[reply]

Deor, fixed, thank you for noticing. Frietjes (talk) 15:11, 21 April 2016 (UTC)[reply]

Ah, Frietjes, we meet again. You might want to consider the case of River Cleddau with reference to this and the SSSI template. As we have it right now, the River Cleddau article describes two rivers, the Eastern and the Western River Cleddau which meet at a common mouth. That doesn't fit with this template well (and I acknowledge that River Cleddau could be split into two articles, one for each component river.) In addition, Eastern & Western both are SSSI; Eastern plus Western is a single Special Area of Conservation; and there's a second SAC at the head of the Eastern. So. A veritable template Clapham Junction, I think. Any thoughts on how we proceed, template-wise, much appreciated. --Tagishsimon (talk) 23:29, 23 April 2016 (UTC)[reply]

I've tried to change several vague and pretentious parameters on the template, but have been reverted multiple times for no reason. Specifically, "physiognomy" should be "physical characteristics" since the former appears to be some ind of pretentious term used solely to sound wordy and impressive, whereas the latter actually describes the parameter. Also, "size" is senselessly vague, so I tried to change that to "watershed area", but was again reverted for no reason. --

Both of these changes seem sensible to me. Physiognomy appears to be plain wrong; "physical characteristics" works well. And "Size" does indeed seem ambiguous. The variable is "basin size" and this does seem akin to Drainage basin - I'd support that as the label rather than watershed. I'm hoping that Rmhermen will give us the benefit of their thoughts on this, so that we can move on. --Tagishsimon (talk) 11:55, 1 June 2016 (UTC)[reply]

I prefer Jakec's suggestions. But either way, edit warring was not the way to go, and Rmhermen was not wrong in reverting as this is more of a personal preference. Rehman 13:50, 1 June 2016 (UTC)[reply]

I too prefer the suggested changes in both cases. Characterizing the current ones as "gibberish" seems unnecessarily hostile. --TimK MSI (talk) 02:13, 2 June 2016 (UTC)[reply]

Physical Characteristics is a better descriptor, but Watershed is an Americanism in this context. Basin Area would be a better term, linked to Drainage Basin...Jokulhlaup (talk) 14:14, 2 June 2016 (UTC)[reply]

Since it seems there's now "consensus", can someone please change it back. BTW I am fine with "basin size" (anything is better than "size") though perhaps "basin area" would be even more specific. --

talk) aka Jakec 23:50, 3 June 2016 (UTC)[reply

]

I've went ahead and changed it to "basin size" (as the parameter is also called that). Thanks, Rehman 00:04, 4 June 2016 (UTC)[reply]

I'm curious why the only available "_cities" field is not simply used to list cities through which the river flows, instead of cities in its drainage basin. Pittsburgh and Denver are both in the Mississippi River basin but are far away from the Mississippi River. The "basin_cities" field would appear to encourage their inclusion in a Mississippi River infobox, but I don't think many editors/readers would find it desirable to include them. Would it be possible to "liberate" the "basin_cities" field from its connection to the river basin? Or, alternatively, to have an additional "cities" field that would be intended to accommodate only cities situated along the river? --TimK MSI (talk) 12:57, 2 June 2016 (UTC)[reply]

Hey there. I agree with what you said, including in the section immediately above. Lets wait a bit longer till the current bot maintenance is complete, before we go deeper into editing. If you're wondering, the current task is just a maintenance task to neaten out existing parameters in articles already using Infobox River. Cheers, Rehman 13:49, 2 June 2016 (UTC)[reply]

@TimK MSI, I went ahead and did the change as it doesn't really impact the current bot task. We now have a new cities field, which is for cities along the river. Cheers, Rehman 13:39, 4 June 2016 (UTC)[reply]

Thanks --TimK MSI (talk) 11:12, 7 June 2016 (UTC)[reply]

Rivers also flow through towns and other settlements, again this is where the adaptability of the Geobox is useful. I have altered the cities parameter for the Penk example to show three towns, without the need for a separate parameter...Jokulhlaup (talk) 10:46, 7 June 2016 (UTC)[reply]

Could we bring over the method used at Template:Infobox settlement? This uses fields named subdivision_type, subdivision_name, subdivision_type1, subdivision_name1, etc., up to subdivision_type6, subdivision_name6. This would allow editors to specify whichever political jurisdictions are appropriate to a given article (countries, provinces, states, counties, cities, towns, municipalities, townships, etc.) This solves the plural/singular problem as well, because the plural/singular form is set case-by-case in the subdivision_type* fields. --TimK MSI (talk) 11:12, 7 June 2016 (UTC)[reply]

Yes this is a better way to go. @Frietjes, may I trouble you for some help to add this support? I tried adding it, but I can't get it to work properly... Thanks in advance! Rehman 08:08, 6 August 2016 (UTC)[reply]

Rehman, added. the use of |subdivision_type1= sets the label and allows for use of |subdivision_name1=. if |subdivision_type1= is not specified, then |subdivision_name1= is ignored, and the value set by |country= is used instead. similar for |subdivision_type2=/|subdivision_name2=/|states= and |subdivision_type3=/|subdivision_name3=/|cities=. Frietjes (talk) 12:49, 6 August 2016 (UTC)[reply]

Many thanks, Frietjes! @TimK MSI, FYI. :-) Rehman 16:54, 6 August 2016 (UTC)[reply]

What is the new paramenter replacing location that is found in quite a number of infobox uses? Agathoclea (talk) 19:42, 22 September 2016 (UTC)[reply]

Hi. Any one of the below groups (depending on if any is used):

| subdivision_type1  = 
| subdivision_name1  = 
| subdivision_type2  = 
| subdivision_name2  = 
| subdivision_type3  = 
| subdivision_name3  = 

--Rehman 23:31, 22 September 2016 (UTC)[reply]

Fixed; please ignore (sorry for the inconvenience)N Oneemuss (talk) 20:49, 25 October 2016 (UTC)[reply]

In this sandbox text page, I attempted to cite my sources for two sets of geographic coordinates (as I've done in the live geobox version of the same article). I can't figure out how to do it without breaking the template. Geographic coordinates are often entered only in the infobox (since they are not comfortably readable in the prose of an article), so I think it's important to have the ability to cite a source for them in the infobox. Can this be done? Thanks--TimK MSI (talk) 18:03, 2 October 2016 (UTC)[reply]

Resolved

 – Another editor solved the problem by moving the citations to "source1_coord_ref" and "mouth_coord_ref" fields.

--TimK MSI (talk) 17:27, 13 November 2016 (UTC)[reply]

I imported the location map feature from {{infobox settlement}}, so this works. this should help simplify the maps that Aymatth2 has been adding to river articles. please let me know if there are any problems. Frietjes (talk) 16:19, 25 December 2016 (UTC)[reply]

That is a big improvement. Even with a basic stub like

Vermelho River (São Lourenço River) we should at least know the mouth coordinates. A map makes the stub much more informative, and |pushpin_map= ... |mouth_coordinates= {{coord ... parameters make the river template more like other location-type templates. Aymatth2 (talk) 20:03, 25 December 2016 (UTC)[reply

]

See this RFC. basically, there is now a LUA module which can take a {{coord|XX|YY|ZZ|NS|AA|BB|CC|DD|EW}} as input and return the latitude and longitude from inside the template. since this is more compact than the method used by this template, the RFC proposes using this more compact method and deprecating the less compact form. Frietjes (talk) 12:12, 13 August 2016 (UTC)[reply]

What was the outcome of the RfC? Agathoclea (talk) 19:42, 22 September 2016 (UTC)[reply]

@Frietjes: I personally don't see any negative impact of using the compact form on this template... If that method is the new norm, would you be able to show the way forward from here? Is it as simple as a bot updating the instances in the articles? And if so, will we be able to simply insert a {{Coord}} into a simple parameter like |coordinates=? Sorry for the dumb question, I'm not too familiar with the way the coord template works... Cheers, Rehman 01:50, 4 December 2016 (UTC)[reply]

The outcome of the RFC was to replace all individual coordinate parameters with coordinates = {{coord}}. A bot can do the work for all or most infoboxes that use coordinates. See Wikipedia:Coordinates in infoboxes, which may look daunting, but you don't have to make the changes yourself. We will get to each infobox in due time. – Jonesey95 (talk) 06:36, 5 December 2016 (UTC)[reply]

Rehman and Jonesey95, I have added alternative syntax, Category:Pages using infobox river with deprecated coordinates parameters for tracking, and updated the documentation. I decided to use a separate tracking category since the mouth_, source1_ syntax here is a bit different from the other infoboxes, and we may be able to get Plastikspork to help. I am sure he is going to be please since he just performed the opposite transformation for us a few months ago. Frietjes (talk) 15:08, 8 December 2016 (UTC)[reply]

Thanks Frietjes, that's great. Do you think we can do the syntax update along with this? Rehman 15:23, 8 December 2016 (UTC)[reply]

Rehman, if that bot can do the coordinate transformations, that would be great to combine the tasks. otherwise, we will need a second bot run. Frietjes (talk) 15:26, 8 December 2016 (UTC)[reply]

it looks like these have all been fixed, so I have updated the template syntax, but temporarily kept the tracking in there in case any new ones pop up. I have also added some checking for parameters without units in Category:Pages using infobox river without units after spotting a few problematic articles. for the elevation it's particularly bad since there is no label associated with the number either, so you just get a floating number with no context. Frietjes (talk) 15:12, 27 December 2016 (UTC)[reply]

I think of a river's source and mouth as being characteristics of the river rather than the basin -- particularly in cases in which a river's source is expressed in the infobox as the confluence of two smaller streams. I think these changes would make sense:

• Move the "main source" and "river mouth" fields to the top of the "physical characteristics" section
• Move the "physical characteristics" section ahead of the "basin" section
• Rename "main source" to "source" and "river mouth" to "mouth."

Agreements/disagreements? Thanks-- TimK MSI (talk) 18:46, 2 October 2016 (UTC)[reply]

I personally like your suggestions. I'm not too sure about the last point though, as the template supports multiple sources/mouths. Cheers, Rehman 22:53, 11 November 2016 (UTC)[reply]

Thanks! In the case of rivers with multiple sources that were separately specified in the infobox, would it be undesirable/confusing to have the "Main source" field read "Source" instead, given that additional sources would be specified as "2nd source," "3rd source," etc.? Looking at the the definitions given in the "River source" article, I think "main source" implies the "the most distant headwater source (irrespective of stream name)." In practice, we often give the source in the infobox as a confluence of other streams, or the location of the farthest headwater assigned the same name (irrespective of distance from the river mouth). I think "source" is a better label than "main source" in these latter instances.

It's not clear to me from the documentation how one would add multiple mouths to the infobox. If it's possible to do so, I think it would be uncommon, and if it were to be labeled as a "secondary mouth" or "other mouth," I don't think it would be confusing if the current "river mouth" field were relabeled "mouth" for conciseness.

Thanks-- TimK MSI (talk) 17:22, 13 November 2016 (UTC)[reply]

Sorry for the late reply, TimK MSI, RL has been quite tough for me lately. Yes, you are right, there should be no issue with your 3rd point well. I'd like to add further points as well, before we proceed with the change:

• altitude_difference is used to state the alt. diff between the source and the mouth. Since the mouth is almost always at 0m above sea level, the alt-diff is almost always equal to source1_elevation. Maybe we should remove this? I added this sometime back, but now I'm wondering if that was a dumb move.
• If the above is done, it leaves us with just five short labels under the "Basin" heading. I propose we merge that to the "Features" section below, and just label is as...well... "Basin features". Any comments?

Kind regards, Rehman 02:07, 4 December 2016 (UTC)[reply]

Many rivers do not run to the sea (at least not directly) Rmhermen (talk) 06:23, 4 December 2016 (UTC)[reply]

Apologies again for the delay. Regarding altitude_difference, I agree that most rivers don't run to the sea. But I guess I don't see the value of displaying a number that results from a simple subtraction calculation of two numbers already displayed in the infobox. Are there scientific (or other) circumstances in which people would use "difference between source elevation and mouth elevation" as a meaningful data point when comparing multiple rivers to one another? I think I've seen "fall per mile" or "fall per km" used as a meaningful data point, but not a simple altitude difference. --TimK MSI (talk) 18:40, 27 December 2016 (UTC)[reply]

On the separate matter of groupings of fields and what they should be labeled, I think "basin features" could work as suggested by

GNIS and HUC identifiers. These don't really make sense in a section labeled "features." If the sections weren't labeled, the custom fields could just be in an unnamed rectangle of their own, as they are on the settlement infobox. --TimK MSI (talk) 18:52, 27 December 2016 (UTC)[reply

]

@Rehman: Any thoughts on these suggestions? Thanks! --TimK MSI (talk) 12:00, 4 February 2017 (UTC)[reply]

TimK MSI: I have merged the sections for now. If I am correct, the no-header format is based on an entirely different way of writing the template. Either way, we can always do that in the days to come. For now, we have a "Basin Features" section! :) Let me know if you have any comments on the changes made. Cheers. Rehman 01:10, 11 February 2017 (UTC)[reply]

@Rehman: Thank you! I'd still like to see the source and mouth pulled out of the "basin features" section and moved to the top of the section that contains the river length, on the grounds that these fields (source and mouth) are most applicable to the river, rather than its basin. And I'd like to see that section moved ahead of the "basin features" section -- the logic being, first we're describing the river: its jurisdictions, where it starts and ends, its length and size. Then we're describing the basin. Does that make sense?/sound good?/sound bad? --TimK MSI (talk) 13:41, 13 February 2017 (UTC)[reply]

Yes, it makes sense. Will start working on it. Cheers, Rehman 23:54, 13 February 2017 (UTC)[reply]

Apologies for the long delay, TimK MSI (I forgot about it). I'll be doing this soon, as there were no objections to it. Rehman 02:31, 1 October 2017 (UTC)[reply]

This is done, TimK MSI. Is it better now? Rehman 22:59, 1 October 2017 (UTC)[reply]

Rehman, thanks!, I'm still waiting for the changes to slowly be implemented across more articles to fully assess. But it looks like the length/source/mouth all got moved to the top section? I was thinking the change would result in a "Physical characteristics" section containing Source, Mouth, Length, Width, Depth, Discharge, in that order. (As it stands now, "Physical characteristics" has gotten pretty slim and contains mostly little-used fields, and the top section is a bit overcrowded with frequently-used fields.) I'm sorry I wasn't clearer! By using your edit as a guide I *think* I could manage to make changes to that effect, if necessary. Thanks-- TimK MSI (talk) 21:01, 2 October 2017 (UTC)[reply]

No worries. I went ahead and changed again. Is this better? Rehman 03:27, 3 October 2017 (UTC)[reply]

Yes, thank you! --TimK MSI (talk) 09:23, 4 October 2017 (UTC)[reply]

{{Geobox|River}}

Penk
The Penk at Penkridge, with Penkridge Viaduct in the background.
Location
Country	England
County	Staffordshire
Physical characteristics
Source
• location	Perton, South Staffordshire
Mouth
• location	Confluence with the Sow
• coordinates	52°48′12″N 2°04′55″W / 52.80333°N 2.08194°W / 52.80333; -2.08194
Length	36 km (22 mi)
Basin size	356 km2 (137 sq mi)
Discharge
• location	Penkridge
• average	2.27 m3/s (80 cu ft/s)
Basin features
Progression	Sow—Trent—Humber—North Sea
Tributaries
• left	Moat Brook, Whiston Brook, Pothooks Brook, Rickerscote Drain
• right	Watershead Brook, Saredon Brook, Deepmoor Drain

Wherever possible, we should replace {{Geobox}} with a more specific template, such as this one, instead of {{tlg|Geobox|River}} (examples above; geobox first). Here's a sample conversion. How might we speed up, or automate, this prcess? What are the barriers to doing so completeley? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:28, 1 June 2016 (UTC)[reply]

As discussed elsewhere some time ago, there is a bot sweep currently in progress (by SporkBot) - see section above. Once that is done, it will be fairly easy to switch articles to use this template, as all the necessary fields of Geobox are now in Infobox River. Or if you like, you may wish to manually change articles for now, or request a separate bot task to change the uses of Geobox to this template. P.s. I have collapsed the infobox examples which you have provided, hope you dont mind. Regards, Rehman 14:47, 1 June 2016 (UTC)[reply]

Until there is a way to present information in Infobox River in a way that is best-suited to the size and geographic extent of the river being described, I would strongly, strongly oppose a sweeping effort to switch from one infobox to another, especially an automated effort deployed just for the sake of switching, without regard for whether the change from one to the other constitutes an improvement to a given article. Looking at Sycamore Creek (Michigan), it appears to me that a switch from Geobox to Infobox River would wipe out the state, county, municipality, and township fields. It would also, illogically for a stream that flows through one U.S. state only, present to the reader first the location of the source (someplace in Michigan), then the location of the mouth (someplace in Michigan), and only THEN tell the reader that the stream's watershed is in the United States. Presenting "basin countries" AFTER the source and mouth information might make sense for large multi-country rivers, but most rivers aren't large. And the infobox's political jurisdiction options won't currently accommodate whichever levels of jurisdiction are most relevant to the size and geographical extent of the river being described, as the Geobox does. I think improvement of the information being communicated in an article ought to be the primary consideration when deciding, on a case-by-case basis, to switch from one infobox to another, and I don't think a switch to Infobox River in its current form would improve the Sycamore Creek (Michigan) article. In this case and many others, I think such a change would reduce the quality of the information provided to the reader. --TimK MSI (talk) 02:11, 2 June 2016 (UTC)[reply]

@TimK MSI: In his reply above, User:Rehman says "all the necessary fields of Geobox are now in Infobox River". Are you saying that that is not the case? Otherwise, what changes would you say are needed to this template, to satisfy your concern? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 2 June 2016 (UTC)[reply]

Yes, I'm saying that all the necessary fields of Geobox are not in Infobox River, and I pointed to several examples above as a start. I'll also point out that in the River Penk example shown, the "Counties" field was stripped out in the change to Infobox River. --TimK MSI (talk) 12:39, 2 June 2016 (UTC)[reply]

Strongly agree with TimK, a mass change from Infobox to Geobox is not supported by

WP:INFOBOXUSE. The Geobox has the advantage of inbuilt conversions, and a degree of adaptability, note how Staffordshire appears as a County in the Geobox (adapted from region), and can’t be included in the Infobox at all. In the example given, it looks better as a Geobox, maybe we should convert the Infoboxes instead...Jokulhlaup (talk) 14:05, 2 June 2016 (UTC)[reply

]

I think the Geobox version looks bloody awful. But neither view is grounds for a separate template. We should standardise on one, and reach consensus as to what features, and style it should use. If your arguments are persuasive, then the end result will be more articles using your preferences! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 6 June 2016 (UTC)[reply]

Completely agree. Lets have a proper discussion/vote as soon as the current tasks are complete. Rehman 23:38, 6 June 2016 (UTC)[reply]

Hi all. Together with the concern raised in the section immediately below, I went ahead and did the necessary corrections (as it doesn't impact the current ongoing bot task). The countries field at the bottom, and other key parameters not being where it should be was something that I overlooked when doing the template cleanup. Hope things are better now? Cheers, Rehman 13:45, 4 June 2016 (UTC)[reply]

@TimK MSI: Are you now satisfied that "all the necessary fields of Geobox are now in Infobox River"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 22 September 2016 (UTC)[reply]

Thanks for asking, I'm away from my computer for a few days but I will investigate next week.--TimK MSI (talk) 12:11, 23 September 2016 (UTC)[reply]

Hi TimK MSI. Just pinging you in case you find time to go through this again. :-) Rehman 01:41, 4 December 2016 (UTC)[reply]

It appears that User:TimK MSI, who has edited on five separate days (UTC) since your ping (and on around 30 days, since their last post here), has lost interest. I suggest we proceed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 27 December 2016 (UTC)[reply]

I haven't lost interest, I've been busy with other matters, sorry. One issue that remains is that the infobox lacks The geobox expresses the place names and landform names for the source and mouth in multiple fields for both source and mouth, whereas the infobox crams all of this into one field each for source and mouth. (This is something that would need to be handled carefully in any programmatic transfer of data from geobox to infobox.) I think at a minimum, something like source_landform and mouth_waterbody fields should be added to the infobox, to allow editors to express things like mountain ranges and seas separately from political jurisdictions. (I know not all rivers end in a body of water, but I don't think it would be problematic to enter, say, a desert name in a mouth_waterbody field when necessary; alternatively the field could have a name like mouth_landform.) --TimK MSI (talk) 18:27, 27 December 2016 (UTC)[reply]

@Rehman: Is there any progress in addressing TimK MSI concerns? Keith D (talk) 01:08, 4 February 2017 (UTC)[reply]

Hey Keith. It's been a very tough start of 2017 for me in RL, hence I apologise for loosing track of most things that were ongoing here. May I ask which points you're referring to in particular? I believe all earlier concerns were already sorted. As for the last paragraph by TimK, I believe such uses fits in the current template? Please correct me if I'm wrong TimK MSI. Cheers, Rehman 07:59, 4 February 2017 (UTC)[reply]

Thanks for reply, I was just looking at the last post by TimK MSI on 27 December 2016 that raised some concerns about missing "a dedicated field to accommodate the landforms and waterbodies at the source and the mouth." Keith D (talk) 11:44, 4 February 2017 (UTC)[reply]

Yes, that was my concern. There is currently a single field each for source and mouth to accommodate very different data points-- political jurisdiction and landform/waterbody. The Geobox allows these to be split between separate fields (two for source and two for mouth, vs. the infobox having one for each -- the Mississippi River geobox illustrates this). I also think there could be some adjustments to the organization of information in the infobox (in the "organization suggestions" discussion below). Thanks--TimK MSI (talk) 12:01, 4 February 2017 (UTC)[reply]

@TimK MSI. I went ahead and added it. Is it better? Rehman 01:07, 11 February 2017 (UTC)[reply]

@Rehman -- yes. Thank you! --TimK MSI (talk) 13:43, 13 February 2017 (UTC)[reply]

Hello Andy, Tim, and Keith. Do you believe everything is now in order, to deprecate the Geobox? Rehman 02:17, 1 October 2017 (UTC)[reply]

Works for me. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:56, 1 October 2017 (UTC)[reply]

Go for it. Keith D (talk) 19:03, 1 October 2017 (UTC)[reply]

It's fine with me, though first I think it would be good to fully implement the organization suggestions below. Rehman reports in that section that it should be soon. --TimK MSI (talk) 22:01, 1 October 2017 (UTC)[reply]

That is resolved (commenting here too, in case this section is archived). There are approximately 15,600 articles that uses Geobox River template at the moment. I'm not too sure if it make sense to do such a large sweep. But then again, it is always better to get things done now, rather than later. Suggestions open... Rehman 09:30, 7 October 2017 (UTC)[reply]

Whichever way it is done it needs a list of Geobox field against Infobox field names to enable the transformation to be done. I guess that a BOT would be best for that many articles as it would take a long time to manually convert them over. Keith D (talk) 20:30, 8 October 2017 (UTC)[reply]

I have raised an RfC at the Rivers WikiProject to help find a consensus on this course of action...Jokulhlaup (talk) 17:26, 22 October 2017 (UTC)[reply]

During the cleanup processes a few years back, I've mentioned that we should remove the etymology parameter as it does not belong in an infobox. There wasn't a clear response to that back then due to the number of other simultaneous ongoing tasks. Now that nearly all of the pending tasks are complete, I would like to propose the removal of the above parameter based on the below reasons:

1. Lengthy texts does not belong in an infobox
2. Data in the parameter cannot be standardised, and hence cannot be integrated with Wikidata

If there are no clear objections, I will go ahead with the removal in about a week, while ensuring that the data in the parameter is transferred to the article body (if not already there). Thank you. Rehman 15:06, 1 March 2018 (UTC)[reply]

Update: Surprisingly, it seems like the parameter is not in use at the moment. (Hence for neatness purposes, I've changed the parameter name from etymology to name_etymology to sync with the name prefixes). Rehman 14:42, 2 March 2018 (UTC)[reply]

@Rehman: How many articles are using it? I see that this parameter is in Template:Infobox settlement, and is included even in the "short version" cut-and-paste, so it would see that it was deemed important for settlements. I'm not sure that it should be remove from this template. Thanks! Plastikspork _―Œ^(talk) 23:39, 1 March 2018 (UTC)[reply]

And, there is an etymology parameter in Wikidata, see "Property:P138". Thanks! Plastikspork _―Œ^(talk) 00:34, 2 March 2018 (UTC)[reply]

Thank you for the info,

H:IB

. Maybe we could loosely limit the number of characters allowed in the infobox (since wikidata supports it), but that's up to the community.

@User:Pigsonthewing: I recall you objecting to the removal before. Just pinging you here as courtesy, if you're still in view that this shouldn't be removed. Best regards, Rehman 04:15, 2 March 2018 (UTC)[reply]

Thank you. I remain opposed to removal of this property. As to the two numbered reasons given above, "lengthy texts" should be copy edited, but are not a reason not to have a parameter; and Wikidata already has a property, as noted by Plastikspork. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 2 March 2018 (UTC)[reply]

Since the parameter isn't presently being used (and it's therefore easy to rename it), I think it might be desirable to rename it "named_after" (with the label "Named after") to match the relevant Wikidata item mentioned above. Compared to "etymology", it seems like "named_after" might reduce editors' temptation to hold forth with lengthy explanations in the infobox, by making clearer that it's intended for straightforward cases such as "named_after=DeWitt Clinton" for Clinton River (Michigan). Thanks--TimK MSI (talk) 15:27, 2 March 2018 (UTC)[reply]

If we do keep it (which seems like the case), I support retaining the word "etymology" since it is used in other infoboxes too (per Plastikspork above). I've added "name_" as prefix only to match the prefixes of the previous parameters, as they are related. P.s. Contrary to my "update" above, there were a small number of articles that did use the parameter. Seems like the category took some time to populate. Rehman 01:16, 3 March 2018 (UTC)[reply]

Plastikspork (talk · contribs) is this something that you could do? It appears to have been hanging around since January. Keith D (talk) 21:25, 30 September 2017 (UTC)[reply]

Ping Plastikspork (and Keith D). Rehman 14:53, 1 March 2018 (UTC)[reply]

This was completed by SporkBot a few days ago. Updating for records. Rehman 03:44, 9 March 2018 (UTC)[reply]

Rehman, it looks like you changed the template to automatically load an image from Wikidata. When this happens, because there is no value in the |image= and there is an image at Wikidata, the article is still flagged in Category:No local image but image on Wikidata. I believe this is an unintended interaction and should be updated. With your change, it should no longer be possible for the article to have a Wikidata image that is not in the article, so the check can probably be removed now. MB 13:58, 26 March 2018 (UTC)[reply]

Rehman, no response, trying another ping. MB 14:38, 4 April 2018 (UTC)[reply]

Hi MB. Thanks for the ping, and my apologies for missing the earlier one. Let me look into it and update here again. Cheers, Rehman 14:59, 4 April 2018 (UTC)[reply]

Hi again. I've removed that. Is that what you wanted? Kind regards, Rehman 15:39, 4 April 2018 (UTC)[reply]

Rehman, yes that does it. The category dropped by about 2k today, so it looks like there were that many rivers that are using Wikidata photos. I have no idea if most of those are good photos for the infobox. I have been working on manually adding Wikidata photos of people to articles and find a lot of the photos Wikidata has associated with people are not "portraits" suitable for the infobox. Sometimes they are things made by the person (books, a painting, a buildings), their graves, shots of a whole team where you can't even see their face, etc. But those things are probably less likely with rivers. MB 19:57, 4 April 2018 (UTC)[reply]

Great! Thanks for bringing this up, MB. Happy editing! Rehman 02:11, 5 April 2018 (UTC)[reply]

Hi. Your opinion at the above RFC is deeply valued. The RFC decides if Wikipedia would support data from Wikidata for use in infoboxes (Example - notice the infobox in edit mode). Thank you, Rehman 17:29, 11 April 2018 (UTC)[reply]

I'm creating a page from the German Wikipedia that lists a lot of different figures for discharge. Specifically, they list the average of the minimum flows from year to year, vs. the lowest flow that has ever been recorded.

Does discharge1_min refer to the "lowest recorded flow (with date)" or the "arithmetic mean of the lowest flows experienced over a series of years"? I'd like to update the documentation accordingly. Germans enjoy precision.-Ich (talk) 17:58, 11 May 2018 (UTC)[reply]

@Sadads: is it? I checked quite a few pages that used {{Infobox river}}, and I couldn't find any that would be problematic Galobtter (pingó mió) 14:50, 24 May 2018 (UTC)[reply]

The subdivision property alone is super inconsistent: take for example, even, in the documentation: you would create a set of text with several random links, only separated by commas after the "River" -- it doesn't make sense to humans. Now multiply this by several dozen different potential political divisions and formats for documenting them in the template. Moreover, there is no consensus on this template that there are significant enough problems in the Wikidata descriptions, to need to substitute: spot checking, I would much rather have the syntax and precision possible with Wikidata descriptions, which can be updated easier. Similar problem Shatt_al-Arab, or Schunter, where you would be brute forcing something that needs more nuance. Sadads (talk) 01:28, 25 May 2018 (UTC)[reply]

There is a consensus to use local short descriptions everywhere; in this case, if needed, the short descriptions can be imported in the text instead, as {{Short description}}, so the same control as with wikidata descriptions can be done; however I'd think it better to have the information from the infobox, and add information as necessary there, gaining that (in the case of Schunter etc, IMO it'd be better to add the data that it is in Lower Saxony in the infobox, and gain there). Though then we should do that first, I suppose Galobtter (pingó mió) 06:07, 25 May 2018 (UTC)[reply]

I'm sorry but that discussion (<20 people) does not represent a global consensus -- every well structured discussion about Wikidata to date has included many more people (i.e.Wikipedia:Wikidata/2018 Infobox RfC). Making changes to every page en-mass, based on that few people in a discussion is bogus. We need to discuss the application of this "Magic Word" or whatever it is, page by page or subject area by subject area with the local community. Sadads (talk) 13:26, 25 May 2018 (UTC)[reply]

Not really, if you want to contest the result you're free to start another RfC, but until then the presumption is that represents the global consensus (and the WMF have added the magic word and are going to switch off Wikidata descriptions once there are enough local descriptions on that basis) Galobtter (pingó mió) 13:30, 25 May 2018 (UTC)[reply]

This template automatically generates links to tributaries provided that a Wikipedia page with that name exists, no matter how silly that link might be. If I have fixed one link generated by this template to a DAB page, I have fixed fifty.

I dread to think how many bad links which this template has created are to irrelevant or misleading

Hello Narky Blert. Thanks for your message. I don't think I follow you... You mean the infobox auto-generates plain text to links, when you add entries in |tributaries_left= and |tributaries_right=? Rehman 01:36, 24 August 2018 (UTC)[reply]

@Rehman: Correct. See e.g. my recent edit to Huron River (northern Michigan). Also, the source=, discharge_location= and mouth_name= fields at least. See my recent edits to Caribou River (Thunder Bay District), Sibagat River and Current River (Ozarks). (Current River (Ozarks) also contains several old tributary fixes, where redlinks were inserted correctly in the first place.) Also, the country=, state=, region= and district= fields. That last group is less likely to cause long-lasting problems: there are editors who monitor notorious DAB pages like Georgia, New York and Washington for new bad links, of which there are several every day. Yrs, Narky Blert (talk) 09:52, 24 August 2018 (UTC)[reply]

Hello Narky Blert. Found the problem. Those pages are using a deprecated subtemplate of {{Geobox}}, not {{Infobox river}}. You are most welcome to assist in updating those articles to use the infobox template instead of geobox. :-) Feel free to let me know if you need any assistance. Best regards, Rehman 09:57, 24 August 2018 (UTC)[reply]

@Rehman: Thanks! I'll add that one to my bag of template-problem tricks, of which I have a good 20. Yrs, Narky Blert (talk) 10:08, 24 August 2018 (UTC)[reply]

@Narky Blert:, nowiki tags are also a workaround for this -- see Salmon River (New York) for an example. Thanks--TimK MSI (talk) 10:29, 24 August 2018 (UTC)[reply]

@

Uzh River and gets the wrong one. (I've checked the incoming links to that page, and they look OK.) Yrs, Narky Blert (talk) 10:41, 24 August 2018 (UTC)[reply

]

There are, of course, other items that are important option in both "infobox-river" and in "geobox", or lacking in one template but not in other and vice-verse. One good way to alleviate this problem in "geobox" is an option "free" (with "free_type"), but you have only one instance of this option.--౪ Santa ౪^99° 20:22, 29 October 2018 (UTC)-[reply]

Hello User:Santasa99. I understand the hydrogeological characteristics which you've explained, but it is still quite ambiguous in terms of application over the two templates (at least to me). Could you please provide a linked example (i.e. article) of the above? Where the geobox uses a these unique entries, which the infobox cannot accommodate? Or vice versa? Thanks, Rehman 01:44, 31 October 2018 (UTC)[reply]

I don't have any article to point out from top of my head, other than those I am involved in editing/creating, but I am not sure that we could find many simply because you can use template only as it is: for instance, one can't include multiple "estuaries"/"mouths"/"confluences" if option is lacking from both templates; "infobox-river" has better option for multiple sources, though only four or five instances of it (one can include only 4 or 5 river sources, but "geobox" lacks these instances altogether). Here's some article examples in which creation and/or editing I am involved: Zalomka, and especially Trebišnjica - rivers like these have extremely interesting and complex hydrogeology, from multiple springs, spring-groups, above ground and underground flows, to multiple estuaries and mouths, all within one and the same basin and same or different watersheds, like all rivers running through Karst (I am myself involved in exploring and writing on features (river, polje, underground aquifers and flows, etc) within karstic region of Dinaric Alps).--౪ Santa ౪^99° 19:43, 31 October 2018 (UTC)[reply]

@Santasa99: just a comment. One thing to keep in mind is that the infobox is meant to be a quick glance source. I would argue that for those very limited number of cases where there is such complex hydrodynamics, we shouldn't try to accommodate every single one. It may be enough to simply list the main tributaries and then say "See article" or something like that. Full disclosure, I'm not even remotely close to being an expert with rivers. I'm coming at this from the template editor perspective... But my point is that if the template works for 99% of rivers, and there is less than 1% where the river is so complex that not all the information will fit in the infobox, it is at least worth considering whether all that information SHOULD go in the infobox. If a river has 10+ tributaries, listing them all in the infobox would be a headache to read. As a reader, I'd rather just see "10 (see below)" or something like that in the infobox and then a section in the article with a table or something. Just some food for thought. --Zackmann (^{Talk to me}/_{What I been doing}) 20:03, 31 October 2018 (UTC)[reply]

No, of course - that's why I focused only on issue of 1) multiple sources (option alredy exist but maybe shouldn't be restricted - currently is restricted on 5? in "infobox-river" and only 3 in "geobox", but that being said this could be matter for "infobox spring"); 1a) also, "geobox" has useful and important option/item "source confluence" lacking in "infobox-river" (this serves to designate starting point for those rivers incurred through merging of two smaller ones (with names of their own), which is, on the other hand, extremely useful for rivers emerging from spring with multiple large outlets, or even multiple "spring-groups" where every "group" has multiple outlets, and so on); 2) possibly include new item called "source-group" (also issue for "infobox spring"); and 3) multiple instances for mouths/estuaries should be option (currently only one instance of this item exists - not sure but I think in in both templates). I suppose these aren't some broad expansions on existing options. And I must object on assumption that only 1% of rivers have these complex features, because number of rivers originating and/or running through karstic zones the world-over is actually significant - these regions exist are all over the planet, from Southeast Asia, South China, Central America, Balkans, and so on.--౪ Santa ౪^99° 22:09, 31 October 2018 (UTC)[reply]

By the way, why not include certain "module parameter" to have option of using other geographical infoboxes?--౪ Santa ౪^99° 22:28, 31 October 2018 (UTC)[reply]

Question that is a bit off topic... What is the story with notability for rivers? I've stumbled upon a few articles (

The documentation says "pushpin_relief=0" allows a standard map to be used. But this hasn't been working. See Karakash River for an example. -- Kautilya3 (talk) 15:41, 22 November 2018 (UTC)[reply]

Actually I just noticed that the documentation says "puhspin_map_relief". However, the engine says this is an unknown parameter. -- Kautilya3 (talk) 15:45, 22 November 2018 (UTC)[reply]

@Kautilya3: GREAT find! Thanks for pointing that out. I've fixed it. :-) --Zackmann (^{Talk to me}/_{What I been doing}) 18:49, 22 November 2018 (UTC)[reply]

Hello. Sorry for bringing this up late, I actually forgot about it. During the previous cleanup, I wanted to add Wikidata support to this infobox, but never found the time. Since we are at it again, do you think we could get it done now? Of course, it would not have any impact on the parameters of the current mergers. An example infobox with Wikidata support is {{Infobox telescope}}. To get an idea of what I am trying to explain, have a look at South Pole Telescope in edit mode.

Basically, if parameters are not filled in the article, it would be fetched from Wikidata (if available). This concept allows that centralised data to be shared across Wikimedia (i.e. all Wikipedias), allowing auto-translations, among other benefits. Rehman 02:33, 20 November 2018 (UTC)[reply]

@Rehman: it looks like that is already in place for the image. I for one would 100% support adding wikidata! Do you want to mock it up in the sandbox first for feedback or are you comfortable just making it happen. I don't see an issue either way. You clearly know what you are doing! :-) --Zackmann (^{Talk to me}/_{What I been doing}) 18:06, 21 November 2018 (UTC)[reply]

Wikidata use in infoboxes is highly controversial, and I strongly suggest that discussion of addition of Wikidata be done separately from the merger (is there any benefit to doing it now rather than after mergers are complete?) Galobtter (pingó mió) 19:34, 21 November 2018 (UTC)[reply]

@Galobtter: I was not aware that this was controversial. As the one performing most of the merging, I don't think the two have any real relation. Since the use of WikiData would be a fallback (if a value was not supplied) I don't see any way for it to conflict. That being said, if this is something that you feel warrants a broader discussion, I would agree. Lets have a broader discussion and not rush into it. --Zackmann (^{Talk to me}/_{What I been doing}) 20:16, 21 November 2018 (UTC)[reply]

See Wikipedia:Requests for comment/Wikidata Phase 2, Wikipedia:Wikidata/2018 Infobox RfC, and Wikipedia:Arbitration Committee/Noticeboard/Archive 11#Motion: Crosswiki issues regarding controversial nature of Wikidata in infoboxes. Galobtter (pingó mió) 20:20, 21 November 2018 (UTC)[reply]

@Galobtter: I'm going to take your word for it. I have too many projects I'm working on right now to wade into this debate. I'm indifferent on the use of Wikidata. All I will say is that we need to definitely follow proper procedure. The way I see it, Rehman raised an idea, you raised an objection. What should follow is a discussion about whether to use the data or not. Once a consensus is reached we can either implement it or not. :-) --Zackmann (^{Talk to me}/_{What I been doing}) 21:16, 21 November 2018 (UTC)[reply]

This should be avoided in any merge process as you are aiming to get something the same before and after merge that you can check out, adding other variables into the equation makes things more difficult to validate the merge is OK. I also do not think that we should be rushing to use WikiData information as per the various discussions that do not have a consensus for general use. This definitely needs a full discussion before any thing is done here. Keith D (talk) 21:46, 21 November 2018 (UTC)[reply]

Okay, let's discuss this after the merger. Thanks for the responses :) Rehman 01:51, 22 November 2018 (UTC)[reply]

So I have encountered an issue with the use of wikidata to find an image... Halton Hills. Any thoughts? --Zackmann (^{Talk to me}/_{What I been doing}) 16:57, 29 November 2018 (UTC)[reply]

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

Hi, I would like to suggest a few simple edits:

• Please move |basin_size= up from "Basin features" to "Physical characteristics" in between |length= and |width= – it's not a feature, it's a characteristic, and it makes no sense that it's isolated from the length and discharge numbers.  Done
• Order the discharge parameters like this: |discharge1_avg=, |discharge1_max=, |discharge1_min=. Average discharge is by far the most important figure here, and its current location below minimum discharge is weird.  Done
• "Confluence" in |source_confluence= shouldn't be capitalized.  Done

I've brought these up a few times on Template talk:Infobox river but there wasn't any opinions or consensus reached. Having created many hundreds of river articles I believe these changes would make the infobox read better. Thanks! Shannon [ Talk ] 18:20, 1 December 2018 (UTC)[reply]

I've marked one done. The others I think need consensus (feel free to request feedback from

WP:RIVERS

). I personally have no issue with the first request but I'm not familiar with this area. That one should be a quick turn change with a few people commenting.

Regarding discharge, I think min/avg/max probably needs to have a better format--maybe instead of separate lines for min and max we have one line that displays like Discharge min-max and a second line (either before or after) that displays Average discharge avg. --Izno (talk) 19:05, 1 December 2018 (UTC)[reply]

Thanks for the change, and I support all of the proposals as made by User:Shannon1. (Personally, I'd prefer that the infobox's sections not have the "Location"/"Physical characteristics"/"Basin features" labels at all -- just lines, like Infobox settlement and various other infoboxes. I thought that a discussion somewhere was leaning toward removing them at some point, but maybe I'm mis-remembering? At any rate, I don't think the section labels add anything useful.) The size of the basin is not really a feature in the basin, so I agree that it doesn't belong where it is. Additionally, I think basin size should be presented adjacently to other figures (such as length and average discharge) that readers use to quickly assess the size of a river. (On that note, I think it would be nice if these fields of numeric data could be set off from the details about the source and mouth with a horizontal line.) Regarding discharge, the aim of the alternative proposal isn't clear to me -- it sounds like you want to merge the two min/max fields into a single field with two values in it? Average definitely should be listed first, regardless. Thanks!-- TimK MSI (talk) 20:25, 1 December 2018 (UTC)[reply]

@TimK MSI and Shannon1: Obviously I've had a big involvement with this but I'll confess to being a bit burnt out by the process. Just been a ton of work! That being said, the two of you have been insanely helpful so I want to make sure I continue to do my part. Can I make a suggestion? I know the main template is protected but how about the two of you work together on updating the sandbox and lets see what your idea looks like? I think it is much easier to decide whether to implement it when we can actually see what you have in mind. I'm happy to help with some of the technical stuff if you get stuck, but how would you feel about playing in the sand(box) for a bit to mock something up? Once that is done, assuming it works and there are no objections, I am more than happy to implement it. Again, if you get stuck or need help with template syntax, please do not hesitate to ping me directly and I'll help out. Let me know your thoughts. --Zackmann (^{Talk to me}/_{What I been doing}) 21:04, 1 December 2018 (UTC)[reply]

Yes, I think it's natural to provide it in the form of a range rather than as two separate lines. --Izno (talk) 21:17, 1 December 2018 (UTC)[reply]

Did the discharge request per TimK. You can update the documentation to place average first on each line for the blank/example template wikitext. Let me look at the first request again. --Izno (talk) 21:21, 1 December 2018 (UTC)[reply]

And the basin_size. Again, you can update the documentation. --Izno (talk) 21:26, 1 December 2018 (UTC)[reply]

Wow, you beat me to it :) I was still tinkering in the sandbox and trying to figure things out. Looks much better now. Shannon [ Talk ] 21:43, 1 December 2018 (UTC)[reply]

Feel free to continue tinkering. I'm happy to help in case you get stuck. --Izno (talk) 21:51, 1 December 2018 (UTC)[reply]

I wanted to talk about the multiple different naming parameters we now have on this template. This discussion is meant to be independent of the ongoing discussion above about my accidentally removing nicknames from River pages as they were converted. There is no argument that the information needs to be restored! When I was adding the nicknames to this template, I realized that we now have 4 different naming parameters... |name=, |name_native=, |name_other= & |nickname=. There are a couple of things about this that I think are worth discussing..

Does all of this really belong in the infobox?

Take Mississippi River for instance. In the infobox it has 7 different native names in 7 different languages. Now I want to be clear, I'm not saying just delete that information, but IMHO, that belongs in the body of the article, not in the Infobox. If the river had just 1 native name, I'd see no problem putting it in the infobox, but 7 seems like overkill to me.

Can we combine some of these?

{{{name_other}}} & {{{nickname}}} seem like they are essentially the same thing. Would it be possible to combine them into one? Thoughts?

I want to re-emphasize that I'm not advocating deleting any information from articles. In some select cases, such as the example above about Mississippi River, I do think we should re-evaluate what belongs in the Infobox versus the body of the article, but not suggesting any of the info be just flat deleted. --Zackmann (^{Talk to me}/_{What I been doing}) 18:56, 8 December 2018 (UTC)[reply]

@Shannon1, TimK MSI, and Izno: definitely want you guys to weigh in here. I come at this from the "template editor" side of things, but you guys have the river knowledge. Want to make sure that any changes work with both perspectives in mind. --Zackmann (^{Talk to me}/_{What I been doing}) 19:40, 8 December 2018 (UTC)[reply]

I'm fine with the name options as they are now. The options afforded are fewer than those at

MOS language ("...which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.") Personally I think the Mississippi River example is OK as it is. Thanks! --TimK MSI (talk) 14:32, 10 December 2018 (UTC)[reply

]

IMO, let's keep all the names in the infobox, but maybe move everything save for the most commonly used name into the space below the images next to "etymology". Although I'd make an exception for certain transboundary rivers - for example more than half the length of the Mekong river is in China, where it is called the "Lancang", while it is only in the several downstream countries where its name is "Mekong" or derivatives thereof. Or what about the Rio Grande, forms the Mexico/USA border for over 1000 miles, so its Spanish name Río Bravo should definitely be up there next to the "main" name. The name fields as they are now are kind of a mess, as sometimes the "native name" is still a commonly used name, while in other cases it's only a historical name. so I guess I suggest for now: move |native_name= and |nickname= below |etymology=, and keep |name_other= where it is now. Shannon [ Talk ] 19:36, 10 December 2018 (UTC)[reply]

Ah, thanks, that sounds like a good change to me too. --TimK MSI (talk) 19:41, 10 December 2018 (UTC)[reply]