User talk:Hike395/Archive 21

Archive 15

←

Archive 19

Archive 20

Archive 21

Archive 22

Archive 23

Settlement and Chembox

YO! So I'll make you a deal... of sorts. I DESPERATELY need some feedback on {{Infobox chemical}}. I really need a fresh set of eyes to look at it and tell me what I'm missing, what needs work, etc. Can I convince you to spend a bit of time looking it over? In return, let me see if I can find a way to write you a script that can help you with you {{Infobox settlement}} issue. I use Ruby which has more advanced parsing abilities than just plain Regexs in AWB. So I might be able to help you out. Either way, I'll definitely devote some time to manually doing it. If you're not interested, no worries. Don't take this as a "help me or I won't help you". That isn't what I mean at all. My point was more that if we are both going to spend an hour on here editing, lets swap projects for a fresh set of eyes. :-p Let me know! Hope you're well. --Zackmann (^{Talk to me}/_{What I been doing}) 21:45, 23 November 2018 (UTC)

@Zackmann08: Happy to help you with {{Infobox chemical}}. I like test-driven development: that's how I built {{Infobox mountain range}} to port from {{Geobox}}. I found it helpful to create a moderately large number of test cases out of popular/top-importance/FA uses of the infobox: those tend to be the most complex and stressed the use of any new infobox. I can add to the test cases, if you like.

One thing I notice right away from the three test cases that you have --- the editors using {{Chembox}} may have grown used to the horizontal lines between the rows: the data in each group tends to be very long, spanning multiple lines of text. In the infobox version, it isn't clear when one row starts and another ends. (I'm looking at aluminum chloride, e.g., appearance/density/melting point). You may wish to consider inserting horizontal lines between each row to make the infobox more readable. I know that goes against standard infobox style, but it may make the editors who use {{Chembox}} more comfortable with the change. If you like this idea, but need help implementing it, let me know. —hike395 (talk) 17:00, 24 November 2018 (UTC)

@Zackmann08: Another potential issue I just found: there seems to be an infrastructure around validating data in {{Chembox}}: see Wikipedia:WikiProject Chemicals/Chembox validation. The bot only seems to run once a quarter and modifies a few articles. You may wish to ping the bot owner to see whether your proposed changes will break anything. It may simply be an update to the bot configuration. —hike395 (talk) 17:36, 24 November 2018 (UTC)

I LOVE TDD!!!! (I'm a software developer by day so I spend a lot of time doing TDD). I love that you have the same approach as me. My first test case was taken from a FA. I actually did a search for FAs that use {{Chembox}}. :-)

I'm on the fence about the horizontal lines. It goes against the standard style of infoboxes which is part of the reason for doing the conversion in the first place... That being said, it might be best to do the conversion retaining the lines initially, then remove them later. It is simply a matter of changing the body class after all. In my initial implementation I did keep the lines but decided to remove them.

I'll reach out to User:CheMoBot right now. In the mean time, if you don't mind adding test cases that would be wonderful! --Zackmann (^{Talk to me}/_{What I been doing}) 19:14, 24 November 2018 (UTC)

@Zackmann08: As I was starting to build more test cases: I notice that you replicated the subtemplates of {{Chembox}} using child {{Infobox}}es. I don't think that those are strictly necessary: if there is no parameter overlap, the whole infobox can be created at once. This would make it easier for new infoboxes to be created and might make the conversion process a little easier, since you would simply drop the |SectionN= parameters, rather than rewriting them to use, say, {{Infobox chemical/structure}}. Was there a compelling reason to use child infoboxes? —hike395 (talk) 19:36, 24 November 2018 (UTC)

So there are a couple of reasons but the main one is to retain as much functionality as possible. The end goal here is that the front end experience does not change at all. Technically speaking, the parameters are all the same. The only thing that has changed is the template names. So, once the testing is complete and we are 100% ready for rolling the template out, the old versions can just be redirected to the new versions. Additionally, there was a lengthy thread on the talk page for the template. A number of users really like the subtemplates as it allows them to put things in different order if they want to. Do I agree with it? No... But I want to do this one step at a time. User:Zackmann08/Chembox has some notes on future enhancements. --Zackmann (^{Talk to me}/_{What I been doing}) 19:51, 24 November 2018 (UTC)

OK, I understand. I think that Infoboxes should have a fixed ordering of elements, but if that is a blocker for adoption of {{Infobox}}, then we can let it go.

@Zackmann08: As you've seen, I added a check for an empty sub-infobox. Would you like me to add that to the other sub-infoboxes, or should I continue to generate test cases? —hike395 (talk) 19:58, 24 November 2018 (UTC)

I want to be clear, I agree with you! Infoboxes SHOULD have a fixed ordering. My concern is that if we try to change too much initially, there is going to be so much objection that we will never get this done. I'd like to do it one step at a time. Just like you pointed out about the horizontal lines... If you don't mind adding that check I'd sure appreciate it! --Zackmann (^{Talk to me}/_{What I been doing}) 20:09, 24 November 2018 (UTC)

@Zackmann08: I think bordered looks good, will probably make everyone happy. We may need to adjust the spacing/widths a little bit --- I'll give that a try. (Did you happen to try only horizontal lines? Does that look worse?) —hike395 (talk) 20:33, 24 November 2018 (UTC)

@Zackmann08: After adding a few more test cases, flipping back and forth between the desktop and mobile skins, and a lot of futzing with CSS, I think it's looking pretty good (at least on Firefox -- I'll check with some other browsers). What do you think? —hike395 (talk) 00:25, 25 November 2018 (UTC)

I think it looks great! What do you think the next step is for rolling it out? Should we go through the process of filing a TFD right away or just redirect the templates? --Zackmann (^{Talk to me}/_{What I been doing}) 00:33, 25 November 2018 (UTC)

@Zackmann08: I wouldn't use TFD. What I would suggest is leave a note at Template talk:Chembox and at Wikipedia talk:WikiProject Chemicals, explaining what we've done and showing the comparison at Template:Infobox chemical/testcases. After resolving any objections (hopefully none), then you can redirect the old templates to the new ones. Does that sound good? —hike395 (talk) 00:46, 25 November 2018 (UTC)

that works for me. Only thing is that I've posted in both those places, and more. Have yet to really get any responses. --Zackmann (^{Talk to me}/_{What I been doing}) 00:47, 25 November 2018 (UTC)

@Zackmann08: ¯\_(ツ)_/¯ Those would be the two places where people care the most. If no one cares, then I think you're free to update the template. I notice that you have 3 TODO items at User:Zackmann08/Chembox --- do you want to resolve those? —hike395 (talk) 00:50, 25 November 2018 (UTC)

The 3rd one isn't a blocker for moving forward. I've already started the TemplateData and it already is better than what was there for {{Chembox}}. The other two are basically just tracking categories. Frankly those categories were such a mess that that I really don't see any reason to keep them. I'm going to spend some more time looking at it tonight. Let me know your thoughts? --Zackmann (^{Talk to me}/_{What I been doing}) 00:59, 25 November 2018 (UTC)

@Zackmann08: It looks like CheMoBot might rely on some of those tracking categories. Perhaps better to keep those. —hike395 (talk) 01:03, 25 November 2018 (UTC)

I should clarify, it is above my head to scrap them myself. Might just copy the code from {{chembox}} over and have that as a future todo. We shall see. Dinner time so I'm going to sign off for a bit. FYI I'm on WP:DISCORD if you ever want to chat here. Also IRC but less so. --Zackmann (^{Talk to me}/_{What I been doing}) 01:16, 25 November 2018 (UTC)

@Zackmann08: Still futzing around. —hike395 (talk) 03:49, 25 November 2018 (UTC)

Do me a favor, take a look at Ammonia? Notice the extra lines above "Related compounds" and below "Spectral data"? --Zackmann (^{Talk to me}/_{What I been doing}) 04:38, 25 November 2018 (UTC)

@Zackmann08: You mean at Template:Infobox chemical/testcases#Ammonia? I don't see an extra line on Firefox+Windows. What browser/OS are you using? Oh, you've converted Ammonia over. I think I know what it is, hold on. —hike395 (talk) 04:52, 25 November 2018 (UTC)

@Zackmann08: Extremely mysterious. Problem does not reproduce at Template:Infobox chemical/testcases#Ammonia. —hike395 (talk) 05:03, 25 November 2018 (UTC)

@Frietjes: WE NEED YOU!!!!!! :-p --Zackmann (^{Talk to me}/_{What I been doing}) 05:07, 25 November 2018 (UTC)

@Zackmann08:, what is the problem? I don't see any extra lines, and there is a lot to inspect there. Frietjes (talk) 17:31, 25 November 2018 (UTC)

@Frietjes and Zackmann08: Sorry for the bother: I fixed it this morning. —hike395 (talk) 17:33, 25 November 2018 (UTC)

A barnstar for you!

	The Technical Barnstar
	For all your helpful work on {{Infobox chemical}}. :-) Zackmann (Talk to me/What I been doing) 23:35, 24 November 2018 (UTC)

@Zackmann08: Thanks! It's fun! —hike395 (talk) 23:36, 24 November 2018 (UTC)

Well I jumped the gun. About ready to just walk away from the process. I do appreciate all of your help though. --Zackmann (^{Talk to me}/_{What I been doing}) 04:22, 26 November 2018 (UTC)

@Zackmann08: I think this can be rescued if you withdraw your TfD, centralize a discussion at Template talk:Chembox, and patiently work with people from Wikipedia:WikiProject Chemicals. —hike395 (talk) 04:25, 26 November 2018 (UTC)

Withdrew my nomination. I have a feeling the only way for it to be implemented at all is for me to walk away completely. But either way, hopefully it actually happens. On to other things. --Zackmann (^{Talk to me}/_{What I been doing}) 05:46, 26 November 2018 (UTC)

Copyright problem on Northern Anatolian conifer and deciduous forests

Content you added to the above article appears to have as its original source https://www.worldwildlife.org/ecoregions/pa0515#, which is not released under a compatible license. Unfortunately, for copyright reasons, the content had to be removed. Please leave a message on my talk page if you have any questions. — Diannaa 🍁 (talk) 14:12, 27 December 2018 (UTC)

Responded at Diannaa's user talk page —hike395 (talk) 18:05, 27 December 2018 (UTC)

Montane forest

Hi Hike395, I noticed that clicking on Montane forest went to the correct section in Montane ecosystems but the section heading was off the top of the page, requiring the reader to scroll up to make sure they've landed at the right place in the article. I moved the anchor into the section heading so now the heading shows. I haven't played with anchors much, so if this isn't correct, please let me know and I'll change it. Leschnei (talk) 14:56, 1 January 2019 (UTC)

@Leschnei: You did the right thing, and fixed my mistake. Thanks! —hike395 (talk) 20:15, 6 January 2019 (UTC)

Mistake on Rocky Mountains article

So on your summary it says metric first, but you either made a mistake or an editing glitch happened for imperial first. Again, your summary includes metric first but a mistake and/or glitch made it imperial first. I can revert it so it matches with your summary having metric first. MetricSupporter89 (talk) 03:54, 8 January 2019 (UTC)

I just found out on the edit history that Imzadi1979 is again with that “rude” behavior reverting my edits when he didn’t discover it. But on your edit summary it includes metric first. I can revert it so it matches with your summary. MetricSupporter89 (talk) 04:00, 8 January 2019 (UTC)

Give me a favor for the CanAm Highway article

The article about the CanAm is an international article so it has to be metric first. MetricSupporter89 (talk) 12:55, 8 January 2019 (UTC)

On Kuna Peak

Sure, but I changed Kuna Peak, a little. Simple reversion won't work, but can go in an edit. --- dino (talk) 17:48, 7 February 2019 (UTC)

@Dino:  Done Thanks for writing the Kuna Crest article. I love that area, especially near Helen Lake. —hike395 (talk) 19:33, 7 February 2019 (UTC)

Simpsons episodes

Can you please solve this case? Thanks Patriccck (talk) 13:07, 19 February 2019 (UTC)

(from id 882524693) Patriccck (talk) 13:08, 19 February 2019 (UTC)

ta

ecoregions seem to get a very piecemeal understanding at the bestof times, and for some reason the higher level geography project tag gets thrown around willy nilly, when it really isnt needed if the ecoregions tag is there, cheers JarrahTree 09:54, 9 March 2019 (UTC)

@JarrahTree: Fair dinkum. Ecoregions are usually local and can usually stay under one national wikiproject. Biomes, on the other hand, tend to occur worldwide. If you want to put Mediterranean forests, woodlands, and scrub under WP:WikiProject Australia, you may wish to consider also adding WP:WikiProject California, WP:WikiProject Chile, WP:WikiProject South Africa. Not sure what to do about the actual Mediterranean —hike395 (talk) 10:24, 9 March 2019 (UTC)

Fair crack of the whip - that is indeed a continual problem with the oz biota project updating that is currently happening ([1] almost only 8k to go - - many items of flora are in papua new guines and melanesia well but the predecessor hard working project taggers tended to leave em off - the med is always easily subsumed into europe... JarrahTree 10:29, 9 March 2019 (UTC)

Newly missing label in Infobox river

Hello, I noticed that a label is newly missing in Template:Infobox river. Its disappearance seems to coincide with your edits to the template earlier this month, so I thought I'd start with you for troubleshooting. The issue is with the label "- location" for {{{mouth_location}}}. An example of the problem can be seen at St. Johns River: Under the "Mouth" section of the infobox, "Jacksonville, Duval County, Florida" has no label and the text has strayed outside the data column.

It looks like {{{mouth_location}}} had the label "- location" prior to your recent edits. Could you have inadvertently removed the label somehow? I couldn't spot the issue when I compared the revisions.

Many thanks for your assistance!-- TimK MSI (talk) 12:45, 20 March 2019 (UTC)

@TimK MSI:  Fixed Thanks for noticing this: I had misnumbered one of the fields. Now fixed! —hike395 (talk) 09:08, 21 March 2019 (UTC)

El Drago Milenario

Thanks for creating the redirect! With the infobox, as I understand it, it's not actually a tree so I'm not sure that using {{Infobox tree}} is correct. Plus the previous infobox included a map, which I think is worth keeping. Thanks. Mike Peel (talk) 20:30, 20 April 2019 (UTC)

@Mike Peel: A tree isn't a well-defined botanical term. Dracaena draco says it's a "tree-like plant", so I think {{Infobox tree}} is appropriate. I can add a map to {{Infobox tree}}, no problem. I really don't like {{Wikidata infobox}}, because it has a bunch of extraneous information that most readers don't care about. —hike395 (talk) 21:22, 20 April 2019 (UTC)

OK, thanks for adding the map back. Wikidata Infobox is mostly designed to work on Commons, it does need some improvement work here. Thanks. Mike Peel (talk)

nicer pict*!*  ??

hey hello Hike395, i sorta liked the "circa 1870" that shows it is still a lot the same.

 i usually "surf web" with text only browser so it is not much matter to me.

but i am trying to make 8 "improvements to the page" with 2 new citations so that i can pass this oils101 class i am taking. regards, tj*!* . 129.24.95.57 (talk) 02:31, 5 May 2019 (UTC) .

Invitation to join the Fifteen Year Society

Dear Hike395/Archive 21,

I'd like to extend a cordial invitation to you to join the Fifteen Year Society, an informal group for editors who've been participating in the Wikipedia project for fifteen years or more. ​

Best regards, Urhixidur (talk) 02:08, 9 May 2019 (UTC)

@Urhixidur: Thanks for letting me know! I remember working with you on astronomical articles, back in 2004 :-) —hike395 (talk) 06:20, 9 May 2019 (UTC)

Twin Lakes (Mono County, California)

You are of course correct that my aerial of the other Twin Lakes was not so appropriate on this article. I was just being lazy. Really need another article. Since you're a 395 fan, maybe you can help. How do people distinguish these lakes of similar names? How should we disambiguate? Perhaps Twin Lakes (Mono County south) and Twin Lakes (Mono County north)? Dicklyon (talk) 05:11, 27 May 2019 (UTC)

@Dicklyon: I propose that Twin Lakes (Mammoth Lakes, California) and Twin Lakes (Bridgeport, California) would be more recognizable and useful. (Mono County reaches Topaz Lake, so Bridgeport is actually in the middle of the County). Twin Lakes (Mono County, California) can be converted into a dab page. —hike395 (talk) 14:34, 27 May 2019 (UTC)

 Done —hike395 (talk) 15:34, 27 May 2019 (UTC)

Thanks! Dicklyon (talk) 17:11, 27 May 2019 (UTC)

Ebbetts Pass

Lol. I went back into the article this morning to fix the links, and saw you had already beat me to it. Lynn (SLW) (talk) 13:45, 16 June 2019 (UTC)

Mount Olympus

Why did you revert my change? The parent peak of Mount Olympus is Mytikas, not Musala. — Preceding unsigned comment added by Demetrios1993 (talk • contribs) 06:03, 17 June 2019 (UTC)

@Demetrios1993: --- Please see the definition of parent peak. Parent peak is not the summit of a mountain. Parent peak is related to the concept of topographic prominence. Topographic prominence of a peak A is measured by finding a path that goes from peak A through a saddle or col to a higher peak B, where the saddle or col is the highest of all possible saddles leading to another peak. Such saddles are known as key cols. The parent peak, topographic prominence, and key col for peaks is computed at https://peakbagger.com . For Olympus, this is described at [2], which is the reference in the infobox.

Mytikas is thus not the parent peak of Olympus. It is the highest point of Olympus, a different concept. I've changed the infobox to show both Mytikas and Musala. If you'd like to discuss more, I would suggest bringing it up at WT:WikiProject Mountains —hike395 (talk) 06:11, 17 June 2019 (UTC)

@Hike395: Ok, i accept it. I wasn't aware of that. Thanks for the add of the peak Mytikas as well.

Scabies/Scrapie

Hike395:

Hello. I was looking at your bighorn sheep page and in the disease section, it states that bighorns are susceptible to "scabies." I think that you mean "scrapie." I do not want to change anything on the article but it seems incorrect so thought I should send the message. Scrapie is the sheep disease that bighorns get. — Preceding unsigned comment added by 66.162.97.66 (talk) 22:07, 19 June 2019 (UTC)

maybe an RFC about dab pages

Hi Hike395, thank you for your participation at Wikipedia:Articles for deletion/List of lakes named McArthur. I disagree with your !vote by my response just now, obviously, but whatever. I think no bigger discussion is needed about SIAs or anything else, to make a decision about whether that article complies with guidelines (which I believe it does not).

But then there are the older relatively few SIAs about lakes and mountains, which I think are all set up as pretty bare-bones lists of place names plus their coordinates and other location information (i.e. what country, state/province, county or other area they belong to). These tend to include a few items with bluelinks, i.e. individually notable items, plus "blacklink" items which are not expected to be Wikipedia-notable. I appreciate your point in the current AFD (and maybe elsewhere) that it seems unnecessary to have a DAB serving navigation purposes, plus a separate SIA / list-article, for many of these. And there is an issue with current guidelines, that if a DAB contains anything other than a mountain/lake/whatever, e.g. if there unfortunately exists a book named "McArthur Lake" or whatever, then technically that book item cannot appear on the same page of an SIA about the lakes named McArthur. So to convey all the info, it would be techically necessary to have a dab page and an SIA page which are highly overlapping, i.e. perhaps with identical membership except for the book item. To cut through this, I wonder about making a proposal to change DAB page guidelines.

The proposal would be to say that 1) coordinates are innocuous and might be included in any dab page where places are included, along with a {{GeoGroup}} template, and that 2) minor places defined in GNIS or similarly, although not deserving of a separate article, might be mentioned in a dab page. That the coordinates are part of identifying which place is which for navigational purposes (i.e. for readers to find their way to existing articles). Serving up info about not-expected-to-be-notable items in general is not legitimate in a dab page by current rules; and serving up extraneous info not needed for navigational purposes is also not allowed. The argument would be that coordinates are innocuous data, and in this age with GIS and all the maps systems going on, that they are simply identifying, unsubstantial info, but somewhat helpful for navigational purposes. I.e. that a reader looking for a place named "St. Mary's Lake" near where they once vacationed, can use the GeoGroup link to see where the items in the dab page are, and hence whether to go to its article, if one exists for that one. If they can see the one near their vacation-place and also determine that there is no corresponding article for it, that helps them in their navigation (the answer is definitively NO, wikipedia has no substantial info about the place for them). Rather than them having to visit articles on "near-ish" places to see, even though it seems less likely, whether perhaps one of those is the one they want. Then we could do away with separate SIA pages which really just serve up coordinates, because all of their info could be carried in the dab page. I wonder if you think that could be successfully argued, or what.

Also, my general thoughts in this area are partially expressed in new draft essay wp:OkayVsNotOkayListsOfPlaces. I do not want to invoke that more general essay in the current AFD, yet, because it is a work in progress. I am inclined to use it in the future in other AFDs or in calling for more general changes about SIAs. (As I say in the current AFD, I do not want to allow any more general debate to derail that AFD's decision on its merits by current rules.) I would welcome your thoughts at its Talk page though, say.

Anyhow, thanks again for your comments in the current AFD. --Doncram (talk) 03:48, 5 September 2019 (UTC)

@Doncram: thanks for reaching out! A few thoughts:

• I think allowing coordinates on a dab page would be helpful for our readers to disambiguate similar items. Other properties (like elevation for mountains) could also help. It's a good idea.
• To answer your question: I don't think this would be successful --- the long-established design goal for dab pages is to be minimal.
• Allowing redlinks to possibly non-notable locations (e.g., from GNIS) may not be good for readers, because that will tend to interfere with navigation. WP:DABRL dates back to 2007, so it's well-established consensus.
• As I said at AfD, WP:LISTN isn't very clear. This reflects the fact that there are many list pages in WP that are much more navigational/completist than informational. Unfortunately, this makes any notability discussion for lists become subjective, where one editor can find a list useful, while another can find it trivial/non-encyclopedic. It would be nice, for SIAs at least, to see if we can come up with some sort of guideline.
  • Do you agree that Dodge Charger or List of ships of the United States Navy named Enterprise are useful lists?
  • A clear guideline has to allow for list articles that are being developed, otherwise they'll get deleted before they can grow, which goes against the wiki philosophy. —hike395 (talk) 07:36, 6 September 2019 (UTC)

• • • Thank you for engaging here. Perhaps the difficulty of getting Wikipedia to change DAB page guidelines could be finessed, could be avoided, by framing a new proposal as changing just SIA guidelines. Currently it is clear as mud about what an SIA is, why it should be defined at all, as not different than a standalone list. It would be true to the history as I understand it, and it could work, perhaps, to define SIA as alternatives to DAB pages which do not require all DAB rules to be met. (Like SHIPS dab pages are simply an exception to DAB page rules, allowing footnotes, extra description, etc., and for them to serve fully the needed navigation function, i.e. without having an almost- or completely- overlapping DAB page, too.) So it is just a modification to SIA rules.
    • In revised SIA guidelines, drop the current SIA requirement that if there is one book or play named Tall Mountain or Black Lake, it can just be included in the SIA, at the beginning or at the end of all the mountain items or lake items. I personally don't see any reason why we have to define SIAs to be "pure" according to some arbitrary definition. So let the SIA step up to fully serve navigational purposes, and drop the extra dabs. I suspect that the SIA requirement was put in, in the past, as some part of letting a few editors feel more comfortable with the big escape of all the SHIPS dab pages, i.e. as a way for these editors to feel the exception was being limited.
    • So an SIA is then is to be understood as primarly a navigation page (allowing for elimination of a DAB page on the topic), that is how it is different from regular standalone lists. And in the new SIA guidelines, restrict SIA contents to be limited, objective-type information that assists in navigation. So allowing coordinates and heights/elevations of mountains (which should be available for every mountain item).
    • But not allowing for custom text, random factoids that might be suitable for a proper standalone list item, information that tends not to be available in comparable terms for all the items. So this definition would not allow the current version of the list-article of lakes named McArthur. (Rant: Trying to be polite, IMHO its contents are shite. It is grossly offensive for that to exist in Wikipedia, I guess because it has zero standard for item inclusion and zero standard for content-about-item inclusion. All lakes have a temperature on some date as measured by some person, and a salinity and other stuff, and those are non-defining, trivial, non-encyclopedic facts. It is not newsworthy or significant to report on that for just one of the lakes in a list. It is obvious padding, as a disruptive, obstructive, anti-authority or whatever pattern of behavior, to put in random shite like that, just because it is the only random shite that can be found in any source, given that no source is available that discusses the item substantially. Off rant.) I am skeptical about the relatively long-existing mountains SIA pages, which seem to be objective info drawn by a bot or by a bot-like human out of a database, with comparable info for each (so potentially useful in navigation) but I am not outright offended and vomiting about them.
    • About the Dodge Charger and U.S. Navy ships named Enterprise, those are very different than mountains or lakes SIA pages, because there is one corporate or government entity attaching the names, and only one model is being produced or sailing at a time, and there is a predecessor-successor relationship chain among them all. Each new Enterprise ship is more modern in some new way, etc., and is named for the previous one or for the previous collection. Lakes named McCarthur have no relationship at all among them.
    • Your idea that lists (including SIAs) should be set up in a way that they can grow into more developed nice things like the Chargers and Enterprise lists, well that is a nice thought. But the SHIPS SIAs were planned to be just for navigation / differentiation purposes, not to include extra stuff, all of the extra stuff going into the individual SHIP articles that WikiProject SHIPS editors were bent on producing. I think it may be okay to have defined sets of things presented with minimal, objective info to serve navigational purposes, and not allowed to grow organically. (It is the organic growth that is most shitty about the McArthur list, in fact, IMHO.)
    • About lists of places, maybe one test could be: is it plausible that anyone would want to visit all of the members? No way about the scattered, unrelated lakes named X. Yes about all the places listed as California State Landmarks, there is a guy who visited them all, and continued to visit new ones to keep his record current. About a list of Charger versions, the comparable thing is yes some rich dude would be thrilled to collect one of each, or to visit and be photographed with one of each. --Doncram (talk) 06:29, 7 September 2019 (UTC)

Doncram, OMG, I advised you stop the bludgeoning and here you are, bludgeoning your favorite hobby horse. I again advise you to avoid the type of compulsive behavior that often leads to topic bans. Please be careful. Cullen³²⁸ Let's discuss it 06:36, 7 September 2019 (UTC)

Thanks, Cullen, for watching my talk page for potential problems. It's ok, I don't feel WP:Bludgeoned. Doncram and I have collaborated on the past (e.g., he helped make List of peaks named Signal much better). Doncram currently sounds very upset about List of lakes named McArthur: I suspect that we need to take some time to think about and discuss SIAs and not do anything intemperate. —hike395 (talk) 11:53, 7 September 2019 (UTC)

(Re-indenting, to continue)

@Doncram: Remember this and this discussion from 2010? If we push SIAs back toward dabs, then editors will really be confused about which format to use. In effect, you'll have two competing guidelines for the same type of article. That's why we pushed SIAs away from dabs in those discussions (and in the guideline). If you wanted to make the changes you desire, I fear you'll need to change the dab guidelines directly :-( —hike395 (talk) 11:53, 7 September 2019 (UTC)

Right, thanks for those links to good discussions in 2010, where puzzlement about SIAs was not resolved (and where there were various participants who could/should be linked in any RFC discussion). I am interested in getting towards some better resolution. The ideas that a SIA should contain simple info only and serve a navigational purpose were there in those discussions. Funny, the second one is concluded by your comment including "I added a clarification to WP:SIA that stresses that SIAs are list articles and all list article criteria and styles should applied to SIAs." Yet about list of lakes named McArthur, you are not conceding that list article criteria are required to be met. I have taken inconsistent positions across the years, too; I used to be more accepting of just any collection of things of the same name. --Doncram (talk) 00:05, 8 September 2019 (UTC)

@Doncram: I think characterizing my position as "you are not conceding that list article criteria are required to be met" is incorrect. I spent a long time puzzling over the WP:SAL+WP:SALAT+WP:GNG+WP:LISTN+WP:LISTPURP+WP:CSC tangle. Notability and acceptable topics for lists has gotten less clear since this RfC in Aug-Oct 2010. I attempted to objectively apply this messy tangle to the AfD. Just because I'm not agreeing with you doesn't mean that I'm not applying established list criteria. —hike395 (talk) 00:21, 8 September 2019 (UTC)

Okay, i'm sorry, i was certainly being glib, and knew that as i wrote it. I didn't even really try to review what you wrote in the AFD to see if that characterization is fair, and you are surely correct that it is not fair. So I apologize for that.

I am not sure I can currently agree to what combination of characteristics for a SIA are acceptable, or that it is a tradeoff and an art, like your comment suggests, it sounds like you are considering tradeoffs. For the McArthur lakes example, it is so off the scale in my view in both its definition and in triviality of purported content which should not be in the encyclopedia at all, that it does not work for me to consider what would be okay there. It is just bad all over, and does blatantly fail to comply with requirements, so we should be done already. Then move on to SIAs with both potentially more legitimate definition and not-so-trivial content.

Your links are interesting. I only vaguely remember being aware of that RFC in 2010, but i find it interesting that it was prompted by brouhaha at List of Masonic buildings which i was in the thick of, and that I chose not to participate in the RFC at all. Nor did you participate there, it seems. Masem seemed to do a great job shepherding the RFC and closing it. Back then, I guess it was not at all obvious to many that List of fire stations and lists of any similar kind of thing or place would be acceptable. Now, I think that if fire station is a thing, as a main article, then the list of notable examples is acceptable and can be split out from the main article if it gets long. And that it can be subdivided by significant characteristics, such as by geography/region. REGION makes sense to divide lists of PLACES always, probably. And I have run with that, creating many such lists, and I believe they are all legit. And I think I have evolved, hardening about lists that seem indiscriminate, trivial, like the "List of U.S. presidents who have eaten eggs" example considered in that RFC. I think i was clear in the McArthur lakes AFD, that I think "by name" is utterly trivial in considering lakes, and the result of dividing the hypothetical big list of lakes by name yields indiscriminate collections like presidents who have eaten eggs. Well, thank you for your further thoughts and links. --Doncram (talk) 01:16, 8 September 2019 (UTC)

@Doncram: If I can distill your thinking into a possible proposal at SIAs --- you want to restrict SIAs to articles which list items of the same type and name, where there is a reason why the items have the same name (e.g., they were named after each other, or named after a single notable person or item). List articles with the same type and name where the similarity in names is coincidental would be considered trivial and non-encyclopedic. Any SIA that does not fulfill the strict condition will be converted to obey MOS:DAB.

The advantage of this is that it is clear and hopefully objective. The disadvantage of this is that vast majority of the 80,000+ SIAs would fail this criterion, and so it could take a tremendous amount of work converting these back to obey MOS:DAB. I'm not convinced that this is a good idea (yet) but let me think about it.

It's interesting to browse Category:All set index articles to see what typical SIAs are like. Many of them them seem like mislabeled dabs. —hike395 (talk) 02:45, 8 September 2019 (UTC)

Later --- it actually seems that most SIAs are surname articles. I don't even know how to think about those. —hike395 (talk) 02:48, 8 September 2019 (UTC)

I'm not sure that is the proposal I would want to go with, thanks for trying to make sense out of what I've said, though.

Yeah a whole lot look like just regular dab pages, for example 1998 Emmy Awards just helps readers make their way to one of three similar awards.

The intro at the main category of SIAs page, Category:All set index articles, explains that the given name, nickname, surname ones were termed SIAs in 2017 "even though such articles resemble disambiguation pages" as a result of "the discussion that brought this about" which links to Template talk:Dmbox#Category:All disambiguation pages. Which is partly a technical-type discussion about what Dmbox does. (Some of the discussion goes off on Bkonrad's concern that unintended links to SIAs should be addressed like unintended links to DABs by the way. IMHO that is easily answered: yes, fine, get the DAB-fixing project to also work on unintended links to SIAs.)

It looks to me like surname collections, e.g. take Aaberg for one, are not valid as disambiguation pages (because the people have different first names, and it is unlikely that readers would think "Aaberg" alone means one specific person), and would not be valid as standalone lists (because there probably(?) or perhaps(?) are not sources discussing the set of people having that name). It seems like editors did decide that these are all acceptable for Wikipedia though. Maybe it relates to fact that we are all probably interested, attuned to info about persons who share our own individual surname (if it is not super-common) or who share the same first-name+last-name type combo, etc. And maybe some in the group are related to each other ("and even to me!") literally, i.e. they are relatives, perhaps literally named after some of the earlier ones. And likely many came from the same country, say. The name suggests/tells us something about the people. So for every name, there is at least some set of persons interested in that as a topic. (Note, this is different than lakes, where same-named lakes are not persons and are not interested in others in the set. And as far as I can tell, it seems same-named lakes are rarely related even by having the same eponym.) So Wikipedia is making a big exception for these sets. That is what a SIA is, I am thinking, a license for a list/collection to exist without necessarily abiding by usual rules for a disambiguation page or for a list-article. Like for the long-standing treatment of high schools, we won't bother to test notability for each one of these, we just assume they are okay, we just allow them. But not all rules go out the window; SIAs have to be modest it seems.

This also happened for ships and mountains apparently. Note the main SIA category page mentions just {{SIA}}, {{mountainindex}} and {{shipindex}} as devices which, pre-2017, put things into SIA area. The SIA designation is a license allowing these not to comply with disambiguation and/or list-article rules.

But this did not happen for lakes or many other types of places. The ships and mountains licenses are political result of there being solid constituencies, i.e. WikiProject Ships and WikiProject Mountains, where members wanted to do what they wanted to do. And/or maybe same-named ships and same-named mountains are in fact more likely to be legitimate collections, i.e. for which there exist sources discussing them as a group. Surely so for same-named U.S. Navy ships, where there is a real chain relationship. Maybe mountains are fundamentally more salient, i.e. they stand out, unlike anything else, so it is more okay to assume that peaks named Kennedy is a grouping of interest. Maybe collections of same-named mountains are more likely to share eponyms than collections of lakes, i think that is possible. And we are willing to suspend some of the rules of no redlinks, no footnotes, no mention of sources, no discussion that apply to dab pages, as long as that is not pushed too far.

By the way, in the Dmbox discussion section just after that, at Template talk:Dmbox#Set index image, in 2009, User:Ezhiki is interacting with JHunterJ (and m Bkonrad?), making the argument similar to what i was saying recently (that including non-notable mountains assists in navigation), that including redlinks in a disambiguation page would assist readers in navigation, i.e. in finding out more efficiently that the item they are looking for does not have a Wikipedia article. And they say "I personally think that sets are a dumb, confusing, and redundant concept, as they add nothing to what a slightly relaxed set of disambig rules wouldn't be able to handle." And also mentions allowing, for geo-places, the {{coord}} info. And that "I am yet to meet an editor who is not particularly involved with disambigs and who could tell the difference between the concepts of a dab and a set." (I agree, I think only the small set of dab/sia interested editors think they know the difference, though they cannot explain it.)

An SIA is not "any collection of like things" where "like" might be "same-named", which is all the dab/sia editors are willing to state. An SIA is better understood as a license, as a permission granted. Permission has been granted for very few kinds of sets. Maybe with condition that an SIA list-article has to be modest, i.e. just a table of mountain names, locations, and heights, without excessiveness, without pretentions that go too far, that say any vague content is allowed. And not allowing a new list-article of persons named Adam Ahmed (the one up at AFD now), or at least not allowing a new collection of Adam Ahmeds who do not have individual articles already. If there were a couple already, then an Ahmed surname page would allow mention of them, but would not allow a lot of bio detail or multiple sources for any single one of them.

Wikipedia editors apparently agreed to allow collections of same-named ships and mountains and surnames to have the license. I am somewhat dubious still about mountains but maybe they are different as being salient maybe the sets of mountains actually done early on were relatively coherent, relatively close to being acceptable as list-articles on their own. I am outright opposed about same-named lakes because how horribly incoherent the set of McArthur ones and some other sets seem to be, in practice, and I believe Wikipedia editors have not given (there are only six of these, created before 2010) and should not give permission there. --Doncram (talk) 04:10, 8 September 2019 (UTC)

Research advice

Hi there, I am a sixth form student currently writing a dissertation titled ‘the maximum altitude humans can theoretically inhabit without pressurisation methods’ and had a question to ask you for my research; you made major contributions to the article ‘Effects of high altitude on humans’ and clearly have a deep understanding of high altitude physiology.

> which medical/physiological conditions do you think are most important for me to research In order to obtain an estimate for the maximum height inhabitable by humans?

Thanks for your time — Preceding unsigned comment added by Bijmo (talk • contribs) 21:49, 3 November 2019 (UTC)

Effects of high altitude on humans

Hello,

I was the IP editor that moved the information back to death zone which I restored, as I believe it is notable for a standalone article. Valoem ^{talk contrib} 04:04, 3 December 2019 (UTC)

WGS84 to OSGB36 UK grid coords in GeoHack

Hi! I see you recently did a nice job of setting up a Lua module to do OSGB36 National Grid coordinate -> WGS84 conversions.

Is there any chance you could have a look at how GeoHack is doing the reverse transformation, ie from WGS84 to National Grid coordinates? I believe the present code is currently missing the Helmert transformation in the WGS84 -> OSGB36 stage; as a result the National Grid references it is returning are not right.

So for example, the correct NG ref for the Greenwich meridian should be TQ 38883 77336 [3]. But GeoHack is currently returning TQ 38770 77375 [4] which is off by about 120 metres, leading eg to incorrect links to services like Streetmap.co.uk (arrow ought to be pointing to the middle of the long thin blue rectangle), as well as bad data being given to users.

I believe GeoHack is written in PHP, and there are PHP libraries around that get this conversion right, eg [5]. Is there any chance that this would be something you could take a look at? Or that you might know somebody that could?

Thanks, Jheald (talk) 13:59, 2 September 2019 (UTC)

@Jheald: I'm afraid I'm not an expert at PHP, nor do I fully understand what's going on at geohack. Here's what I've found: it looks like the source to geohack is at bitbucket. The transversemercator PHP code looks like it's already been modified by Roger Haworth. Roger knows PHP pretty well --- maybe he can update the transversemercator code to use the correct Helmert transformation, and then generate a Pull Request? I'm not 100% sure how the code migrates from bitbucket.org to geohack itself: there may be some sort of continuous deployment? The repository is owned by Magnus Manske --- he might be able to tell us how this could get updated. —hike395 (talk) 14:45, 2 September 2019 (UTC)

@RHaworth and Jheald: Bringing this back up: Roger, would you be interested in trying to fix the geohack PHP code? As Jheald says. some of our map sources are broken. —hike395 (talk) 13:00, 5 October 2019 (UTC)

Later --- A while back, Roger shared a version of Egil Kvaleberg's OS library with me. On my Linux box, I cloned geohack, patched in Roger's version of transversemercator.php and helm_gb.php, then modified mapsources.php to call the right function:

	/*  UK National Grid, see http://www.gps.gov.uk/guide7.asp
		 *  central meridian 47N 2W, offset 100km N 400km W */
		$osgb36 = new transversemercator();
		$osgb36ref = $osgb36->WGS2OSGB( $this->p->latdeg, $this->p->londeg );

and now the OS maps work correctly! I could generate a pull request, but if Magnus Manske asks me questions about the code, I wouldn't be able to answer. Roger: would you be willing to submit a pull request to bitbucket? —hike395 (talk) 13:53, 5 October 2019 (UTC)

Even later --- I've poked around with diff'ing Roger's code and the current geohack code, and the only real difference is that Roger's code added the Helmert transformation. So I think I can explain what is going on to Magnus, if absolutely required. But I still feel weird about checking Roger's code into geohack, so I'm still hoping that Roger will generate a pull request himself. —hike395 (talk) 14:20, 5 October 2019 (UTC)

@Jheald: Created a Bitbucket issue to alert the developers, attached code fix. — hike395 (talk) 18:32, 23 November 2019 (UTC)

@Jheald: FWIW, I never heard back from any developer, despite pinging in multiple places. It's a pity -- I have a fix all ready to go. — hike395 (talk) 12:09, 13 January 2020 (UTC)

ancillary information

More appropriate in that section, and a full link that states one is accessing a list. That is how I see it, okay with you? ~ cygnis insignis 15:53, 13 January 2020 (UTC)

@Cygnis insignis: Sure. — hike395 (talk) 19:10, 19 January 2020 (UTC)

Zone of Death (geography)

Hi, I disagree with your change moving the Zone of Death from geography to legal, as it's clearly a specific geographic area. I would revert the move per WP:BRD but I can't seem to do so. SportingFlyer T·C 23:52, 2 February 2020 (UTC)

@SportingFlyer: I'm sorry -- that's my fault: I edited Zone of Death (geography) to just point to the dab page Zone of Death, because Death zone could also be interpreted as being geographical. Because I edited it, the move can't be undone without admin assistance. That wasn't my intent, though.

The right answer is to use the standard WP:RM framework to propose moving back to Zone of Death (geography). We can discuss the merits of the disambiguators at Talk:Zone of Death (legal), if you'd like to start the WP:RM process? — hike395 (talk) 05:21, 3 February 2020 (UTC)

That sounds good, cheers! SportingFlyer T·C 05:42, 3 February 2020 (UTC)

WikiProject Backpacking

Cullen328 recommended I offer you an invite to the project. Salute! —philoserf (talk) 03:14, 10 March 2020 (UTC)

Mazazatl orogeny

I'd appreciate you taking a look at this. The article as I found it two days ago was an absolute mess. I'm still not entirely happy with the section discussing the possible correspondence with the Picuris orogeny; this was basically where I shoved the original article and tried to make sense of it. I'm inclined to change the quality to Start but not C until that section is cleaned up a bit more but would like your opinion. --Kent G. Budge (talk) 23:49, 19 April 2020 (UTC)

@Kent G. Budge: I think this is C-class also. I'm not super familiar with the Proterozoic assembly of Laurentia, since I'm not a geologist. I'm definitely learning by reading these articles. How much is known about these orogenies? You can see the rating definitions at WP:ASSESS: this is definitely C-class (because it seems well-cited, perhaps with some not-too-serious balance issues). Is this a reasonably complete representation of what's known about the Mazaztal orogeny? I don't have the expertise to assess C-class vs B-class for this topic. — hike395 (talk) 06:29, 20 April 2020 (UTC)