User talk:Hike395/Archive 22

Archive 15

←

Archive 20

Archive 21

Archive 22

Archive 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)

Gallery properties

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, P_p^T'lln ,  ( P. ^sig'd   ).. 19:15, 14 December 2020 (UTC)

@Paptilian: Thank you! You can find documentation of galleries in multiple places:

• For documentation for the <gallery>...</gallery> tag, see Help:Gallery tag
  • For more advanced usage, you can use {{Gallery}} here on en, or Commons:Template:Gallery
• The gallery on my user page is built with a wikitable, whose syntax is described here
  • The images on the right are packed together using {{Multiple image}}, also available at Commons:Template:Multiple image. Note that this template is very rarely used in Commons galleries --- <gallery>...</gallery> is strongly preferred.

Hope this helps! Let me know if you need more help. — hike395 (talk) 05:37, 15 December 2020 (UTC)

Super, thanks. Paptilian, P_p^T'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)

WT:PLANTS#Next Featured List project

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)

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)

Links to ongoing geocleanup

I know you already provided a few at User talk:FOARP, but I was wondering if there are any other project pages, taskforces, or recentish discussions I should take a look at. I'm probably going to try and hold myself to another weeks long wikibreak starting in the next few days here, but given my occasional random page patrol this has been on my mind for some time and might be something I look into helping out with when I get back. I don't mean to fork things but it occurred to me that FOARP is probably going to be bit distracted for a few days here while being used as a punching bag (and people wonder why no one wants to help clearing discussion backlogs), and hence it might be best to let you handle the information dump. IP still changing uncontrollably unfortunately, but I can't argue with the connection speed, and meatball:LoginsAreEvil. Regards, 188.168.28.98 (talk) 15:39, 24 November 2021 (UTC)

Thanks for offering. I think that the WP:WikiProject California/GNIS cleanup task force still needs a lot of work. Mass creation floods cause a huge amount of work. I'm thinking on going on a wikibreak through the end of the year, myself. — hike395 (talk) 00:08, 25 November 2021 (UTC)

Bookmarked, thanks. 62.78.82.94 (talk) 20:00, 25 November 2021 (UTC)

FAR for Geology of the Lassen volcanic area

I have nominated Geology of the Lassen volcanic area 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. Bumbubookworm (talk) 20:18, 1 January 2022 (UTC)

Module:Portal-inline - Sandbox

Hi Hike395, with this edit did you mean to point at the sandbox version? As I noticed due to errors in main-space that popped up in CAT:MISSFILE that I tracked to this edit meaning for instance {{|trPortal-inline|hyderabad}} now shows the image from Module:Portal/images/h/sandbox which is deleted. Cheers KylieTastic (talk) 12:42, 3 January 2022 (UTC)

• I have fixed the image in Module:Portal/images/h/sandbox for now to stop people fixing the errors by just removing the template. Cheers KylieTastic (talk) 13:32, 3 January 2022 (UTC)

@KylieTastic: Thanks for checking! It was, indeed, a mistake, now fixed. Sorry for the trouble. — hike395 (talk) 13:56, 3 January 2022 (UTC)

No trouble, these things happen - Cheers KylieTastic (talk) 14:00, 3 January 2022 (UTC)

Category:Pages with empty sister project links

Hello, Hike395,

This category showed up on the Empty Categories list and I was wondering what it was for and if you expect it to remain empty. Thank you. Liz ^{Read! Talk!} 01:46, 6 January 2022 (UTC)

@Liz:  Fixed --- marked as a possible empty category (it's a tracking category for Module:Sister project links and related templates). — hike395 (talk) 02:03, 6 January 2022 (UTC)

portal tracking cats

Category:Portal templates with redlinked portals has a Village Pump archive. This is the second one today. I edited the archived page for the first one (the portal was deleted since it was linked in the discussion, so my edit made it easier to follow the discussion if anyone ever looks at it). I thought it might be a quick way to deal with a one-off, but now there is another. I don't really want to be editing a lot of archives. This namespace should really be excluded from the tracking. If the WP namespace is really not excluded, I'm surprised there have been so few of these. Can you look into this? Thanks. MB 06:04, 9 January 2022 (UTC)

@MB: It's easy to exclude Wikipedia: I'll do so now. — hike395 (talk) 06:16, 9 January 2022 (UTC)

Thanks. MB 06:26, 9 January 2022 (UTC)

Module:Icon breaks one use case of Icon link

Hi, your recent change to {{Icon link}} to use Module:Icon seems to have broken one use case; specifically if the article title contains multiple italics. That is, Pokemon Red and Green displays the correct text (everything italicized except the "and") but the link includes the interior apostrophes instead of removing them. --PresN 17:05, 9 January 2022 (UTC)

@PresN: Thanks for telling me! It looks like we've found a bug in getPlain() from Module:Text. I will attempt a fix. — hike395 (talk) 18:53, 9 January 2022 (UTC)

@PresN:  Fixed (see above). It looks like no one tested Module:Text at all, so I fixed bugs there. — hike395 (talk) 19:40, 9 January 2022 (UTC)

Awesome, thank you! --PresN 00:48, 10 January 2022 (UTC)

Infobox film

Hello! Is it possible to add a parameter for voice actors?. That should primarily be used for animated features. It can be necessary with a parameter for that. Yours sincerely, Sondre --88.89.14.227 (talk) 10:58, 30 January 2022 (UTC)

@88.89.14.227: I would suggest making this request at Template talk:Infobox film, so that other editors can comment on whether it is a good idea. — hike395 (talk) 15:45, 30 January 2022 (UTC)

Himalayan summits in Indian Territory

K2, Nanga Parbat, Gasherbrum etc are lies in Indian Territory as Ladakh Uniion Territory Het666 (talk) 13:41, 29 January 2022 (UTC)

@Het666: — The K2 article already handles the dispute between India and Pakistan in an neutral way with a footnote:

K2 is located in Gilgit–Baltistan, a region, which along with Azad Kashmir, forms Pakistan administered Kashmir. The Kashmir region is currently the centre of a territorial dispute between Pakistan and India. India maintains a territorial dispute on Pakistan-administered Kashmir. Likewise, Pakistan maintains a territorial dispute on Jammu and Kashmir, the Indian-administered part of the region.

hike395 (talk) 16:30, 29 January 2022 (UTC)

It's better to mention India in italic , which will indicate K2 lies in Indian Territory but under Pakistani and Chinese administration Het666 (talk) 08:38, 30 January 2022 (UTC)

@Het666: You're welcome to bring it up at Talk:K2 to see if there is a consensus to change. This will be a sensitive topic: there have been multiple edit wars in WP since 2005 over Kashmir. I would recommend being very scrupulous about civility and neutrality. You may wish to follow those links and read them before commenting at Talk:K2. I'll also leave a note on your User Talk page linking to the expectations of behavior for editors who work on the India/Pakistan dispute. — hike395 (talk) 15:34, 30 January 2022 (UTC)

@Het666: I see that someone already alerted you to the expectations back in September, so I won't put that on your Talk page again --- you can find that in your edit history. Let me know if you need help with that. — hike395 (talk) 15:44, 30 January 2022 (UTC)

I have put my statement on Talk page of K2 so better to discuss it there Het666 (talk) 04:09, 31 January 2022 (UTC)

Template help

Hey, the redlink portals are occurring just a couple a day, so that has been going smoothly. There has also been a recent change to detect redlink hatnotes (Category:Articles with hatnote templates targeting a nonexistent page). There are about 20 like Category:Sports leagues established in 1871 that have a {{see also}} to Category:Sports leagues disestablished in 1871. This is coming from {{Sports leagues established in YYYY category header}} which just creates the hatnote for the corresponding disestablished category. Is there a way to check if the category exists here? (it doesn't for about 20 years out of 150). MB 01:15, 1 February 2022 (UTC)

@MB:  Done --- I simply replaced {{See also}} with {{See also if exists}}. — hike395 (talk) 01:33, 1 February 2022 (UTC)

Thanks. I could have done that myself, but I have never heard of that template before. MB 01:39, 1 February 2022 (UTC)

Today there are over 200 redlink portals in film cats, from {{YYYY genre films category header/core}} which add a portal for the film genre. There is no Portal:Drama, Portal:Action, or Portal:Thriller. I thought about creating redirects to Portal:Film, but these genres could be things besides films. Portal:Drama was a redirect once before and deleted for that reason. So it's probably better to do something inside the template - either no portal or portal:film, unless you have a better idea. (There are some corresponding genre portals that do exist, like Portal:Comedy which is used in Category:2007 comedy films). MB 00:16, 3 February 2022 (UTC)

@MB: I put in an explicit check to see whether the genre portal exists. It's not strictly necessary, but it should the tracking category tidy. @Gonnym: you may wish to set |tracking=no for portal calls in new category header templates. — hike395 (talk) 07:54, 3 February 2022 (UTC)

via cleanup

When you cleanup via, do take care to do the proper cleanup. You're just removing the URL, you're not fixing the actual problem. These are the proper fixes. You're making a mess. Please revert your AWB run because you're creating more problem than you solve. Headbomb {t · c · p · b} 09:24, 20 March 2022 (UTC)

@Headbomb: No problem. Reverted. I'll stop attempting any fixes. — hike395 (talk) 12:34, 20 March 2022 (UTC)

Thanks. You can still fix things, just more carefully. Headbomb {t · c · p · b} 15:58, 20 March 2022 (UTC)

It's too complex to be tractably automated, so I'll leave it to other editors. — hike395 (talk) 20:59, 20 March 2022 (UTC)

Do not remove OnTheMap links from the via parameter. They are needed for verifiability in stable articles and frankly, running AWB scripts at this pace is akin to bot-like editing. SounderBruce 19:22, 27 March 2022 (UTC)

@SounderBruce: Happy to stop, because there doesn't seem to be consensus on what |via= should do. I was trying to emulate (some of) Headbomb's edits: if I understand correctly, |via= should be used if the content deliverer is different from the publisher, and we want to show that this is on purpose, not by accident. In the case of Edmonds, Washington, OnTheMap is a US Census website, the publisher is the US Census, so |via= isn't appropriate, because the URL already is a US Census site. Having a URL in |via= causes a CS1 error (if you look at reference 64 in Edmonds, Washington, you'll see there is a red error message). My goal was to slowly chip away at those errors.

Given your objection, I can't run AWB to fix |via= at all, because this appears to be controversial, so I will truly give up on the whole fix. I only made 76 edits (at 2/minute, which I don't believe is bot-like editing). Would you like me to revert those 76 edits? — hike395 (talk) 03:26, 28 March 2022 (UTC)

@SounderBruce: Later: playing around with https://onthemap.ces.census.gov/ --- it's quite a neat tool. I just figured out how to generate deep links to the result of OnTheMap, see, e.g., the report for Edmonds. Would it make more sense to make that be the main URL for the reference, instead of linking to the page which links to raw LODES data access? — hike395 (talk) 07:03, 28 March 2022 (UTC)

Must be a new feature. I'll have to test to see if the link actually sticks (the Census website in particular is awful at permalinks) before I fix the dozen or so articles that would be affected. SounderBruce 07:21, 28 March 2022 (UTC)

We could use http://web.archive.org to save the generated html page, and then not worry if the url dies later.

Let me know if you want me to revert the other 74 |via= edits. — hike395 (talk) 07:26, 28 March 2022 (UTC)

A barnstar for you!

	The Technical Barnstar
	Thanks for creating and improving {{Detect singular}}, allowing it to be used in a wide variety of applications! {{u|Sdkb}} talk 22:47, 8 January 2022 (UTC)

Portal tracking

If you check "what links here" on Portal:Syria and Portal:Zimbabwe, you will find hundreds of articles that I think will eventually be listed in the Category:Portal templates with redlinked portals. A couple already were. I've gone through both of these lists and removed all the cases that had the portal listed in a portal template on the page. In the majority, the link is coming from some other template. If you want to look into this.... MB 01:07, 11 January 2022 (UTC)

@MB: I think it will be fine. Check out User:Hike395/sandbox2, which consists of {{#ifexist: Portal:Slobovia|yes|no}}. Notice that the what links here page for Portal:Slobovia now contains User:Hike395/sandbox2.

What I think is happening is that the existence of portals are being checked in many places (e.g., Template:Foo–Bar relations category/inner core), and that is showing up as "what links here". So these links are not being supplied to {{Portal}} and will not flood the redlink category. — hike395 (talk) 04:59, 11 January 2022 (UTC)

OK. This is new. In the past, I've used "what links here" to find deleted portals before they have shown up in the category but never had "spurious" redlinks. The replication lag (if that is the right term) seems very slow now, I think it will take weeks to get caught up. Module:hatnote has been changed a couple of times and that is still going through many thousands of files. MB 05:20, 11 January 2022 (UTC)

There is one today, Category:Handball clubs established in 2018 which has a portal link created by {{Handball club estcat}} MB 04:43, 12 January 2022 (UTC)

@MB: Portal:Handball doesn't exist, so I just removed {{Portal}} from that template entirely. — hike395 (talk) 10:38, 12 January 2022 (UTC)

But didn't that remove the creation of a year or decade portal also? Although many decades don't have portals either. MB 14:22, 12 January 2022 (UTC)

@MB: I can restore the decade portal, if you think that's best. I figured that without a Handball portal, having just a decade portal was strange. — hike395 (talk) 01:36, 13 January 2022 (UTC)

Fine by me as it is, I am not a big portal fan myself and don't find them useful. I just remove redlink potals when I find them, I think others may replace them with a more general portal that still exists. MB 01:50, 13 January 2022 (UTC)

Category:Portal templates with redlinked portals has 15 more today that are coming from templates auto-creating portal links. This time, the "main" portal does exist. MB 15:44, 14 January 2022 (UTC)

@MB: Easy to fix. You can do this too: just add |tracking=0 to the portal calls inside of templates that are generating junk. — hike395 (talk) 22:23, 15 January 2022 (UTC)

That turns off all tracking, which hides other errors we would potentially want to see. For example, if someone inadvertently changed |portal=Education to |portal=Educatio in Category:Education companies established in the 1880s, we would not find and fix that. I would have thought there would be a better way. {{FindYDCportal}} says it returns an empty sting if there is NO portal, so can't {{FooIndustry companies (dis)established in the YYY0s}} check that? MB 23:03, 15 January 2022 (UTC)

@MB: What was happening is that the template author(s) used {{{portal}}} instead of {{{portal|}}}, so it was looking for [[Portal:{{{portal}}}]], which doesn't exist. I changed the template to use the more typical {{{portal|}}} which does not generate errors. — hike395 (talk) 01:52, 16 January 2022 (UTC)

That seems to be a much better fix. Thanks. There have been no new errors detected, so maybe that was the last of this type of issue we will see. MB 04:00, 16 January 2022 (UTC)

A new one today, from {{YYY0s in women's weightlifting category header}}, redlink portal at Category:2000s in women's weightlifting. I might be able to figure out a fix from looking at previous fixes, but probably much faster if you did this one. MB 01:10, 26 April 2022 (UTC)

@MB: Wow, Category:Portal templates with redlinked portals suddenly sprouted, I don't know what happened. The template you highlighted linked to Portal:weightlifting, which does not appear to exist. I just deleted the portal call. I have no idea why it took months to show up in the tracking. — hike395 (talk) 02:37, 26 April 2022 (UTC)

A few new ones are showing up almost every day. A couple times, there has been a big burst like this too. It seems like some process is hitting pages that haven't been edited in years. There have been some redlinks in other cats too on pages that have not changed in years. MB 02:46, 26 April 2022 (UTC)

There are three today also coming from a header template if you can take a look. MB 15:40, 10 May 2022 (UTC)

Nevermind, I did a null edit and that fixed them. MB 15:42, 10 May 2022 (UTC)

Talk:Koyaanisqatsi

Not sure I understand why you chose to undo my edits. The most recent threads were three years stale, and I deliberately chose one-click archiving as I feel it is a better fit for low-traffic talk pages and the previous auto archiving hadn't done a thing in nine years. Beeblebrox (talk) 04:34, 16 July 2022 (UTC)

Hi, Beeblebrox! I was following the advice given at the Archiving help page, which says

It is customary to periodically archive old discussions on a talk page when that page becomes too large. Bulky talk pages may be hard to navigate, contain obsolete discussion, or become a burden for users with slow Internet connections or computers.

To me, the purpose of archiving is to reduce Talk pages down to a manageable size, not to eliminate discussions that are only four years old. I think it's important for editors to see what issues other editors have been grappling with, even if those issues are a few years old. I've seen old discussions flare back up after some years. If we entirely archive a Talk page and leave it empty, editors are not going to seek out the archive issues. To me, it's a matter of transparency and not hiding information.

Currently, Talk:Koyaanisqatsi currently only contains 3 threads and is only 2600 bytes long. I think that's easy to navigate. I thought about unarchiving more threads, but I could see why nine-year-old discussions could be considered obsolete. I thought having 3 threads might be a good compromise. What do you think? — hike395 (talk) 04:53, 16 July 2022 (UTC)

By the way, the autoarchiving was only set up in 2020: one more thread would have triggered it. The parameters seem typical for a quiet Talk page. — hike395 (talk) 04:57, 16 July 2022 (UTC)

New template

Can you please make sure you don't remove the archived urls when introducing your newly created template into the articles? Thanks. M.Bitton (talk) 23:35, 25 September 2022 (UTC)

@M.Bitton: Thanks for reminding me! For recent dates, there was simply a URL change, and so I don't think archive-url is necessary. But for older links, the content may have changed, so keeping an archive-url is important for those. — hike395 (talk) 00:17, 26 September 2022 (UTC)

Thank you for adding the "archived-url" to the template. What's going to happen to the articles that have been already edited (such as Arabs, where many archived urls have been removed)? Do you intend on going through them again? M.Bitton (talk) 00:21, 26 September 2022 (UTC)

Yes, I'm just going back to look at them now. It looks like the accessdate for the links in Arabs is in 2021, so the most recent version at the CIA should be fine. The template just wraps {{cite web}}, so we can add links to archive.org if we need them. — hike395 (talk) 00:26, 26 September 2022 (UTC)

I didn't see any |archive-url= for links with |access-date= before 2021 and with |url-status=dead, so I think everything is fine. If I keep going, I'll make sure that I preserve archive links to older versions. It's very tedious: AWB doesn't help that much. — hike395 (talk) 00:48, 26 September 2022 (UTC)

@M.Bitton: Unless you were also thinking of archive links where |url-status=live? Those aren't required for WP:V, but could help in the future. Let me know. — hike395 (talk) 00:55, 26 September 2022 (UTC)

The thing with their site is that they tend to change information from time (sometimes, even contradicting their previous articles), and when that happens, whatever the original link (source) was supposed to support ends up not being sourced any more. That's why I the archived-url is important to keep. M.Bitton (talk) 01:01, 26 September 2022 (UTC)

@M.Bitton: I agree. There are annual archives of the World Factbook available at the CIA, going back more than 20 years. I'll have the template link to those, also, for verifiability. — hike395 (talk) 01:04, 26 September 2022 (UTC)

Problems with #invoke and an unnamed parameter

After seeing you use of {{#invoke:Template wrapper I have decided to use if for another wrapper project. However I have run into a problem and I am hoping that you can suggest a simple solution.

I have set up a simple template in User:PBS/test3 which contains:

One={{{1}}}

A={{{A}}}

B={{{B}}}

I have a wrapper template User:PBS/test4

{{#invoke:Template wrapper|wrap|_template=User:PBS/test3|_alias-map=
|A=This parameter is set in test 4
}}

And finally a test of the two template in User:PBS/test5. When I call test3 from test five it acts as I expect. However if I call test4 from test five it does not pass on the value in unnamed parameter 1=value Do you know if this a limitation with #invoke, or have I made a mistake? If it is a limitation do you know if there is there a common work around? -- PBS (talk) 11:44, 26 September 2022 (UTC)

@PBS: In test4, you need to set |_include-positional=yes, see Module:Template_wrapper/doc#include-positional. — hike395 (talk) 12:00, 26 September 2022 (UTC)

Many thanks it worked a treat. -- PBS (talk) 12:05, 26 September 2022 (UTC)

did you break a template?

It appears that something in your recent edit to {{Include-USGov}} broke it. See the articles that currently populate Category:CS1 errors: URL–wikilink conflict.

—Trappist the monk (talk) 22:27, 6 October 2022 (UTC)

@Trappist: It was actually [1], but there is a simple fix, now implemented. — hike395 (talk) 22:29, 6 October 2022 (UTC)

{{Include-USGov}} is now stricter about what it accepts as |agency=. All cases now fixed. — hike395 (talk) 22:46, 6 October 2022 (UTC)

And now {{USGS}}. See Category:CS1 errors: chapter ignored. You know, we have sandboxen, test cases, and the Show preview button for a reason. Please use them.

—Trappist the monk (talk) 23:27, 6 October 2022 (UTC)

I did use them! I didn't anticipate this case, so there was no test coverage. — hike395 (talk) 00:20, 7 October 2022 (UTC)

Those were not problems in the template, but problems in calling {{USGS}}. — hike395 (talk) 00:27, 7 October 2022 (UTC)

(edit conflict)

{{Include-USGov}} still broken? This from Bangkok:

{{Include-USGov |agency=Overseas Security Advisory Council |title=Thailand 2012 Crime and Safety Report: Bangkok|date=14 March 2012 |url=https://www.osac.gov/Pages/ContentReportDetails.aspx?cid=12189 |website=Overseas Security Advisory Council website |publisher=Bureau of Diplomatic Security, U.S. Department of State|access-date=24 September 2012}}

 This article incorporates public domain material from "Thailand 2012 Crime and Safety Report: Bangkok". Overseas Security Advisory Council website. Bureau of Diplomatic Security, U.S. Department of State. 14 March 2012. Retrieved 24 September 2012.

and this from Joint Declaration of Pope Francis and Patriarch Kirill:

{{Include-USGov|agency=United States Department of State|policy=https://2009-2017.state.gov/misc/87529.htm|author=Bureau of Democracy, Human Rights, and Labor|year=2005|title=Russia|journal=International Religious Freedom Report|location=Washington, DC|publisher=Department of State|issn=1936-4156|url=https://2009-2017.state.gov/j/drl/rls/irf/2005/51576.htm|access-date=2019-05-26}}

 This article incorporates public domain material from Bureau of Democracy, Human Rights, and Labor (2005). "Russia". International Religious Freedom Report. Washington, DC: Department of State. ISSN 1936-4156. Retrieved 2019-05-26.{{citation}}: CS1 maint: multiple names: authors list (link)

—Trappist the monk (talk) 00:30, 7 October 2022 (UTC)

 Fixed --- Thanks for reporting those to me. I was attempting to do something fancy with |work= and |publisher=, but it clearly was not robust against corner cases. I added all of your reported bugs as new test cases. Please let me know if you see anything else. — hike395 (talk) 02:14, 7 October 2022 (UTC)

Template:EPA content/doc?

—Trappist the monk (talk) 15:00, 7 October 2022 (UTC)

 Fixed Thanks, easy fix (remove wlink from |agency=). Is there an existing template or module that strips wlinks from strings? — hike395 (talk) 15:09, 7 October 2022 (UTC)

A found a couple of other calling templates and fixed those, also. — hike395 (talk) 15:57, 7 October 2022 (UTC)

Went through main namespace with AWB and stomped on all incorrect usage of |agency=. There should not be any other Title/URL conflicts. — hike395 (talk) 17:03, 7 October 2022 (UTC)

Added {{delink}} to {{Cite USGov}} to avoid future errors of this sort. — hike395 (talk) 17:17, 7 October 2022 (UTC)

Treeline

Good morning My professor (University of Basel, Switzerland) would be very happy to discuss the "tree line" with you. Please contact him at: ch.koerner@unibas.ch (he is not used to wikipedia, therefore, email would be better for him). Best, Hantzzz (talk) 08:56, 26 September 2022 (UTC)

Mr Körner wrote me these words, he would be very glad if you could reply him :-) Thank you very much.

"Dear colleagues who care for this Wicki-page on treeline. I found the page only by chance and read it with great interest. I would love to come in contact with you, given the treeline concept underwent some development over that past two decades and the web page could profit from some edits. I am the author of ‘Alpine Treelines’ Springer, Basel, a book that was also translated into Chinese. I am happy to share a few recent works with you. You can find my profile under https://duw.unibas.ch/en/koerner" Hantzzz (talk) 12:54, 5 October 2022 (UTC)

@Hantzzz: Please tell Professor Körner that I very much respect his work: I first cited his work at treeline back in 2010. We could engage in a private conversation, but it would be more in the Wiki style for Professor Körner to post comments/suggestions/criticisms at Talk:Treeline. There is no requirement for formatting, or even getting a Wikipedia account -- it would be wonderful to get his feedback, either positive or negative. Could you perhaps show Professor Körner how to post to a talk page? — hike395 (talk) 15:43, 5 October 2022 (UTC)

Thank you very much for your reply. Christian Körner would be really happy if you could contact him via email (ch.koerner@unibas.ch) 2A02:1210:32F4:5500:39E4:D402:2D0E:2940 (talk) 15:22, 6 October 2022 (UTC)

Dear colleague at hike395... I am not familiar with these wicki routines and it would be easier for me to communicate per e-mail at

ch.koerner@unibas.ch

The description of the alpine treeline is a great improvement over much earlier attempts, but it still suffers from a few formal and conceptual shortcomings, and I found the literature somewhat outdated (I know, an always true statement).

Maybe you cannot change this because spell checkers did not get grips on the new terminology, but you would best use treeline and NOT tree line. The latter brings a lot of useless hits at searches. Just as the outdated timberline, we should all use treeline for coherence. Timberline refers to timber, and thus misguides users. Whether something is a 'tree' in biology is not related to its usfulness as timber. I discuss this in Alpine Treelines, Springer 2012 (with a Chinese translation). The line of the closed forest shoud be termed forest line (as suggested), and for the transition from forest line to the uppermost individual trees the term treeline ecotone has been suggested. I am discussing the problem of 'line' in alpine treelins. The ecotone may be wider or narrower for disturbance or normal forest dynamics reasons. All more formalistic issue.

Conceptually

Here the problems go deeper. Are we approaching this problem from a geographical or from a biological perspective? For a Geographer any forest edge on a mountain may be a treeline. A biologist would ask, is, what I see, the biological limit of the life form tree or have people cut the trees higher up, did a fire devast the forest (as in many places (e.g. Klimanjaro), or do we see the outcome of millennia of pastoralism? Also absence of soil like on Kinabalu does not permit trees to grow at the life form limit. Since we biologists always ask for theory and testable hypothesis the only thing that matters for us is tree biology and not human interference, fire, stochastic phenomena (not predictable). To make the story short: humans cannot shift the treeline, but they may cause the absence of trees from the treeline. I summarized this both in the Encyclopedia of Biomes (Elsevier) and in Trends Ecol Evol 2021. I think the endless dispute of what is a treeline and what not can only be resolved of a distinction is made between the upper edge of fundamentalniche of the life form tree and the edge of realized niche. With the first it is possible to predict climatic treeline positions across the globe at 78 m precisition (10 m in NZ), with that remaining error reflecting the limited climatic data for remote places (see Paulsen and Körner 2014, Alpine Botany). I am happy to provide pdfs on request to ch.koerner@unibas.ch. There are other issues such as the inappropriate use of the term tundra outside the Arctic or the inclusion of drought driven tree absence in the term treeline. With that idea we have subSaharan treelines and the term loses sense.Not all physiological tree limits are treelines. Drought is clearly not a common phenomenon of mountains. But locally, there are drought driven tree distribution limits. Notable the dier a mountain the higher the treeline up to a limit of 250 mm precip when trees cannot grow anywhere.

Causes for treeline

I stop here to see whether there is an interest to dive into this terrain. The explanation is related to tree architecture and aerodynamics, with trees reaching the biologically universal low T limit for plant growth, but they reach it at lower elevation than non-trees for physical reasons. So physiologically trees are not inferior to other life forms, but the upright growth sets a thermal limit. This is why krummholz does not represent a treeline but may be included in the ecotone term. All explained in Alpine Treelines (Springer) 2A02:1210:502E:5900:8876:70FC:FCF7:CBE3 (talk) 11:36, 30 October 2022 (UTC)

DYK nomination of Vogelsang Pass

Hello! Your submission of Vogelsang Pass at the Did You Know nominations page has been reviewed, and some issues with it may need to be clarified. Please review the comment(s) at your nomination's entry and respond there at your earliest convenience. Thank you for contributing to Did You Know! —David Eppstein (talk) 00:20, 31 October 2022 (UTC)

A Dobos torte for you!

7&6=thirteen (☎) has given you a Dobos torte to enjoy! Seven layers of fun because you deserve it. To give a Dobos torte and spread the WikiLove, just place {{subst:Dobos Torte}} on someone else's talkpage, whether it be someone you have had disagreements with in the past or a good friend.

A trifle for your troubles. 7&6=thirteen (☎) 16:36, 9 November 2022 (UTC)

Thanks! Don't worry -- you didn't cause any problems at all! — hike395 (talk) 00:09, 10 November 2022 (UTC)

DYK for Vogelsang Pass

On 19 November 2022, Did you know was updated with a fact from the article Vogelsang Pass, which you recently created, substantially expanded, or brought to good article status. The fact was ... that the view from Vogelsang Pass has been described as "one of the most stunning" in Yosemite National Park? The nomination discussion and review may be seen at Template:Did you know nominations/Vogelsang Pass. You are welcome to check how many pageviews the nominated article or articles got while on the front page (here's how, Vogelsang Pass), and if they received a combined total of at least 416.7 views per hour (i.e., 5,000 views in 12 hours or 10,000 in 24), the hook may be added to the statistics page. Finally, if you know of an interesting fact from another recently created article, then please feel free to suggest it on the Did you know talk page.

Cas Liber (talk · contribs) 00:02, 19 November 2022 (UTC)

Template:Infobox settlement

Thanks for your efforts to improve this template. I tried to make one change, but the article is locked. At "native name", it reads:"This will display under the name/official name." Could you change to "This will display below (or beneath??) the name/official name." This is because "under" can be misunderstood as meaning "within" (eg. file this under "top secret"). Cheers! Magnolia677 (talk) 22:40, 21 November 2022 (UTC)

 Done Good idea: I used the word "below". — hike395 (talk) 23:42, 21 November 2022 (UTC)