Jump to content

User talk:Hike395/Archive 22

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< User talk:Hike395

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 00:41, 12 August 2022 (Archiving 2 discussion(s) from User talk:Hike395) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archive 15←Archive 20Archive 21Archive 22Archive 23

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)
Thank you, Hike. I appreciate this. I'm fine with both copying to Wikidata and the temporary trackers. But I have a small clarification. On the Wikidata topic, you plan to first enable wd article-by-article, before Wikidata is fully enabled, correct? So if you move these data now, won't you double your work, in the sense that you will need to verify the same once more? I'm not suggesting anything, just figuring out the path ahead. Rehman 10:29, 14 May 2020 (UTC)
I thought the plan was to only check those articles that had fallback? That is, when the infobox had an empty parameter, but there was data in Wikidata. I thought you were proposing that the bot convert the numeric parameters to a single CSV parameter? That means that there wouldn't be any fallback.
To make sure we're agreeing, let's be very concrete. Let's say there's a page that currently has |country1=Argentina and |country2=Colombia. I would first copy |country1= and |country2= over to Wikidata. You'd then run a bot that removes |country1= and |country2= and writes |country=Argentina, Colombia to the infobox. At that point, there would be no fallback, so no checking required, right?
Or were you thinking that the bot wouldn't write |country=Argentina, Columbia and leave it blank instead? — hike395 (talk) 11:41, 14 May 2020 (UTC)
Ah right, okay. I misread the above as you wanting to move the content wd, instead of copying. In that case yes, same plan. Rehman 12:02, 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)

Numbers Fire

Are you anywhere near this fire? I got a shot of the smoke from afar and started an article, but it could sure use a better photo. Dicklyon (talk) 03:08, 9 July 2020 (UTC)

Not very close, sorry. — hike395 (talk) 05:52, 10 July 2020 (UTC)

FS1037C text size

You restored text to normal size because, "almost all PD-US templates are normal size." I was just trying to make things consistent. Should I modify others such as {{FOLDOC}} to be normal size? ~Kvng (talk) 14:10, 21 August 2020 (UTC)

@Kvng: I think that would be good. — hike395 (talk) 20:09, 21 August 2020 (UTC)

Accidental ping

I accidentally pinged you when reverting vandalism. Apologies. Dudley Miles (talk) 10:08, 8 October 2020 (UTC)

You have a very nice user gallery, I would like to emulate. You reverted an edit I made, thank you, my error, and I would like to understand properties of the gallery tag. Could you send me some tutorials? Paptilian, PpT'lln ,  ( P. sig'd   ).. 19:15, 14 December 2020 (UTC)

@Paptilian: Thank you! You can find documentation of galleries in multiple places:
Hope this helps! Let me know if you need more help. — hike395 (talk) 05:37, 15 December 2020 (UTC)
Super, thanks. Paptilian, PpT'lln ,  ( P. sig'd   ).. 07:46, 15 December 2020 (UTC)

FAR notice

I have nominated Mount St. Helens for a featured article review here. Please join the discussion on whether this article meets featured article criteria. Articles are typically reviewed for two weeks. If substantial concerns are not addressed during the review period, the article will be moved to the Featured Article Removal Candidates list for a further period, where editors may declare "Keep" or "Delist" the article's featured status. The instructions for the review process are here. Hog Farm Talk 04:06, 13 March 2021 (UTC)

Changes to Speciesbox/sandbox

Moved message to Template talk:Speciesbox#Simplification of template. Peter coxhead (talk) 18:33, 27 May 2021 (UTC)

I would like to stress that in many cases (even most) using auto-pass-through is good, and it was a plausible idea to apply it to {{Speciesbox}}. It's simply that {{Speciesbox}} can't be considered in isolation from {{Automatic taxobox}}, {{Ichnobox}}, {{Virusbox}}, {{Infraspeciesbox}}, etc., all of which use {{Taxobox/core}} in different ways. Peter coxhead (talk) 16:48, 28 May 2021 (UTC)
@Peter coxhead: I agree --- I've recently wrapped {{cite web}} into a bunch of specialized templates (e.g., {{cite gvp}}). That's a case where all of the parameters of {{cite web}} are meaningful for each of the specialized templates. That doesn't seem to be the case with derivatives of {{Taxobox}}. I'm happy to withdraw the suggestion. I also like to defer to editors who have been maintaining the templates for a long time, because they understand the usage better than a newcomer. (That deference doesn't seem to be common in WP, so our templates may be gradually getting worse). Overall, not a problem.
I was just sitting down to add Module:Check for unknown parameters to {{Speciesbox/sandbox}} per Plantdrew, since that may be helpful for them. As usual, I won't promote to the main template without discussing first. — hike395 (talk) 16:55, 28 May 2021 (UTC)
Yes, that needed doing some time ago; I think I intended to, but forgot. Definitely a good idea. Peter coxhead (talk) 17:19, 28 May 2021 (UTC)

Thanks for coming up with some suggestions. My initial reaction is: any of those might be good to work on ... anywhere except WP:FLC, which requires a "complete" list in some sense ... and how could we ever come up with a complete list of, say, culinary nuts? But this is really more a stopper for me personally than for nominators in general. If you want to pick any of those lists to work on, I'll pitch in and see what I can do to help. - Dank (push to talk) 13:42, 9 September 2021 (UTC)

@Dank: I nominated List of edible seeds at FLC back in 2006, and got rejected for lack of comprehensiveness. Although the list has gotten much better in the last 15 years, it seems that the de facto criteria for FLC have drifted beyond what's written in the guideline. You're right that there will never be a complete list, only a comprehensive one. Do you think List of edible seeds is close to FLC success? Waitak got List of culinary nuts promoted back in 2012. — hike395 (talk) 15:05, 9 September 2021 (UTC)
I'm not saying that I don't want to work on the list, or even that it couldn't get through FLC ... sometimes it depends on who shows up to review. But that particular list does seem to me to light on sourcing ... it probably wouldn't be my choice at FLC. And sometimes, it's important to start strong at FLC ... if you successfully make the case a few times that there's at least a rough consensus about which items should be included in that list among the relevant scientists, then people are more likely to give you the benefit of the doubt in future lists. OTOH ... I do think you're on the right track, thinking about lists that will appeal to a wide range of readers (and reviewers!) - Dank (push to talk) 16:04, 9 September 2021 (UTC)`
I'll look for better sourcing, thanks. I haven't worked on this article since 2019. — hike395 (talk) 16:24, 9 September 2021 (UTC)

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)

FAR for Yosemite

I have nominated Yosemite National Park for a featured article review here. Please join the discussion on whether this article meets featured article criteria. Articles are typically reviewed for two weeks. If substantial concerns are not addressed during the review period, the article will be moved to the Featured Article Removal Candidates list for a further period, where editors may declare "Keep" or "Delist" the article's featured status. The instructions for the review process are here. Hog Farm Talk 07:29, 14 November 2021 (UTC)

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=User_talk:Hike395/Archive_22&oldid=1103994691"