Template talk:Infobox river/Archive 2

Same Line
Same Line
Physical characteristics
Source	The Wishing Well, The magic forest
Discharge	Atlantic Ocean, Boston

some river
some river
Physical characteristics
Source	The Wishing Well
• location	The magic forest
Discharge	Atlantic Ocean
• location	Boston

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

Template-protected edit request on 12 December 2018

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

‹ The template Edit template-protected is being considered for merging. ›

As discussed towards the end of this section above, the former Geobox (which this template has replaced) supported parameters that recorded the lengths of headwaters tributaries. These were deleted during the conversion to infobox, and I propose supporting this content in this infobox, via the addition of these parameters:

|source1_length=
|source2_length=
|source3_length=
|source4_length=
|source5_length=

...inserted following |source1_coordinates=, |source2_coordinates=, etc. As I described above, this would accommodate a couple of scenarios: 1) to record data about headwaters tributaries that may not otherwise merit their own articles, and 2) to communicate that a very short stream is formed by a confluence of much longer streams that are designated as "forks" or "branches," etc., in cases where editors choose not to create separate articles for them all. Thank you! --TimK MSI (talk) 18:31, 12 December 2018 (UTC)

I'm going to object to this based on MOS:INFOBOXPURPOSE. There is already a ton of information in this infobox. Adding the length of multiple sources to the Infobox is overkill. In my eyes this is akin to having an infobox about a city, and including not only the population of that city, but also the population of all the adjacent cities. If a river source is notable, it will have its own article where its length will be listed. If it is not notable enough to have its own article, I don't see how it is notable enough to have its length in the Infobox. There is no objection to putting this information in the body of the article, but putting it in the Infobox is overkill. --Zackmann (^{Talk to me}/_{What I been doing}) 19:26, 12 December 2018 (UTC)

Looking at the archive.org Geobox version of the Steer Creek article, I think the lengths of the left and right forks are indeed "key facts" (to use MOS:INFOBOXPURPOSE's language) about the physical feature the article describes -- a short "Steer Creek" with two longer "fork" tributaries that share its name. This is very different from putting statistics about one city in the infobox of an article about a different city. I don't think it benefits readers to withhold these facts from the infobox. And including them supports one of Wikipedia's pillars (namely that it combines features of specialized almanacs and gazetteers). Thanks--TimK MSI (talk) 19:44, 12 December 2018 (UTC)

@TimK MSI: Using {{geobox}} is not going to support your case here... That infobox was an absolute disaster. It included Zip Codes and Telephone Area Codes in articles about a river. I'm not really interested in going around in circles on this. To me if you have an article about Holly River, there is absolutely no reason to put the length of Right Fork Holly River (one of its sources) in the infobox. If you want to mention it in the article, that's fine. But putting it in the Infobox clearly contradicts MOS:INFOBOXPURPOSE. If an admin or a different template editor disagrees with me that's fine. Just voicing my stance. Note that I intentionally did NOT close the request. --Zackmann (^{Talk to me}/_{What I been doing}) 19:56, 12 December 2018 (UTC)

I also support using source-length, since it is highly relevant to certain types of rivers. It may not be necessary for something like San Juan River (Colorado River tributary) a river which is 380 miles long, but its forks are only a few miles long each (i.e. negligible in comparison to the mainstem). However take something like Quillayute River, which is only 4 miles long but the two rivers that join to form it are each over 50 miles long. Thus having only an option for the main stem length will, in some cases, be somewhat misleading as to the actual size of the river system.Shannon [ Talk ] 20:11, 12 December 2018 (UTC)

@Zackmann08: I'm guessing it won't change your mind, but the example you cited (Right Fork Holly River) is in fact a redirect to Holly River; it was wikilinked in the infobox by your script last month (I removed the faulty wikilinks just now). The Holly River article is the place on Wikipedia where the Right Fork Holly River is described. I think editors need the flexibility to precisely describe the basic statistical facts of situations such as these. Thanks--TimK MSI (talk) 20:14, 12 December 2018 (UTC)

having an option for source length seems reasonable for the situations described above. I agree that it shouldn't be used in all cases, but from the list I provided in the removed parameters section above, it appears it wouldn't be used in all cases. Frietjes (talk) 15:17, 13 December 2018 (UTC)

Support inclusion of multiple sources, besides the forks situation described above it would also be useful in cases where the source of the river is disputed - you could give the info on both candidates, or in cases where the pop culture source and hydrologic source differ (e.g. Hudson River). It's not going to be used most of the time, but it's still a useful functionality to have in the template. Kmusser (talk) 20:18, 13 December 2018 (UTC)

"edit template-protected" template disabled until consensus is reached. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:36, 12 December 2018 (UTC)

I see a lot of support and not much objection, so now added. Frietjes (talk) 19:39, 14 December 2018 (UTC)

Merger of Geobox/river into this template

I am not the proposer, just notifying this forum of a current discussion about moving all instances of Template:Geobox|river to Infobox river. – Jonesey95 (talk) 18:17, 21 October 2018 (UTC)

@Jonesey95: there is already a notice on the template... --Zackmann (^{Talk to me}/_{What I been doing}) 18:53, 21 October 2018 (UTC)

@Galobtter, Sadads, Frietjes, and Jonesey95: as major contributors to the template, can you all take a look at the Sandbox/Testcases and provide some feedback? This stems from a discussion at TFD... --Zackmann (^{Talk to me}/_{What I been doing}) 01:29, 23 October 2018 (UTC)

Must say I much prefer the original layout of the template than the modified version. Keith D (talk) 16:46, 23 October 2018 (UTC)

@Keith D: can you elaborate? What specifically do you like? Looking for any and all feedback but would be helpful if you could give some details about what exactly you like better about the other version so we can work towards the best solution. Shannon1 can you add a bit of info here about the reasoning behind this redesign? Add a link to that image of yours as well if you don't mind! --Zackmann (^{Talk to me}/_{What I been doing}) 18:14, 23 October 2018 (UTC)

Hi, specifically removal of border round the box and the squashing of all the headings / sub-headings in the left hand side of the box makes it very difficult to scan and determine what is a header and what is a sub-heading. Keith D (talk) 18:20, 23 October 2018 (UTC)

@Keith D: so funny story... You just hit on exactly what I don't really like about it as well. This is an ongoing process, I saw this as a "version 1" NOT as a final product. Going to try a different mockup this afternoon and will take that feedback to heart. Thank you! --Zackmann (^{Talk to me}/_{What I been doing}) 18:52, 23 October 2018 (UTC)

Hey there. I did a large part of the changes to this infobox in early 2016, which the aim of actually superseding the Geobox. You can find more info about why things are the way it is here and also here. That being said, I'd like to repeat what was said above, and add that the Geobox-style looks much more cluttered on mobile, compared to the standard infobox style (what is currently in use). Of course, we can always discuss things again, as that was nearly 3 years ago. Personally, I prefer the standard infobox style (without any extra styling or decoration), for the sake of Wiki-wide standardisation. Kind regards, Reh man 13:10, 24 October 2018 (UTC)

I have closed the TfD with the result of merge but I will hold off on implementing this until discussion on how best to merge the appearance and functionality is concluded. I have identified the following factors below that were brought up in the discussion. It would be helpful if people could comment on each separate issue. If there are other points, please add in a new subheading. — Martin (MSGJ · talk) 11:36, 26 October 2018 (UTC)

Thanks for the comprehensive summary and follow-up MSGJ. I'm assuming the below is more vote based, hence I am responding as such. Kind regards, Reh man 12:02, 26 October 2018 (UTC)

I've put a comparision of the current sandbox and geobox at Template:Infobox river/comparison sandbox vs geobox incase anyone wishes to compare. -- WOSlinker (talk) 09:53, 27 October 2018 (UTC)

That's great. Do you know how to put the map at the bottom using infobox? — Martin (MSGJ · talk) 10:05, 27 October 2018 (UTC)

Yes, I've done that now. Just used a data param rather than an image param in the code. -- WOSlinker (talk) 10:09, 27 October 2018 (UTC)

I've started working out which fields map to which. Please see Template:Infobox river/parameter mapping and add/correct as necessary. — Martin (MSGJ · talk) 12:47, 31 October 2018 (UTC)

@MSGJ: bravo! I think this needs to be the #1 priority! Adjustments to the look and feel of the template can be made at any point, but correct mapping of the fields is needed before conversions can start taking place. --Zackmann (^{Talk to me}/_{What I been doing}) 17:38, 31 October 2018 (UTC)

Well, both discussions are important, which is why I am giving time for the discussions below to conclude before starting the merge. Any help with the mappings would be appreciated. Could someone start coding support for the imperial measurements because this has wide support. — Martin (MSGJ · talk) 13:21, 1 November 2018 (UTC)

I've created an initial helper template at Template:Infobox river/convert helper which may be of use. Still needs a little more tidying up though. -- WOSlinker (talk) 14:02, 1 November 2018 (UTC)

Question, should we add a {{{type}}}? I.E. River, Stream, Creek, etc. --Zackmann (^{Talk to me}/_{What I been doing}) 22:48, 13 November 2018 (UTC)

@Zackmann08: Good question-- No, there are no formal NPOV distinctions between these terms, and the use of a given term in the name of a watercourse isn't a reliable indicator of anything in particular. (Most of us think of "creeks" as being smaller than "rivers" in the generic sense, but there are lots of individual watercourses named "creek" that are much larger than many other individual watercourses named "river.") Thanks--TimK MSI (talk) 20:41, 15 November 2018 (UTC)

Automatic conversions

Some contributors to the TfD saids that Template:Geobox/type/river performs some automatic conversions that are useful. What exactly does it do and should we implement that functionality in this template? — Martin (MSGJ · talk) 11:20, 26 October 2018 (UTC)

Oppose. I've always thought automatic actions (i.e. conversions) are troublesome. I recall having read valid arguments against it but cannot find any right now. I personally am against auto conversion, but would be happy to help add them if the community thinks so. Reh man 12:02, 26 October 2018 (UTC)
Support both I know a number of other templates support both. So for example you have a {{{length}}} that expects {{convert}} to be used. But you also have {{{length_km}}} and {{{length_mi}}} that if used will auto-convert. Rehman thoughts on that? --Zackmann (^{Talk to me}/_{What I been doing}) 16:54, 26 October 2018 (UTC)
Support as it would make things less tedious.—Mythdon (talk • contribs) 08:10, 27 October 2018 (UTC)
Support as above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 27 October 2018 (UTC)
Support. Should keep the naming conventions as used in geobox, so *_imperial parameters should be added and to compliment them, there should be *_metric versions. Should also add *_note parameters as well to ease conversion from geobox. -- WOSlinker (talk) 17:10, 27 October 2018 (UTC)
There's also the option of using code such as {{#if:{{isnumeric|{{{length}}}}}|{{Convert|{{{length}}}|km|mi}}|{{{length|}}}}} and then the parameter would work with both passing just a number (|length=100) and also the full convert information (|length={{convert|100|km|mi}}) but it may be better to keep them as separate options. However, using it would ease the conversion from geobox. -- WOSlinker (talk) 17:21, 27 October 2018 (UTC)
I think I agree with you. I suggest length should allow any form of entry, including units and more complicated uses of {{convert}}. length_imperial and length_metric should accept values and auto-convert. As an interim measure we could use the logic you suggest on length so that values only are treated as metric. — Martin (MSGJ · talk) 17:08, 6 November 2018 (UTC)

@WOSlinker: I am having second thoughts about this as it is massively complicating the template. For discharge quantities alone we are talking about 3*3*5=45 parameters. Plus the separate note parameters (which cannot be combined with the quantity in the case of unitless entry). I really not sure this is worthwhile for the limited use it may get. — Martin (MSGJ · talk) 21:05, 12 November 2018 (UTC)
@MSGJ: Using Template:Infobox river/convert helper would simplify it a bit. -- WOSlinker (talk) 21:11, 12 November 2018 (UTC)
The disadvantage of doing the calculations in this template rather than using {{convert}} is that there are lots of options offered by {{convert}} that we would not be able to implement here, such as precision. For example, which of the following is preferred would depend on how precise the length is:
- 6,400 kilometres (4,000 mi)
- 6,400 kilometres (3,977 mi)
All sorts of other options are available in {{convert}} including rare kinds of unit, etc. — Martin (MSGJ · talk) 14:04, 1 November 2018 (UTC)

Position of map

Shannon1 suggests that putting the map at the bottom of the infobox makes it look more "balanced" and avoids having two images together at the top. What do others think about this — Martin (MSGJ · talk) 11:23, 26 October 2018 (UTC)

Support. Reh man 12:02, 26 October 2018 (UTC)
Support as two images put together at the top only forces readers to have to scroll so much just to see the values. Best to have the template be as readable as possible.—Mythdon (talk • contribs) 08:12, 27 October 2018 (UTC)
Oppose Most of our other infoboxes have the map between the main image and the data fields. Such consistency aids our readers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 27 October 2018 (UTC)
Oppose It may seem minor but consistency is key here. I'm with Pigsonthewing on this one. Map should stay up at the top as this is the standard format. --Zackmann (^{Talk to me}/_{What I been doing}) 20:23, 29 October 2018 (UTC)
Oppose Per consistency with other infoboxes and personal preference. – BrandonXLF ^(t@lk) 21:44, 31 October 2018 (UTC)
People saying oppose: please look at Template:Geobox/testcases and tell me if you are happy with three images at the top of the infobox before you get to any of the text? — Martin (MSGJ · talk) 21:47, 4 November 2018 (UTC)
@Zackmann08, BrandonXLF, and Pigsonthewing: — Martin (MSGJ · talk) 17:09, 6 November 2018 (UTC)

Looks good to me. :-) Sorry for the late response, thanks for the ping. --Zackmann (^{Talk to me}/_{What I been doing}) 17:11, 6 November 2018 (UTC)

Two images are ok I guess but three is too much. I would suggest adding the "show map" functionality to river infobox if it isn't there already. For example, See the infobox on Oakland, California. Shannon [ Talk ] 18:15, 6 November 2018 (UTC)

Support as much more balanced, with more important details of a property displayed first. $ɱ$ (talk) · vbm · coi) 00:44, 20 November 2018 (UTC)

Layout of "source"

{{Geobox/type/river}} has subheadings for location, elevation and coordinates. {{Infobox river}} has all this information bundled together. Which version is preferred? — Martin (MSGJ · talk) 11:26, 26 October 2018 (UTC)

I feel we should keep the Infobox version. The content is obvious (i.e. a displayed coord, is obviously a coord, etc). More headings mean more text in the infobox, which means more clutter. Reh man 12:02, 26 October 2018 (UTC)
I like the Geobox version - it might not be immediately obvious to readers unfamiliar with the subject what a bundle of unlabeled info means. IMO, infobox river looks more cluttered due to the lack of distinguishing sub-headings, especially on mobile. Besides, every other infobox type I can think of has a heading/subheading for each data point. See for example, San Francisco, George Washington Bridge, Fort Peck Dam... etc. Shannon [ Talk ] 16:32, 26 October 2018 (UTC)
Per Shannon1.—Mythdon (talk • contribs) 08:15, 27 October 2018 (UTC)
Coded in sandbox, awaiting comments. Please see Template:Infobox river/comparison sandbox vs geobox — Martin (MSGJ · talk) 16:57, 6 November 2018 (UTC)

Looks good to me. Shannon [ Talk ] 18:15, 6 November 2018 (UTC)

Layout of "discharge"

{{Geobox/type/river}} has subheadings in the left column for average, max and min whereas {{Infobox river}} stacks this detail in the right column. Which version is preferred? — Martin (MSGJ · talk) 11:28, 26 October 2018 (UTC)

Infobox looks neater, IMO. It is more clear that all those info fall under "discharge". Reh man 12:02, 26 October 2018 (UTC)
For the same reason I prefer Geobox. It reads more intuitively as a grid, rather than a single column. look again at San Francisco, I doubt the infobox would read easier if under the "Government" or "Area" heading every subheading was stacked into the right column. Shannon [ Talk ] 16:35, 26 October 2018 (UTC)
Per Shannon1.—Mythdon (talk • contribs) 08:17, 27 October 2018 (UTC)
Coded in sandbox, awaiting comments. Please see Template:Infobox river/comparison sandbox vs geobox — Martin (MSGJ · talk) 16:58, 6 November 2018 (UTC)

Position of "basin size"

{{Geobox/type/river}} puts basin size after the length of the river. {{Infobox river}} puts this field at the end with tributaries. Which position is better? — Martin (MSGJ · talk) 11:32, 26 October 2018 (UTC)

No strong preference, but leaning towards keeping it where it is now. Reh man 12:02, 26 October 2018 (UTC)
I suggested going with the geobox style because basin size is a numerical statistic, and makes sense to be grouped with length and discharge. Shannon [ Talk ] 20:54, 26 October 2018 (UTC)
Per Shannon1.—Mythdon (talk • contribs) 08:07, 27 October 2018 (UTC)

Pages to test Infobox river against

Ideally a lot of the current parameters against geobox would be added to infobox river so that conversion can be done by just changing the template name in the majority of cases. If you spot any good examples of of articles using the geobox template with lots of parameters or parameter that you think are obscure and only used occasionally then add them to the list below for testing with. -- WOSlinker (talk) 21:02, 27 October 2018 (UTC)

Tanjil River
Barkly River (Victoria)
Susquehanna River (uses imperial params)
Shade River (cites sources)

Disappointed at handling of Geobox river to Infobox river merge proposal

I am disappointed at the handling of the Geobox river to Infobox river merge proposal (concluded at Wikipedia:Templates for discussion/Log/2018 October 19#Template:Infobox river), now concluded and now moving apace. I realize Wikipedia does not revolve around me , but I had no idea there was even a discussion for merge going on, let alone that it had been concluded until now. And I am a frequent and recent user of the Geobox river template. I do not have {{Infobox river}} or WikiProject Rivers or Templates for discussion on my watchlist: I did not get updates on the progress of the discussion on my watchlist from the latter, and wasn't in a position to be aware of the notifications at either of the former. I'll note that though there was a notification at WikiProject Rivers, it is rather generic rather than titled "Merge proposal Geobox river to Infobox river". There was a Merge template added to the {{Geobox/type/river}} page (see edit), and I do have the Geobox template on my watchlist, but because of a subsequent edit, the change adding the merge proposal would have been visible on the watchlist for just 15 hours, from a Friday night my time to mid-Saturday morning. I am rather perplexed that the discussion has even arisen again, when an Rfc at Wikiproject Rivers was concluded just this past January with a decision to keep both templates. There were a number of folks who participated at that Rfc speaking in favour of Geobox like @Chris troutman, Jokulhlaup, and Ruhrfisch who have not commented at all at the recent merge discussion. While WP:MERGE does describe "Notify involved users" as optional, for a contentious and oft discussed topic, how difficult would it have been to contact these users, and frequent users of the template like myself? Now that the merge discussion is closed (in six days, when the Rfc took more than 3 months) with a decision to merge into Infobox river, now a discussion is underway at the Infobox river talkpage as to what features from Geobox — including core differences like autoconversion — should be incorporated into Infobox, with the merger suspended until the discussion is included; this feels to me slightly like I have a gun to my head, where I have to justify things I find useful at my home pitch at the pitch of the away team. Why are we having a discussion about including the key things that makes Geobox river different at all? If we are not prepared to automatically make those changes to Infobox river, we are not merging, we are deleting Geobox river. For the record: 1) I do not ascribe malign intention to anyone involved in the recent merger and I do Wikipedia:Assume good faith 2) I do like Geobox river at the moment better, but I am not against Infoboxes: I have switched to Infoboxes for new articles on lakes ({{Infobox body of water}}) and settlements, and have manually converted many articles I had created in those categories with Geobox to Infoboxes. I do not assume that Geobox should continue, and I do see the logic in using one type of information box for rivers. END NUMBERED LIST My conclusions and suggestions. 1) I feel as if I have been disenfranchised 2) Despite abiding with good faith by the form of the process, the spirit was not: a full and fair discussions of the merge was not undertaken, since not all interested parties were involved. 3) I request that the merge be rescinded (with humour intended: sorry User @Pigsonthewing/Andy Mabbett, if this makes you pull out more of your hair!) until all those parties including recent Geobox river template users have been notified and have had ample opportunity and time to chime in. I am prepared to accept a de facto rescission: all those who spoke in favour of the merge and the person who closed the merge discussion (I believe User:MSGJ) would need to indicate, perhaps on this talk page, that they are in agreement with the rescission. 4) In parallel, efforts should continue to soft merge the Geobox river into Infobox, including key Geobox features such as autoconversion, autolinking, the ability to change any field name when using the template, and the ability to add reference fields to any template field (and there may be more). In fact, with gentle remonstrance, I don't know why this wasn't the approach taken in the first place. I pledge to be part of this effort in creating a superlative rivers information box, such that an eventual merge discussion will be moot. --papageno (talk) 19:01, 27 October 2018 (UTC)

I opposed, and still oppose, this merger. Regardless, Wikipedia is an adhocracy. If you can't be bothered to keep a bunch of pages on your watchlist, then your opponents will find a venue to establish "consensus" when you're not looking. If it were me, I'd just re-create the geobox and start a new RfC to stop further merges. Chris Troutman (talk) 23:37, 27 October 2018 (UTC)

@Qui1che: personally my issue isn't about your statement of Wikipedia does not revolve around me. It is that you have barely 10,000 edits and seem upset that editors with way, WAY more experience than you are making changes that are beyond your understanding. (To be clear, I'm not just talking about myself...)

@Chris troutman: If you can't be bothered to keep a bunch of pages on your watchlist, then your opponents will find a venue to establish "consensus" when you're not looking. If that is the attitude you want to adopt, I certainly can't and won't stop you, but I think that is a wildly unfair statement. No one attempted to do anything while you're not looking. Wikipedia has a process where when large changes are being considered they are nominated for discussion. That discussion was open for almost a week and over a dozen different users chimed in. There was overwhelming support to merge the templates. I would ask you (and I mean this seriously, please do NOT misunderstand my tone as passive aggressive or sarcastic), what would you have had us do? Should we have pinged every user to ever use the template? Even if someone had the time to do that, I have no idea how you could go about figuring that out. There was no attempt here to pull a fast one on anybody...

Now you both disagree with the decision, and that is totally fine. I'm not going to necessarily try to change your mind. However, I would encourage you to take part in the discussion above. Shannon1 initially opposed the merger, but after discussing what we are trying to achieve it seems that they are now on board. In fact Shannon is taking a lead role in making sure that riverbox has the right look and feel moving forward. So while the decision may not have gone the way you wanted, that doesn't mean you can't take part in the discussion moving forward. Talk about your concerns. If there is something you don't like about the Infobox, join the conversation and help us improve it! This really don't need to be an us vs you type thing... The end goal is to have the best working template. We are all on the same team here. --Zackmann (^{Talk to me}/_{What I been doing}) 20:28, 28 October 2018 (UTC)

Clarification: I said earlier above words to the effect that some Geobox proponents involved in an earlier Rfc had not been made aware of the tfd merge proposal and had not commented. I am not quite sure how this escaped me, but this was incorrect. User WOSlinker (talk) did {{ping}} many of those proponents and several other users in the short period of under four hours after the establishment of the discussion, and I believe two Geobox river proponents, User Ruhrfisch (talk) and User Shannon1 (talk), made several replies. Apologies to to all, in particular @WOSlinker. --papageno (talk) 05:35, 31 October 2018 (UTC)

@Zackmann08: Would you be willing to stipulate that at the end of the 30 days suspension of the Geobox river to Infobox river merge in place at the moment (not quite sure why 30 days?) to allow for improvements/changes to Infobox river, that an Rfc (or simpler/better equivalent if you know one) be undertaken so that all participants in the effort can formally chime in that they are satisfied that all necessary changes have been made and that the merge should go ahead? This would go allay concerns about the input from Geobox users being taken seriously, and would put meat on the bones of your (I acknowledge) goodwill message. It would incur a small time penalty, at the benefit of adding more solidity to the merge process. Perhaps this would have been done anyway. [Some additional comments to come later, but this is more important time wise as the discussions about changes to Infobox river are already underway.] Regards to all. --papageno (talk) 05:35, 31 October 2018 (UTC)

@Qui1che: you don't really seem to have any idea what is going on here or how this works. I'm not stipulating to anything, nor am I in any position to. A TfD was filled and has been closed by an admin as merge. The fact that you don't like the outcome doesn't mean you get to throw a temper tantrum to get your way. You are welcome to take part in the discussion above to outline your concerns, but so far all you have done is complain about the fact that no one has wined and dinned you through this process. --Zackmann (^{Talk to me}/_{What I been doing}) 05:58, 31 October 2018 (UTC)

I'm not sure why suspending the merge so that improvements/changes to Infobox river can take place would help? Improvements/changes to Infobox river are being discussed now, and the replacing of infoboxes on articles won't be happening until the changes to Infobox river have been made. You could contribute to this process now so that when all the changes have been done you are happy with them. -- WOSlinker (talk) 08:04, 31 October 2018 (UTC)

Thanks for your comments @Zackmann08 and WOSlinker. Key question: in the Tfd, @Ruhrfisch said I am also OK with trying to come up with a revamped River Infobox that has all the functionality of the Geobox River but is easier to maintain as code (my emphasis added); no one took issue with his statement. The TFD summary by @MSGJ seems to only suggest that They are both infobox templates and both have similar functionality (this may have been an inadvertent omission on his part). Should I understand the Tfd as having concluded with a commitment to include all the functionality of Geobox River in the new merged template? The formatting of the infobox is important, and I acknowledge Shannon1's salutary efforts which you also highlight Zackmann08, but there are key differences in functionality that will need to be coded afresh, which I already mentioned above as including things such as auto-conversion (being addressed) and auto-linking (which worryingly no one has mentioned). If so, this would resolve my concerns about the merge process (that key functionality of Geobox River is subject to majority voting in the discussion rather than already agreed to/ subject to a formal process), and would give me the confidence to participate. --papageno (talk) 06:49, 11 November 2018 (UTC)

For the record, I am certainly no power user on the order of you, Zackmann08, or several other users involved here. However, I have been around the block: I have been editing Wikipedia since June 2004, making me one of the longest serving editors if not the longest serving editor involved in these discussions. I do understand what is going on. I know to take my concerns to talk. I don't use condescension, insults, whine, or pull rank; and if I make a mistake, I own up and apologise…well, hardly ever/mostly. And why am I spending so much time on this bloody template? One of my primary interests for years now is the geography of my home province of Ontario, especially rivers and lake. I first used Geobox river in an Ontario article after switching from Infobox river on 28 November 2008, almost ten years ago, longer than some users here have been editing, and have used it regularly ever since.

I am not nor have I ever said I was upset at "losing" or disagreed with the outcome of the Tfd about Geobox river. I'm upset at not having had a voice in it. As is the case for an unknown number of other followers and users of the template. (Frankly, one does not lose discussions anyway: the objective is to come up with the best outcome possible.) I am not sure I have to repeat, but I do believe Zackmann08 that you are a capable editor and that you desire the best outcome possible for the river Infobox. I confess that is why I am also flabbergasted that any user let alone a power user would answer this disenfranchisement with an argument to the effect that "the process was followed" (paraphrasing). I agree you followed process, and using processes is commendable, but they are intended to achieve an outcome: they are not are the objectives themselves. Just several weeks ago on October 22, municipal elections were held in my home province of Ontario; quite a number of municipalities tried online voting for the first time, and problems cropped up, meaning many voters could not vote by the official closing times. Were they out of luck? No: officials extended the voting period by several to almost 24 hours depending on the jurisdiction to ensure all votes counted (for example, in in Greater Sudbury.

As you said to me above, I may not change your minds, but to you and other power users (I think only @Pigsonthewing hasn't been mentioned yet) I ask merely for your reflection. You (obviously) can choose not to reply, or even can reply "I decline to comment" to avoid vulgarity, and I will take it as a pithy, robust riposte on your part without malice. 1. Would it have cost anything to delay to the merge process by 30 days to verify that all those who might have contributed to a better discussion outcome had participated? 2. Is having just two users of a merge candidate template with over half the published articles and most of the best ones in the topic sufficient to be considered a "consensus"? 3. Is seven days a sufficient amount of time to declare a consensus, when previous discussions had taken 3 months? 4. Could greater care have been taken so that more interested parties were pinged to comment on the Tfd (eg, @Chris troutman and Thewellman were missed even though they had participated in the 2017 Rfc, and I was missed on the Geobox talk page)? 5. Could identifying those users with merge candidate and merge target templates on their Watchlists provide a way to identify more parties who might contribute to discussions about templates? Are there other methods that might be considered? 6. Was a Tfd even necessary to address the key concern of those users involved with templates, that Geobox is cumbersome and outdated? I agree a Tfd is maximally efficient, but the Geobox river code could have been re-written at any time without merging as a test of the feasibility of doing so. Regards to all, --papageno (talk) 06:49, 11 November 2018 (UTC)

To answer your specific question about the TfD, no it was not closed "with a commitment to include all the functionality of Geobox River in the new merged template". Which of this functionality to incorporate into the merged template is exactly what we are discussing above (and you are invited to join in!) You may notice that the appearance of the sandboxed version is currently looking a lot more like Geobox|river than Infobox river. However there are some "features" which are really not a good idea, e.g. autolinking causes more problems than it solves and i haven't seen anyone in this discussion even suggest that it should be retained. — Martin (MSGJ · talk) 08:04, 12 November 2018 (UTC)

@MSGJ: 1. The argument about auto-linking does not hold water. I've mentioned auto-linking several times in my comments, and I'm a 10-year template user. @Ruhrfisch stated I am also OK with trying to come up with a revamped River Infobox that has all the functionality of the Geobox River but is easier to maintain as code (my emphasis added) not "all functionality except auto-linking". Previous discussions, cited in in the Tfd, all mentioned autolinking; any reader of the Tfd, especially those who had participated in previous discussions (like, for example, Pigsonthewing) would be well aware of it. While you yourself brought up and various other interested editors from the template coding side of the house readily supported autoconversion, everyone held their tongue on autolinking. Did you not understand the template well enough to understand this key difference in functionality and/or Ruhrfisch's comment? or was it an accidental oversight? If so, is it rational to have concluded the Tfd with the text "They are both infobox templates and both have similar functionality"? 2. You may notice that the appearance of the sandboxed version is currently looking a lot more like Geobox That's great, and clearly many editors (perhaps even yourself) have been involved and invested effort in making this happen, which I salute,

but previous discussions have turned on functionality, rather than look and feel alone, something readily apparent when reading those previous discussions. 3. "and you are invited to join in!" I regret I did not and do not have confidence in the process, given the factors I've cited here and cited above. I still am trying to cling to WP:AGF, but it's hard. It is looking to me rather like a well-intentioned yet hasty and sloppy Tfd (with an admittedly unforeseeable but now reported disenfranchisement) has led to an unequally-weighted merge process, and now a request to delete Geobox. By the way, Zackmann08 posted that request to delete Geobox fours days ago. He knows my interest in the topic. Somehow, he seems to have forgotten to ping me about it. Barely clinging to WP:AGF indeed. --papageno (talk) 00:52, 16 November 2018 (UTC)

@Qui1che: get the hell over yourself. It is not my responsibility to ping you. Given what an absolute pill you have been through the entire process, why on earth would I go out of my way to help you? You have no interest in finding a solution, all you are interested in is ranting so I have chosen to simply ignore your rants and work with the other editors on a constructive solution. Thanks. --Zackmann (^{Talk to me}/_{What I been doing}) 01:48, 16 November 2018 (UTC)

Source confluence

Geobox distinguishes between a source and a source confluence. Is the word "confluence" needed, or can this be lumped together with "source"? — Martin (MSGJ · talk) 13:52, 1 November 2018 (UTC)

A google search suggests that "source confluence" is not a term widely used by anyone. Unless anyone suggests the contrary, I will merge these parameters into "source". That does not stop editors using "source_location" to describe the confluence. — Martin (MSGJ · talk) 20:27, 5 November 2018 (UTC)

How would that affect the presentation of source information in Ohio River, for instance? Would any of the information be lost? Thanks--TimK MSI (talk) 20:41, 5 November 2018 (UTC)

Please keep them separate. "Source" and "secondary source" in geobox refer to two tributaries (Allegheny and Monongahela) that join together at a certain point "source confluence" to form a river (Ohio). Merging those parameters would cause a lot of duplicate data field errors if and when the two templates are ultimately combined, or would result in the unintended deletion of content in either the "source" or "source confluence" field.

idea 1-

make geobox "source" correspond with infobox "source1"
make geobox "source1" correspond with infobox "source2"
add a new field "source confluence" to infobox, corresponding with geobox "source confluence", so that geobox data could be merged in more smoothly

idea 2-

add a new field "headwater1" to infobox, to correspond to geobox "source"
add a new field "headwater2" to infobox, to correspond to geobox "source1"
change "source3", "source4", "source5" in infobox to "headwater3", "headwater4", "headwater5" for consistency
make geobox "source confluence" correspond to infobox "source"

If anything, it's infobox that is confusing because you can indicate multiple sources but there is no way to list where their confluence is located. For Ohio River, for example, infobox doesn't have sufficient fields to list Allegheny and Monongahela as the two main tributaries and the fact that they join at Pittsburgh, plus elevation and coordinates and other related data. If there's a better term for "source confluence" I would be fine with changing that too. Shannon [ Talk ] 08:09, 6 November 2018 (UTC)

Well the first idea is definitely more straightforward than the second. I don't want to be introducing new parameters - that neither template currently use - at this stage. — Martin (MSGJ · talk) 08:23, 6 November 2018 (UTC)

@MSGJ:@Shannon1: Apologies for the delay in responding to this. I think a "source_confluence" or "headwaters_confluence" field is necessary for the Infobox. Since it is only present in Geoboxes where multiple sources are specified, simply moving the information from Geobox "source_confluence" into an Infobox "source" field would seem to create a mess (it would clash with the multiple sources listed in other fields). I think the Infobox confluence parameters and mappings could be handled similarly to the source1, source1_location, source1_elevation, and source1_coordinates in the parameter mapping document. Thanks-- TimK MSI (talk) 21:05, 15 November 2018 (UTC)

Depth

Geobox has a single field depth. Is this generally used to record the average depth of a river or the maximum depth of the river? — Martin (MSGJ · talk) 16:45, 1 November 2018 (UTC)

In the sandbox version, depth is assumed to be an average depth. But I think it would be good to deprecate this parameter in favour of depth_avg, depth_min and depth_max. — Martin (MSGJ · talk) 17:03, 6 November 2018 (UTC)

I also support deprecation in favor of the clearer depth_avg, depth_min and depth_max.

ɱ

(talk) · vbm · coi) 00:48, 20 November 2018 (UTC)

Width

I was surprised to see that geobox assumes that a number is in kilometres. I would have expected a more natural unit for river width to be metres. — Martin (MSGJ · talk) 17:02, 6 November 2018 (UTC)

Just a comment- I never found this field to be much use, since there aren't many rivers with a consistent width from source to mouth (excepting very short rivers formed by a confluence of two good sized streams, something like Quillayute River). Though others may disagree... Shannon [ Talk ] 18:19, 6 November 2018 (UTC)

I'm guessinhg it's in kilometers as width is not specific to river and is open for all types of geobox. -- WOSlinker (talk) 18:51, 6 November 2018 (UTC)

Coordinates

Geobox accepts a parameter coordinates as a general location of the river. This does not seem very useful as rivers are not at one location. Infobox river has mouth_coordinates, source_coordinates, etc. I'm wondering how best to use the coordinates parameter. Which part of the river is it generally used for? — Martin (MSGJ · talk) 21:50, 4 November 2018 (UTC)

Around the mouth region makes more sense in my personal opinion. If I remember correctly, this was brought up in the previous cleanup, and the uses were all moved from generic coords to mouth location. For rivers discharging into another river (tributaries), the coordinates of the junction (i.e. mouth region of the subject river) is stated. Reh man 01:38, 5 November 2018 (UTC)

Great. So hopefully it is not being used anymore and we can stop supporting its use after the merge. — Martin (MSGJ · talk) 07:27, 5 November 2018 (UTC)

Status

So this process has gotten a bit stalled. Can those involved give a status update? What are the action items? What currently needs to be done to further the process? If any and all interested parties could add to the list below listing their current concerns so that we can make sure they are all addressed that would be great!

~~Need to add {{{discharge1}}}, {{{discharge2}}}, etc. The names of the discharges to go along with their locations.~~

--Zackmann (^{Talk to me}/_{What I been doing}) 20:05, 11 November 2018 (UTC)

@Shannon1, Pigsonthewing, Mythdon, Rehman, WOSlinker, and MSGJ: as active members of this thread could you provide some updates? Can we keep this process moving along? What are the blockers that you see currently? --Zackmann (^{Talk to me}/_{What I been doing}) 07:41, 12 November 2018 (UTC)

Nothing is stalled here. I will try and finish the coding this week. Further comments on the specific queries raised above would be helpful though. — Martin (MSGJ · talk) 07:58, 12 November 2018 (UTC)

@MSGJ: all I meant was that I want to make sure we are clear on what the next steps are. :-) The one thing I noticed is that while we have {{{discharge1_location}}} we don't have a name for said discharge. --Zackmann (^{Talk to me}/_{What I been doing}) 20:00, 12 November 2018 (UTC)

@MSGJ: holy crap you have done some serious work on that sandbox!!! I confess I hadn't looked at it in a while. AMAZING job!!! Made a few small changes to allow for adding the name of the discharge location(s). That is something that {{Geobox}} has and I don't think we want to loose. --Zackmann (^{Talk to me}/_{What I been doing}) 20:20, 12 November 2018 (UTC)

Give me an example of how that is used? I see a whole new row has been added for location now, which is a pity if it the name is not used. — Martin (MSGJ · talk) 20:26, 12 November 2018 (UTC)

@MSGJ: I have no problem with you adjusting the format. The important thing for me is that we need the ability to display both a discharge location and a name for the discharge. This is consistent with what you have already done with river sources and with the mouth. I'm trying to find a real world example but for example see the mock-up to the right.

The important point is that this is consistent with river sources and the mouth. You make a good point about the new row for location. To be fair though, I was following your lead in Template:Infobox river/source. What if we combined the name with the location? Do some logic to produce this second output. (Note in the code here I just merged the values for the inputs. I'm suggesting doing some logic on the template to take 2 parameters and merge them onto one line.) That way you can provide a discharge name as well as a discharge location. If both are provided, we comma separate them. If just one is provide, we display that one. If neither is provided, but one of the other discharge values is, THEN we just insert the NBSP. Thoughts? If you like the idea, I'm happy to code it and mock it up. We can always tweak it...--Zackmann (^{Talk to me}/_{What I been doing}) 22:30, 12 November 2018 (UTC)

My understanding of the discharge_location field is that it is simply recording the place where a given flow rate is measured. (i.e., that's where the stream gauge is located for the measurement that follows.) If that's the case it's not really a parallel situation to source and mouth, is it? We might record the location of the discharge measurement as a city, or as being at the mouth, but it doesn't seem necessary to record something like Atlantic Ocean when recording the site where a river measurement is taken. Regardless, for the source and mouth I think it is worthwhile (and VERY beneficial to an automated conversion process, given how information is recorded in Geobox) to maintain the existing separate fields for physical features (such as mountain ranges/lakes at the source, and rivers/lakes/oceans at the mouth) and political jurisdictions (such as cities, etc.) Maintaining that distinction for mouth and source also seems like it would be beneficial from a Wikidata perspective. Apologies if I'm misunderstanding here. Thanks--TimK MSI (talk) 23:08, 12 November 2018 (UTC)

@TimK MSI and MSGJ: hmm well it seems like I may have a fundamental misunderstanding for discharge. MSGJ feel free to revert my change then. I've said my peace but honestly you two have a MUCH better understanding of rivers that I do... So I 100% defer to you. :-) --Zackmann (^{Talk to me}/_{What I been doing}) 00:17, 13 November 2018 (UTC)

Well I'll check the current behaviour and try to replicate as far as possible. I like your suggestion of combining it with the location. — Martin (MSGJ · talk) 11:21, 13 November 2018 (UTC)

Cool. Keep me posted and let me know how I can be helpful. --Zackmann (^{Talk to me}/_{What I been doing}) 19:31, 13 November 2018 (UTC)

@Zackmann08:: I noticed you're already converting a lot of geoboxes to infobox, but didn't we agree in the original discussion that this conversion would only take place after the new infobox format has been finalised, per all the points raised above? What's the status on that right now? Shannon [ Talk ] 02:26, 16 November 2018 (UTC)

@Shannon1: so a couple of things to keep in mind...

The merger can take place at any point as the TFD was closed as merge. That being said, what we are working on right now is making sure that this template will retain 100% of the information AND that it will display in a manner that everyone likes.
What I am working on is building a script that will allow this conversion to take place. Part of that is to actually convert pages and test the results. (See the thread below with TimK MSI
The big concern is a loss of information here. I am fairly confident that no information has been lost in any of the work I have done. If you feel otherwise PLEASE bring it to my attention right away and I will fix it!
One of the reasons I am doing conversions is so that I can look at a lot of pages and see what we are missing and what looked better on {{geobox}}. I have already identified a few issues that we are working on resolving.

The nice thing is that once these are all on one template, changes to the template will be reflected on all pages. Let me know if you have any other concerns. --Zackmann (^{Talk to me}/_{What I been doing}) 03:10, 16 November 2018 (UTC)

@Zackmann08: Echoing @Shannon1's comment. Why are you converting? Did @MSGJ not close the Tfd with the text I will wait 30 days to give time for these discussions to conclude, before beginning the implementation of this merger? I take the point that format can be walked back/updated. --papageno (talk) 05:55, 16 November 2018 (UTC)

@Zackmann08: I noticed you changed to the newer version, thanks! However I am seeing that your script is deleting maps from some infoboxes, such as on Aliso Creek (Orange County) and Cedar River (Washington) which happened to be on my watchlist. Shannon [ Talk ] 01:19, 17 November 2018 (UTC)

@Shannon1: thanks for catching that. There is an error in my script that if the Geobox has both an image map AND an pushpin map, only one is being kept. I'll fix the script now! --Zackmann (^{Talk to me}/_{What I been doing}) 01:27, 17 November 2018 (UTC)

@Zackmann08: Another issue I am seeing- tributaries are losing their wikilinks in the conversion. Also I think we discussed this a while back, but it would be nice to tweak the order of the discharge fields so that "average" comes before "minimum", since average is the more important figure here. Thanks! Shannon [ Talk ] 19:11, 17 November 2018 (UTC)

@Zackmann08: Wikilinks are being lost for various place names, in addition to tributaries, as here. It looks to be pretty widespread among the hundreds of conversions you've done.--TimK MSI (talk) 19:26, 17 November 2018 (UTC)

(edit conflict) @Shannon1: both good points! So the issue with the Wikilinks is kind of unavoidable. This is due to the fact that {{Geobox}} uses {{autolink}}. There have been a number of issues with using autolinking as it leads to WP:OVERLINKing. As for the order, I'm choosing not to worry about that as part of my conversion. Why? Because my work doesn't affect what order they show up in. As I said before {{Infobox river}} is still a work in progress. There are still a number of improvements that can and absolutely should be made! But those are independant of converting pages from geobox to the infobox. If tomorrow we switch the order of average and minimum, all the pages using {{Infobox river}} will automatically update. Does that make sense? If this was a matter of needing to change the way I converted the template, then I would be concerned about it right now. Let me know if I'm not doing a good job explaining that. I'm pretty well versed with templates so I never know how much to explain to people. I don't want you to think I'm talking down to you, but also want to make sure I'm giving you a good enough explanation. Finally, I really want to commend you on the way you are continuing to point out issues. You aren't being a pain about it or being difficult. You are raising real concerns and continuing a very constructive dialog so I want to once again thank you for that! Please continue to ping me whenever you notice something that needs my attention! --Zackmann (^{Talk to me}/_{What I been doing}) 19:29, 17 November 2018 (UTC)

@TimK MSI: see my comment above. I'm going to stop conversions for a bit and start a thread to discuss this issue. It is something we should talk more about. Give me a moment to start a new thread? I'll be sure to ping you in it and absolutely want you to voice your concerns. Thanks! --Zackmann (^{Talk to me}/_{What I been doing}) 19:31, 17 November 2018 (UTC)

@Zackmann08: It looks like the "image size" field is being ignored by the conversion, as occurred on Snake River and presumably a lot of other pages that used a custom header image size. Also I'm not sure if I asked this previously, but are you going to run through all the pages a second time once the script has been finalised? Shannon [ Talk ] 04:33, 20 November 2018 (UTC)

@Shannon1: I fixed it, thanks. Sadly there really is no easy want to go back and re-run the script a second time. I would have to manually go through all the pages again which is difficult to do. Right now I'm working from Category:Geobox usage tracking for river type. No real way to go back and figure out which pages I converted. This is all being done manually. --Zackmann (^{Talk to me}/_{What I been doing}) 06:32, 20 November 2018 (UTC)

@Zackmann08: I understand there is a lot of work involved, but one of the big concerns with this merger was the potential for unintentional losses/changes to fields, and so far several things have come up: maps being accidentally deleted, wikilinks being lost, image size being lost, and probably others that we haven't noticed yet... You also mention a couple days ago in the section below that this project is "still very much in the testing phase" - so this means you have converted hundreds of articles for "testing" but have no intention of going back to check for errors? Sorry if I am sounding unreasonable but I think we both want to get this merger implemented right. Shannon [ Talk ] 07:22, 20 November 2018 (UTC)

Preventing widespread loss of information during conversions

Via my watchlist I noticed a recent round of geobox-->infobox conversions on articles about protected areas. To take one example of many, in comparing the geobox version to the infobox version, several pieces of information were deleted, including in fields that are accommodated by infobox. (i.e., it's not that the information couldn't in all cases be accommodated by infobox; rather, the converting editor appears to have opted to strip it out). Here is another before and after. This represents my greatest fear about these conversions: that a decade's worth of information carefully recorded by countless editors across thousands of articles will be quickly deleted in the process. The example I cited brings that fear exactly to life. I would really like to avoid that outcome! Thanks--TimK MSI (talk) 10:55, 12 November 2018 (UTC)

@Zackmann08:: would you like to attend to the above, as this was your edit? — Martin (MSGJ · talk) 11:14, 12 November 2018 (UTC)

@MSGJ: yup! I've been sleeping. :-p Sorry for that. TimK pinged me in 3 different locations informing me that I destroyed the page so I'll get on it. --Zackmann (^{Talk to me}/_{What I been doing}) 18:50, 12 November 2018 (UTC)

@Zackmann08: Wait a sec, your edit to Aliso and Wood Canyons Wilderness Park compared with previous revision deleted about half the fields transitioning from geobox to infobox... looks like I'm not the first one here though... Shannon [ Talk ] 01:47, 13 November 2018 (UTC)

@Shannon1: fixed. --Zackmann (^{Talk to me}/_{What I been doing}) 01:52, 13 November 2018 (UTC)

Will a bot be doing any of the conversion work?

These conversions from Geobox to Infobox are highly prone to human error when undertaken manually by individual editors, as we see in the section above. There is potential to accidentally delete important information with each edit. I guess I assumed that with 10,000+ articles involved, a bot would be programmed to do some or most of the conversions, lessening the need for each article to be carefully reviewed for mistakes. Is that not the case? --TimK MSI (talk) 21:30, 15 November 2018 (UTC)

@TimK MSI: I'm working on testing something out right now. I have a script setup locally. What it allows me to do is copy and paste the geobox code into a file on my machine, run it and it spits out the converted form. The most important part of my current testing is to make sure that it fails when it hits an unhandled case. It is impossible to account for every permutation of the Geobox, but so far the script I have is working pretty darn well. When it hits a case that it doesn't know how to handle, or when it finds parameters in the code that it isn't working with, then it fails. This prevents me from deleting bunches of information. Right now still very much in the testing phase and NOT a bot, as it required me to manually perform a number of the operations, but so far, has potential. --Zackmann (^{Talk to me}/_{What I been doing}) 21:48, 15 November 2018 (UTC)

Thanks! --TimK MSI (talk) 21:56, 15 November 2018 (UTC)

Location of Other name/native names

@MSGJ, Rehman, WOSlinker, Shannon1, and Mythdon: and everyone else involved, can I propose moving the {{{name_native}}} and {{{name_other}}} to the top of the infobox? I.E. using the {{{subheader}}} of the {{Infobox}}? I don't think it is necesary to include a label for other names or native names. This would follow the pattern of some of the most used templates like {{Infobox settlement}} for example. Thoughts? (Happy to code it myself). --Zackmann (^{Talk to me}/_{What I been doing}) 23:38, 15 November 2018 (UTC)

Hi. I'm neutral on reordering parameters. But, may I ask if there are any parameter renames that is part of this? Reh man 01:44, 16 November 2018 (UTC)

@Rehman: I sure hope not... Personally, there are some parameters I would like to rename at some point, but 1 thing at a time. I think if we try to do too much in one go, this is all going to come crashing down. --Zackmann (^{Talk to me}/_{What I been doing}) 01:48, 16 November 2018 (UTC)

Thanks. I'm fine with reordering based on opinions of those who are familiar with the topic. But I am against renaming existing parameters unless there is a strong reason with consensus. Just wanted to clear that. Cheers, Reh man 02:40, 16 November 2018 (UTC)

Autolinking discussion

@MSGJ, TimK MSI, and Shannon1: There have been some concerns raised about links being lost as part of the conversion process. The reason for this is that {{Geobox}} uses {{Autolink}} while {{Infobox river}} does not. Now MSGJ has previously posted about some of the issues of using the autolink feature. So there are a couple of things to discuss here.

I'm pretty confident that we do NOT want to implement autolinking in {{Infobox river}} but MSGJ would you mind explaining (again I know) why autolinking is problematic? I have a good idea of it but just want to make sure we have this clearly articulated.
Since we are not using autolinking... How do we want to address converting the pages. My script is doing direct parameter replacement. So if the page had {{Geobox|country=United States}} that is being converted to {{Infobox river|country=United States}}. The issue again is that with autolinking, geobox would automatically convert that from plaintext to a link. So now the question becomes, should my script (or any script for that matter) automatically make all country values linked? I see a number of issues with this. What if the country value was united states? Or {{Geobox|country=United States & Canada}}? Apart from the technical challenges, there is the whole issue of WP:OVERLINKing.

MSGJ, TimK, Shannon and anyone else involved in this discussion if you could please share your thoughts on this matter that would be great! --Zackmann (^{Talk to me}/_{What I been doing}) 19:40, 17 November 2018 (UTC)

@Zackmann08: Even as a (formerly) heavy user of Geobox I disliked its autolinking, so I'm definitely not in favor of introducing it into the Infobox. I think among regular Geobox users it was widely known that the autolinking could be overridden, either by using wikilink markup (to accommodate pipe linking, or to link to multiple articles) or by using nowiki tags. There may be other ways, and I assume the template markup you mentioned overrides it too. Would it be possible for the script to create wikilinks in the affected fields, conditionally upon the absence of such markup? This would preserve the status quo, which I think would be best. When I was using Geobox I know I was mindful of its autolinking behavior and adjusted accordingly, to avoid either over- or under-linking, and I would hate for editors' efforts in that regard to be undone by a script. On the topic of overlinking, I think a lot of these have been addressed in individual articles over the years (via projects to repair links to disambiguation pages, for instance), such that maintaining the current wikilinking status quo would be reasonable in a script-based project. I also think readers generally expect place names and landforms to be wikilinked in geographic infoboxes, and that this conversion (to cite the same example I cited above) resulted in an under-linked infobox. Thanks!-- TimK MSI (talk) 21:33, 17 November 2018 (UTC)

Seconded. While there may be some mistakes in existing geobox with linking to disambiguation pages, it would be preferable to preserve the status quo rather than completely delete everything. Overall the goal should be to minimize disruption and unintended content changes during the conversion process. Pre-existing problems can be corrected later and should have nothing to do with the conversion. Shannon [ Talk ] 21:37, 17 November 2018 (UTC)

@TimK MSI and Shannon1: you both hit the nail on the head. I just had an idea over lunch that I'm going to test out in a few minutes. Essentially want I want to try to do is use a subst: function along with a check for existence. So in the case above... {{Geobox|country=United States}} → {{Infobox river|country=United States}} while {{Geobox|country=Zack's Magic Land}} → {{Infobox river|country=Zack's Magic Land}}. This should preserve the status quo. If the page is overlinked at he moment, it will remain overlinked, but that can easily be corrected. Also, I would only apply this to fields that are currently autolinked so I wouldn't be introducing any new links. Got a number of chores to do at home today, but I will try to get on this in the next few hours. --Zackmann (^{Talk to me}/_{What I been doing}) 21:57, 17 November 2018 (UTC)

Update... Preliminary testing in mysandbox shows that this should work {{subst:#ifexist:United States |[[Untied States]]|Untied States}} --Zackmann (^{Talk to me}/_{What I been doing}) 22:06, 17 November 2018 (UTC)

@TimK MSI and Shannon1: so tested the new solution on English River (Iowa). I ran the old geobox through the updated script and the result was that it linked a number of params. Compare the overall change and the recent update. Looks like it should work! More testing to follow... --Zackmann (^{Talk to me}/_{What I been doing}) 22:43, 17 November 2018 (UTC)

Thanks - looks better. Just wondering if you're planning to re-run the finalised script on the earlier conversions you did? Shannon [ Talk ] 03:53, 18 November 2018 (UTC)

I also support not using Autolink in river infoboxes; I've had to use workarounds. Is Autolink even used on any other infobox types? $ɱ$ (talk) · vbm · coi) 00:51, 20 November 2018 (UTC)
- @Ɱ: Nope it isn't. I did a few regex searches. There are a half dozen or so rarely used infoboxes with autolinking. None of the well documented ones do. --Zackmann (^{Talk to me}/_{What I been doing}) 01:37, 20 November 2018 (UTC)

Credit to @Zackmann08 for raising this issue. Question: what is the technical feasibility of autolinking? How was it achieved in Geobox, and how might it be achieved in an Infobox? --papageno (talk) 05:14, 20 November 2018 (UTC)
- @Qui1che: it was achieved in {{geobox}} using {{autolink}}... --Zackmann (^{Talk to me}/_{What I been doing}) 05:22, 20 November 2018 (UTC)
  - @Zackmann08: Is {{autolink}} still a feasible approach? If autolinking were to be implemented —and I'm not making the judgement that it should, just asking how it might be done—should it still be done with that template? Or could a more efficient updated approach be taken? Or…? --papageno (talk) 05:41, 25 November 2018 (UTC)

Picking up on other comments earlier: 1. I don't think overlinking is a risk, given the many articles have basic geographic information, and source, mouth, and tributary details. 2. While autlinking does occasionally lead to snafus, the workarounds—like using nowiki tags—are easy to document, and simple for even a basic user to implement. --papageno (talk) 05:41, 25 November 2018 (UTC)

Taking a step back, While I suspect autolinking was implemented by the Geobox creators to remove the need to hard-code links, I think the outcome—links to articles—is more important than the method. For example, perhaps it would be possible to achieve links by a patrol bot using the approach in the Geobox-to-Infobox conversion bot, which I gather is adding links for field values that aren't 'nowikied'. Another approach might be to limit autolinking (or added linking by bot) to say countries, regions, provinces and cities (the subdivision fields in the Location section), which would reduce the chance of snafu links as articles for countries etc are already more likely to exist. For example, I gather {{Infobox Australian place}} uses autolinking only for cities/towns/etc. A bot-based linking approach could also be implemented in stages or only in a limited fashion; and could be applied to other Infoboxes with country and region information. --papageno (talk) 05:41, 25 November 2018 (UTC)

We're not doing autolinking. The workaround of using nowiki tags is absolutely ridiculous. Sorry but just no. --Zackmann (^{Talk to me}/_{What I been doing}) 05:44, 25 November 2018 (UTC)

Thanks for your response. I realize I made a fair number of suggestions in my comments above, but I would view favourably a more detailed response to them. Also, I think the question "Is autolinking feasible or hard to implement from a technical point of view" should be answered. I do not have the knowledge to answer the question, hence me posing it, now several times. Regards, --papageno (talk) 06:36, 25 November 2018 (UTC)

Order of discharge fields

I believe it's more appropriate to order the discharge section as "avg – max – min" rather than the current "min – avg – max"; average is the most important figure and that should be reflected as such. Shannon [ Talk ] 01:01, 20 November 2018 (UTC)

Other nitpicks

A number of small visual tweaks to infobox that I think would improve it (may add more if other things come up):

Should the source and mouth data/coordinates have their own separate heading, titled "river locations" or similar? The current "physical characteristics" section is getting a bit long.
"Basin size" should be put under physical characteristics rather than basin features; it's a characteristic, not a feature, and makes sense to be put alongside other numerical data of length and discharge.
"River mouth" can just read "mouth", it's obvious what it refers to, and is kind of redundant since it's obviously an infobox for a river.

Thoughts? Shannon [ Talk ] 04:44, 20 November 2018 (UTC)

@Shannon1: I have no opinion on the first two but they can easily be changed at any point. I went ahead and addressed the third one. Totally agree. --Zackmann (^{Talk to me}/_{What I been doing}) 06:30, 20 November 2018 (UTC)

Depth issue

In a lengthy thread on Talk:Hudson_River#Infobox Shannon1 raised a concern that we need to discuss. The issue is what do we do with |depth= values from {{geobox}}. My initial stance was that they need to just be removed. Why? They are non-specific. {{Infobox river}} has avg, min and max depth. A generic "depth" to me means nothing because a river's depth is absolutely non-uniform. That being said, simply removing the value flat out is bordering on unexplained content removal. I'm looking for suggestions. In the meantime, I'm going to write up a script that will give us a list of pages that are using {{geobox}} with a non-nil value for |depth=. I want to see what sort of numbers we are looking at. If the list is small enough, it might be practical to just manually update the values with the more correct version of avg, min or max. @Shannon1: please chime in here and make sure I'm accurately summarizing your concerns. Want to make sure I'm not putting words in your mouth or misrepresenting your position. --Zackmann (^{Talk to me}/_{What I been doing}) 18:04, 21 November 2018 (UTC)

If the number of usages are small, then I'd say we find the refs for those numbers, and update accordingly. Else, if it's just an isolated number without any way of identifying, then we should remove it. Having no value is better than having a wrong/misleading value. Reh man 01:54, 22 November 2018 (UTC)

@Rehman: my thoughts EXACTLY! --Zackmann (^{Talk to me}/_{What I been doing}) 02:35, 22 November 2018 (UTC)

@Zackmann08: Thanks for moving the discussion over here - yes that's pretty much the issue I brought up. There's also the "width" field that probably should be taken care of the same way, and also a "volume" field (though I have no idea what that one is for, since there's already discharge). Other than that I don't think there are any issues with ambiguous fields. I would be glad to help look at some of these cases as well. Shannon [ Talk ] 05:29, 22 November 2018 (UTC)

@Rehman and Shannon1: Good news. The total count is 57, that is 57 of the remaining river {{Geobox}} pages have a |depth= value. Working on getting the actual list of page names and will post it below in a bit. --Zackmann (^{Talk to me}/_{What I been doing}) 21:14, 22 November 2018 (UTC)

Thanks a lot! I'll look at some of these as well. Shannon [ Talk ] 17:18, 23 November 2018 (UTC)

Is 1.2km a bit wide for a river (Narva River)? -- WOSlinker (talk) 21:20, 24 November 2018 (UTC)

@WOSlinker: Looking at Google Maps that does seem to be about the width of the river near its mouth. Shannon [ Talk ] 02:05, 26 November 2018 (UTC)

@Zackmann08: A lot of these articles with depth fields appear to refer to estuaries and I think it would be appropriate to convert that to |max_depth=. The "volume" field appears to refer to the volume of the estuary only, so I haven't thought of a way to deal with that, yet. I've labeled those with a *, hope that helps. Also some of these aren't rivers at all... I'll have a look at those too. Shannon [ Talk ] 02:05, 26 November 2018 (UTC)

@Zackmann08: I reverted the one on Puget Sound for now since you deleted a good 50% of what was in the geobox. Granted that page shouldn't have been using river geobox at all, ~~I'm going to go see what it can be replaced with sometime in the next few days.~~ Replaced with infobox body of water. All good now. Shannon [ Talk ] 07:33, 3 December 2018 (UTC)

Coded links to tributaries accidentally stripped during conversion

At Dunrankin River, hard-coded links to two tributaries from the penultimate edit appear to be missing in the most recent edit after the Geobox to Infobox conversion. A second issue is the naming of the "Districts" field, which is (automatically) plural in the old Geobox and singular in the new Infobox. In both cases, the fields in question were "field" and "field1" in the old Geobox. A third issue is that the source and mouth elevations, by default metric parameters in the old Geobox, have been changed to hard-coded convert templates rather than auto-converted fields. --papageno (talk) 06:25, 25 November 2018 (UTC)

@Qui1che: You can pluralize district in the infobox, see my last edit. Also the tributaries were autolinked as well. --Zackmann (^{Talk to me}/_{What I been doing}) 08:04, 25 November 2018 (UTC)

"Source confluence" (again)

@Zackmann08: The information in Geobox "source confluence" is being incorrectly converted to "3rd source" in infobox. (Examples here and here.) Labeling the confluence of two headwaters streams as a "3rd source" would make no sense to readers. There was a never-resolved discussion about this above. I think the simplest solution would be the one @Shannon1: and I each proposed there -- adding a set of "Source confluence" fields to which this information can be mapped. Thanks--TimK MSI (talk) 11:27, 28 November 2018 (UTC)

@TimK MSI: FWIW that was an intentional change that I made. Call it WP:BOLD. That being said, you've objected and I'm totally fine with your solution. I see no reason not to add a source confluence. Let's see if anyone else chimes in? If there are not objections I will implement a source confluence set of fields. Either way I won't convert ANY more source confluence pages until this is resolved. Thanks for the notes! --Zackmann (^{Talk to me}/_{What I been doing}) 17:54, 28 November 2018 (UTC)

@Zackmann08: Thanks for the reply, and I'm happy with the re-done Hughes River (West Virginia) conversion with the added fields. Thanks! --TimK MSI (talk) 18:55, 28 November 2018 (UTC)

@TimK MSI: My pleasure! Thanks for checking my work and calling out my mistakes. Been super helpful having a second set of eyes on this. :-) We are slowly but surely getting there... As I type this we have just over 2,000 pages left: Category:Geobox usage tracking for river type (0) --Zackmann (^{Talk to me}/_{What I been doing}) 19:04, 28 November 2018 (UTC)

@Zackmann08: Hmmm, the Delaware River conversion appears to have lost this info. There was some data recorded in the Geobox that wasn't displaying in Geobox (it apparently was wrongly encoded for Geobox? That stuff is in fields "source_confluence_district", "source_confluence_region", etc.) However, the elevation and coordinates were displaying in Geobox, but have gotten stripped out of the Infobox. Thanks--TimK MSI (talk) 21:16, 28 November 2018 (UTC)

@TimK MSI: SON OF A B$#@H!!! lol. 1) Dayum son... You are good at spotting this stuff!!!! 2) I'm on it. I know exactly what the problem is. --Zackmann (^{Talk to me}/_{What I been doing}) 21:19, 28 November 2018 (UTC)

Checking the recent conversions for errors, cleanup, etc.

So several thousand articles have been converted from Geobox to infobox in recent days. I have been spot checking the work as it has been proceeding, and I would like to spend some more time reviewing the changes, looking for issues, etc., in the days/weeks ahead, and I assume some other editors might like to as well. The easiest way (really, the only effective way) to review a conversion is by using the "visual" difference mode (as opposed to the wikitext mode). Unfortunately the disabling of the Geobox template (in this series of edits, pinging @Zackmann08: and @Frietjes:) has had the effect of disabling the "visual" difference mode as well: see this difference, for instance. Formerly editors could make a quick comparison of the info in Geobox to the info in Infobox; now the Geobox version just says "Template:Geobox is no longer supported!" The wikitext version is not useful for efficiently reviewing the edit.

Having had a single editor make several thousands of these conversions, in a script-driven process, I think it is important for other sets of eyes to be given an adequate opportunity to review that work. Deleting Geobox on the same day that the conversions were completed has had the effect of preventing us from doing so. Can anything be done? Personally, I just want a week or two to look through some of the ranges of script-driven conversions that I have not had a chance to check. Thanks for considering-- TimK MSI (talk) 19:21, 29 November 2018 (UTC)

@TimK MSI: that is an excellent point. Frietjes I'm going to revert your edit to the {{Geobox}} so that it will still render, but with the error message. This will allow for visual checking for a few weeks. --Zackmann (^{Talk to me}/_{What I been doing}) 19:22, 29 November 2018 (UTC)

sounds good. Frietjes (talk) 19:23, 29 November 2018 (UTC)

Thank you! TimK MSI (talk) 19:25, 29 November 2018 (UTC)

@TimK MSI: yup! Thanks for renaming the section. :-p --Zackmann (^{Talk to me}/_{What I been doing}) 20:40, 29 November 2018 (UTC)

@Pigsonthewing: reverted your speedy of the category until this issue is resolved. Want to keep the category until we completely delete the template. If someone reverts a change and restores the {{geobox}} to a page, that is the cat I'm using to know. --Zackmann (^{Talk to me}/_{What I been doing}) 21:27, 29 November 2018 (UTC)

Now the template has been deleted entirely. I've left a message at the deleting admin's talk page pointing to this discussion.-- TimK MSI (talk) 16:47, 2 December 2018 (UTC)

Page has been restored. Let me know when it's good to be re-deleted. Primefac (talk) 17:18, 2 December 2018 (UTC)

@Primefac: thanks for getting right on that. TimK MSI FYI we have an issue with an overeager editor who marked the page as ready for speedy deletion which is why it got nuked. --Zackmann (^{Talk to me}/_{What I been doing}) 19:42, 2 December 2018 (UTC)

@Primefac: From my perspective it is fine to re-delete Geobox... thank you for accommodating the delay. --TimK MSI (talk) 18:59, 20 December 2018 (UTC)

Thanks for letting me know. Primefac (talk) 21:29, 23 December 2018 (UTC)

Nicknames gone

@Zackmann08: I just noticed that the "nickname" field was completely omitted from your conversions. I have no idea how many articles this might have affected, but see the edit on Columbia River for example. Shannon [ Talk ] 21:25, 5 December 2018 (UTC)

@Zackmann08: The edit cited by Shannon1 had the effect of stripping sourced content from a featured article -- content that was not present elsewhere in the article. Is there a way of determining which other articles had this field deleted, so that they may be manually reviewed? You stated here that you were taking care "to make sure that [the script] fails when it hits an unhandled case. ... When it hits a case that it doesn't know how to handle, or when it finds parameters in the code that it isn't working with, then it fails." So it should have failed in this instance, right? Thanks-- TimK MSI (talk) 10:58, 6 December 2018 (UTC)

To be clear about my personal sense of the seriousness of the matter, I think my next step would be to raise the issue at WP:ANI if it cannot be resolved here. I don't think script-driven editing projects should be removing sourced content from featured articles. And when that is discovered to have occurred, as in this instance, we need to be able to ascertain the scope of the problem, so that the damage to other articles can be repaired, and so that future damage can be prevented. So: Is it possible to determine which other articles have been affected by the problem identified by Shannon1? Thanks-- TimK MSI (talk) 17:34, 6 December 2018 (UTC)

Sorry for the delay, been busy with other projects and real life. If you really feel that you need to raise this at WP:ANI then you are dramatically over-reacting and I'm not going to be very interested in helping with a solution. This process has been transparent from the beginning and I have worked in good faith to resolve the issues every step of the way. Your complaint is that information was accidentally removed from one field. Is that a problem? Definitely. Should we (particularly I) try to solve it? Absolutely! Does it require notification at WP:ANI which is for (and I quote from the ANI page) discussion of urgent incidents and chronic, intractable behavioral problems? Well I guess that is for you to decide. I will say that if you choose to move forward with an ANI, you cannot then expect me to be eager to work with you on a solution. If you would like to actually discuss solving the issue, I'll be very happy to look into possible solutions. --Zackmann (^{Talk to me}/_{What I been doing}) 17:49, 6 December 2018 (UTC)

Thanks! As I said, I do think ANI would be warranted if it cannot be resolved here, as a matter of some urgency, given the scale of the project, and your earlier assurances that anything like this would be caught. (If this didn't get flagged, what else was deleted without being flagged?) Apologies if that is excessive. I would very much prefer to resolve things here! --TimK MSI (talk) 18:06, 6 December 2018 (UTC)

@TimK MSI: look I did my best. Other than pointing out my mistakes, I got very little in the way of support from anyone. There is nothing about this that is urgent. The fact that you felt the need to threaten with WP:ANI in order to get my attention doesn't exactly show a real eagerness to work together. If you want to pursue an administrative intervention, please go right ahead. --Zackmann (^{Talk to me}/_{What I been doing}) 18:48, 6 December 2018 (UTC)

I did not intend to indicate an unwillingness to work together, only to convey my personal sense of the seriousness of the situation. Are you unable/unwilling to assist in identifying which articles were impacted by the deletion of this field? Thanks-- TimK MSI (talk) 19:05, 6 December 2018 (UTC)

I mean, if I had a simple list of the articles I would be happy to manually review them to make sure the content was accounted for in the body of the article. --TimK MSI (talk) 19:20, 6 December 2018 (UTC)

@TimK MSI: here is a list of every river article I have touched in my last 100,000 edits. User:Zackmann08/river pages --Zackmann (^{Talk to me}/_{What I been doing}) 19:58, 6 December 2018 (UTC)

Thanks. So I take it there is not a way editors would be able to specifically review instances where the script encountered a Geobox parameter it was unable to transfer to infobox? --TimK MSI (talk) 20:19, 6 December 2018 (UTC)

I would also be glad to help if a more specific list was available, though I shall note that that quite a while back, near the beginning of this process I pointed out that it shouldn't go forward on a large scale until the kinks were ironed out. Hopefully there is a better way to address this than manually going through all 6900+ pages, and I strongly suggest that any remaining conversions be put on hold until we are sure all issues are resolved. Shannon [ Talk ] 00:03, 7 December 2018 (UTC)

thought: Is there a way to search old revisions of pages for the |nickname= and limit that search to articles in the river category? Shannon [ Talk ] 00:04, 7 December 2018 (UTC)

@Shannon1: Thanks for the response. There aren't any conversions left to do, so the damage has been done. I have also found that any content that was in the Geobox's source_length and source1_length fields was also deleted by the script, so there may be more fields to discover. Also the list of 6900+ articles isn't complete -- the Columbia River and the article I just cited aren't on it, so even a manual review of that list wouldn't have caught that damage. This is why I think this is a matter that merits attention from administrators. I don't think Wikipedia content is supposed to be deleted by editors running scripts! --TimK MSI (talk) 07:04, 7 December 2018 (UTC)

TimK MSI, I expanded the list, but if we are going to use a bot or script to search the old revisions, it is probably safer to just check all transclusions of this infobox. I am working on a solution to search the old revisions for "nickname", and if that works, we can use the same method to search for other parameters. I will report back in about 24 hours. Frietjes (talk) 18:49, 7 December 2018 (UTC)

Thank you! --TimK MSI (talk) 18:50, 7 December 2018 (UTC)

@Shannon1 and TimK MSI:, my search took several hours, but found that the following articles had a non-blank nicknames parameter before the most recent revision by Zackmann08: Boardman River
Columbia River
East Bay River
Ford Green Brook
Igara Paraná River (wasn't actual nickname)
Kaaimans River
Lagoa do Fogo
Lerderderg River
Līva
Minho (river)
Mississippi River
Mu River
Murrumbidgee River
Nall River (wasn't actual nickname)
Onon River
Patawalonga River
Petitcodiac River
Pinguk River
Rabacca Dry River
Rajang River
River Crouch
River Frome, Bristol
Sacramento River
Salmon River (Idaho)
Skootamatta River
Snowy River
Tuul River
Upper Neretva
Vaikkojoki
Yarra River
Yarrowee River
Zambezi
. [Note from TimK MSI strikethrough indicates the content has been re-added.]

the search script is probably not perfect. it (1) loads the list of all pages currently transcluding this template, (2) loads the list of revisions starting from November 11, 2018, (3) walks backwards through the revisions to find the last edit by Zackmann08, (4) loads the article content from the revision before that edit, (5) looks for a non-blank |nickname= or |nicknames=. I plan to put a few more sanity checks in there to make sure it's not missing any articles, but otherwise, it seems to be pretty close. Plastikspork, the process would go faster if I had all the old revisions saved to a file, which would require something other than a browser script; could you help? Frietjes (talk) 14:32, 8 December 2018 (UTC)

@Frietjes: Many thanks for this. I will work on adding back the deleted content in the days ahead, and will mark them with a strikethrough. --TimK MSI (talk) 15:36, 8 December 2018 (UTC)

@Shannon1: On the Columbia River and Sacramento River articles I put the nicknames in a custom field at the bottom, which has the effect of inaccurately labeling them as "basin features." Do you have any thoughts on alternatives? Should there be a blue color bar labeled "Other" at the bottom? Thanks-- TimK MSI (talk) 15:57, 8 December 2018 (UTC)

@Frietjes: huge thanks for doing this!!! Really appreciate you taking the time. --Zackmann (^{Talk to me}/_{What I been doing}) 18:04, 8 December 2018 (UTC)

@Frietjes: I thank you as well, will look at the list soon. Shannon [ Talk ] 18:36, 8 December 2018 (UTC)

@Shannon1 and TimK MSI: I have added support for |nickname=. I'm not certain that where I added it is the best place. Part of me thinks it should go up in the header with native_name and other_name. But that can easily be changed. The important part right now is just displaying it. We can easily change where in the infobox it renders. if you have strong feelings on the matter, let me know? --Zackmann (^{Talk to me}/_{What I been doing}) 18:12, 8 December 2018 (UTC)

I have restored the nickname field for all the remaining pages on the list Frietjes created. There were 2 pages (which I noted in the list above) where the nickname parameter was the exact same value as the main name. For those I did not restore the nickname. --Zackmann (^{Talk to me}/_{What I been doing}) 18:36, 8 December 2018 (UTC)

@Zackmann08: Thank you! I am happy with the location you chose for the parameter, and thanks for finishing the list.

@Frietjes: Thank you again for generating the list. Based on your experience, would it be feasible to generate a list of articles that formerly had a |source_length= field in the Geobox? (I think a list based on that parameter would also include all or nearly all instances of the related |source1_length= parameter.) I know I personally used to use the |source_length= parameter fairly often in Geobox but I don't have a sense of how widespread it was otherwise.

I do think it would be worthwhile to add |source1_length=, |source2_length=, etc., to the infobox, to accommodate a couple of not-terribly-uncommon scenarios: 1) to record data about headwaters tributaries that may not otherwise merit their own article, and 2) to communicate that a very short stream is formed by a confluence of much longer streams that are named as "forks" or "branches," etc., in cases where editors choose not to create separate articles for them all. Thanks! --TimK MSI (talk) 14:51, 10 December 2018 (UTC)

TimK MSI, I haven't forgotten about your request. I have now created a general javascript tool for searching the old revisions of a list of pages for a particular template and parameter name. after a lot of testing and debugging, it seems to be working so long as my browser doesn't crash or hang :) I put in some "checkpointing" every 100 articles to avoid restarting the entire search when it hangs. so far it through the As, Bs, Cs, and Ds and found Armstrong Creek (West Virginia), Arnold Creek (West Virginia), Berounka, and Danube. I should have the entire list in about 24 hours. Frietjes (talk) 00:18, 12 December 2018 (UTC)

Wonderful, thank you! I hope your tool proves to be widely useful :) --TimK MSI (talk) 01:51, 12 December 2018 (UTC)

TimK MSI, here is the full list: Armstrong Creek (West Virginia)
Arnold Creek (West Virginia)
~~Berounka~~ (added to body)
~~Danube~~ (unnecessary to article)
Holly River
~~Izvorul Gropii River (Bâsculița)~~ (elevation wrongly encoded)
~~Jărăștuia River~~ (elevation wrongly encoded)
McElroy Creek
Meathouse Fork
~~Mells River~~ (geobox encoding error?)
Mill Creek (western West Virginia)
~~Mirna (Croatia)~~ (empty parameter)
~~Mutha River~~ (geobox encoding error)
~~Ostrach (Danube)~~ (re-added misencoded length)
Paraná River
Pripor River (Bâsca Mică)
Rahmat Khali Canal
Reedy Creek (West Virginia)
Sandy Creek (Ohio River)
Schussen
Shade River
Spring Creek (Little Kanawha River)
Steer Creek (West Virginia)
Twomile Creek (Kanawha River)
Valea Cucului River
Vils (Danube)
Yamaska River
Yenisei River
. Frietjes (talk) 17:36, 12 December 2018 (UTC)

Thank you! I'll strike through them as I check/update them, but first I'll request having the relevant parameters added to infobox.--TimK MSI (talk) 18:16, 12 December 2018 (UTC)

TimK MSI, now enabled see test 3 for an example. Frietjes (talk) 19:40, 14 December 2018 (UTC)

Frietjes, thank you!! I tried adding the parameters to Steer Creek (West Virginia) and got a preview warning, and they're not displaying... I wonder if they also need to be added in the "header9" cluster towards the top of the code? Or could it just be a lag? Thanks!-- TimK MSI (talk) 20:10, 14 December 2018 (UTC)

TimK MSI, I fixed that article. I don't know why, but you had put some unprintable characters between the "length" and the "=". I changed those characters to spaces and it works. Frietjes (talk) 20:30, 14 December 2018 (UTC)