User talk:Hike395

Token of gratitude

		The Volcanoes Barnstar
		Hike395 - thanks for your gracious help with getting Three Sisters (Oregon) to featured article status. Your extensive content addition, painstaking image searches, and research was invaluable to reaching this milestone, and I look forward to working together in the future! ceranthor 15:54, 8 December 2017 (UTC)

Thanks! It was fun --- the best part of editing WP is when several editors cooperate to make a high-quality article. —hike395 (talk) 22:09, 9 December 2017 (UTC)

Precious

hiking mountains

Thank you for quality articles around the Geology of the Rocky Mountains and Lake Sammamish State Park, for improving and fixing templates, for welcoming and advising users, for your contributions from 2003 saying "the best part of editing WP is when several editors cooperate to make a high-quality article", such as The Three Sisters, - you are an awesome Wikipedian!

--Gerda Arendt (talk) 08:39, 6 January 2018 (UTC)

Thank you, Gerda! —hike395 (talk) 14:07, 6 January 2018 (UTC)

Two years ago, you were recipient no. 1818 of Precious, a prize of QAI! --Gerda Arendt (talk) 07:29, 6 January 2020 (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,

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)

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)

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)

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)

Infobox mountain

Hey there. Btw you don't have to ping me for each reply. I'm watching the page, and will respond whenever I'm free or not at work. Cheers, Rehman 05:24, 5 May 2020 (UTC)

OK, sorry. the page is kind of messy, so I want to make sure you see my questions/comments. I'll stop pinging you. — hike395 (talk) 05:27, 5 May 2020 (UTC)

Good day, Hike. Another person (Mikeblas) has responded. Before I do anything, I'm commenting here purely to not upset you further. Please take all the time you need to reply to this. From Mikeblas's response, they prefer the right-hand look (collapsed view), while also "making the parameter list a little less unruly" (removing the parameter series), but they have not weighted on the reasons behind these changes. We can go three ways:

1. Of the large swaths of text by MSGJ, you, and me, Mikeblas only posted two short comments with vague standings and no comment on the technical aspects (no offence to Mikeblas, if they are reading this). Hence we can take his comments as neutral, and move on?
2. From what I understand, Mikeblas wanted a collapsed look, "without unruly parameter lists". That still means a single parameter (although how the content is output is debatable). MSGJ and I are fine with csv, you and Mikeblas wants a collapsible list. So perhaps we (you?) can close the existing thread as consensus reached for a single parameter, and start a subthread on how the output should be handled?
3. If you disagree with both above, we can start a 3O or RFC or something similar, for that section. If we do that, I'd like to suggest you collapse the entire Misc section so that it does not look bad (you may want to re-read that to know what I mean). I'm also completely fine if you don't want to collapse that.

Take your time to respond. I will not comment on the parameter series thread before you comment there or here. Cheers, Rehman 03:06, 10 May 2020 (UTC)

@Rehman: Instead of the two paths you outlined above, I'd like to spend a time to find a single compromise that somewhat satisfies all four of the involved editors. How about this: for the parameters that take lists, we have only one parameter (e.g., |city=). For each of those parameters, we ask editors to enter the list with a delimiter. Following {{location map}}, I would suggest using ## as the delimiter. For example, for Andes, the country parameter would look like

country=[[Argentina]]##[[Bolivia]]##[[Chile]]##[[Colombia]]##[[Ecuador]]##[[Peru]]##[[Venezuela]]

I can write some very simple Lua to parse this and produce a CSV output, where each list element has a no-wrap around it.

Some things to note about this proposal:

• I've suggested ## as a delimiter, because a single # occurs in section links. I'm open to other delimiters, too.
• It's not that I truly want a large number of parameters. I just want to keep the automatic list formatting in the infobox.
• This idea was inspired by the back-and-forth between myself and Martin --- I find it helpful to discuss ideas for a little while: sometimes the final idea doesn't occur to me right away. If you have new alternatives on any of the Infobox mountain proposals, please feel free to propose them. The search for consensus often runs on new ideas.
• I found your argument that {{Collapsible list}} doesn't collapse on mobile to be persuasive. So I'm content with displaying a CSV. This may not be to Mikeblas' taste, however. I can investigate how to make a collapsed list on mobile.
• Again, after talking to Martin, I'd like to automatically put a nowrap in for each list element. I think most editors don't know to use {{nowrap}}.
• We can discuss whether to use an "and" or whether to use an Oxford comma. Those are not as important to me. The use of "and" and no Oxford comma are standard in the mw.text.listToText Lua function, but that's a relatively weak argument.

What do you think? — hike395 (talk) 15:29, 11 May 2020 (UTC)

My main concern is to not have repetitive endless parameters, that approach is outdated and messy, as I explained before. My second concern, which MSGJ also echoed, is to not force formatting on articles, and let the browser decide how entered values are displayed - that means no hardcoding additional functions. Of course, we can state to always use csv, or always use br tags, or whatever as a guide or rule, but that is as far as it can go IMHO. Just imagine the complexity and annoyance if every parameter of every infobox starts to implement additional code to force and mould output, instead of letting the editor decide? As MSGJ stated, this is a trivial thing, but if you wish, we can of course request for more experienced opinions. But after working with a lot of templates, I'm certain the outcome would not be any different.

And if you're worried that after combining the parameters, some articles will have csv, some will have br, and what not, we can always use this opportunity to tell the bot to update all the usages to one format. That means we could easily tell the bot to update as "A, B, C, D, and E" if you wish. I think if that is done in one go for all articles, it creates a much better chance for editors to identify the standard format, and simply copy it. Rehman 03:27, 12 May 2020 (UTC)

@Rehman: Sorry: I think my proposal wasn't clear. I agree that always forcing formatting is not a good idea: I had intended this to be purely opt-in. Let me clarify:

• Fields that take lists should have a single argument (e.g., |country=).
• If there is no ## in the passed parameter (e.g., state=New Hampshire, New York) then the parameter is rendered normally just as any other parameter. Editors should be able to always override or ignore any pre-defined formatting (e.g., if it's broken or inappropriate)
• If there is at least one ## in the passed parameter (e.g., state=New Hampshire##New York) then the infobox splits the parameter by "##" and uses whatever list rendering is the consensus of the Wikiproject. Thus, editors can opt-in to be conformant, but it's not required. It's just a easy-to-use convenience so that editors don't have to understand how to implement the current consensus.
• We take articles that use existing numbered arguments (e.g., |city1=, |city2=) and use a bot to convert them into using single-argument ##-delimited lists. These hundreds of articles will serve as examples of how to use ##-delimited lists (per your point above of teaching editors to use the standard format)
• We update the documentation to explain what ## does.
• We can discuss how we want the ##-delimited lists to render -- so far, seems to be a split opinion between CSV and the existing rendering. I'm suggesting item-no-wrapped CSV as a compromise between the two. But deciding on optional ##-delimited lists is a separate discussion from how we render the list (as you've pointed out, above).
• If, in the future, the consensus for how to render lists in this infobox changes, we can update the code instead of asking a bot. That will be a lot easier.

What do you think? Would this be satisfactory to you? — hike395 (talk) 16:19, 13 May 2020 (UTC)

I appreciate you for taking the time to explain, but I genuinely don't see what this is supposed to solve, other than making things more complicated. Everyone (and I mean in the world, not just Wikipedia) is more familiar with either typing sentence-case (a, b, and c) or using html br-tags, that is de-facto. Then comes wiki-world formatting, ubl, etc. What you are suggesting is something uncommon (and unheard of in such scenarios, tbh), and would definitely raise red flags if we get the bot to do that.

If you prefer sentence case, we can most definitely get the bot to do that, and people can mirror that in new articles if you want to maintain a standard (or we could simply let editors choose their style).

Let me know your thoughts. Or if you don't believe me, I'm fine with getting more opinions in that discussion. Rehman 17:04, 13 May 2020 (UTC)

@Rehman: Thanks. I agree that ##-delimited lists are quite strange, and that part of my proposal didn't make me very happy. But I'm trying to come to a compromise between your desire for a single argument and the information I want to keep in WP.

Here's the problem that I'm trying to solve. Right now, the individual list elements (e.g., |country1=, |country2=) are kept in a text format that is parsed by software. I really want to keep those individual list elements read by software, and not "flatten" them into an unparsable format. If we run a bot and convert each list into a text CSV format, we're going to lose the capability of going back and parsing it later. I think there are a number of scenarios where parsing is important

• If we want to go back later and change the default format (as described, above), we should keep the list readable by software.
• If we want to load the list into wikidata later, we're going to want something a bot can unambiguously read. If we flatten now, any such future wikidata loading will be pretty difficult.
• Other downstream users (e.g, researchers or companies like Metaweb) parse infoboxes to extract data to fill in their own databases. Again, doing that parsing is going to be difficult.

Here's another proposal that I hope you find acceptable:

• We create a template named {{Compact list}} (or something similar).
  • {{Compact list|A|B|C|D}} takes the list "A, B, C, D" and formats it according to consensus.
  • It should take an unlimited number of arguments
  • The use of {{Compact list}} is encouraged, but not required
• All of the parameters ending in numbers in the Mountain infobox are converted to the corresponding non-numeric single parameter
• When the bot does the conversion, it converts the multiple parameters into a single call to {{Compact list}}, keeping the list parsable by software
• Update the documentation to suggest the use of {{Compact list}}

This will keep the list in a software-readable format and preserve the list as data. Nothing weird or special: just a template call. I think this is analogous to the proposal you were making for converting parameters such as |elevation_ft=XXX into |elevation={{convert|XXX|ft}}.

What do you think? — hike395 (talk) 05:23, 14 May 2020 (UTC)

Re "number of scenarios where parsing is important"; so to make this clear, you are willing to compromise on simpler user experience for Wikipedians, because more advanced external tech users would find it difficult to pull data from Wikipedia?

1. Simple csv is still readable by software. There are bots that do maintenance on such parameters as we speak, based on linked phrases, commas, and various other factors. If consensus is reached to change csv to anything else, it is still very much possible. Bots don't have to depend on separate parameters alone to get such work done.
2. Again, for exporting data to Wikidata, bots can still read without any issue. The values that were pulled earlier were obviously not from infoboxes that used a series of a single parameter. The issue is getting consensus to mass export, which I don't think will happen with a proper plan.
3. Do you really think research companies, who are obviously so much more advanced when it comes to methods of collecting data, depend on internal Wikipedia template parameters? And regardless, if they want to get data from Wikipedia, the way they get that is their problem. We should not give up our UX for that.

I'm no longer in favour of my original UBL proposal, but for discussions-sake, you opposed using an existing known template such as {{Unbulleted list}}, but you are willing create a new template for a slightly different use? The reason such a template doesn't already exist is because of what I explained earlier.

On a separate note, I'm also not happy that you are updating other infoboxes with newly created modules in parallel to this discussion. I will comment on those separately in the right place, when I get the time. Rehman 06:04, 14 May 2020 (UTC)

Could you show me where the natural-language CSV parsing code is in Wikipedia? I'd really like to learn about it. "True" CSV (e.g., in a CSV file) looks strange to humans, in that any string with a comma in it need to be double-quoted. Any double-quote needs to be repeated. So it won't look nice in an infobox. See Comma-separated values for the complexity of true CSV. This can happen with common entities like Telluride, Colorado (even worse without wlink). People usually fall back to semi-colons in English. Should we suggest the use of semi-colons? I suppose that's more parsable than CSV, although people might think it looks odd

I think you are mischaracterizing my proposal. I'm trying to make the UX better by decoupling the specification of the input as a list from the formatting of the output. That allows us to have whatever formatting we like (now and in the future) while keeping the input simple. For example, we can add nowrap for editors automatically (which is still on the table, I think).

Can you explain what makes using {{Convert}} ok while using {{Compact list}} objectionable? I don't understand this --- I'm probably missing something.

I opposed the original UBL proposal because of the formatting output. I find templates-within-templates to be a bit ugly. But, I'm willing to use templates-within-templates to come to a compromise. You previously said I was unwilling to compromise, and I'm really trying to find something that makes us both happy (and MSGJ and Mikeblas, too). I'd like to keep the list software-parsable. I'm happy to have a single parameter (which was your top concern), if we can somehow keep the list software-parsable. Let me turn it around, can you think of a creative way to have a single parameter while having some sort of separation between the concept of the list and the formatting? If we could agree, that would instantly end the discussion.

When you say "the reason such a template doesn't already exist is because of what I explained earlier", I'm afraid I don't understand. I went back and looked at your comments in this section and couldn't figure out which one you meant.

Are you talking about the use of Module:Compact list? That was a pure cleanup of the implementation of the infoboxes. That implementation did not change the appearance of any article or the meaning of any existing infobox parameter. Those infoboxes previously used {{Collapsible list}} and {{enum}}. Those have been in the infoboxes for a long time --- check the diffs. My plan was to propagate whatever formatting decision we reached here to those other infoboxes, unless other editors objected.

Or are you saying that I'm not allowed to edit any infobox while you work on Infobox mountain? Surely you're not saying that?

You said (previously) that you're not angry and that you want to work with me. But it seems like I can't make you happy with any suggestion for compromise, and you seem to unhappy (even angry) over my infobox maintenance. I'm sorry that I've made you unhappy. We're close to agreement, I think. Is there any compromise that we can reach? — hike395 (talk) 07:18, 14 May 2020 (UTC)

The user experience will certainly not be better if we are going to force editors to use a particular format, or mould the input to something else through a series of additional templates or modules. Following the 3 points you mentioned for pursuing this, I've already explained that they are not valid. So why are we continuing to discuss beyond that? If you're disagreeing with that (i.e. you don't believe me, which is fine), then I'm afraid the only other way is to get more experienced people who work in infoboxes to comment on that aspect, and close this case once and for all. I'm absolutely fine with you editing whatever; just not a fan of customisations and things that are non-standard without a very solid reasoning. Rehman 07:59, 14 May 2020 (UTC)

First, I want to say that I do believe you. And I appreciate all of the work you're putting into the wikidata fallback.

I suspect we're both getting close to burning out. In order to prevent that, I will concede the point --- let's flatten the numeric arguments down to single arguments, not have a formatting template, and just have a bot write some consensus format.

I have one request (with two parts). Before you flatten all of those parameters, would you mind if I imported them to Wikidata? I just found HarvestTemplates over at WMFlabs. That tool can import data based on arguments like |city2=. I can wait to do run the import until after you've defined all of the new properties for the infobox, so I don't make a mess.

The second part of the request is: would it be ok with you if I added a temporary tracking category for articles with the numeric arguments that you want to get rid of? That would make HarvestTemplates much faster to run (since it would not have to search 25,000 articles, but just the ones in the tracking category). I can toss the tracking category after Wikidata import.

Thanks in advance for letting me scrape the data. — hike395 (talk) 09:26, 14 May 2020 (UTC)

Back-and-forth discussion

Yes, I agree that the back-and-forth discussion we had two days ago was not conducive to harmonious editing, and worse, has triggered WP:EWWW. If you agree, I would move that discussion into this sub-section on my Talk page (and collapse it, if you agree). I would suggest eliding the entire "Misc topics" section and moving it here, except for Mikeblas' comment, which we can simply append to the end of the discussion on the previous sub-section (with a notice that says something like "long digression moved to User talk"). Is that acceptable to you? — hike395 (talk) 15:29, 11 May 2020 (UTC)

I agree with collapsing, but not moving it elsewhere. This is purely on grounds of transparency/audit, since our edits are made to that page, and the only other place it could go is it's archive. I'm also fine with leaving Mikeblas' comment below the collapsed section. Rehman 03:27, 12 May 2020 (UTC)

OK, will do. — hike395 (talk) 15:47, 13 May 2020 (UTC)