User talk:Hike395/Archive 19
This is an archive of past discussions with User:Hike395. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 15 | ← | Archive 17 | Archive 18 | Archive 19 | Archive 20 | Archive 21 | → | Archive 23 |
List of peaks named Signal Mountain
Hi. I was just looking up creator of List of peaks named Signal Mountain in order to notify them, and I click on your contributions and see that you just posted at the AFD. Sorry I didn't extend the notification courtesy sooner. This is regarding Wikipedia:Articles for deletion/List of peaks named Signal Mountain. What motivated me to start the AFD was not that the existence of List of Peaks article bothered me, but rather it is the combined treatment of the SIA and the DAB, and how guidance wp:SIA is written about it. I hardly ever initiate an AFD, but it seemed to me to be the right way to draw attention into a process that leads to an actual decision. So although my AFD nomination may come across as strident, I would be all for working out some kind of creative solution. --doncram 15:15, 13 August 2015 (UTC)
- I'm happy to improve WP:SIA, Signal Mountain, and List of peaks named Signal Mountain. Specific suggestions are more than welcome! —hike395 (talk) 15:29, 13 August 2015 (UTC)
- Thank you very much for your constructive participation. You posed a good challenge back to me, that was great. I think there's a consensus more or less now, and that the discussion has been productive, both towards improving the SIA guidelines and towards improving some WikiProject Mountains articles, I hope you may agree. Thanks, --doncram 00:27, 16 August 2015 (UTC)
- Thanks! I think the discussion was productive and we came to a simple conclusion (you're going to move the SIA back to Signal Mountain, right?). The eventual guideline changes are less clear to me. I'm not sure what you're going to propose at WT:SIA. But, I'm happy to wait to see and participate in the eventual discussion.
- I think we should start a discussion at WT:WikiProject Mountains and see if we can come to a new consensus about the format and contents of Mountain SIA. Whatever the outcome of guideline discussions at WT:SIA, I would like to continue to be able to make list articles about mountains with the same name that contain elevation and coordinate information (as I did at List of peaks named Kennedy) —hike395 (talk) 14:26, 16 August 2015 (UTC)
- I would be glad to participate. My AFD nom and my comments at Talk page of the SIA will have previewed my views: a better standard that looks better visually, accomplishes more, etc. is possible; there's been evolution since 2007 for other tables of geographic places. I have referred to the List of mountains in Mexico as one example that conveys more, and think that although it is not an SIA (it does not play any disambiguating-type role) there are aspects of it which could be adopted for the other mountains SIAs. I'd like to see your and others' examples of models to emulate, hopefully some with pics. The tables have to allow a text column, for descriptions and other notes that interest readers or provide crucial disambiguating-type information, IMO.
- But should we focus on modifying the Signal Mountains SIA first? As i commented today at the AFD, I would like for the Signal Mountain-related AFD to settle as much as it can, and am afraid of possibility that if we don't address the details by working out a good Signal Mountain SIA, then there will be continuing disagreement. An editor's "No." reply proves my point. Could you please comment there, and/or could we just proceed in editing to try to make the Signal Mountain SIA serve well from several points of view. That is, for it to be a better mountains list, and for it also to better deliver its disambiguating function (which in my mind I am equating to being an SIA serving a necessary role, as opposed to being a list-article unrelated to disambiguation, whose notability is very questionable). Maybe you prefer to do both concurrently...I will begin watching wt:WikiProject Mountains. --doncram 01:07, 19 August 2015 (UTC)
- @Doncram: I like the edits you make at List of peaks named Kennedy: definitely made it better. I moved the note out into the lede, to make the whole thing more list-article-like (i.e., to set the context). —hike395 (talk) 10:57, 19 August 2015 (UTC)
- Later --- I'm attempting to use User:Buaidh's nice compact templates, to give more room for notes. But, I'm running into a problem (draft at User:Hike395/sandbox2). If I can sort that out, I'll update the format of List of peaks named Kennedy. —hike395 (talk) 11:58, 19 August 2015 (UTC)
@Doncram: Sorry I have been super busy IRL, not much time for WP. I'm still trying to fix User:Hike395/sandbox2, so that I can fix List of peaks named Kennedy and List of peaks named Signal, so that we can propose the new formatting at WT:WikiProject Mountains. —hike395 (talk) 00:56, 24 August 2015 (UTC)
- Thanks for notice at my Talk page, i was confused before when an edit of mine reported Edit conflict, i thought it was EC with myself in a different window or from having hit return twice.
- Now i see your edit. It may have been doing more, but one thing was that you were changing display to hide the full names of the intended articles, e.g. to diplay "Signal Mountain" rather than "Signal Mountain (County, State)". Please don't change those right now. It's a matter of disambiguation page policy, that the full name SHOULD be displayed. I am not going to explain it right immediately, but i think the point is we want to see the difference on the page. It's not just for disambiguation pages, either, though it is subtle. I worked this out about lists of historic sites in a given area, and got to a consensus with the historic sites wikiproject. Say for a case where there were two "Cooper House"'s in one county list, which were to link to "Cooper House (Brookfield, Connecticut)" and "Cooper House (Bridgeport, Connecticut)". On the list-article page you don't want them to both show "Cooper House"... that looks like you are making a mistake and/or the reader will believe that both links will go to same place. You want to convey to reader that they will go to different places (accurately), so have to display "Cooper House (Brookfield)" and "Cooper House (Bridgeport)" or to display "Cooper House (Brookfield, Connecticut)" and "Cooper House (Bridgeport, Connecticut)". Let's talk this out more if necessary and not edit back and forth. It's a big point of difference that will apply to all the mountains SIA pages. I was realizing it was a big point that would need to be covered. This is one of those places where the devil is in the details.
- I am done at the List of peaks named Signal Mountain for now though so go ahead with whatever else.
- thanks, cheers, --doncram 04:50, 24 August 2015 (UTC)
- Likewise for names appearing on the linked OSM or Bing map. It is no help if all the places show as the same name; you want to be able to see which is the specific name of a given pinpoint on the map, and be able to consult the row in the table of that specific name. Right now the OSM map looks pretty good i think. The Bing map is funny about updating or not. --doncram 05:02, 24 August 2015 (UTC)
- P.S. The AFD closure was unhelpful given issues open and request that no overly simple closure be done. It is unsatisfactory. Note I redirected other page but was reverted by editor Bkonrad. I figure it's best to clean up the SIA so that it does serve disambiguation purpose well, and then open new AFD to completely delete the other page, to emphasize that the SIA is to provide disambiguation and there is no room for any other disambiguation page. I was for having a short disambiguation page to cover the towns in my proposal, but I think now that keeping any separate disambiguation page at all confusing and opens the door to encourage disambiguation-focused editors to develop it into overlapping, poor status. The AFD closer did not understand: if the disambiguation is to be done on a non-SIA page, then the SIA page is not valid (it has no sources and is simply not a valid article topic; all the mountains are covered in geographically-organized list-articles (or they can be) and we don't generate duplicative slices and dices of same information for no reason). An SIA page that performs the disambiguation is a valid reason; I want to make the mountains SIAs work that for doing disambiguation, like the Ships SIAs do. And there are no damn duplicative disambiguation pages for the Ships SIAs. And that battle was fought between... let me call it an old guard of too-narrowly-focused disambiguation editors... vs. Ships editors and it was unpleasant I believe, and it was decided, and Ships won, which was good. The wp:SIA writeup was not revised to make sense back then, however, and does not reflect the decision properly, though. I have swung a bit back and forth in my understanding, actually; now I see that duplication is bad and the dab page cannot duplicate while once I said duplication wasn't the problem. Anyhow, I hope the SIA can be cleaned up to avoid confusing small issues, then expect to have a new AFD or RFC or the like to re-establish consensus. Maybe requires bringing in the Ships editors who fought with the old guard of disambiguation editors. --doncram 05:27, 24 August 2015 (UTC)
- I'm glad you proceeded with edits at List of peaks named Signal Mountain: merging Canada and Mexico into table is good; dropping some GNIS-listed lesser items as non-notable is great, is a relief; I comment at Talk page about Mexican mountains snafu; overall it looks very much better. I saw you used some fixed percentages that constrain table column widths rather than allowing whatever is the default column-width-setting algorithm to run. The default may work better for some browsers, for some screen sizes, for some reader choices on how wide their window is open on their screen. I think but am not sure (worth checking) that there are no such constraints in huge system of tables of historic sites. I'm curious about that, anyhow.
- P.S. The AFD closure was unhelpful given issues open and request that no overly simple closure be done. It is unsatisfactory. Note I redirected other page but was reverted by editor Bkonrad. I figure it's best to clean up the SIA so that it does serve disambiguation purpose well, and then open new AFD to completely delete the other page, to emphasize that the SIA is to provide disambiguation and there is no room for any other disambiguation page. I was for having a short disambiguation page to cover the towns in my proposal, but I think now that keeping any separate disambiguation page at all confusing and opens the door to encourage disambiguation-focused editors to develop it into overlapping, poor status. The AFD closer did not understand: if the disambiguation is to be done on a non-SIA page, then the SIA page is not valid (it has no sources and is simply not a valid article topic; all the mountains are covered in geographically-organized list-articles (or they can be) and we don't generate duplicative slices and dices of same information for no reason). An SIA page that performs the disambiguation is a valid reason; I want to make the mountains SIAs work that for doing disambiguation, like the Ships SIAs do. And there are no damn duplicative disambiguation pages for the Ships SIAs. And that battle was fought between... let me call it an old guard of too-narrowly-focused disambiguation editors... vs. Ships editors and it was unpleasant I believe, and it was decided, and Ships won, which was good. The wp:SIA writeup was not revised to make sense back then, however, and does not reflect the decision properly, though. I have swung a bit back and forth in my understanding, actually; now I see that duplication is bad and the dab page cannot duplicate while once I said duplication wasn't the problem. Anyhow, I hope the SIA can be cleaned up to avoid confusing small issues, then expect to have a new AFD or RFC or the like to re-establish consensus. Maybe requires bringing in the Ships editors who fought with the old guard of disambiguation editors. --doncram 05:27, 24 August 2015 (UTC)
- Upon further thought, maybe the next public discussion should be an AFD about Kennedy Peak, the new disambiguation page that duplicates entries in List of peaks named Kennedy. The new dab definitely was created in good faith, in absence of decent guidance at wp:SIA. An AFD on it would be more straightforward as Kennedy peaks is a "pure" topic, meaning clear of non-mountains items, analogous to multiple pure Ships pages in Category:Set indices on ships. I want to review and classify the ship SIAs by types, first. For example, USS Alliance is an SIA fully performing disambiguation of "USS Alliance" term but where no non-disambiguation features are used (there are no footnotes, no entries with multiple bluelinks). It serves a role at Alliance (disambiguation)#Other uses as does similar HMS Alliance. HMS Alliance does use a non-dab feature: its redlink item is supported by a footnote reference; other references that would be useful in creating article for the redlink topic can accumulate there too. This is a role of an SIA page that serves development of Wikipedia, akin to reasoning for wp:redlinks in general: "Redlinks help the wikipedia grow". Actually your decision-making process at Signal peaks SIA is a great example of non-dab features assisting in disambiguation purpose: you used existence of good peakbagger footnotes plus 100m prominence as criteria in which items to keep as probably-notable. For disambiguation pages, paring off unlikely prospects as clutter is understood by disambiguation editors to be part of serving readers; that process is enhanced at an SIA allowing info accumulation. That's another aspect of SIAs to be covered in a new SIA guideline. Thanks for bringing that up at Talk page!
- Or, the next public discussion should be about for combo AFD regarding "pure" Kennedy peak SIA (where no other disambiguation is needed) and nearly-pure but "mixed" Signal peak SIA (where mountains are wp:PRIMARYUSAGE and two other uses may be served by hatnotes only) and perhaps other types of "mixed" SIAs where non-mountain usages are more commons. Hope you don't mind my thinking out loud here. --doncram 13:42, 24 August 2015 (UTC)
- @Doncram: AfD is a very blunt instrument -- it's not designed to resolve policy discussions, but to consider whether individual articles should be deleted according to the guidelines at WP:DP. It also tends to make editors angry, which tends to exacerbate differing opinions. I would recommend not doing that.
- Instead, let's start a discussion at WT:WikiProject Mountains, leaving pointers from WT:D and WT:SIA. The discussion should cover the following topics:
- What should be the contents of a mountain SIA: should they try to be inclusive, or list only peaks likely to be notable by themselves?
- Formatting of the mountain SIA -- do editors like List of peaks named Kennedy?
- What to do when SIAs and dab pages overlap (like Signal Mountain) -- should we follow WP:TWODAB and combine them?
- I can try to start the discussion, but again I'm super busy, so it may be tonight or tomorrow. —hike395 (talk) 15:56, 24 August 2015 (UTC)
- Okay, you're right. I have participated in some very constructive AFDs where good decisions were worked out, but maybe in those the article-creators were long gone and there were not defensive parties; i see what you mean, thank you for saying that. I haven't participated or seen any policy discussion at wt:Mountains(?) but am happy to try that. Wp:ships examples need to be discussed and it would be natural to give notice there too. No rush. Do we have some stuff to sort out first, in terms of getting either/both of the K and S pages in good order and being agreed upon it? Or to discern a list of principles that have applied for dabs or elsewhere, that should apply to a SIA the same way, or modified. I am happy for those to come out naturally in new discussion though, if you want to open it.
- The new point last night is addressed for dab pages within wp:D guideline at wp:DABSTYLE: "Do not pipe the name of the links to the articles being listed" (but see exceptions). Which I see applying for SIA pages, at least or especially when there are redlinks and the usage of the page is partly to help determine what names for new articles should be. Maybe there is an offsetting principle that applies also and expresses why past mountain SIA usage has been to hide the peak names, although I don't see it myself. Do some think it looks more elegant, or that using pipelinks that way is required? Perhaps it is right to say that hiding is effectively required in usual circumstances where there is just one link to any Signal Peak and you would not show a disambiguating parenthetical as there's nothing to differentiate. But this is different, where differentiation is needed else readers don't know what to expect (do all the Signal Peak links go to one big, separate article covering them all, rather than going to separate pages for each one), and we are not bound to present the links the same way. Like I said about historic site lists, even when they are completely finished and all links are blue, I have became convinced it's best to show at least the differentiating part in names displayed (e.g. Brookfield vs. Bridgeport) while maybe not any non-differentiating part (Connecticut). I don't know if this is a style issue where large numbers of mountains SIAs have the hiding style and where editors will cleave to that for some reason, or if this is no big deal at all. --doncram 22:53, 24 August 2015 (UTC)
- Instead, let's start a discussion at WT:WikiProject Mountains, leaving pointers from WT:D and WT:SIA. The discussion should cover the following topics:
Thanks for big view
Thank you Hike395, for seeing the big view on the wikimedia situation, and then also taking the time to share it at my commons talk page so clearly. It's a very constructive satellite view of the problems and opportunities, and extremely appreciated. Your insights/input is most helpful.
I will reply more under the topic on my commons talk page in future, when have sufficient calmness and clarity about proceeding, but did not want to wait to thank you. Take care Look2See1 t a l k → 01:50, 25 August 2015 (UTC)
- I'm glad that my advice wasn't too upsetting, then. Good luck figuring things out! —hike395 (talk) 13:57, 25 August 2015 (UTC)
List of flora of the east of the Sierra Nevada region
I thought you might be interested that I will start working on List of flora of the east of the Sierra Nevada region, after I finish going through the new Jepson 2nd ed. (page by page) to make the List of flora of the Mojave Desert region. My method will be to first alphabetically go through each Jepson Manual entry and highlight "SNE", "W&I", and "C" (if it does not exclude SNE and W&I). Then I will go back and write the list from the entries with the highlights. I will then use these lists to pare things down and select from the list, to write narrative flora articles similar to Flora of the Sierra Nevada alpine zone. Do you have suggestions for a source to use for Nevada endemics in each region, since they will not be in Jepson? FloraWilde (talk) 00:52, 26 May 2015 (UTC)
- Yes, I am quite interested in articles about the eastern Sierra (as you may have guessed from my user name). One issue that has come up multiple times in Wikipedia: there is no globally accepted division of ecoregions. This could affect your list article, because you are choosing to follow Jepsen, who roughly follows Kuchler (1977). This a division that hasn't yet made it into Wikipedia: there are articles that use the EPA ecoregions, following Omernik (1987) (e.g., a very sketchy article about the Central Basin and Range ecoregion), and others that follow WWF (e.g., Great Basin shrub steppe). Unfortunately, WP's articles about the Great Basin are in disarray -- I tried to clean up and merge some of them, but ran into resistance from other editors.
- To answer your question, I don't have Nevada-specific books on endemics. If you are going to describe the eastern slope of the Sierra, you may wish to consult "Sierra East" by Genny Smith, and the "Laws Field Guide" by John Muir Laws. I think you've already cited the former in the alpine flora article. For the Inyo-White mountains, you could try "Natural History of the White-Inyo Range" by Clarence Hall. The latter may be already covered by Jepson, however. —hike395 (talk) 06:25, 26 May 2015 (UTC)
- Later --- there's also the results of the Sierra Nevada Ecosystem Project study, see here. —hike395 (talk) 06:41, 26 May 2015 (UTC)
- Thanks. I will use those sources and check out the references in them, too. FloraWilde (talk) 12:41, 26 May 2015 (UTC)
- Thank you both for working on the Eastern Sierra flora. Here are several other resources that have been helpful in my CA/Sierra flora explorations.
- The Calflora Database searchpage has several field parameter specifiers, such as plant community (e.g. Sagebrush Scrub, Pinyon-Juniper Woodland, Bristle-cone Pine Forest), County, CA native, etc. A result list for Calflora Database (Sagebrush Scrub, Inyo County, Native to California, species names in plain text) search example. Calflora (& Jepson eflora) provides the latest Jepson Project approved bot. names in my experiences, but Calflora has very detailed verified collection locations by county for distribution info (via Interactive Distribution Map option on map), & links to other databases, that Jepson doesn't provide.
- The Bristlecone Chapter of the California Native Plant Society covers all of Mono and Inyo Counties and northeastern Kern County, so includes the Eastern Sierra, Great Basin deserts, & Inyo/White Mountains habitats. People on its board may be helpful too, my local chapter's board is patiently so. The Bristleconecnps.org: Plant Lists tab has links to specific plant lists for places in their area & mention others not uploaded yet, but perhaps available? The Bristleconecnps.org: Resources tab has oodles of region's (botany/ecology/environment) books, organizations, et al links that may be helpful.
- In anecdotal spirit only, one definition of Eastern Sierra I've heard from some botanists over the decades is − from the Sierra Crest's rain shadow eastwards/southeastwards. In actual visual experiences, the Eastern Sierra seems to be one of those wonderful/messy ecotones merging Sierra 'ecoregion'/California Floristic Province & (one of the) Great Basin 'ecoregions'/Great Basin Floristic Province, as the Chaparral/CA Deserts do in rain shadowed sides of Transverse/Peninsular Ranges.
- I hope I'm not intruding on a more private conversation or rambling too much, please let me know if am. Thanks, Look2See1 t a l k → 02:59, 25 August 2015 (UTC)
- Thanks for the sources! @FloraWilde: to ensure that s/he sees this. —hike395 (talk) 13:57, 25 August 2015 (UTC)
- Hi, did post note at FloraWilde's talk page yesterday, under a "This account has been blocked indefinitely as a sock puppet - effective 15 July" banner. Perplexing. — Look2See1 t a l k → 00:31, 26 August 2015 (UTC)
- Yes, I was surprised by that. See User talk:JamesBWatson/Archive 63#Sockpuppet investigations/KatieBoundary for the thinking behind the block. —hike395 (talk) 04:37, 26 August 2015 (UTC)
Need help merging two articles
Hey Hike, (hope you don't mind the informality), how did you merge Great Basin Shrub Steppe into Great Basin Desert? Federal Land Use Policy Act of 1976 needs to be merged into Federal Land Policy and Management Act Lynn (SLW) (talk) 18:42, 12 September 2015 (UTC)
- @LynnWysong:. Most people on WP call me "Hike" :-). Check out WP:MERGETEXT for instructions of how to do a copy-paste merge. —hike395 (talk) 20:13, 12 September 2015 (UTC)
Got it, Thanks. Lynn (SLW) (talk) 21:19, 12 September 2015 (UTC)
Possible to fix broken links with link to Internet archive
Hi Hike395, I saw your updates to The Enchantments fixing a broken reference. Thanks for doing that, and especially for finding a replacement source for the information (which is, of course, the hard part). I just wanted to make sure you know that short of doing all that work, it's also fair to fix a broken link with a link to an archived version of the now-defunct page. See Wikipedia:Citing_sources/Example_style#Repairing broken webpage references. For example, the Leonard reference you removed from The Enchantments could be viewed at [1]. Thanks for the hard work! W.stanovsky (talk) 03:00, 26 September 2015 (UTC)
- @W.stanovsky: Thanks for finding that -- I use User:Dispenser's WP:Checklinks tool, and somehow must have missed the archived version of the Leonard reference. —hike395 (talk) 19:46, 26 September 2015 (UTC)
Hello
Greetings to you, Hike395. I remember you well for your encouraging words when I first started editing. I hadn't noticed you here on Wikipedia for a while until today when your name popped up on my watch list. I just want to let you know that I am pleased that you are still so active here. Cullen328 Let's discuss it 05:04, 6 November 2015 (UTC)
- @Cullen328: Thanks for your kind words --- I have been getting somewhat discouraged lately, because WP editors seem to be less cooperative and more focused on minutiae than they used to be. Many good editors have left WP or have decreased their activity levels. I'm glad that you've become an accomplished and prolific editor! —hike395 (talk) 00:21, 7 November 2015 (UTC)
Usual
Hi dear friend!
Question: In the text: "The Macro Video was a normal and average cinema 10 years ago and It is a 5-floor building cinema now. "The Macro Video used to be a usual cinema but it's got many halls." Does the adjective 'usual' imply suitable usage? Alborzagros (talk) 13:09, 15 November 2015 (U
- @Alborzagros: I see you've asked several editors the same question. I would suggest the following usage:
- "The Macro Video used to be a typical cinema, but now it has an unusual number of floors" —hike395 (talk) 02:33, 16 November 2015 (UTC)
- Thanks for answer. Alborzagros (talk) 06:03, 16 November 2015 (UTC)
Southern Alps
I have closed you requested move Talk:Southern Alps#Requested move 29 November 2015. It was a technical close. This sort of move request does not need to be initiated see WP:RMUM which is a section to allow for the reversal of this type of bold move, to discourage people gaming the system (not that I think there was any gaming in this case). -- PBS (talk) 11:20, 30 November 2015 (UTC)
Mountain and mountain range infoboxes
I stumbled across these two in the WP:TFD/HC; how should we proceed? Alakzi (talk) 09:48, 7 September 2015 (UTC)
- @Alakzi: Thanks for offering to help! The last step is to convert the
|region=
parameter in articles that use {{Infobox mountain}} to use|region_code=
, to be compatible with {{Infobox mountain range}}. There are about 16,000 articles that use {{Infobox mountain}}, and sadly a substantial fraction of them use|region=
. I've used AWB to fix about 5,000 of the articles a few months ago, but then I got tired of the tedium and busy IRL, so I've left it half-finished.
- If you have access to AWB, or some other bot, and can convert the rest of the articles, I (and other mountain editors) would be so appreciative!
- After the AWB run, we just need to copy
theUser:Hike395/MtnComboBox to {{Infobox mountain}}, redirect {{Infobox mountain range}} to {{Infobox mountain}}, and then we're done! —hike395 (talk) 10:20, 7 September 2015 (UTC)|region=
code from {{Infobox mountain range}}- Oh, I see. {{Infobox mountain range}} provides a complete breakdown by country, state, region, district, and city; whereas {{Infobox mountain}} has only got the one, amalgamated
|location=
field. I believe the latter is customary in all infoboxes bar {{Infobox settlement}}, the reasoning being that a breakdown by administrative division is most relevant to administrative divisions, rather than landforms, buildings, etc. Are we sure we don't want to stick with|location=
? There's only about 2,500 mountain range transclusions, which would make our task a fair bit easier. Alakzi (talk) 10:53, 7 September 2015 (UTC)
- Oh, I see. {{Infobox mountain range}} provides a complete breakdown by country, state, region, district, and city; whereas {{Infobox mountain}} has only got the one, amalgamated
- @Alakzi: As part of the merge discussion, both User:RedWolf and I liked the merge because we liked the breakout of the amalgamated
|location=
field. It's a large amount of work, but I thought it was worth it to keep that parameter. I just did ~500 articles with AWB in 20 minutes, with 10,000 left to go, so it's about 7 hours of work left.
- @Alakzi: As part of the merge discussion, both User:RedWolf and I liked the merge because we liked the breakout of the amalgamated
- I know it's been a long time (by the calendar). I will try to chip away at it. I've asked for help, but no other interested editors seem to be able to run AWB. —hike395 (talk) 11:11, 7 September 2015 (UTC)
- OK. I'll try to chip in. Alakzi (talk) 11:12, 7 September 2015 (UTC)
- @BU Rob13: If you're interested. Alakzi (talk) 11:13, 7 September 2015 (UTC)
- With the semester starting, I don't really have any time to help work through these manually. Besides, pressing the save button a few thousand times would cause finger strain. I could, on the other hand, produce a bot task to do it for us. If you want me to take a stab at it, let me know. It would probably be a somewhat lengthy wait to get the bot approved, though; I have a bit of a "backlog" of tasks waiting to be submitted. I'm trying to avoid clogging up the BRFA process by limiting myself to two requests at a time. ~ RobTalk 02:54, 8 September 2015 (UTC)
- @BU Rob13: If you're interested. Alakzi (talk) 11:13, 7 September 2015 (UTC)
- OK. I'll try to chip in. Alakzi (talk) 11:12, 7 September 2015 (UTC)
- I know it's been a long time (by the calendar). I will try to chip away at it. I've asked for help, but no other interested editors seem to be able to run AWB. —hike395 (talk) 11:11, 7 September 2015 (UTC)
I didn't realize that AWB could be used automatically under a bot account. You just set it up to run autonomously under windows, and let it run for N hours? At BRFA, do you just post the AWB script? I could do this myself. —hike395 (talk) 03:14, 8 September 2015 (UTC)
- Yes. Not everyone posts their regex at BRFA, but as a first-time bot operator (which I assume you would be), you probably will be asked to. You'll be approved for trial, at which point you can request AWB access for your bot account as a bot, which will "unlock" a new tab in AWB that allows auto-save. If you have any questions about filling out the BRFA or anything, let me know, happy to help. AWB is exclusion compliant by default, by the way, which is one of the questions for the BRFA. ~ RobTalk 03:19, 8 September 2015 (UTC)
- There's no need to use regexes, by the way; AWB has got a template parameter renaming function. Alakzi (talk) 10:39, 14 September 2015 (UTC)
- @Alakzi: Can you point me in the direction of that? I wasn't aware of that function, and it may be a more efficient way to handle certain tasks. ~ RobTalk 23:18, 14 September 2015 (UTC)
- There's no need to use regexes, by the way; AWB has got a template parameter renaming function. Alakzi (talk) 10:39, 14 September 2015 (UTC)
I have not been too active on here lately (been busy) but I have been changing |region=
to |region_code=
in mountain articles I come across. If I understood how to use AWB I would probably use it to get this merge done and over with. Volcanoguy 10:33, 14 September 2015 (UTC)
- I've created Category:Articles using Template:Infobox mountain with region to see how many remain; it'll be a while before it fills up. Alakzi (talk) 10:49, 14 September 2015 (UTC)
- @Alakzi: Thanks for this. I am in the process of changing
|region=
to|region_code=
. If someone can help out that would be great. Volcanoguy 17:30, 4 December 2015 (UTC)- @Volcanoguy: @Alakzi: Thanks for helping -- it's a gigantic task, much larger than I had originally foreseen. —hike395 (talk) 15:33, 6 December 2015 (UTC)
- @Alakzi: Thanks for this. I am in the process of changing
Summit Lake
Hello, this discussion stalled. Care to get rid of the Alaska page as we discussed? --Midas02 (talk) 06:17, 23 February 2016 (UTC)
Kindly asking for a review of POTD captions
Hello! I come back to you as I promised some months ago. I have indeed rellocated a batch of POTDs, about 75 spread over the months of April, May, June and July. You will recognise they all have an English and a Spanish caption. Thank you very much for your help! --Poco2 21:38, 11 March 2016 (UTC)
Cascade Range
Hi! Thanks for going over my last batch of edits to Cascade Range. It looks better. As far as font size changing, the "image captions should have normal font, per MOS:FONTSIZE" section you mention is a bit fuzzy, it states "Editors should avoid manually inserting large and small font sizes into prose. Increased and decreased font size should primarily be produced through automated facilities such as headings or through carefully designed templates." Thumbnail images are not in the main article prose and they can be considered a template style. I've seen this done on other articles, in fact, using smaller fonts is for image captions is referred to here. But either way works for me, at times it just helps with spacing.
I'm not sure if there's a MOS on it, perhaps this, but images spanning sections does not seem to be considered proper style. Your edit did break this in most browser window widths with the Mt. St. Helens image in Cascade Range#History. Is there a chance you can tweak it back to shape? Regards. 72.234.220.38 (talk) 04:40, 7 May 2016 (UTC)
- @72.234.220.38: Images spanning sections is OK. In fact, I was following the part of MOS:Images#Vertical placement that says "An image should generally be placed in the most relevant article section; if this is not possible, try not to place an image "too early" i.e. far ahead of the point in the text discussing what the image illustrates, if this will puzzle the reader." The paragraph about the Mt. St. Helens eruption is immediately to the right of the corresponding image. That image is as high as it can go without ahead of that paragraph (and without conflicting with the image of the Coquihalla River) —hike395 (talk) 04:55, 7 May 2016 (UTC)
- Okay, no biggie for me. You'll get some strong disagreement from other editors on this (I know from personal experience!). Sure, images should be kept close to the text discussing what the image illustrates, but it seems they say not if it will span a section, or also, "sandwich" text between images, or "stack" the images. I've done a little tweak that you're welcome to undo if you don't like. I've set the vertical size to "upright=0.65" which eliminates the issue until ones browser width gets to over about 1200px. 72.234.220.38 (talk) 05:32, 7 May 2016 (UTC)