User talk:Headbomb/Archives/2017/February
 | This page is an archive of past discussions. 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. |
Your graphics request.
If you are satisfied, please copy/paste the following code and add it to your request:
{{resolved|1=~~~~}} You can remove this notice at any time by removing the {{GL Illustration reply}} template.
Hey, CheChe here. I've tried to fix your problem over at the graphics lab. Let me know what you think. --♫CheChe♫ talk 22:30, 28 January 2017 (UTC)
- @CheCheDaWaff: Could you take a look at File:Bouncing_ball_compression_and_decompression.svg again? I uploaded a new version and I still have that alignment issue. Same for File:Impact with spin.svg (this one is new). Headbomb {talk / contribs / physics / books} 19:28, 1 February 2017 (UTC)
BAG News
| BAG News February 2017 | |
|---|---|
 Greetings Bot Approvals Group member!
Thank you! 17:52, 5 February 2017 (UTC) (You can unsubscribe from future BAG Spam by removing your name from this list.) | |
wp:hidebots
copied from arbcom casepage 47.222.203.135 (talk) 12:47, 6 February 2017 (UTC)
- I often find small robo-fixes annoying though that stops short of "disruptive". Their presence from that perspective is just another of the million annoying Wikipedia aspects that editors have to deal with. I'm sure some other editors have the same view. That's out of scope of the case per se, but it's part of the background that should be taken into consideration. 50.0.136.56 (talk) 23:42, 18 January 2017 (UTC)
- If these things annoy you, then I suggest hiding bots from your watchlist. Or if specific bots annoy you, see WP:HIDEBOTS. Headbomb {talk / contribs / physics / books} 13:49, 5 February 2017 (UTC)
Headbomb, anons are not permitted by the mediawiki software to utilize watchlists, which are a feature restricted only to username-wielding wikipedians. See also the comments by 50.0.136.56 about the WP:ABUSEFILTER which treats edits by anons as distinct from how edits by bluelinked wikipedians are treated. Pointing this out because #1) it annoys me when computationally proficient editors like yourself forget that not everybody has a watchlist <grin> and also #2) because as a computationally proficient editor you might be in a position to resolve the root cause of the difficulty someday, i.e. help implement watchlists/thanking/echo/userpages/etc/etc/etc for long-haul anons to utilize, rather than the current status quo assumption that only bluelinked wikipedians will have any use for such things. 47.222.203.135 (talk) 12:47, 6 February 2017 (UTC)
- Then they should register and not complain about features they choose not to use. While I'm 'technically proficient', I'm also not a mediawiki developer and have limited programming abilities, so there is literally nothing I can do about that.Headbomb {talk / contribs / physics / books} 13:06, 6 February 2017 (UTC)
- Sure, that would 'solve' the annoyance of bots-on-the-watchlist for the human behind user:whatever_fka_50.0.136.56 ... but of course, they were complaining about the *general* problem of bots-on-enWiki being annoying, in various ways. It is literally impossible for them to have been complaining about watchlist-spam, however, since as an anon they have no watchlist. They were complaining about, I presume, bot-caused article-history-spam, bot-related arbcom-drama (which from reading their commentary is the major peeve of 50.0.136.56), bot-caused edit-conflicts (my own pet peeve), or just the inevitable mistakes which bots generally make, being non-human automatons. That bots are essential, and a huge reason why enWiki is still a viable project, does not make bots free of annoyances; I get the vibe that 50.0.136.56 believes bots are essential to the continued success of wikipedia broadly construed, and therefore wants to minimize any collateral annoyance they cause in the enWiki community. Because, since enWiki cannot thrive without bots and botdevs, best find ways to co-exist contentedly with the bots (hence 'second law of bots' type lingo they proposed for the arbs).
- As for the other matter, I used the word 'implement' which made you think I was asking for a technical programmatic fix, code implemented by you personally. But actually I was talking about implement-in-the-wikipedia-political-sense. My understanding is that the only way anons can have echo-notify and watchlists and such, is if there is a bot approved, someday, which would provide such features. The main roadblock to such approval is sociological, not technological. It would be (relatively speaking compared to e.g. Yobot) fairly simple to write the bot that would convert echo-notification-to-anons and {{ping}}'ing of anons, into messages on their user-talkpages. The difficulty is in the political capital necessary to get such a bot approved: there is political opposition from the WMF and the mediawiki devs to such improvements, because despite their commitment to keeping anon-editing possible they don't seem to want it to be easy. But there is also enWiki-based sociological-slash-political opposition to such improvements, and as a trifecta personage (bot-operator / template-fu-master / semi-active-BAG-member), you actually do have a decidedly non-negligible chance of "implementing" such a change, in the sense of permitting such a change to occur, should somebody like myself or 50.0.136.56 ever get around to programmatically-implementing-the-bot-in-question. Hence my post here, about techies that don't see login-preferential-feature-implementation-strategy which the mediawiki devs seemingly pursue, *as* a kind of software bug, broadly construed. 47.222.203.135 (talk) 14:09, 9 February 2017 (UTC)
- Then they should register and not complain about features they choose not to use. While I'm 'technically proficient', I'm also not a mediawiki developer and have limited programming abilities, so there is literally nothing I can do about that.Headbomb {talk / contribs / physics / books} 13:06, 6 February 2017 (UTC)
- I have yet to see evidence of such opposition from either the WMF, devs, or the community. If you have ideas on what or how to improve the editing experience of IPs, I suggest making a post at WP:VPT. But you also have to realize that by refusing to create an account, you also agree to have more limited options for your preferences. You can't give IPs watchlist, because IPs can be shared by multiple people. You can't hide bot edits in the history, because IPs should have access to all the history just as everyone else does, etc. As for conflicts, they'll happen regardless of who's an IP and who's not. Most maintenance bots, however, have delays on editing to reduce the chance of such conflicts from happening though. Yobot in particular, operates on datadumps, so whatever it fixes is already several days, if not weeks old. Headbomb {talk / contribs / physics / books} 14:23, 9 February 2017 (UTC)
- Yes, by editing anon, that is me agreeing to live with the limitations thereof. I'm not complaining for myself, I don't mind the limitations, I'm complaining as a kind of class action whining for all anons ;-) And to be clear, I like Yobot just fine, I've never seen Yobot actually screw anything up, which cannot be said for other bots. And admins unblocking their own bots is NOT wheelwarring either, so long as they are not unblocking in anger :-)
- As for evidence, you are asking that I prove a negative, and show you how the WMF and the mediawiki devs have not implemented features with anons in mind, but rather, have tended to implement features that only work for those with usernames. There is no proof of intent, but there is surely a vast amount of circumstantial evidence.
- I have yet to see evidence of such opposition from either the WMF, devs, or the community. If you have ideas on what or how to improve the editing experience of IPs, I suggest making a post at WP:VPT. But you also have to realize that by refusing to create an account, you also agree to have more limited options for your preferences. You can't give IPs watchlist, because IPs can be shared by multiple people. You can't hide bot edits in the history, because IPs should have access to all the history just as everyone else does, etc. As for conflicts, they'll happen regardless of who's an IP and who's not. Most maintenance bots, however, have delays on editing to reduce the chance of such conflicts from happening though. Yobot in particular, operates on datadumps, so whatever it fixes is already several days, if not weeks old. Headbomb {talk / contribs / physics / books} 14:23, 9 February 2017 (UTC)
- WP:BENEFITS extols all the disadvantages to remaining an anon: for instance, anons are purposely restricted from the ability to use custom CSS (this is a purely sociological decision -- the system is 100% ready to support custom CSS -- all pages of the form User:$IP/monobook.cs are admin-page-prot because only registered usernames are trusted to alter their CSS). Anons cannot create their own bluelinked userpage, another sociological limitation. Anons can only provide their email, by registering for a wikipedia-username and then opting into the allow-other-wikipedians-to-email-me feature... or by posting their raw email straight into enWiki. I've seen a lot of people make that self-doxxing mistake, which is usually quickly revdel'd, of course, but the question is, why hasn't the technological limitation been solved? And the answer is, there is no evidence that the WMF does not wanna solve such things, but there is plenty of circumstantial evidence that they are NOT solving such things. Instead they are busy with WP:FLOW and WP:VISUALEDITOR and in-person edit-a-thons and the like. Some of the restrictions on anons *are* technological in nature, for instance, the mediawiki software is directly responsible for only registered username wikipedians being able to have user-perms such as the admin-bit. But there is a sociological aspect as well: anons cannot cast WP:NOTVOTEs at RfA, but must only leave comments in the special discussion-area, at the very bottom. I'm pointing these out to highlight that, yes, some of the restrictions are based in the mediawiki codebase, but the majority of them have some enWiki sociology aspect, and quite a few of them are purely sociological/psychological.
- I've tried under previous IP addresses various technological suggestions, though not the two you mentioned. "You can't give IPs watchlist, because IPs can be shared by multiple people." Sure, you cannot give anons the traditional old-school watchlist, but it is certainly technically plausible to give anons the equivalent functionality, for instance, by modifying the output of Template:Shared_IP so that it would accept an arglist of 'anon-watchlisted' articles and then display the corresponding watchlist-content directly *on* the anon's usertalk. Something like
{{Shared IP |nameOfRegistrar |host=rdnsHostname |watch1=Quark |watch2=List of baryons |watch3=1755 (band) |watch4=ADA collider }}for instance. This is obviously not a REAL watchlist, since it would only get updated on page-reload. That could be solved by AJAX gadgetry, if there was sociopolitical-capital necessary. Or it could be solved by modifying the behavior of core mediawiki code, too, obviously. I don't think implementing the additional args into the template (or a custom {{Anon Watchlist}} perhaps) is technologically difficult. It's just not a priority™ - As for re-implementing/re-imagining WP:HIDEBOTS in a way that anons could utilize, one option is to unlock the monobook.css and monobook.js portions of the userspace for anons that want such browser-magic. But this has the flaw that on shared IP addresses, one person might hide bot-edits for an entire high school's worth of potential editors. "You can't hide bot edits in the history, because IPs should have access to all the history just as everyone else does." So in this case, it makes more sense to alter the mediawiki implementation of the history-tab itself. There is already a button there, for instance, that allows anons to see that your usertalk has 182 watchers.[1] But there is no toggle-checkbox or radio-button, which would allow anons to click something that says "Hide Bot Edits" which would then alter the display of the history-tab, on-the-fly. This checkbox could be 'permanent' with a browser cookie, but would be almost as useful even if it required manually clicking/tapping the checkbox each time one wanted a botspam-free history-tab. For an ad hoc example, your usertalk history currently displays 50 recent edits which consist of 22 edits made yourself (Headbomb), 16 edits made by eight other distinct wikipedian humans, and 12 bot-edits (all of them with some regex-friendly string in the edit-summary...
^Bot:
/^Archiving.*(bot)$
/^Signing comment by
...and all of them with bot-usernames obviously). Hitting the hypothetical toggle-button would reduce the linecount from 50 visible entries, by roughly 25% which is 'statistically significant' at least for this uno-sample. Definitely would be tricksy to get this idea *perfect* since regex is inherently imperfect, but it would be a reasonable feature to implement. Checkboxes that are off by default, are inherently opt-in. And might be appreciated by more than just anons ;-)
- In any case, I'm happy to chat further about VPT-type stuff, here or there or whatever location that you like, but my main point was merely to say, WP:HIDEBOTS was not going to solve the annoyances, which 50.0.36.135 was specifically handwaving about. It also doesn't solve the arbcom case, either, of course... but as a side note I do appreciate you trying to step in and work something out with the participants there, even though I don't necessarily agree with all your proposals thereon 47.222.203.135 (talk) 16:35, 9 February 2017 (UTC)
- Two things. I'm not asking you to prove a negative, you assert that the community is idealogically opposed to IPs having a good editing experience. If you can't show evidence of that, then I wonder what you base your claim on. And going from your example, e.g. the restriction on CSS has nothing to do with a 'sociological' desire to leave IPs hanging, but because there is no mechanism by which to store such custom CSS for IPs. IPs are, of course, free to developed their own browser scripts to implement their own custom CSS tweaks. If that's your evidence that the WMF or devs, don't do enough for IPs, I have to say I remain unconvinced this is there case.
- For the cookie-based 'hide bot' feature, I've never heard that being proposed, so my advice is start a thread at WP:VPT with general concept on how to customize the edit history, with a list of desired customization features. I suspect most people would support giving the option (because why the hell not?), but it would also come down to a matter of coding priorities. How many people would really make use of such a feature vs all the other features people are asking for out there? Devs might not get assigned to that, but since MediaWiki is open access, everyone can write code for it, so you might find someone interesting in coding such a thing). Headbomb {talk / contribs / physics / books} 16:52, 9 February 2017 (UTC)
- "it would also come down to a matter of coding priorities" <== This is what I'm griping about, exactly. I don't assert that wmf / mediawikiDevs / templateDevs / enWikiCommunityBroadlyConstrued / activeWikipedians *are* ideologically opposed to improving the editing-experience for anons. Quite the reverse actually, all those groups are, on balance and eliding rare & radical "only registered people should edit because spam/coi/vandals/reputation/whatever" type opinions, are ideologically in favor of anons being able to edit, and the anon-editing-experience being made as good as time and resources permit. But that's the kicker: in my long observation, time and resources NEVAH actually permit significant tangible improvements, and thus gradual decline of anon-editing-experience because of benign neglect, is the typical end-result :-)
- Counterexample disproves my good-intentions-which-never-get-acted-upon hypothesis, of course: I will write up a proposal for the dynamic-checkbox-to-hide-bots-in-history-tab thing, and propose it at WP:VPT, with cookie-backed and non-cookie-backed variants. Is it okay if I run the rough draft by you first, before I enter the den of the lions? ;-) if you are busy elsewhere, no worries, but if not, I will post dyna-hidebots to userspace first and ping you, before sending a finalized version to the pump-watchers for critique 47.222.203.135 (talk) 12:20, 10 February 2017 (UTC)
DYK nomination of Bouncing ball
Hello! Your submission of Bouncing ball 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) underneath your nomination's entry and respond there as soon as possible. Thank you for contributing to Did You Know! Andrew D. (talk) 13:10, 10 February 2017 (UTC)
Replied there. Headbomb {talk / contribs / physics / books} 13:27, 10 February 2017 (UTC)
You can remove comments with swearwords from a vandal?
This vandal *Idk idk idk because idk (talk · contribs · deleted contribs · nuke contribs · logs · filter log · block user · block log) made edits commented with aggresive language with swearwords on Roy Conli and Byron Howard; He it's blocked but he made edits with aggressive language, leaving commented editions with swearwords. I would be thankful if someone can remove those comments from his edits. You can look at his contributions, if you don't mind. (Idk idk idk because idk) Thanks. 79.152.75.100 (talk) 02:19, 13 February 2017 (UTC)
- Thank you. 79.152.75.100 (talk) 02:21, 13 February 2017 (UTC)
- The problem has been solved. The vandal comments have just been erased, thank you. 79.152.75.100 (talk) 02:35, 13 February 2017 (UTC)
- Also, If you don't mind. You can remove these agressive comments with swearwords from the contributions of this another vandal? Look at his contributions. (Soooonnn oooffff aaaa bbbiiitttccchhh mmootheerffuucckeerr) Thanks. 2.136.128.142 (talk) 02:52, 13 February 2017 (UTC)
Hello, Headbomb. I'm leaving you this message because you have been essentially curating this RfC and the process involved. I earlier closed the design discussion RfC, and was attempting to assess the consensus at this one and close it. It has been open waaay too long, as I'm sure you'll agree. I see varying levels of consensus on the sub-sections, (e.g., B3 is very clear, B1 and B4 less so, and B2 borderline), but an honest opinion would lead me to close this as "no consensus" for the entire proposal. There is a significant body of opinion expressed that the entire visual status indicator idea is not acceptable. I think the only honest way forward is to close this with a tentative indication of how the processing would work and then re-run a new RfC to see if there is significant buy-in to proceed forward. Before I did that, however, I wanted to let you know what I thought and see if you had objections to, in one sense, starting over at, not exactly square one, but maybe square 5. Thanks. Eggishorn (talk) (contrib) 23:33, 9 February 2017 (UTC)
- Eggishorn (talk · contribs) Thanks for consulting with me! It certainly wasn't required. As for my opinion, personally, consensus to me seems that B1) All locks should be allowed, but not mandated everywhere. This lets people choose the convention they want in their article, since there is no consensus that the existing convention (flag only non-free for the url, flag only non-subscription for identifiers) is clear, nor that flagging everything is desired. This also lets us get rid of additional side templates like {{closed access}} that are offend appended to citations templates because there was no way to indicate a url was non-free. B2) By implication, regardless of the !votes, we shouldn't flag by flag non-free identifiers by default, because if some are flagged by default then this de facto mandates locks on the rest of the identifiers for consistency. B3) is a clear deprecate. B4) Is a consensus for autolinking titles, but the exact implementation matters and shouldn't be rolled out carelessly. Trappist has some technical objections, but those can actually easily be addressed. Likewise for Ocaasi, who believes "we [don't] yet live in a world where we can reliably autolink the title." This would definitely be true if we were proposing to autolink the title based on the presence of a free pre-print (e.g.), but what is actually proposed is linking the title when free official versions are available, to match the existing behaviour. There are a few other "don't autolink" votes, but some of those don't even seem to understand what is even meant with autolinking (e.g. "never autolink title; always autolink pmc parameter" based mostly on the fact that the PMID isn't shown in the example).
- Now this aligns with my !votes as far as what I think should be done with the template, but I don't want this to be construed as me trying to impose my will on the community. For instance I personally think it's not necessary or desirable to flag non-free identifiers, but I can't say there is consensus for that option, so I voted for the option that I felt was best for the community.
- Let me know what you think. Headbomb {talk / contribs / physics / books} 01:16, 10 February 2017 (UTC)
- Headbomb, thanks for your input. I generally agree with your assessment on the subsections, but my close is (of necessity) more conservative. I also think the larger forest-vs-trees aspect of the discussion needs to be addressed, and I can only honestly say that the overall proposal does not yet have consensus based on what I've seen there. This is what I've written in the close. I personally believe that the RfC was too confusing for many editors, and building on the partial consensus to re-visit the issue can provide further clarity. I hope this helps. Eggishorn (talk) (contrib) 02:46, 10 February 2017 (UTC)
- Let me know what you think. Headbomb {talk / contribs / physics / books} 01:16, 10 February 2017 (UTC)
"B1) All locks should be allowed"... this will be helpful to me with some kinds of articles. In particular I'd like to see |archive-url-access= which is distinct from |url-access= for cases where the original URL is a paywall and the archive is not, or vice versa. Is there some specific template_talk page where I should make the request, for the new parameter |archive-url-access= and the associated lock-indicator-magic? 47.222.203.135 (talk) 13:20, 10 February 2017 (UTC)
ZAMP
Dear Headbomb, how are you? From this edit I understand that AWB suggests to use a capital for "angewandte" in "Zeitschrift für angewandte Mathematik und Physik". However the publisher's website uses lowercase. I don't care much either way, but is this a bug in AWB? Best regards, Crowsnest (talk) 18:11, 16 February 2017 (UTC)
- I was just standardizing ZAMP usage accross Wikipedia. See Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Z2, and our article, located at Zeitschrift für Angewandte Mathematik und Physik. It's not an AWB issue, so if it should be lowercased, then it's just as easy to standardize on the lowercase version. Headbomb {talk / contribs / physics / books} 18:14, 16 February 2017 (UTC)
Washington Monument
I reverted your edits in Washington Monument wherein you changed hyphens to n-dashes in several pages (but ignored others). You apparently did not read the HTML comment immediately following each: "hyphenated page is one page, not a range, because book uses page within chapter numbering". Please be more observant in the future. I wonder whether {{cbignore}} would be useful here as it apparently is after three non-dead links in this article, if you used some bot to identify these pages. — Joe Kress (talk) 18:29, 17 February 2017 (UTC)
- Strange, I remember seeing that comment and skipping that page. Must have been a misclick. However, a better tactic than {{cbignore}} will probably to put the comment next to the hyphen, rather than outside the template. This should prevent AWB from even trying to 'fix' what isn't broken. Headbomb {talk / contribs / physics / books} 20:53, 17 February 2017 (UTC)
Edits altering citations
Why are you removing accessdate parameters, such as at [2]? Unscintillating (talk) 16:05, 18 February 2017 (UTC)
- Because those are unneeded and populate Category:Pages using citations with accessdate and no URL? Headbomb {talk / contribs / physics / books} 16:06, 18 February 2017 (UTC)
- If the problem is that they are populating a category that you don't want populated, that doesn't define that they are not needed. Is there discussion somewhere to support your decision to remove information? Unscintillating (talk) 16:53, 18 February 2017 (UTC)
- Here, [3], is the URL for Wikipedia:Articles for deletion/Port Place Shopping Centre. Unscintillating (talk) 17:11, 18 February 2017 (UTC)
See User_talk:CitationCleanerBot#Accessdates for the long explanation. Headbomb {talk / contribs / physics / books} 17:19, 18 February 2017 (UTC)
- Here, [4], is the URL for Wikipedia:Articles for deletion/Columbia Mall (Missouri). Unscintillating (talk) 17:22, 18 February 2017 (UTC)
- I'm not really sure why you're telling me this, tbh. It'd be much more productive to add it to the citations given. Headbomb {talk / contribs / physics / books} 17:29, 18 February 2017 (UTC)
- "tbh"? I don't know what that means.
It appears that you are removing the accessdate arguing that the URL is missing, without attempting to obtain the URL. Is that correct?
As for the alternative that you propose, every once in a while, editors have dumped on me for editing closed discussions, so maybe you can do the edits for the closed discussions. Thanks, Unscintillating (talk) 18:08, 18 February 2017 (UTC)
- "tbh"? I don't know what that means.
- I'm not really sure why you're telling me this, tbh. It'd be much more productive to add it to the citations given. Headbomb {talk / contribs / physics / books} 17:29, 18 February 2017 (UTC)
- Here, [5], is the paywall for Wikipedia:Articles for deletion/Sumter Mall (2nd nomination) and Wikipedia:Deletion review/Log/2014 May 19. Since you need a URL, this seems to address the problem. Unscintillating (talk) 18:08, 18 February 2017 (UTC)
- TBH = To be honest. I've put the urls in place for those above, but if you're doing that, it's really simpler to just fix those yourself than come here with the fix without doing it. Headbomb {talk / contribs / physics / books} 18:11, 18 February 2017 (UTC)
- Thanks for updating those pages. Unscintillating (talk) 20:22, 18 February 2017 (UTC)
see above section in regards to journals, thank you--Ozzie10aaaa (talk) 20:19, 19 February 2017 (UTC)
Folic acid
I undid your revision on folic acid as I felt you removed a peer reviewed article without adequate explanation. I also included a more updated meta analysis to give a more balanced reflection of current opinion.
I also mischaracterized one of the articles as a meta-analysis in my edit summaries, though it is still secondary research (non-statistical). The newer reference from 1/17 is a bonefied meta-analysis. Ies (talk) 17:06, 20 February 2017 (UTC)
fission products
Thanks for the changes to the fission products table. I generated these from the IAEA HTML tables using a program, and could have done some of them at that time. I should remember this if the source tables ever change. Gah4 (talk) 22:57, 20 February 2017 (UTC)
- Gah4 (talk · contribs) no problem. Which article would that be (I cleaned up so many I don't remember which it was)? Headbomb {talk / contribs / physics / books} 23:15, 20 February 2017 (UTC)
- I noticed Fission product yield and Activation product, both of which were done about the same way. I converted them from HTML tables, some of which where stored column by column, to Wikitables. I did change some of the cell contents, but mostly not if it worked, and if I didn't know a better way. I think I knew that there was a ±, but didn't know if it was better than ± or not. Also, I didn't know about −, but again, left it as in the original. I did ask IAEA to be sure that there wasn't any problem putting the table in. Thanks, Gah4 (talk) 00:05, 21 February 2017 (UTC)
AWB edits: ellipses
Hi there. I noticed that you partially reverted this edit after committing it and ended up only fixing the typo in the contraction "i.e.,". Your edit to the journal title in that revision was appropriate, so it needn't have been reverted. However, the reason I'm posting this section pertains more to the automated edits that you made to the quoted clauses that contained an ellipsis in that revision. Ellipses should be preceded by a nonbreaking space (this would appear as ... in the source) per MOS:ELLIPSIS; so, it might be helpful to program AWB to replace the text string " ..." (i.e., a regular space followed by an ellipsis) with " ..." (i.e., a non-breaking space followed by an ellipsis) when editing pages with AWB in the future. Regards, Seppi333 (Insert 2¢) 01:21, 21 February 2017 (UTC)
- The point of my fix that was to catch instances of badly abbreviated journals like "J . Appl. Sci .". I just so happened to also match spaced ellipsis, so I reverted my edit since I had clicked "save" by accident. If you have ideas for general AWB improvements, there's a place to suggest them at WP:AWB. This way, they'll get deployed to every AWB user, and not just me.Headbomb {talk / contribs / physics / books} 01:27, 21 February 2017 (UTC)
Thanks for passing for GA. Should there be a green icon on the article itself? Apparently something went awry. Can you correct? Thanks!! --Doug Coldwell (talk) 13:07, 21 February 2017 (UTC)
A beer for you!
|
You made my day with your edits. :) Magioladitis (talk) 15:18, 24 February 2017 (UTC) |
Help with orphan article
Hi-
Thanks for your prior edits to my article: https://en.wikipedia.org/wiki/Blossom_Damania
Can you help de-orphan this article? I am not quite sure how to do this.
Appreciate your help! — Preceding unsigned comment added by Vwxy1234 (talk • contribs) 02:32, 26 February 2017 (UTC)