Wikipedia talk:Twinkle/Archive 21

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 15 Archive 19 Archive 20 Archive 21 Archive 22 Archive 23 Archive 25

Minor change to {{uw-username}} template

Hi all,
I've boldly made a little change to the {{uw-username}} after as a result of this Village pump discussion. The relevant Village pump archive the discussion will be included in is Wikipedia:Village pump (policy)/Archive 83. This may perhaps affect Twinkle template messages. Your thoughts?
--Shirt58 (talk) 11:56, 1 January 2011 (UTC)

Template:Uw-mos3 has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. :| TelCoNaSpVe :| 02:47, 3 January 2011 (UTC)

Automated edits

I've been assuming that all Twinkle edits count as automated, but I've also heard the theory that the tagging of an article counts as a manual edit and the informing of an author as automated. Can anyone confirm which way this works? ϢereSpielChequers 02:09, 6 January 2011 (UTC)

The process is automated, but the initiation is manual, and users can choose whether or not to send the notification. All Twinkle users are, however, responsible for every edit they make when using Twinkle. SchuminWeb (Talk) 04:27, 6 January 2011 (UTC)
I have no idea whatsoever how that automated edit counter works; you need to check with X! (talk · contribs), I think. T. Canens (talk) 04:55, 6 January 2011 (UTC)

I was wondering if it could be changed so that if {{refimproveBLP}} is added, then {{unreferencedBLP}} is automatically removed (and vice versa)? There will never be a case when both of these templates need to be on an article simultaneously. Mhiji 23:48, 6 January 2011 (UTC)

And similarly could the same be done for {{refimprove}} and {{unreferenced}} too please. Mhiji 20:40, 9 January 2011 (UTC)

Is a sanity check possible?

A few days ago, I moved a page out of userspace. Five minutes later, someone using Twinkle tagged the article as being uncategorized.

Problem: The cats were present, just commented out. (If you have active cats in userspace, then people fuss at you, and I was in the process of creating the planned series of redirects [another thing people fuss about if you do it early], and just hadn't gotten to un-commenting the cats yet.)

The editor says that tagging it rather than fixing it can't possibly be his fault, because Twinkle doesn't show the codes on the page, so he was incapable of discovering that they just needed to be un-commented.

Question: Can Twinkle actually do a sanity check for these things? Is it, e.g., possible to have Twinkle search the page for the string [[Category: and produce an error message if the string is present? WhatamIdoing (talk) 00:01, 7 January 2011 (UTC)

Is this a big enough issue to dedicate programming time for installing this kind of a check? Admittedly, the person probably should have looked before they tagged, but is this a big enough problem to program this in? SchuminWeb (Talk) 02:51, 7 January 2011 (UTC)
I don't know what the scale of the problem is. I assume that the code would be generalizable, e.g., to prevent someone from adding welcome templates to user pages that already contain it, or {{unref}} to pages that contain <ref> tags, so it might have utility beyond the instant case. WhatamIdoing (talk) 04:59, 7 January 2011 (UTC)
You just lost my support on that one. I have worked to have certain alleged "sanity checks" like that removed because there are legitimate reasons for placing tags in places where, by a strict interpretation, they otherwise ought not be. For instance, the unreferenced tag would still correctly go on a page where the only use of the ref tag is for an explanation rather than an actual reference. Likewise, I had the restriction on dropping a welcome tag on one's own userpage removed after I found that it was useful to allow it for test purposes. And for multiple welcome tags, that often happens with IP users, where you will have an IP that many people use. You have a lot of vandals, and then that one shining good user on them, and we want to call that good user out (and encourage them to register a username). Thus it could easily be warning, warning, warning, welcome, warning, warning, welcome, etc.
So in short: Nix on that, I believe. SchuminWeb (Talk) 01:40, 8 January 2011 (UTC)
I don't think it's reasonable to expect a user to check for commented out cats each time. Of course I do think it is lame to tag something as uncaegorized when it takes just as much time to just add the category yourself, but that's another story. I would suggest in future un-commenting the cats as your last edit before moving the page, that won't give anyone enough time to nitpick about it. Beeblebrox (talk) 06:25, 12 January 2011 (UTC)
I dunno, Schumin: I think that a script that says, "Are you sure about that, because this page seems to contain (whatever the string is)?" is preferable to one that makes edits blindly.
In the cat example, we're actually talking about an edit that the user would never have made, except that the script's interface prevents him from seeing what was already there. If he'd been editing manually, he would have opened the page and immediately seen the cats. The current interface for the script does not provide him with the opportunity to notice things like this. Why should the editor using Twinkle be stuck with less information? WhatamIdoing (talk) 00:59, 13 January 2011 (UTC)

Automatic warnings for vandalism?

I recently started using Twinkle. Prior to that I had used Huggle, but Twinkle is nice in cases where I want to revert vandalism with a better edit summary without having to launch a standalone application. However, Huggle virtually always automatically warns the vandal via their talk page, incrementing the warning level as necessary. When I rollback a vandal edit with Twinkle, it says something about loading talk page for the user, but I never see a warning left for them. Are there special circumstances for automatic warning, an option I don't have enabled, or is something not working? I am using Google Chrome. Thanks. –CWenger (talk) 21:05, 9 January 2011 (UTC)

When Twinkle opens the talk page of the editor you have reverted, you have to choose the level and the nature of the warning yourself from the TW box in the upper right corner. --Saddhiyama (talk) 21:52, 9 January 2011 (UTC)
I thought it might be trying to open the user's talk page so I could add the warning, but it never happens. It just stays on the page that tells you what it did. No new tabs or browsers opened. –CWenger (talk) 22:10, 9 January 2011 (UTC)
You probably are running a pop-up blocker. Twinkle opens the user's talk page in a pop-up window so if you have them blocked that function does not work. Beeblebrox (talk) 06:20, 12 January 2011 (UTC)
Ah, you're right. Google Chrome blocks pop-ups by default. Thanks. –CWenger (talk) 16:00, 12 January 2011 (UTC)

Issuing warnings/notices to other users

As we know twinkle has a range of warning/notices that can be issued to a user but only one article can be added to the Linked article box where the user has been disruptive or has done something wrong. Is there any way in which we could add more than one article in the Linked article box? This would be helpful when a user has repeated the same over multiple articles. Thanks, —Abhishek191288 (talk) 04:44, 12 January 2011 (UTC)

Right now, Twinkle can't do that because the underlying templates only support a single article title as a parameter. Change the templates to support more article titles listed at once, and then we might be able to modify Twinkle to function with it. See Wikipedia talk:Template messages/User talk namespace to discuss the template changes.
However, Twinkle does have a text box beneath the warning. It is free-form, and anything that goes into that box gets tacked onto the end of the warning. So you might want to include the extra articles in there. SchuminWeb (Talk) 06:07, 12 January 2011 (UTC)


Well thanks. But I am aware of the text box and if I use the same the message would appear like this:
  • Welcome to Wikipedia. Although everyone is welcome to contribute to Wikipedia, at least one of your recent edits, such as the one you made to Bangalore, did not appear to be constructive and has been reverted or removed. Please use the sandbox for any test edits you would like to make, and read the welcome page to learn more about contributing constructively to this encyclopedia. Thank you. You have also made similar changes to Mysore and Mangalore articles. Please do not repeat the same.
But it would really look better if the message looked something like this:
  • Welcome to Wikipedia. Although everyone is welcome to contribute to Wikipedia, at least one of your recent edits, such as the one you made to Bangalore, Mysore and Mangalore did not appear to be constructive and has been reverted or removed. Please use the sandbox for any test edits you would like to make, and read the welcome page to learn more about contributing constructively to this encyclopedia. Thank you.
A message somewhat like the above would be better and there should be a facility to include multiple articles (maybe limited to a specific number) in the link box probably being able to separate one article from another by use of a special character ( ; or , for eg). The text box should be for solely adding any additional information to the user who is being given a warning/issue. Abhishek191288 (talk) 17:27, 14 January 2011 (UTC)

While I'm here

...Any chance we could have {{anonblock}} and {{schoolblock}} back in the block options, please? HJ Mitchell | Penny for your thoughts? 17:17, 14 January 2011 (UTC)

Update

There are many template that need {{Twinkle standard installation}} and the interface also needs to be updated to use the current template names. – Allen4names 19:57, 12 January 2011 (UTC)

Anyone can add the {{Twinkle standard installation}} tag to a template page. Feel free. Otherwise, as far as names, which ones need their names updated? SchuminWeb (Talk) 21:14, 12 January 2011 (UTC)
I am working on getting a list ready. – Allen4names in domus 97.115.143.23 (talk) 23:01, 12 January 2011 (UTC)
I have a preliminary list ready.
User:Ioeth/friendlyshared.js
Template:sharedip - Redirect to Template:Shared IP
Template:sharedipedu - Redirect to Template:Shared IP edu
Template:sharedippublic - Redirect to Template:Shared IP address (public)
Template:sharedipusmilitary - Redirect to Template:Shared IP gov
Template:dynamicip - Redirect to Template:DynamicIP
Template:isp - Redirect to Template:ISP
Template:mobileip - Redirect to Template:MobileIP
User:Ioeth/friendlytag.js
Template:catimprove - Redirect to Template:Cat improve
Template:copyedit - Redirect to Template:Copy edit
Template:deadend - Redirect to Template:Dead end
Template:expand - TFD
Template:expert - Redirect to Template:Expert-subject
Template:fansite - Redirect to Template:Fanpov
Template:morefootnotes - Redirect to Template:More footnotes
Template:nofootnotes - Redirect to Template:No footnotes
Template:notenglish - Redirect to Template:Not English
Template:pov-check - Redirect to Template:POV-check
Template:tone - Redirect to Template:Inappropriate tone
Template:verylong - Redirect to Template:Very long
Template:close paraphrase - Redirect to Template:Close paraphrasing
Template:coi - Redirect to Template:COI
Template:Globalize/China
Template:Globalize/India
Template:globalize/Luxembourg
Template:Globalize/Middle East
Template:Globalize/Pakistan
Template:globalize/Russia
Template:Globalize/South Africa
Template:Globalize/West
Template:npov - Redirect to Template:POV
Template:primarysources - Redirect to Template:Primary sources
Template:refimproveBLP - Redirect to Template:BLP sources
Template:toofewopinions - Redirect to Template:Too few opinions
Template:unencyclopedic - Redirect to Template:NOT
Template:unreferencedBLP - Redirect to Template:BLP unsourced
Template:goceinuse - Redirect to Template:GOCEinuse
Template:inuse - Redirect to Template:In use
Template:underconstruction - Redirect to Template:Under construction
Template:R from full name - Redirect to Template:R from long name
User:Ioeth/friendlywelcome.js
Template:Welcom - Redirect from Template:WelCom to Template:User WelCom, this is a userbox
Template:Firstarticle - Redirect to Template:First article
I would like you to consider if links to redirects should be avoided to prevent unnecessary bot edits. In the mean time I will be adding {{Twinkle standard installation}} to some of the templates that need it. – Allen4names 02:00, 13 January 2011 (UTC)

I believe there might have been a technical limitation as to why we used non-spaced versions of the ones that have spaces. Someone more fluent in Javascript than myself would be able to answer this question more definitively. Otherwise, I can fix the ones that are outright name changes without spaces. SchuminWeb (Talk) 02:05, 13 January 2011 (UTC)

I have added to the list. There may be more problems but I expect to be busy for awhile. Text that is in quotes should be able to contain spaces but it would be best to consult someone with more experience. – Allen4names 17:13, 13 January 2011 (UTC)
I am not going to do anything about the sub-templates of Template:Globalize as I think I have a better idea (see Template talk:Twinkle standard installation) but if you think that they should have {{Twinkle standard installation}} added to them feel free to do so. Other than that I think that all the templates that need {{Twinkle standard installation}} have them but if I missed any please finish the job or at least let me know on my talk page. – Allen4names 20:55, 15 January 2011 (UTC)

Merger update?

Any updates on the progress of merging Friendly and Twinkle? Seems like we are getting nowhere. — Train2104 (talk • contribs • count) 15:38, 15 January 2011 (UTC)

Template:Expand

FYI, Template:Expand, which is listed on Twinkle's "tag" menu, recently went through a TFD discussion, the end result of which was to delete the template. Removing the template from the menu is beyond my competence level, or else I'd do it. But it does unfortunately need to go... SchuminWeb (Talk) 03:39, 27 December 2010 (UTC)

Agree {{Expand}} is officially being deleted, so it should be removed from the list. Logan Talk Contributions 02:03, 5 January 2011 (UTC)
Gone. Amalthea 18:31, 16 January 2011 (UTC)

Trivia

Okay, I'll admit the wording of the blocking page is trivial in the larger scheme of things, but you could get 15 years to meditate on it in Thailand. --Pawyilee (talk) 07:15, 20 January 2011 (UTC)

Got no "tag" tab

Help, I'm lost! I've been using Twinkle for years, and it's great as far as it goes. But lately I've seen other people adding things like cleanup tags to articles with Twinkle. I don't see a tab for that! I'm using Chrome (currently; sometimes I also use Firefox) on Ubuntu 64-bit, with the old Monobook skin. On an article page I see the following tabs:

  • article
  • discussion
  • edit this page
  • history
  • auto ed (yes, I added that script too, after Twinkle in my Monobook.js)
  • move
  • unwatch
  • csd
  • last
  • rpp
  • prod
  • xfd
  • unlink

I do not see a "tag" tab! I tried replacing my old Twinkle configuration with the currently posted one...and all the Twinkle tabs went away! It turned out I needed to add the following line:

if( typeof( FriendlyConfig ) == 'undefined' ) FriendlyConfig = {}; // DO NOT REMOVE THIS LINE - ALL TWINKLE SETTINGS AFTER THIS

That made the regular tabs come back, but I still don't have "tag". Where is it?! -- Ken_g6 (factors | composites) 23:00, 21 January 2011 (UTC)

The merge of Twinkle and Friendly may not be complete yet so keep Friendly enabled in your preferences. – Allen4names 01:48, 22 January 2011 (UTC)
Thanks for the idea. But...
  • I tried adding importScript('User:Ioeth/friendlytag.js');. No tag tab.
  • I tried just importScript('User:AzaToth/morebits.js');importScript('User:Ioeth/friendlytag.js');. That made a tag tab. But I didn't include Twinkle, so there were no Twinkle tabs.
  • I tried them all together: importScript('User:AzaToth/twinkle.js');importScript('User:AzaToth/morebits.js');importScript('User:Ioeth/friendlytag.js');. Twinkle came back, but the tag tab disappeared again.
Any more ideas? -- Ken_g6 (factors | composites) 04:20, 22 January 2011 (UTC)
On second look, it looks like this last version works in Firefox, and seems to be starting to work in Chrome. Maybe this was that Chrome intermittent display bug. Thanks! -- Ken_g6 (factors | composites) 04:41, 22 January 2011 (UTC)

pending changes?

For all intents and purposes pending changes appears to be here to stay. Twinkle doesn't support it as an option when protecting, any chance of getting it added? I like the way it adds the tags and everything for you when you use it (like I have to explain why Twinkle is awesome). On a related note, I can't actually find any templates for PC, anyone know if they even exist? Beeblebrox (talk) 23:48, 25 January 2011 (UTC)

Re template: We had a protection template at the start of the trial, but it was quickly found superfluous and deleted. The TfD was at Wikipedia:Templates for discussion/Log/2010 July 27#Template:Pp-pending, the larger discussion that prompted it was at one of the PC trial pages, but I don't remember which one.
Regarding the protection tool: Patches are welcome. :) I'll even carve another barnstar.
Cheers, Amalthea 00:09, 26 January 2011 (UTC)
Reading that discussion I suppose it is a bit superfluous to have a template. I'd happily add the "patch" if I had the slightest idea how to do that or even knew what it meant. I just drive this thing, I don't know what goes on under the hood. Beeblebrox (talk) 00:13, 26 January 2011 (UTC)
Yeah, that was more a general call. :) Amalthea 00:21, 26 January 2011 (UTC)

TW revert in diff view?

The three revert options normally available in diff view (AGF, rollback, vandalism) have disappeared, they still appear for me in contribution lists, but don't appear to be working properly. Is anyone else experiencing this, or have an explanation/suggestion; before I report it as a bug? Pol430 talk to me 17:10, 12 January 2011 (UTC)

They still show up for me. I notice sometimes they seem to be gone but a refresh puts them back. –CWenger (talk) 19:33, 12 January 2011 (UTC)
I have the same problem - bypassing my cache doesn't fix it. – ukexpat (talk) 02:12, 13 January 2011 (UTC)
I'm seeing it all, and it also never disappeared for me. You may wish to look at my vector file and check yours against mine. SchuminWeb (Talk) 15:39, 13 January 2011 (UTC)
  • Hmmm, a refresh seems to fix the problem sometimes but not always, bypassing the cache seems to make no difference either. I have enabled Twinkle and Friendly via gadgets and I use monobook rather than vector. Pol430 talk to me 17:53, 13 January 2011 (UTC)
There seems to be a conflict between the revisionjumper gadget and Twinkle, at least in my case when installing Twinkle in monobook.js. Disabling revisionjumper fixed the problem. – ukexpat (talk) 15:56, 19 January 2011 (UTC)
Spot on! that has fixed the problem :) Pol430 talk to me 22:03, 21 January 2011 (UTC)
I just came over here to see about this. That works for me also. Now to figure out why saving adds a blank line to my edits (not Tw related I'm pretty sure) Dougweller (talk) 15:53, 26 January 2011 (UTC)
When you say a blank line, do you mean an extra line of whitespace to the page? If so, I don't believe I'm experiencing that problem, could be another gadget conflict though (maybe) Pol430 talk to me 19:22, 26 January 2011 (UTC)

Template:Recent death

As a courtesy, this is notice of Wikipedia:Templates for discussion/Log/2011 January 28#Template:Recent death -- Mattinbgn (talk) 03:36, 28 January 2011 (UTC)

RfPP

I've repeatedly seen protection requests made via Twinkle displace the header as the top of the section, most recently just a few minutes ago [1]. Can this be fixed? It seems to have only been a problem fairly recently. HJ Mitchell | Penny for your thoughts? 17:13, 14 January 2011 (UTC)

Can't reproduce this here, I'm assuming that it might only happen on certain platforms. Will try to find out more. Amalthea 17:56, 14 January 2011 (UTC)
Another diff if it helps. HJ Mitchell | Penny for your thoughts? 20:25, 17 January 2011 (UTC)
and another. HJ Mitchell | Penny for your thoughts? 01:54, 23 January 2011 (UTC)
And three minutes later! HJ Mitchell | Penny for your thoughts? 01:56, 23 January 2011 (UTC)
Poke. HJ Mitchell | Penny for your thoughts? 01:19, 28 January 2011 (UTC)
Hopefully fixed now. Give it a grace period of one or two days so that we can be reasonably confident that most browsers have loaded the updated script, but if you notice it again after that please reopen WP:TW/BUGS#419.
Cheers, Amalthea 22:30, 8 February 2011 (UTC)

Red links?

I'm sure I'm doing something obviously wrong, but when I try to tag articles for deletion using twinkle (such as this one or this one) the link to the articles deletion page always comes up red, but clicking it still brings you there. Does anyone know what I did wrong, and how I could fix this? Thanks so much!--Yaksar (let's chat) 00:10, 30 January 2011 (UTC)

I don't believe you did anything wrong, because I've seen it happen to me before as well. Someone has explained in the past what causes that to happen, but I don't recall offhand what that explanation was. I just ignore it, since clicking it does what it's supposed to do, even if the link is the wrong color. SchuminWeb (Talk) 02:55, 30 January 2011 (UTC)
You can try purging the page. Purge this page or copy the link and replace the title value. – Allen4names 01:45, 31 January 2011 (UTC)

Shoving together warning templates

Is there a way to group similar warning templates together? If a contributor uploads 5 images and doesn't get the license in the right spot and doesn't provide a source, they could get 10 long warning templates within a few minutes. Is there a way to check whether a logged in user has been to the talk page (like with the yellow "You have new messages" bar) and group all the new messages together? I've just seen some talk pages that could only be described as abominably bitey and it's Twinkle that's doing that biting and I'm trying to figure out if there's a way to do anything about it. --Danger (talk) 02:57, 9 February 2011 (UTC)

I think there's another consideration here, and it's before we even get to automated processes. Many processes, a lot of them related to files, not only require that we notify the participants, but also specify exactly what template we are to use and how to use it. Twinkle can be configured to do just about anything you want it to do, but we're only following the guidelines that the system operates under, and Twinkle is following all the steps. I personally think that the notifications are a colossal pain to do manually, and if I'm required to leave them, I'm glad that Twinkle will do that step for me.
So basically, what I'm recommending is this: Change the rules that we have to operate under first, and then Twinkle will follow suit. SchuminWeb (Talk) 18:56, 9 February 2011 (UTC)
I mean, you have to notify and I see no problem with that, but there's no requirement for a separate wall of text for each file, is there? To be clearer about my initial request, when several templates are added in quick succession, is it possible to amend them to say, "File X, File Y and File Z do not have source tags, please add them." rather than having three separate sections, each with the accompanying and now redundant text? --Danger (talk) 20:38, 9 February 2011 (UTC)
What you're suggesting makes sense, however, from a technical standpoint, I'm not sure how you would accomplish that. One concern I would bring is that I wouldn't want Twinkle, a semi-automated script, to edit existing sections of text. Too much of a chance that it would mess something up. As a new block of text, the only thing I could think of would be to allow users to make a queue of file tagging requests and then fire them all at once, but I have no idea how one would go about putting that into code. Sounds really complicated. SchuminWeb (Talk) 00:25, 10 February 2011 (UTC)
I often use templates (added via Twinkle or manually) to create a standard message, then edit the message to add more details. Thus, if I needed to send the same message about 5 files, I would create the message for the first file using a template, save it, then edit the page to add the names of the other files to that message. --Orlady (talk) 00:29, 10 February 2011 (UTC)
That's the good way to do it. My concern is also that a lot of the worst of this tagging is done via bot and bots, being heartless beasts, would not stop to combine the messages. I figured that this would be the place to go to figure out a way to do this automatically so that both bots and taggers can avoid putting up walls. --Danger (talk) 01:44, 10 February 2011 (UTC)
All it would have to do is insert the additional tagged files' links after the original link in the first sentence given a certain set of conditions (the original template was placed within the last hour, for example); it doesn't have to do anything crazy with the text. But then, I'm not a programmer. --Danger (talk) 01:44, 10 February 2011 (UTC)
Wouldn't a simple hack be to just enter into the article or file text field, some extra brackets. Assume it automatically adds [[ ]], so if you want to delete the ham article, the egg article, and the cheese article, just put: ham]], [[egg]], and [[cheese in the field? Ocaasi (talk) 22:00, 11 February 2011 (UTC)

Mediawiki 1.117

Would you mind checking the source code for TWINKLE ans morebits.js against the new 1.17 mediawiki, as post upgrade it seems that enabling TWINKLE in gadgets means that it for whatever reason doesn't seem to work on File: namespace pages properly? Sfan00 IMG (talk) 13:25, 16 February 2011 (UTC)

Rollback and restore version links missing on diff pages

Since MediaWiki 1.17 upgrade last night, I am having trouble with obtaining Twinkle rollback links in the diff views. Most often when I visit a "most recent" diff, I do not see any rollback or "restore this version" links at the top of the page. Sometimes I can get them to appear by going back and forth in the article history, but I would expect them to appear on every page they are applicable without such fiddling. Is anyone else having this issue? Elizium23 (talk) 23:31, 16 February 2011 (UTC)

Try clearing your cache a couple of times, that does it for me. Xeworlebi (talk) 23:53, 16 February 2011 (UTC)
Already tried that. Thanks. Elizium23 (talk) 00:03, 17 February 2011 (UTC)
It turns out that if I'm not getting the links on a diff page, that a rollback from the "user contributions" view fails, too. I tried both the normal and the vandalism rollback links, and they just take me to the most recent diff view but do not initiate a revert at all. I am using Google Chromium 9.0.597.98; but I tried switching back to Firefox 3.6.13 and had exactly the same problems. Elizium23 (talk) 04:03, 17 February 2011 (UTC)
I am also experiencing the same problem. I cleared my browser cache, but in vain. I tried using a different browser, but the problem persists. Abhishek Talk to me 14:37, 17 February 2011 (UTC)
Aha, it seems to be an interaction with revisionjumper, which I had recently enabled, and which never seemed to function anyway. I disabled it and all links are appearing regularly. Elizium23 (talk) 05:10, 18 February 2011 (UTC)
Seconded as having problems with revisionjumper and Twinkle under the recent change. Since revisionjumper didn't work for me over the last couple of weeks it's not great loss to disable it... Tabercil (talk) 01:24, 19 February 2011 (UTC)

Page blanking (or lack thereof)

I have noticed that recently pages that are marked as attack pages and have a blanked as acourtesy tamplate added aren't actually blanked. ConconJondor (talk) 17:12, 18 February 2011 (UTC)

checkY Fixed, thanks! You may need to bypass your browser cache to get the updated script. Amalthea 19:19, 18 February 2011 (UTC)

default to minor

Resolved

I see that currently Twinkle (and Friendly) marks adding a tag by default as minor, but the guideline WP:MINOR says that this is always a major edit---as it should be,, so it will show up on watchlists, which many (?most) people set to not show minor edits. DGG ( talk ) 17:35, 17 February 2011 (UTC)

Here's what I wrote 15 months ago about this:

Hmm. I fixed it by removing the recommendation from the help page. This was brought up twice before at WT:FRIENDLY, I don't think there was ever a consensus for that addition to Help:Minor edit: There's some sparse, ongoing discussion on its talk page since 2007, it was added early 2009 by a now-banned editor, and I for one don't think that such a blanket recommendation makes sense. In particular with new page patrolling, I don't consider any added Friendly tags as major edits. It certainly is a different story with older, more established articles, I would agree with you that addition of tags should not be called minor. Then again, in my opinion Friendly shouldn't be used to tag any established articles anyway: Pointing out issues on the talk page or, if possible, just fixing them makes way more sense with older article with many revisions and authors, where the categorization isn't that helpful, issues are typically not as clear-cut or undisputed, and drive-by tagging understandably angers the main editors of those articles a bit anyway.
Any user can already change his Friendly configuration to not mark taggings as minor. We could also add a checkbox to display and toggle the status in the Friendly window.
Feel free to discuss this or ask for more opinions at WT:FRIENDLY though.
Cheers, Amalthea 15:08, 15 November 2009 (UTC)

Then again, I hardly edit at the moment, and I've always kept minor edits visible on my watchlist, so this isn't really an issue for me. Amalthea 19:31, 18 February 2011 (UTC)

The guideline makes sense to me; tags are supposed to get people's attention, and marking their addition as minor means less attention being got via watchlists. Rd232 talk 21:44, 18 February 2011 (UTC)

Alright, default changed to major edit. Thanks, Amalthea 11:50, 23 February 2011 (UTC)

A minor issue

As a frequent NPPer, for the last couple of weeks when I tag pages for either CSD or maintenance they aren't being marked as patrolled. Is this just me, or is there a wider problem with this? (I usually use Firefox 3.6, but this has also been happening when I use Safari) The Blade of the Northern Lights (話して下さい) 04:10, 22 February 2011 (UTC)

I'm experiencing the same problem. Could this be caused by the recent upgrade to MediaWiki 1.17? I'm using the vector skin in Firefox 3.6.13. Thanks. —Bruce1eetalk 05:56, 22 February 2011 (UTC)
WP:TW/BUGS#437. I haven't looked into it yet. Amalthea 14:35, 22 February 2011 (UTC)
Sorry, I should have looked at the BUGS page first! —Bruce1eetalk 14:54, 22 February 2011 (UTC)

Another issue I've found is that CSD G10 does not blank the page. In this edit it says it did, but it didn't. —Bruce1eetalk 10:29, 22 February 2011 (UTC)

#Page blanking (or lack thereof). Amalthea 14:35, 22 February 2011 (UTC)
Oops, didn't see that section above – cache now cleared! Next time I'll open my eyes :) —Bruce1eetalk 14:54, 22 February 2011 (UTC)

Twinkle stalling during User Warn

Today, after submitting a user warning the dialog switches to say "User talk page modification: data loaded..." and sits there. Is this due to something that changed on my system, on WP or on Twinkle? Jojalozzo 17:14, 23 February 2011 (UTC)

I'm seeing the same issue when trying to add Shared IP info. Looks like something broke somewhere. --Alan the Roving Ambassador (talk) 17:25, 23 February 2011 (UTC)
Experianceing the same. Hangs when trying to warn the user from their talk page. Also stalls for me when trying to Revert using any of the 3 Buttons (rollback (AGF), rollback, rollback (VANDAL)). Have tried turning off Frendly in My preferences and tested in the New Admin School Rollback but no difference. Just decided to search full recent changes for anyone with a (TW) tag, have found nobody using and I assume there would be someone else around. I am out of ideas. WoodyWerm (talk) 17:29, 23 February 2011 (UTC)

Just about none of the things I do using Twinkle is working for me at the moment - if I try to CSD it just hangs trying to fetch data, similarly if I try to report to UAA or AIV, and I sometimes get red error messages (sorry I don't have any actual examples of red error messages, but I'll record the details next time it happens) -- Boing! said Zebedee (talk) 17:36, 23 February 2011 (UTC)

Oh yes, it fails trying to Revert too. -- Boing! said Zebedee (talk) 17:37, 23 February 2011 (UTC)
I have same issue on IP talk page. Bagumba (talk) 17:38, 23 February 2011 (UTC)
I've reported bug at Wikipedia_talk:Twinkle/Bugs#TW-B-440_(new) Bagumba (talk) 17:46, 23 February 2011 (UTC)

Its not working, here either. Off2riorob (talk) 17:58, 23 February 2011 (UTC)

Red error message "Reverting page: couldn't grab element "editform", aborting, this could indicate failed response from the server" when trying to use the blue "rollback" link -- Boing! said Zebedee (talk) 18:04, 23 February 2011 (UTC)
All of the above presently broken for me too. Were working two hours ago. --Walter Görlitz (talk) 18:14, 23 February 2011 (UTC)
Any word from server folks? Binksternet (talk) 18:30, 23 February 2011 (UTC)
Also failing for me in the UK, I'm assuming it's a UK or Europe-based issue and not worldwide(?) —Half Price 19:21, 23 February 2011 (UTC)
If something was changed in Twinkle itself, locality won't matter...and since I'm in the US, I think you just confirmed it's not a server issue. --Alan the Roving Ambassador (talk) 19:27, 23 February 2011 (UTC)
Canada. Not restricted to UK/Europe. --Walter Görlitz (talk) 19:32, 23 February 2011 (UTC)
Same problem. Reverting page: couldn't grab element "editform", aborting, this could indicate failed response from the server Warfieldian (talk) 19:37, 23 February 2011 (UTC)
Same for me it just stalls when warning IP's.RAIN*the*ONE BAM 19:51, 23 February 2011 (UTC)
Ditto for me, I'm getting the "couldn't grab element..." error and also it just hangs when I try to warn someone. Bento00 (talk) 20:21, 23 February 2011 (UTC)
Apparently, the issue that's affecting Twinkle right now has also broken the ARV tool that I often use to report vandals. --SoCalSuperEagle (talk) 20:26, 23 February 2011 (UTC)
Not that I'm glad everyone is having problems, but I am a bit relieved that I am not the only one. Hopefully this will get fixed soon.--Jojhutton (talk) 21:44, 23 February 2011 (UTC)
It also won't let me tag new pages for deletion. Baseball Watcher 22:04, 23 February 2011 (UTC)
I'm also having problems with Twinkle, can't revert, can't warn, and can't report vandals. Powergate92Talk 22:06, 23 February 2011 (UTC)
Yes, I am having TW problems also cant seem to do anything with it, even tried removing HotCat to see if there was a conflict, still dosen't work... Making my NPP work very difficult Pol430 talk to me 22:14, 23 February 2011 (UTC)
I think the problem is that something's happened to the so-called "editform" javascript element. All javascript-based tools that I currently use which rely on that particular object have ceased normal operations. --SoCalSuperEagle (talk) 22:25, 23 February 2011 (UTC)
Correct. It might have something to do with the recent skin changes. --Walter Görlitz (talk) 22:33, 23 February 2011 (UTC)
So glad I'm not the only one suffering tonight.............--5 albert square (talk) 23:05, 23 February 2011 (UTC)
This really makes it clear how valuable twinkle is.--CutOffTies (talk) 00:08, 24 February 2011 (UTC)
I have to keep doing thing manually because of the issue of Twinkle right now! Baseball Watcher 00:39, 24 February 2011 (UTC)
Same CutOffTies. Friendly dosen't work either. --Guerillero | My Talk 01:54, 24 February 2011 (UTC)
Well crap. I think some of these programs are starting to think that the laws are a bit too good for them.--Yaksar (let's chat) 02:01, 24 February 2011 (UTC)
This stinks. Baseball Watcher 02:25, 24 February 2011 (UTC)

Does anyone know if the powers that be are aware of the problem?And are they working on it? Also, I noticed that there is a banner on this articles page stating that twinkle and Friendly are in the process of being merged. Could this be causing the problem?--Jojhutton (talk) 03:06, 24 February 2011 (UTC)

The "merge" tag has been there for a long time - it's old news, I think. - The Bushranger One ping only 04:34, 24 February 2011 (UTC)
I'm getting a similar thing, I just get "Couldn't grab editform" - nothing about a server issue, and since I'm not using any of the modern skins, and nothing on this one has changed, I don't think it's a skin issue. I'm using Monobook, standard with all beta features disabled. It was working fine yesterday, this appears to be a fairly new issue and I'm not aware of anything which has changed in the last < 24 hours. BarkingFish 03:50, 24 February 2011 (UTC)

For those looking for updates: I'd imagine we'd most likely see it on the bug page Bagumba (talk) 04:09, 24 February 2011 (UTC)

The bugs that have been reported haven't had their status changed to acknowledged. That implies the bug isn't being worked on. Sigh. Eeekster (talk) 05:06, 24 February 2011 (UTC)
Actually, they still say "new" and "resolution:none"? And it appears to be the DOCTYPE. - The Bushranger One ping only 05:29, 24 February 2011 (UTC)
  • Just to add my voice to this as well - for tagging it just sits there. For restore or rollback it returns an error about the server. Soundvisions1 (talk) 04:10, 24 February 2011 (UTC)
I'm experiencing the same problem as everyone else, but recently the rollback features haven't been working either. Is this a separate problem? Friginator (talk) 06:11, 24 February 2011 (UTC)
[Edit conflict] Me too. It hangs when trying to place a welcome template. – SMasters (talk) 06:13, 24 February 2011 (UTC)
..*sigh* hard work doing it manual again :-( probably a ploy by the twinkle people to make us appreciate their gadget a lot more.--ClubOranjeT 09:43, 24 February 2011 (UTC)

I have successfully upgraded the standalone ARV tool to use the API. My working version can be found at User:UncleDouggie/aiv.js. Now we just need to fix Twinkle! My changes to the ARV tool were rather extensive. However, if Twinkle is modular enough, perhaps I can easily deploy the same fix? I'll go start looking at it. —UncleDouggie (talk) 11:54, 24 February 2011 (UTC)

2011-02-24

The tagging doesn't work. It goes well just to the data loaded. ~~Awsome EBE123~~(talk | Contribs) 11:47, 24 February 2011 (UTC)

I'm also getting this problem, from two different computers each with different IP addresses. None of the usual Twinkle functions are working. Has something been changed somewhere along the line? Mr. Stradivarius (drop me a line) 13:01, 24 February 2011 (UTC)
You might want to read the post just above this one… Xeworlebi (talk) 13:03, 24 February 2011 (UTC)
Yes, sorry, guilty as charged. it looks like things are being sorted out. I've been wasting electrons a lot today... Mr. Stradivarius (drop me a line) 13:09, 24 February 2011 (UTC)

Right guys - I now know what's happened, and where. Yesterday afternoon, one of our developers, Roan Kattouw, enabled the use of HTML5 across Wiki at 15.40UTC. This has buggered the screen scraping, which in turn has buggered everything that screen scrapes. I spoke to tech team, and their solution? Stop using screen scraping, and switch to using the API. My solution? Stop buggering with things which break stuff that works!!!!!! BarkingFish 13:12, 24 February 2011 (UTC)

Twinkle IS now working. The HTML5 switch on, has been switched off. I tested it by CSD'ing this page :P, don't panic, it's been undone. BarkingFish 13:44, 24 February 2011 (UTC)

Good news! But lets not bash the development team. Wikipedia needs to keep up with changes in technologies and standards, so change is inevitable. Screen scraping, while an effective technique, has an inherent sensitivity to change. That's not the developer's fault. UncleDouggie is working hard to convert Twinkle to stop using screen scraping and to use the API, so that the development team can eventually move ahead with their changes. Thank you UncleDouggie! -- Tom N (tcncv) talk/contrib 14:55, 24 February 2011 (UTC)
Not bash the development team? What they did was a live public beta at best and closer to a public alpha. In short it was unprofessional. This isn't someone's hobby website. They should have a test site and at least run unit tests to see what would break and sought a private beta to prevent this sort of mayhem. --Walter Görlitz (talk) 15:08, 24 February 2011 (UTC)
It's no big deal, guys. I'm pretty sure no one was seriously injured. It's not 100% efficient, and you can't blame people for trying to improve the software, even if it backfires. Twinkle isn't something that's guaranteed to you. And to be frank, if you spent all of yesterday trying to warn people on Wikipedia, it might be time to take a deep breath and consider doing something else. Thanks to the team for cleaning up the mess. Friginator (talk) 15:58, 24 February 2011 (UTC)
Well spoken Friginator and Tcncv. —TheDJ (talkcontribs) 20:21, 24 February 2011 (UTC)
You've missed the point. It's not about what we were or were not trying to do, it's what the developers who implemented HTML 5 without taking into account the consequences ended up doing. I appreciate that they're moving forward, but it's irresponsible to do so without testing first.
Are you sure you ant to be telling those who patrol vandalism to consider doing something else? Walter Görlitz (talk) 20:49, 24 February 2011 (UTC)
The developers are well aware of the consequences of switching to HTML5, but they're not going to fix every JavaScript tool on every Wikimedia project to work with HTML5. It's up to the script maintainers to make sure they continue to work. Twinkle isn't an essential tool, you can continue to do what you're doing without it. And once Twinkle is fixed, you can use it again. Reach Out to the Truth 21:16, 24 February 2011 (UTC)
I assume that means you are willing to help out upgrading the tool, or are you just trolling? AzaToth 21:20, 24 February 2011 (UTC)
Neither really. It might be a conflict of interest and I'd have to check with my employers before I volunteer. Since I'm a professional tester and my terms of employment may indicate that I can't assist with testing of products other than theirs. Besides, it's not an option since I don't know where the developers are doing their testing which makes it difficult to assist.
What I'm doing is sending a warning that they should be testing tools or at least solicit support from the various tool vendors when upgrading anything. It's bad form to make changes that break functionality without giving the developers of those tools the opportunity to make changes. It's why there are betas of releases of things like Firefox, OpenOffice, and all commercial tools. Why should this development project be any different? Are you saying they're justified in doing whatever they want whenever without regard for the existing users? --Walter Görlitz (talk) 22:05, 24 February 2011 (UTC)

FYI - UncleDouggie has implemented a partial fix that converts the "warn" function to the API. For now it requires a manual refresh to see the change on the talk page. Please report any problems with that function. (If necessary an administrator can undo these changes.) I assume other fixes will follow, but there are a lot of scripts to update. -- Tom N (tcncv) talk/contrib 16:12, 24 February 2011 (UTC)

Since we have a temporary reprieve from the developers, let's undo my fix to the warning module for now to get auto-reload back. Then we can clean up the API usage while not in a panic. —UncleDouggie (talk) 16:34, 24 February 2011 (UTC)
HTML5 was switched off for another reason and the devs might switch it on again: mediazilla:27478. — AlexSm 16:46, 24 February 2011 (UTC)
Oh joy. I'll continue to polish up the new Twinkle warning module over the next few days so at least we'll have that one ready. I've already made a few more fixes, but it doesn't auto reload yet. —UncleDouggie (talk) 17:59, 24 February 2011 (UTC)

I've plannede to convert twinkle to API years ago, but free time ran away, and there wasn't any people willing to help :( But perhaps now there might be some code monkeys available? :) AzaToth 18:31, 24 February 2011 (UTC)

The reality of volunteer written userscripts. We can't keep up as script editors, but can't do without them either as Wikipedia editors. Wish I had the time to help. —TheDJ (talkcontribs) 20:23, 24 February 2011 (UTC)
AzaToth, if you want volunteer coders to help you maintain and update Twinkle, I'd be happy to sign on with you. Get in touch with me through Special:Emailuser or through my talk page :) BarkingFish 02:27, 25 February 2011 (UTC)

I'm currently working on twinkleunlink. Just a note, especially to UncleDouggie (who has already been converting scripts): AzaToth's morebits.js has a small API called "Wikipedia.api", which can be used for calling the API. It's not very fail-safe, and needs work, but I suggest that you use this rather than jQuery, so that if any implementation details need to be changed in future, this can be done with (relative) ease. — This, that, and the other (talk) 08:47, 25 February 2011 (UTC)

An upgraded version of twinkleunlink is at User:This, that and the other/twinkleunlink.js; here's a cross-page diff of the changes (which include upgrading to use the edit API, and other improvements). It works solidly for backlinks (for me, at least!), but I haven't been able to test too much with image usage. It's not perfect, but the remaining problems are a) in morebits.js, not twinkleunlink, and b) long-standing and not caused by the screen-scraping issue, so I'm not fussed about them too much. Could an admin please copy this over to the master script, and revert if any issues arise? — This, that, and the other (talk) 01:26, 26 February 2011 (UTC)

Twinkle CSD improvements, including {{db-multiple}} support

Rejoice, Twinkle fans! I have written an alternative version of Twinkle's speedy deletion functionality, giving it a minor boost. The modified version of the script, User:This, that and the other/twinklespeedy.js, supports the following new features:

  • Support for the {{db-multiple}} template, allowing pages to be tagged with more than one criterion using Twinkle. This is a long-standing and popular feature request (now archived). (Note that admins don't get this functionality at the moment - I'm not an admin, so I can't test any modifications I make to the admin code.)
  • Support for rationales for the G7 (author request) speedy criterion (often useful if a user requests deletion at an XfD discussion - you can now provide a link to the XfD when tagging the page for G7).
  • Also includes support for {{db-reason}}. (This apparently once did exist in Twinkle, but was seemingly removed. So maybe consensus is against including this in the main version of Twinkle. If you use my script, then use this feature with great care.)
  • Other, quite minor improvements.

To find all my changes, do a text search for **TTO in the script. There is also a cross-page diff which shows the changes I've made.

If you want to try out the script, remove your normal method of invocation for Twinkle (i.e. turn off the gadget or remove the script), and import User:This, that and the other/twinkle.js. (If you don't trust me, then you can make your own copy of the speedy script in your userspace, and import that.) Also, if it is desired to incorporate some or all of my changes into the master copy of twinklespeedy.js, I am happy to assist an admin. — This, that, and the other (talk) 10:55, 5 February 2011 (UTC)

Oh, forgot to mention, if you have any questions, comments or suggestions, please ask me. — This, that, and the other (talk) 21:36, 6 February 2011 (UTC)
I've copied your modified script to Twinkle, thanks again! If any issues arise, please post on this page. Cheers, Amalthea 14:28, 17 February 2011 (UTC)
I just noticed this capability, and wondered where it came from. Thanks! --Muhandes (talk) 10:44, 28 February 2011 (UTC)

Request to remove various temporal templates from Twinkle

I see from the {{Twinkle standard installation}} notices placed on {{current}}, {{current person}}, {{recent death}}, {{current related}}, {{current sport}}, {{current spaceflight}} that WP:Twinkle has these templates as standard choices for Twinkle editors to select and use.

In general, these templates are used infrequently, and in general, only a few (as in significantly fewer than ten articles) at any time properly have such templates on the articles. In general, these templates are suggested to be used for those outstandingly unusual situations in which a massive crush of editors are active on an article, and further, are recommended not to be used to merely indicate that an article is in the news or subject to error and change, since all articles in Wikipedia are subject to being in error and or changed, a fact indicated in the WP:general disclaimer at the bottom of all Wikipedia articles.

That these templates are standard in Twinkle implies that a population of editors will be led to believe it is expected to use these exceptional templates for many articles, which is most definitely not the case. It is perfectly adequate to add these particular templates manually, with judgment, and rarely, without the help of Twinkle.
-- Yellowdesk (talk) 03:07, 20 February 2011 (UTC)

I admit - I have never used the "current" template or similar through Twinkle, and probably wouldn't think to use Twinkle to add that kind of a tag if I needed to. The problem with it is that it doesn't really fall within Twinkle's scope, because the tag list is otherwise all maintenance tags. So I agree that it should probably come out of Twinkle, though it seems for different reasons. SchuminWeb (Talk) 16:18, 20 February 2011 (UTC)
  • Besides pleading here in this section, what next persuasive steps can I take for maintainers to consider the proposal?
    -- Yellowdesk (talk) 12:55, 26 February 2011 (UTC)
    • Nagging is sufficient. I usually wait with requests like this to see consensus, but if there is like here no discussion then requests are sometimes forgotten and archived if not bumped.
      checkY Current event templates are now removed. Thanks, Amalthea 13:52, 26 February 2011 (UTC)
    • Many thanks, Amalthea, for your prompt reply and action.
      -- Yellowdesk (talk) 15:17, 26 February 2011 (UTC)

Not Signing my Warning Posts

Has anybody had that happen? Twinkle signed my vandalism warning message but not the sub-message about the IP address. see here: http://en.wikipedia.org/wiki/User_talk:207.157.35.4#February_2011 RemingtonHill 20:21, 28 February 2011 (UTC) — Preceding unsigned comment added by Remingtonhill1 (talkcontribs)

OK that is just strange. SineBot signed my message right after my signature? Remingtonhill1 (talk) 20:35, 28 February 2011 (UTC)
That's because it, like the one on the IP talk page, is not a valid signature. Your signature must include at least one link to your user, talk, or contributions page, as in your second note above. (See WP:SIG for more information.) As for Twinkle signing the "warning message but not the sub-message", that's the standard, accepted practice. MANdARAX  XAЯAbИAM 20:57, 28 February 2011 (UTC)

Adding a template...

Not to pile additional workload on those making sure Twinkle survives Media's changes (and thanks to all of you who are doing that! :)), but is there any way the {{uw-consensus}} series of templates could be added to Twinkle? I don't believe they're on it yet... thanks! - The Bushranger One ping only 23:20, 1 March 2011 (UTC)

We can do it, but it will have to wait until the current updates are done, which will probably be a few weeks. We need to freeze all non-critical updates to the baseline to keep any control over this process and enable us to run diffs. —UncleDouggie (talk) 01:57, 2 March 2011 (UTC)
No rush! I appreciate the work y'all are doing (Java code makes my eyes glaze over) and know that it takes a lot of work. It's appreciated. - The Bushranger One ping only 02:17, 2 March 2011 (UTC)

Issue

Can someone tell me what I did wrong here to make TW not work? Probably related to watching speedy deletions. CTJF83 20:48, 5 March 2011 (UTC)

You're missing a comma between: 'g1' 'g3' —UncleDouggie (talk) 23:38, 5 March 2011 (UTC)
LOL, wow, that easy, huh? Thank you! CTJF83 23:45, 5 March 2011 (UTC)

Whats going on?

I was trying to revert some vandalism and it says, Reverting page: couldn't grab element "editform", aborting, this could indicate failed response from the server. Baseball Watcher 20:19, 6 March 2011 (UTC)

I run into that every once in a while. It usually clears up after a few minutes. Millahnna (talk) 20:38, 6 March 2011 (UTC)

HotCat

i notice that HotCat is no longer showing up, is this a known issue? - The Elves Of Dunsimore (talk) 08:49, 8 March 2011 (UTC)

Why are you asking about HotCat at Wikipedia talk:Twinkle? T. Canens (talk) 08:53, 8 March 2011 (UTC)
my apologies, i thought thats what twinkle used for category editing. let me rephrase my question, why is it that today, when new page patrolling, i dont see the category editing box at the bottom of pages anymore? - The Elves Of Dunsimore (talk) 09:00, 8 March 2011 (UTC)

forget it, it just came back, thanks to whoever fixed it - The Elves Of Dunsimore (talk) 09:05, 8 March 2011 (UTC)

Not marking new pages as "patrolled"

I recently used A7'd a new page. The message still said "Marking as patrolled...done" (or whatever it says). However, I noticed that the article was still highlighted at Special:NewPages and I had to click "mark as patrolled" manually. I've also noticed several articles that have not been marked as 'patrolled' despite having a CSD tag placed on them by Twinkle. Has anyone else noticed this? Swarm X 05:30, 28 February 2011 (UTC)

This appears to be a recent problem. I am currently investigating this. — This, that, and the other (talk) 09:02, 28 February 2011 (UTC)
Patrolling now requires a token in MediaWiki 1.17. Is Twinkle using the provided token? Reach Out to the Truth 20:28, 28 February 2011 (UTC)
It doesn't look like it. I think it just sends a GET request with the "rcid" value supplied. I'll take a look at this soon. — This, that, and the other (talk) 08:02, 1 March 2011 (UTC)
I'm not sure if I'm right on this but I seem to remember that this was deliberate because if someone removes a CSD template shortly after it has been applied by Twinkle - and of course we get a lot of this - if the page had been automatically been marked as 'patrolled', then the removal might get missed, unless someone catches its removal at RCP. Kudpung (talk) 11:25, 1 March 2011 (UTC)
If you do remember correctly, and it was deliberate, please include an option to automatically mark the pages as patrolled even if the default is not to. Thanks to everyone who is putting in all this hard work on the update! VQuakr (talk) 07:48, 5 March 2011 (UTC)

Any updates on this? If it was deliberately done, the software needs to be updated so it no longer says "marking as patrolled: done". If it's an error, is it going to be fixed? Swarm X 05:50, 5 March 2011 (UTC)

Tell us how you want it to work and we can try to put it into the rewrite. Unless the current version starts turning pages into gibberish, enhancing it is a losing proposition because the internals of the new version are completely different. —UncleDouggie (talk) 07:26, 5 March 2011 (UTC)
I'm fairly sure it has something to do with the breaking change to patrolling in 1.17. T. Canens (talk) 06:07, 7 March 2011 (UTC)
Kudpung has suggested above that perhaps Twinkle should not mark such pages as patrolled. I'm merely asking for consensus on how it should work. I'm happy to implement it either way, so long as it can wait for the rewritten version. —UncleDouggie (talk) 07:21, 7 March 2011 (UTC)
My !vote is for it to mark pages as patrolled by default, but I have no strong preference either way provided there is an option to set Twinkle to mark pages as patrolled. VQuakr (talk) 07:47, 7 March 2011 (UTC)
WP:NPPLOG#What to mark as patrolled: "Any page that is tagged for speedy deletion, so people do not waste time reviewing the same page multiple times."
It was set up to be enabled by default, and it hasn't been disabled intentionally. Amalthea 13:56, 7 March 2011 (UTC)
So why do the config parameters markSpeedyPagesAsPatrolled and markTaggedPagesAsPatrolled even exist? It seems that they should always be true. To address Kudpung's concern, Twinkle could add CSD pages from NPP only to the Twinkle user's watch list. Either the page is going to be deleted or the CSD tag is going to be removed. However, it seems like other tools could handle this better. —UncleDouggie (talk) 14:28, 7 March 2011 (UTC)
No particular reason for that option I think, but you'd have to ask Ioeth.
Twinkle only marks a page as patrolled if the Twinkler arrived at the page from Special:NewPages (at least as long as bugzilla:15936 remains open), so the patrol function will only work for NPPers, and they will know what works best for them. Folks there clearly say that any SD-tagged pages should be marked as patrolled. But if there really is doubt about what works best for them, ask them.
In addition, there is an edit filter that collects most relevant SD tag removals, so those can and are still checked. An article, once tagged, is not likely to drop off the radar.
Amalthea 15:22, 7 March 2011 (UTC)
Many CSD removals are in fact being caught by User:SDPatrolBot, which is the kind of better tool I was referring to. It seems that Twinkle should just behave according to markSpeedyPagesAsPatrolled and markTaggedPagesAsPatrolled, both of which default to true. —UncleDouggie (talk) 15:39, 7 March 2011 (UTC)
Ah, right, I forgot about the bot. Amalthea 15:58, 7 March 2011 (UTC)
It might be possible for Twinkle to steal the patrol token off the document before executing the speedy, but we're trying to get away from such fragile processing. The right way to do it is when tagging any page as CSD, query the API for list=recentchanges restricted by the user and timestamp information received from a previous query for the revision information. If the article is unpatrolled, we will get back a patrol token that we can then use to mark it as patrolled in yet a third API call. The setup for the list=recentchanges call is just the API equivalent of the previous MediaWiki PHP based attempt that had performance issues. Because we will only make the Twinkle calls following a CSD tagging operation, performance won't be an issue like it was in the failed MediaWiki attempt. Hopefully tto can follow all that and/or it still makes sense to me next week as well. I think we should get the rest of the port done first because being ready for HTML 5 seems more important. —UncleDouggie (talk) 16:21, 7 March 2011 (UTC)
Yep, absolutely. Amalthea 16:39, 7 March 2011 (UTC)
Can't it just pull the token from the URL of the "Mark this page as patrolled" link that's right on the page? Just use regex to search the page source for \<div class='patrollink'\>.*&action=markpatrolled&rcid=(.*)&token=(.*)\" —SW— comment 15:21, 8 March 2011 (UTC)
Actually, it seems we're already doing something similar. If Twinkle can tell us that page patrolling isn't working and give us a link to click on to mark the page as patrolled, then why can't it just open that URL automatically in the background like it used to? If it's giving us a link to click on, then clearly there is no problem with obtaining the token. —SW— confabulate 15:31, 8 March 2011 (UTC)
I am trying to fix this as a priority. I'll see if I can get it done today or tomorrow. — This, that, and the other (talk) 08:05, 9 March 2011 (UTC)

This should be checkY Fixed. If not, please post below or let me know on my talk page. Thanks, — This, that, and the other (talk) 01:44, 12 March 2011 (UTC)

Undated file CSD templates bug me.

In the CSD tab for files, the F4, F5, and F6 options should be removed from the menu. F5 doesn't even appear to date the tag.

  • F4 is the same as {{Di-no license}}
  • F5 is the same as {{Di-orphaned fair use}}
  • F6 is the same as {{Di-no rationale}}
  • So technically, none of the three count as CSD. They are already in the DI (7 day grace period) tab anyway, so removing them from the CSD would hopefully keep them on the DI menu.

mechamind90 16:51, 7 March 2011 (UTC)

Yes. I agree; I'm going to see if I can fix this as part of the Twinkle upgrade in the near future. — This, that, and the other (talk) 08:03, 9 March 2011 (UTC)

Twinkle accidentally calls users TWITs

Check this diff.

Am I right to assume that the last part of this is somehow coming from Twinkle? The edit in question was a rollback (AGF), and the edit summary I provided did not include that text. I'm guessing that TWIT here is an abbreviated form of some sort of error or other indication about the edit, but really, the potential for misunderstanding is significant given Twit, (a) is this in fact coming from Twinkle, and (b) can it be fixed? I've only seen it a few times, and I haven't figured out how to consistently reproduce it, but it's not a one-off, either. --joe deckertalk to me 18:47, 10 March 2011 (UTC)

This is not "twit" but "tw|t" with a pipe and it's obviously just a part of [[WP:TW|TW]] which was cutt off due to summary length limit. IMHO Twinkle could check the summary length and warn the user it it's too long. — AlexSm 19:04, 10 March 2011 (UTC)
Ahh, indeed, | not I. Indeed. --joe deckertalk to me 19:22, 10 March 2011 (UTC)
you could also enable the gadget the expands the edit summary. ---— Gadget850 (Ed) talk 20:07, 10 March 2011 (UTC)
Oooh, had no idea. Done! Thanks! --joe deckertalk to me 20:13, 10 March 2011 (UTC)
Actually, this will not help per Wikipedia:Village pump (technical)/Archive 87#Edit summary length. Even when the gadget worked I suspect that Twinkle prompts for summary text in its own input field (cannot say for sure since I don't use Twinkle myself). — AlexSm 20:19, 10 March 2011 (UTC)
I have also seen the ad messed up if an edit summary has unbalanced []. Some revision related pages can handle this and some can't. Seems like we should limit the size of the edit summary input and maybe do some other sanity checking eventually. —UncleDouggie (talk) 20:40, 10 March 2011 (UTC)
Indeed, because some of us (looking at self) can really get long-winded in an edit summary, and Twinkle doesn't cut me off when I've said too much and messes up the summary. So to cut me off when it's time would be really beneficial... SchuminWeb (Talk) 07:27, 12 March 2011 (UTC)

Maintenance Box issue

Please help. I've totally re-edited, re-written the Chanel No. 5 page, and re-formatted it according to encyclopedic standards. There is a maintenance box at the top, calling for deletion of the page and soliciting for re-edits of the entry. How do I delete this maintenance box now that I've done the work called for? I'm new to Wiki's "technical" aspects and don't know how to go about it. Please advise as to process. Thanks. Betempte (talk) 20:01, 13 March 2011 (UTC)

CSD - Author blanked

When selecting CSD criterion G7, there are two options (author requested and author blanked). When selecting the "author blanked" option, Twinkle still prompts for an explanation. I think this option is self explanatory and it would be safe to remove the prompt for more information. VQuakr (talk) 04:20, 16 March 2011 (UTC)

There is absolutely no difference between selecting "author requests deletion" and "author blanked". I am probably going to remove the "author blanked" option from Twinkle with the next update, as it is redundant to the "requested" option. The prompt is not expected to be needed very much; I'm not sure what to do about it, though, as I (for one) find it very useful. I might make it into a preference, so that the user can enable the G7 prompt manually (an option which would, of course, be disabled by default). In the meantime, if the prompt is not wanted, it can simply be dismissed by pressing "enter" (on Macs, "return"). Anyway, thanks for your feedback; do you have any further suggestions? — This, that, and the other (talk) 05:47, 17 March 2011 (UTC)

Courtesy FYI

A significant edit was made to the following Rcats:

The edit allows editors to subdue the default populating of Category:Unprintworthy redirects and to instead populate Printworthy redirects for plurals and singulars such as those that derive from the Arabic and Latin languages.  — Paine Ellsworth ( CLIMAX )  17:49, 16 February 2011 (UTC)

In-universe

Resolved

This is a courtesy notice that this discussion has now closed as delete. The documentation for these templates indicated that they are used by Twinkle. Thanks! Plastikspork ―Œ(talk) 01:53, 13 March 2011 (UTC)

I have no idea what this is for. "trek" doesn't exist in the Twinkle code and the only page reference we have is here, which doesn't seem very applicable. —UncleDouggie (talk) 07:59, 28 March 2011 (UTC)
User:Ioeth/friendlytag.js can be used to tag with {{in-universe}}, but only the base template, not the deleted specializations, so we're good. Sorry for not replying sooner. Amalthea 11:41, 28 March 2011 (UTC)

Tagging and hatnote detection

Twinkle does not appear to recognize {{Other uses}} as a hatnote and adds tags above it instead of underXeworlebi (talk) 12:50, 23 March 2011 (UTC)

checkY Fixed, thanks. Was broken since all those "otherFOO" hatnote templates were moved to "other FOO". Amalthea 12:31, 28 March 2011 (UTC)

Page notices

The page notice at Sonny with a Chance prevents Twinkle from reverting, and may affect other functionality there. I realise the issue is the page notice itself, but I've raised the issue of page notices before and, since I have no idea what the problem is since I can't edit it, I thought you might have a look and perhaps be able to find a way to get Twinkle to ignore page notices entirely, if that's possible. --AussieLegend (talk) 07:16, 28 March 2011 (UTC)

This problem will probably go away once the Twinkle rewrite is complete because edit notices should have no impact on the API, which we are moving to exclusively. —UncleDouggie (talk) 07:54, 28 March 2011 (UTC)
What UncleDouggie says, but I fixed the editnotice here. Amalthea 11:47, 28 March 2011 (UTC)

Template:El redirect to Template:External links

Template:El redirect to Template:External links and not to the Greek language icon. EL is the official ISO language code of Greek. Unlike other languages where you can use e.g {{en}} for English, {{de}} for German and {{fr}} for French you have to use {{el icon}} because {{el}} misdirects you to Template:External links. The Template:External links page mentioned that the template is used by Twinkle as default but is the redirect Template:El also used? Else it should redirect to the Greek language icon Template:El icon to ensure consistency with other languages.

See also the Template:El talk page and the discussion at the Village pump. SpeakFree (talk) 23:29, 1 April 2011 (UTC)

Twinkle does not use {{el}}. I'll add further comment at Template talk:El. Amalthea 12:24, 2 April 2011 (UTC)

Firefox 4 and Twinkle

I'm just wondering if anyone else is having trouble with Firefox 4 and Twinkle? I upgraded to Firefox 4 today and now it seems all my Twinkle stuff has disappeared!--5 albert square (talk) 13:50, 3 April 2011 (UTC)

I briefly ran the old Twinkle with FF4 today and it showed up in the menu, but I didn't try to do much. I use FF4 with the new Twinkle all the time, but I didn't need to change anything because of FF4. Can you be more specific about the problem? You can try to open Tools -> Error console, click on "Errors", "Clear" and then reload the page. —UncleDouggie (talk) 14:33, 3 April 2011 (UTC)
It's alright, I got it now, I reinstalled the script manually, thanks :)--5 albert square (talk) 15:46, 3 April 2011 (UTC)

Preference Duplication

So preferences has check-boxes for both Twinkle and Twinkle:Friendly. Should I have them both checked? Or only Twinkle? If only one, should we get the list cleaned up? Thanks UncleD! Ocaasi c 09:09, 8 April 2011 (UTC)

You need them both for now. As soon as we finish rewriting the legacy Twinkle modules, we will set to work on the Friendly modules and merge them at last as real Twinkle modules. After that, the second preference can be removed. —UncleDouggie (talk) 13:50, 8 April 2011 (UTC)

{{Refimprove}} up for deletion

Resolved

I have put {{Refimprove}} up for deletion. See Wikipedia:Templates_for_discussion/Log/2011_April_9#Template:Refimprove. -- Alan Liefting (talk) - 18:12, 9 April 2011 (UTC)

Thanks for the note. FTR, template was kept. Amalthea 17:54, 13 April 2011 (UTC)

Blacklist

Resolved

Hello, I have been blacklisted to use twinkle but there is a lot of time passed until then and I never faced any problems. So who do I need to speak to get my twinkle back?--NovaSkola (talk) 16:29, 13 April 2011 (UTC)

Notified admin. This would have resolved itself soon anyway. Amalthea 17:54, 13 April 2011 (UTC)

Code restructuring

We now have several developers actively working on salvaging Twinkle before the MediaWiki developers apply the HTML5 update again. (See bugzilla #27478.) We're going to centralize discussion here.

Active developers

  • UncleDouggie (talk · contribs) – previous discussion
    Status: Did a complete rewrite of the initialization code in all modules to properly remove deprecated code and for robustness in loading properly. The ordering of modules in the TW menu will now always be the same instead of being random based on which module loads first. The latest version of all the modules is currently in my directory, but others will probably be syncing to it and making further updates. I also recently rewrote all the error handling for the Wikipedia.api and Wikipedia.page classes. Task status for Wikipedia.api and Wikipedia.page:
    • Add use of the md5 hash to eliminate the need for the current hack that was added long ago to prevent page corruption during interrupted API calls. This will significantly improve overall reliability.
    • Finish handling of redirects.  Done
    • Check for edit conflicts properly.  Done
    • Test general error handling. Some error conditions are silently failing currently.  Done
    • Abstract out use of the Status class so we can upgrade to jQuery UI in the future.
    • Review all status updates.  Done
    • Add getInitialContributor() method. This may be worked by TTO.  Done
    • Add support for general revision information and reverts. This may be worked by Tcncv.
    UncleDouggie (talk) 16:44, 1 April 2011 (UTC)
    The initial version of all non-admin functions is now working, although we still have more polishing and testing to do. The trouble is that Tcncv has been AWOL for the last month and so the admin modules have made very little progress. I'm finding it difficult to rewrite the existing admin screen-scraping functions without ever having used the actual screens! I don't really have the time or stomach for the messy RfA process. Besides, I'm not that interested in being a full-time admin, I just want to get Twinkle done. Too bad we don't have a process to approve a technical admin, even on a temporary basis. Need some help here. —UncleDouggie (talk) 16:26, 11 April 2011 (UTC)
    Are you saying you can't complete this project because you don't have access to admin tools? My first thought is, whoa what admin doesn't rely on Twinkle; you're a trusted user; you should have tool access, at least on a temporary basis. So, a) ask at WP:AN if there's a provisional, limited way to get access to them; b) see if Test Wiki is a suitable alternative; c) appeal to Jimbo; d) get permission to log in under another admin's name and use the tools only in non-consequential ways (you can block me!); e) contact WMF directly, perhaps Eric Moller and ask if they can help.. A bureaucratic hold-up when a user is going out of their way to develop a tool everyone uses is a bit nuts. Ocaasi c 00:52, 12 April 2011 (UTC)
    Choosing option D, by the way, will likely earn the person who let someone else use their account a desysop and perhaps also an indef-block, and the person who used the account might also get an indef-block for same. A better option, rather than investigating any of the aforementioned options, is to place UncleDouggie's name into nomination for adminship over at WP:RFA. It is clear that UncleDouggie has a need for access to the tools, and once the RFA is complete, we'll hopefully have a new admin that can really do a stand-up job. SchuminWeb (Talk) 01:05, 12 April 2011 (UTC)
    Of course option D isn't an alternative. I don't see a whole lot of choices other than WP:RFA. The test wiki doesn't allow such use and wouldn't be sufficient if it did. —UncleDouggie (talk) 02:05, 12 April 2011 (UTC)
    Obviously (to me), I meant get permission not just from the admin but from WP:AN, WP:ARBCOM, or the WP:WMF, for an admin to 'briefly lend' an account to be used solely for testing on specific pages and in a completely transparent and non-consequential way. Ocaasi c 03:32, 12 April 2011 (UTC)
    I don't think there's a precedent for this. Just one more casualty of the currently poor RfA environment that so discourages anyone from running. Had to laugh at "completely transparent and non-consequential way". Just so long as there aren't any bugs! Of course, the alternative is to put something out there and have hundreds of admins running buggy software at the same time. That would certainly ruin your day. —UncleDouggie (talk) 04:12, 12 April 2011 (UTC)
    I don't think there's precedent for that, either, and I think it seems a bit overcomplicated anyway. Besides, if the community would think you are worthy of using the mop to test some code, why not go for the full nelson? I think it might be worthwhile to nominate you for adminship in the usual way and get you the sysop bit. What do you think? SchuminWeb (Talk) 04:23, 12 April 2011 (UTC)
    I respect Douggie's preference to not go through the hassle. You shouldn't have to be RfA'd to contribute in this way. Like the weapons manufacturer doesn't need to go through Police Academy so that he can supply the force with guns and shouldn't need to just in order to inspect their weapons so he can make them better. Not that you wouldn't likely make a great admin (or cop). p.s. I asked Kingpin13 to comment here, since he's an admin and familiar with BAG. I'm inclined to post something about this at AN myself, since it seems to be of obvious benefit, but i'd rather you make the move you prefer. Ocaasi c 04:30, 12 April 2011 (UTC)
  • twinklewarn - Built on UncleDouggie work to clean up loose ends. Operational. TODO: Convert to use new TwinkleCommon page class.
  • twinklefluff - Finished converting RevertPage and RevertTorevision functions to use the edit API undo and undoafter functions. Operational. TODO: Convert to use new Wikipedia.page class.
  • Admin functions - Currently reviewing current functionality to determine what needs to change.
  • Status: Most likely online between 00:00 and 06:00 UTC.
  • FYI - Found a workaround for the broken JQuery empty attribute exists selector - replace .find('Page[missing]') with .find('Page[missing*=""]'). This is fixed in the latest JQuery release, but Wikipedia is running an old version.

I don't know if User:Amalthea intends to participate. See previous discussion.

IRC sessions

We occasionally get together on IRC channel #wikipedia-userscripts. Wikipedia username/IRC username:

  • UncleDouggie / UncleDouggie
  • Tcncv / Tom_N
  • This, that and the other / tto -- :I'll try to get on at 06:00 daily, if possible. If there's someone else there we can discuss developments. If I'm on at any other time of day, I may just be idling and away.
  • AzaToth / AzaToth -- I'm always idling there, thus if there's something, just poke me. AzaToth 17:44, 7 March 2011 (UTC)
Proposed sessions

Testers

Module status

If you make updates to any module and have it in a running state, place the link to your copy in the Master column and move whatever link is there to the Partial column. Please put a note on your status line when you are working on a module that someone else currently has the master for. Don't forget, extensive comments, both before the code and within it, are absolutely invaluable. If we'd had these in Wikipedia.wiki.post, we might be able to know why some of the strange checks and balances got put there.

Apologies if I forgot to credit anyone for their work. — This, that, and the other (talk) 07:08, 18 April 2011 (UTC)

Baseline version Link to latest version Users involved in updating Status Notes
User:AzaToth/twinkle.js latest version at github UncleDouggie, TTO, AzaToth Thumbs up iconThumbs up iconThumbs up icon Completely rewritten: Needs review, and testing by others
User:AzaToth/morebits.js latest version at github UncleDouggie, TTO, AzaToth, tcncv Thumbs up iconThumbs up icon More stuff might be added, but I (TTO) feel that the functionality of the existing features there is pretty stable
User:AzaToth/twinklefluff.js latest version at github UncleDouggie, tcncv Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinklewarn.js latest version at github UncleDouggie, tcncv Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinklearv.js latest version at github UncleDouggie Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinklespeedy.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others (especially admins, to test the admin functionality)
User:AzaToth/twinkleprotect.js latest version at github UncleDouggie Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others (especially admins, to test the admin functionality)
User:AzaToth/twinklediff.js latest version at github UncleDouggie Thumbs up iconThumbs up iconThumbs up icon No changes needed, so long as Wikipedia.api remains backwards compatible.
Changes made for new loader.
User:AzaToth/twinkleprod.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinklexfd.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinkleimage.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinkleunlink.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:AzaToth/twinkledelimages.js github version out of date User:Tcncv/twinkledelimages.js Analyzing Requires admin tester
User:AzaToth/twinkledeprod.js User:Tcncv/twinkledeprod.js Analyzing Requires admin tester
User:AzaToth/twinklebatchdelete.js User:Tcncv/twinklebatchdelete.js  Working Requires admin tester
User:AzaToth/twinklebatchprotect.js User:Tcncv/twinklebatchprotect.js Analyzing Requires admin tester
User:AzaToth/twinkleimagetraverse.js User:Tcncv/twinkleimagetraverse.js Analyzing Requires admin tester
User:AzaToth/twinklebatchundelete.js User:Tcncv/twinklebatchundelete.js  Working Requires admin tester
Apparently rarely used; may not be worthwhile updating
User:AzaToth/twinkleundelete.js User:Tcncv/twinkleundelete.js  Working Requires admin tester. Not part of standard feature set.
twinkleconfig.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon New module: Needs review, and testing by others
User:Ioeth/friendlytag.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:Ioeth/friendlywelcome.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:Ioeth/friendlytalkback.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others
User:Ioeth/friendlyshared.js latest version at github TTO Thumbs up iconThumbs up iconThumbs up icon Needs review, and testing by others

Thumbs up icon means that the module should now work with HTML 5. It doesn't mean that it's completely done and tested, including handling all possible error conditions.

Thumbs up iconThumbs up icon means that the module is close to final code, including proper use of Wikipedia.page and/or Wikipedia.api.

Thumbs up iconThumbs up iconThumbs up icon means that the module is complete and ready for review.

Thumbs up iconThumbs up iconThumbs up icon means that the module has been reviewed and is ready for beta testing.

 Done means that the module is ready to go live.

Extended content

I made a zip file of the entire live Twinkle source tree that I'll send to anyone who sends me an email with the email user feature. I have it setup so I can instantly search the entire tree for dependencies. —UncleDouggie (talk) 08:14, 27 February 2011 (UTC)

I'm editing code offline with an editor that actually understands JavaScript and then pasting it back into Wikipedia. I suppose I could even use the API, but maybe not today. ;-) Let's all please stick with the tab indenting style. Everyone may have different tab stops setup, but as long as no one reverts to spaces we'll be OK.

Baseline code size is 11293 non-blank lines. —UncleDouggie (talk) 11:32, 27 February 2011 (UTC)

Loading the new Twinkle

The Twinkle loader has been completely rewritten. The default is now to load the modules minified and to allow for caching. For debugging purposes, it is necessary to disable this behavior by putting the following in your custom .js file:

TwinkleConfig.debug = true; // don't minify scripts, bypass cache

When using Firefox with Firebug for debugging, the only way currently to display the module source is to load it using the deprecated method. To enable this, put the following in your custom .js file, which overrides any setting of TwinkleConfig.debug:

TwinkleConfig.debugFirefox = true; // use old import method for Firefox debugging

When debugging the twinkle.js loader in Opera, you must load the script in your custom.js file using mw.loader.load with debug and no caching because there is no reliable way to bypass the Opera cache after making changes. However, if using Firefox, you need to use the old importScript() instead. We almost need a loader for the loader.

It is no longer possible to directly load morebits.js and individual modules. To use a subset of the modules, you must now fork twinkle.js and remove the modules you don't want. —UncleDouggie (talk) 17:49, 2 April 2011 (UTC)

If you use mw.loader.load and pass it an URL, you won't actually get a minified version. All it does is inject a script node with that url as a source; it's simply a poorer implementation of importScript.
I've looked at the resource loader a few days ago to figure out how to load an arbitrary script properly minified and combined, but as far as I can tell there is no way to do that, all those modules need to be set up in PHP.
The only gross workaround that came to mind was to create users for each Twinkle module, you can then load their script files minified and cached. :)
Amalthea 21:06, 2 April 2011 (UTC)
You're very right. I thought I saw something in Firebug that looked like a minified Twinkle module, but I was mistaken. I've posted the details of my painful experience. The multiple user hack is certainly innovative, but I'm not sure that I want that complexity.
I ran some load timing tests using a small wikipage in Firefox 4. All tests were done reloading from cache. A full load from the server is obviously longer. The combined, non-minified twinkle source is currently 455 kB. Minified it is 340 kB. Loading using a single file in non-minified form saves 1 second over loading the files separately. The same thing minified saves an extra 1 second. This is a very noticeable difference. With all my gadgets, user scripts and the standard Twinkle loader, it takes me 5 seconds to fully render a small page from cache. Switching to a single, minified Twinkle file cuts it down to 3 seconds. Your mileage will certainly vary.
I like maintaining the source as individual modules. However, we're using github for the repository so there's little need for separate files on-wiki. We could just replace twinkle.js with the minified file. Or, we could place the expanded source into a new user account as a single file so we can load it minimized on the fly from twinkle.js. All this is of course complicated by other users of morebits.js, but that part makes my head hurt right now. —UncleDouggie (talk) 09:46, 3 April 2011 (UTC)
If anyone else wants to test the timing, I've uploaded the minified version in a stand-alone file suitable for use with importScript(). Beware that this is a development snapshot that probably has bugs and not all modules have been finished. However, it should fully load and render the TW menu properly. The warning module is fairly safe to use. Feel free to drop as many warnings as you like on User talk:UncleDouggieTest2. Since I went back to importScript() in the standard loader, the load time has improved considerably, but it might also just be that the servers are very lightly loaded at this hour. It would be useful if others could test the difference. Just reload several times to get a good average time. —UncleDouggie (talk) 11:27, 3 April 2011 (UTC)

Github usage

I took the plunge and setup git as my seventh configuration control system. We have a public repository at https://github.com/azatoth/twinkle that tto and I have write permission for currently. The initial setup was rather messy with strange diffs due to stripping of some trailing spaces, hanging branches and two forks. I injected some sanity by reloading the baseline files from Wikipedia with the trailing spaces, deleting the branches and dropping my fork. I think we should use it as a Centralized Workflow instead of an Integration-Manager Workflow. Although, tto is welcome to keep his fork if he doesn't mind the extra work to keep it in sync and is willing to figure out how to deal with the occasional remote repository fork apply conflicts. I'm perfectly happy to limit myself to resolving merge conflicts locally after a fetch, now that I've got that much figured out.

The baseline files from User:AzaToth, as of 26 February 2011, are tagged as "baseline" and all have a commit comment of "rollback n", where n is 1, 2 or 3. The latest rollback commit is what's tagged as the baseline. The rollbacks are the result of how I pruned the branches that AzaToth had started for us, this being my first day using git and all. At least I got it to work. On top of the baseline, I committed my morebits and twinklewarn. At that point, I was able to do a straight apply on the github website of tto's forked morebits with the create/recreate methods added. Before I rebuilt things, it wouldn't let me perform that apply. I haven't yet applied the changes from tcncv, but that's an easy thing to do. Developers can create local branches if they like. I don't think we need to push those branches to github for now, although we could during the testing if we need to continue work at the same time. Just merge anything you have back into your local master branch and then push that to github.

tto: Don't continue to work on your local morebits with the stripped spaces any further. I recommend deleting everything and then cloning straight from azatoth/twinkle.

Now for the best part: AzaToth has left us a present in the form of a perl script that it is claimed will push all of our local scripts directly to Wikipedia using the API! I'm going to have to eat my original joke about doing this. It's been a little painful getting it to run, having to compile a new version of Perl and all, but I'm pretty close. I just have a few library dependencies left to get installed. Perl plus the Wikipedia API. The possibilities are endless, but I don't think I'm going to get into the BOT business just yet. —UncleDouggie (talk) 06:40, 7 March 2011 (UTC)

I've finished my github setup along with the perl sync script. I can now push/pull the entire Twinkle tree to/from both github and my Wikipedia userspace with a single command. This will certainly make it easy to setup the beta tree error-free when we're ready. The github diffs are a huge improvement over what's provided by MediaWiki. Github and my userspace are currently in sync, with the exception of twinkle.js, which I only sync manually because everyone has a different one. The other scripts are the baseline from AzaToth, plus my morebits (with Tto's create/recreate), my twinkewarn (a Wikipedia.page compliant version of what Tcncv had expanded from my original work), and Tcncv's twinklefluff. I believe that both Tcncv and Tto have other local work that hasn't been uploaded to github yet. Let's please try to get everything up there so we have a consistent picture of the modules. Thanks! —UncleDouggie (talk) 06:33, 8 March 2011 (UTC)

Ajax library deprecation

The most important issue as I see it is that the whole ajax.js library has been deprecated in favor of jQuery.ajax. Therefore, I've been trying to drop the ajax.js library as much as possible when I do updates. I still have some in the standalone ARV tool in fact, but I didn't change that portion. Redoing things twice doesn't make a lot of sense to me. I know this is a major upset to the Twinkle codebase and I don't think we need to convert the whole thing today. I do think it would be good if our rewrites are as future-proofed as possible. Once we decide this issue, we can then make more detailed plans. —UncleDouggie (talk) 05:13, 27 February 2011 (UTC)

If we can keep all API calls channeled through the Twinkle wikibits functions, we can convert that from ajax to JQuery with minimal impact to the other modules. I think dropping the JQuery call in as a replacement for the current ajax call should not be a big deal. Both will take the API parameter list, call the API, and upon receiving the XML results, invoke the callback function. There might be some tweaking of error handling, but that should have minimal impact on the calling code. -- Tom N (tcncv) talk/contrib 05:27, 27 February 2011 (UTC)
(edit conflict) Oho! Well, that throws a spanner in the works. We have to convert morebits to use jQuery!! What a nuisance. Anyway, that's a slightly longer-term consideration than the impending HTML5 switching-back-on, and it shouldn't be too difficult (in fact, only Wikipedia.api.post, Wikipedia.wiki.postget, and Wikipedia.wiki,post use AJAX out of all of morebits.js). The main thing I was hinting at was the importance of making a central function in morebits.js for using the API for editing, as without this there will be a lot of code duplication and unnecessary XPath calls.
So in other words, the most pressing concern is to get Twinkle using the edit API. I suggest using my wikipedia.editPage function (at User:This, that and the other/morebits.js, and which probably needs to be applied to the main copy of morebits before any more work can occur), but if anyone has a superior alternative, I'm sure we'll all be happy to hear about it. — This, that, and the other (talk) 05:30, 27 February 2011 (UTC)
I like the new functions you added to User:This, that and the other/morebits.js. They look very similar to the API calls I currently have in the warn module User:Tcncv/twinklewarnTest.js (diff from original), after building on UncleDouggie's initial work. The new code used the twinkle wikibits Wikipedia.api class, and no longer uses the Wikipedia.wiki class. I suspect we may eventually be able to eliminate the Wikipedia.wiki class, simplifying the wikibits upgrade. On a side note, diff doesn't seem to handle tab vs space changes very well, so I'd recommend keeping a consistant indentation style. -- Tom N (tcncv) talk/contrib 05:44, 27 February 2011 (UTC)
By the time we're done with the update, the entire Wikipedia.wiki class will be gone because it's fundamentally incompatible with HTML 5. I was always planning to make a central function in morebits.js for using the API for editing, I had just hacked together my twinklewarn.js temporarily to get us running again. I would prefer for anything new we do to use the jQuery library since it isn't that much more work. Much of our effort will be in testing and I'd rather not do that twice. —UncleDouggie (talk) 06:23, 27 February 2011 (UTC)
Wikipedia.wiki is still good for marking pages as patrolled and suchlike, when we don't actually care about the output we get back from the server. But I agree that its use should be phased out. I think one task we do need to do is identify why all the fancy-looking lag checks and retrying code, etc. in Wikipedia.wiki.post are there, and if applicable add them to Wikipedia.api.
Regarding indentation style, I really don't know what causes this issue. I know I have my text editor set to using tab characters (which is apparently the usual style for Twinkle code). But I suspect Firefox or something else (possibly the wikEd gadget which I use?) mangles them into spaces. I would love to get to the bottom of this if I could, because it makes cross-page diffs next to useless. — This, that, and the other (talk) 06:33, 27 February 2011 (UTC)
Good point on the patrolled issue. Let's leave that for the end. On indentation style, the number one culprit for me is wikEd. If I turn it off, all is well. I agree that we need to keep consistency for diffs or we'll be sorry. —UncleDouggie (talk) 06:40, 27 February 2011 (UTC)
I'm going to call it a night, but I'll take a stab at replacing the code in the Wikipedia.api post function with equivalent JQuery code tomorrow. As for functions like mark-patrolled, those would be very simple API calls, so I'd recommend converting them to the API as well, especially if it will let us eliminate the current form of the Wikipedia.wiki class. I agree with This-That that we need to take a close look at the subtle housekeeping functions that likely represent years of troubleshooting. -- Tom N (tcncv) talk/contrib 06:55, 27 February 2011 (UTC)

Other deprecations

I've grep'd the entire codebase of all instances of other methods scheduled to be deprecated. Please try to eliminate these during the updates. —UncleDouggie (talk) 01:48, 28 February 2011 (UTC)

morebits.js:    if (skin=="vector") appendCSS( ...
morebits.js:    else if (skin=="modern") appendCSS( ...
morebits.js:            var xmlhttp = sajax_init_object();
morebits.js:            var xmlhttp = sajax_init_object();
morebits.js:            var xmlhttp = sajax_init_object();
morebits.js:addOnloadHook(function()
(done) twinkle.js:importScript('User:AzaToth/morebits.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklefluff.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklewarn.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklearv.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklespeedy.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklediff.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkleprotect.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkleprod.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklexfd.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkleimage.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkleunlink.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkledelimages.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkledeprod.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklebatchdelete.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklebatchprotect.js');
(done) twinkle.js:        importScript('User:AzaToth/twinkleimagetraverse.js');
(done) twinkle.js:        importScript('User:AzaToth/twinklebatchundelete.js');
twinklediff.js: var ntitle = getElementsByClassName( document.getElementById('bodyContent'), 'td' , 'diff-ntitle' )[0];
twinklefluff.js:                var ntitle = getElementsByClassName( document.getElementById('bodyContent'), 'td' , 'diff-ntitle' )[0];
(done) twinklefluff.js:addOnloadHook( function() {

Wikipedia.api class

There are 137 references to the Wikipedia.api class in the baseline modules.

twinklearv.js:0
twinklebatchdelete.js:12
twinklebatchprotect.js:6
twinklebatchundelete.js:3
twinkledelimages.js:9
twinkledeprod.js:9
twinklediff.js:3
twinklefluff.js:9
twinkleimage.js:6
twinkleimagetraverse.js:16
twinkleprod.js:6
twinkleprotect.js:0
twinklespeedy.js:21
twinkleunlink.js:3
twinklewarn.js:0
twinklexfd.js:34

Twinkle currently uses XPath to query the XML returned by the ajax.js calls in Wikipedia.api. We're going to be adding lots of new queries when we replace the Wikipedia.wiki class, whether they be in the new Wikipedia.page class or directly in the modules. It's better to use the jQuery.find library to perform the parsing, which has much more intuitive syntax than XPath. Sample code using jQuery.find from my update of the standalone aiv.js tool:

   success: function(xml){
       var pagetext = $(xml).find('rev').text();
       var edittoken = $(xml).find('page').attr('edittoken');

There are also methods such as "foreach" that allow easy traversal of multiple instances of an element.

User:Tcncv/twinklewarnTest.js has jQuery.find working with the .XMLresponse returned from the ajax.js call in the baseline morebits.js.

User:UncleDouggie/twinklecommon.js has now been upgraded to use jQuery.ajax in Wikipedia.api. It even worked the first time, although I did put a lot of thought into those 17 lines of code. All my changes are in Wikipedia.api.prototype. You can merge it into whatever other version you're working on. I had first tried running with the in-work version from This, that, but it appears to have a syntax error so I reverted to building on the base module. I tested it using Tom's latest version of the warning module. I also did a CSD on a userpage using the stock speedy module. That one has several .api references, but I don't know if my tagging actually used any. —UncleDouggie (talk) 16:52, 27 February 2011 (UTC)

I've fixed the syntax error in my version of morebits. So, it actually works now. Sorry about that - I was tired and left some half-completed code in there. — This, that, and the other (talk) 06:18, 28 February 2011 (UTC)

Wikipedia.page class

Now that I've fully digested it, I really like Tom N's suggestion on my talk page to create a wrapper class around the API to simplify the modules. The Wikipedia.editpage class is a first step in that direction. Let's try to work out the interface here and get it done. —UncleDouggie (talk) 07:12, 27 February 2011 (UTC)

Tom's suggestion: The Wikipedia.page class will allow the main routines to simply get the page, modify the text, set the summary, and save with all the details of query parameters, edit tokens, timestamps, handled within the class.

Wikipedia.page class user documentation
 * Class: Wikipedia.page
 * Uses the MediaWiki API to load a page and optionally edit it.
 *
 * Callers are not permitted to directly access the properties of this class!
 * All property access is through the appropriate getProperty() or setProperty() method.
 *
 * Callers should set Wikipedia.actionCompleted.notice and Wikipedia.actionCompleted.redirect
 * before the first call to Wikipedia.page.load().
 *
 * Each of the callback functions takes one parameter, which is a
 * reference to the Wikipedia.page object that registered the callback.
 * Callback functions may invoke any Wikipedia.page prototype method using this reference.
 *
 * Constructor: Wikipedia.page(pageName, currentAction)
 *    pageName - the name of the page, prefixed by the namespace (if any)
 *               (for the current page, use wgPageName)
 *    currentAction - a string describing the action about to be undertaken (optional)
 *
 * load(onSuccess, onFailure): Loads the text for the page
 *    onSuccess - callback function which is called when the load has succeeded
 *    onFailure - callback function which is called when the load fails (optional)
 *                *** onFailure for load() is not yet implemented – do we need it? ***
 *
 * save(onSuccess, onFailure): Saves the text for the page. Must be preceded by calling load().
 *    onSuccess - callback function which is called when the save has succeeded (optional)
 *    onFailure - callback function which is called when the save fails (optional)
 *    Warning: Calling save() can result in additional calls to the previous load() callbacks to
 *             recover from edit conflicts!
 *             In this case, callers must make the same edit to the new pageText and reinvoke save().
 *             This behavior can be disabled with setMaxConflictRetries(0).
 *
 * append(onSuccess, onFailure): Adds the text provided via setAppendText() to the end of the page.
 *                               Does not require calling load() first.
 *    onSuccess - callback function which is called when the method has succeeded (optional)
 *    onFailure - callback function which is called when the method fails (optional)
 *
 * prepend(onSuccess, onFailure): Adds the text provided via setPrependText() to the start of the page.
 *                                Does not require calling load() first.
 *    onSuccess - callback function which is called when the method has succeeded (optional)
 *    onFailure - callback function which is called when the method fails (optional)
 *
 * getPageName(): returns a string containing the name of the loaded page, including the namespace
 *
 * getPageText(): returns a string containing the text of the page after a successful load()
 *
 * setPageText(pageText)
 *    pageText - string containing the updated page text that will be saved when save() is called
 *
 * setAppendText(appendText)
 *    appendText - string containing the text that will be appended to the page when append() is called
 *
 * setPrependText(prependText)
 *    prependText - string containing the text that will be prepended to the page when prepend() is called
 *
 * setEditSummary(summary)
 *    summary - string containing the text of the edit summary that will be used when save() is called
 *
 * setMinorEdit(minorEdit)
 *    minorEdit is a boolean value:
 *       true  - When save is called, the resulting edit will be marked as "minor".
 *       false - When save is called, the resulting edit will not be marked as "minor". (default)
 *
 * setMaxConflictRetries(maxRetries)
 *    maxRetries - number of retries for save errors involving an edit conflict or loss of edit token
 *    default: 2
 *
 * setMaxRetries(maxRetries)
 *    maxRetries - number of retries for save errors not involving an edit conflict or loss of edit token
 *    default: 2
 *
 * setCallbackParameters(callbackParameters)
 *    callbackParameters - an object for use in a callback function
 *
 * getCallbackParameters(): returns the object previous set by setCallbackParameters()
 *
 *    Callback notes: callbackParameters is for use by the caller only. The parameters
 *                    allow a caller to pass the proper context into its callback function.
 *                    Callers must ensure that any changes to the callbackParameters array
 *                    within a load() callback still permit a proper re-entry into the
 *                    load() callback if an edit conflict is detected upon calling save().
 *
 * getStatusElement(): returns the Status element created by the constructor
 *
 * setFollowRedirect(followRedirect)
 *    followRedirect is a boolean value:
 *       true  - a maximum of one redirect will be followed.
 *               In the event of a redirect, a message is displayed to the user and
 *               the redirect target can be retrieved with getPageName().
 *       false - the requested pageName will be used without regard to any redirect. (default)
 *
 * setWatchlist(watchlistOption)
 *    watchlistOption is a boolean value:
 *       true  - page will be added to the user's watchlist when save() is called
 *       false - watchlist status of the page will not be changed (default)
 *
 * setWatchlistFromPreferences(watchlistOption)
 *    watchlistOption is a boolean value:
 *       true  - page watchlist status will be set based on the user's
 *               preference settings when save() is called
 *       false - watchlist status of the page will not be changed (default)
 *
 *    Watchlist notes:
 *       1. The MediaWiki API value of 'unwatch' isn't used here because it seems to behave
 *          the same as 'nochange'. Not sure why we would want this option anyway.
 *       2. If both setWatchlist() and setWatchlistFromPreferences() are called,
 *          the last call takes priority.
 *       3. Twinkle modules should use the appropriate TwinkleConfig parameter to set the watchlist options.
 *       4. Most Twinkle modules use setWatchlist().
 *          setWatchlistFromPreferences() is only used for the few TwinkleConfig watchlist parameters
 *          that accept a string value of 'default'.
Wikipedia.page class internal documentation
 * Call sequence for common operations (optional final user callbacks not shown):
 *
 *    Edit current contents of a page (no edit conflict):
 *       .load() -> Wikipedia.api.post() -> .callbacks.loadSuccess() -> userTextEditCallback() ->
 *                  .save() -> Wikipedia.api.post() -> .callbacks.saveSuccess()
 *
 *    Edit current contents of a page (with edit conflict):
 *       .load() -> Wikipedia.api.post() -> .callbacks.loadSuccess() -> userTextEditCallback() ->
 *                  .save() -> Wikipedia.api.post() -> .callbacks.saveFailure() ->
 *       .load() -> Wikipedia.api.post() -> .callbacks.loadSuccess() -> userTextEditCallback() ->
 *                  .save() -> Wikipedia.api.post() -> .callbacks.saveSuccess()
 *
 *    Append to a page: (similar for prepend)
 *       .append() -> .load() -> Wikipedia.api.post() ->
 *                    .callbacks.loadSuccess() -> .callbacks.autoSave() ->
 *                    .save() -> Wikipedia.api.post() -> .callbacks.saveSuccess()
 *
 *    Notes:
 *       1. All functions following Wikipedia.api.post() are invoked asynchronously
 *          from the jQuery AJAX library.
 *       2. In the case of .edit(), .callbacks.loadSuccess() performs one re-entry into .load()
 *          when following a redirect.
 *       3. In the case of .append() or .prepend(), .callbacks.loadSuccess() performs two re-entries 
 *          into .load() when following a redirect. The first re-entry is to retrieve the
 *          redirect target and the second is to verify that the target is not itself a redirect.
 *       4. Edit conflicts do not result in additional re-entries due to redirects because the
 *          resolved page name is retained from the first edit attempt.
 *       5. The sequence for append/prepend could be slightly shortened, but it would require
 *          significant duplication of code for little benefit.

Methods in Tom's message that aren't implemented yet:

  • FindPriorUserRevision(callback)
  • RevertToReveision(callback)

Properties in Tom's message that aren't implemented yet:

  • latestRevision
  • latestUser
  • priorUserRevision
  • priorUser
  • LastResult?
  • LastMessage?

The class will focuses on functions that make the mainline code smaller and easier to read, understand, and maintain. Some application-specific functions can be included to handle tasks like finding the appropriate insertion point on a page, adding a section heading, or other operations where we find that the same 10-20 lines of code are currently duplicated in two or more places.

By creating this class, we open ourselves to more reuse than the current modules have. We don't need to create all the methods up front. As we update a module, we can just place the common code it needs in this class and let the module focus on its unique needs.

The initial proposal was the result of about a five minute analysis, so it's definitely open to rework. It might be better to think of it as an "apiResponse" class rather than just a page class, but could incorporate both general and page-specific functions. The main intent was to capture the API response XML in a class that contains a variety of convenience functions and properties to simplify mainline code. For example, there's no need for the mainline code to concern itself with edittokens and starttimestamps, if this can be encapsulated in a page get/put class. Most JQuery expressions could be implemented as convenience functions or properties, so that mainline code could reference wikiApiResponse.text instead of $(xml).find('rev').text();. -- Tom N (tcncv) talk/contrib 18:20, 27 February 2011 (UTC)

The class has been briefly exercised using twinklewarn.js. Error handling still needs a lot of work. We should now be able to add more methods following the same pattern used for .get and .save(). Please give it a good review and see if you like the method signatures vs. what is set through properties before we get too deep into updating the modules to use the class. I see several things we could probably do to make the naming scheme a bit more consistent. —UncleDouggie (talk) 13:34, 1 March 2011 (UTC)

It appears we have two versions of the Wikipedia.Page class under parallel development (User:This, that and the other/morebits.js and User:UncleDouggie/twinklecommon.js). Both seem to have similar core get-edit-save support, but each also has other distinct functionality. Could you two work together to merge the best of both? -- Tom N (tcncv) talk/contrib 01:39, 2 March 2011 (UTC)
I think the get/save model is preferable to an edit method because it gives the modules more flexibility to query multiple pages and then decide what if anything needs to be updated. It would be great if both of you could update my version to add the missing methods and merge in the extra features from This, that. I won't be doing any work for the next 24 hours. —UncleDouggie (talk) 02:01, 2 March 2011 (UTC)
I like UncleDouggie's work. It looks good, and (ought to) work well. I will reconcile his modifications with mine. Once ResourceLoader is used for loading these scripts, all comments will be removed when the script is downloaded to the browser, so do not hesitate from writing long, documentation-rich comments, as I have been doing.
On the matter of morebits/twinklecommon, there is no reason why non-Twinkle consumers will not want to use Wikipedia.page. There is very little Twinkle-specific information in morebits.js, as many other morebits-based user scripts (like the formerly separate Friendly, for example) use a lot of functionality that Twinkle uses too. I don't think any name change for this file is necessary, and will only cause headaches. — This, that, and the other (talk) 05:03, 2 March 2011 (UTC)
Now that I've had more time to think about it, I tend to agree. I had originally assumed that morebits was a twinkle module that other scripts adopted, but now understand that it was intended as a general module for which twinkle was just one client (subtle difference). If we can be sure of maintaining backward compatability, we can keen the morebits name. If we are unsure of compatability, perhaps morebits2. I look forward to seeing the merged module.
UncleDouggie and I had an IRC discussion regarding error detection and retry logic. We decided if would be best to set separate retry options for edit-conflicts and other errors. Retrying after a comm glitch or other general error might be desired across the board, while retry after an edit conflict might be handled differently on talk pages, articles, and assortid notice boards. The action would be different also. A general error might just rety the current action. An invalid token error would require an extra step to retrieve a fresh token. An edit conflict retry would involve re-retrieving the latest version of the page, invoking the callback to modify the page again, and retrying the save.
As for implicit save vs explicit save, I could go either way. To me, the test is how clean and understandable is the minimal code to get, alter, and save an article. I think the two methods are close enough for me to call a tie. Perhaps we should put together a couple of code fragments and ask other script-maintainers to comment. -- Tom N (tcncv) talk/contrib 07:52, 2 March 2011 (UTC)
AzaToth asked me to comment here -- I've been working on a jQuery-based API framework for MediaWiki. In particular I wrote a method to handle getting edit tokens, and editing pages, fairly cleanly and with little code. Since jQuery is already loaded on every MediaWiki page these days you may find it useful. For now it lives in extensions/UploadWizard, I'm maybe a few days away from moving it out of the UploadWizard extension in to the general resources/ directory in 1.17.
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UploadWizard/resources/mw.Api.js
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UploadWizard/resources/mw.Api.edit.js
It may be hard to see how to use all this stuff together. Basically the "postWithEditToken" is a wrapper to another API call; you don't have to manually fetch the token, it will handle that for you.
var api = new mw.Api( { url: "http://sample.com/api.php" } );
var params = { ...params for your API call that requires an edit token... };
var success = function() { ...what you want to happen on success... };
var failure = function() { ...what you want to happen on failure... };

// will transparently obtain new edit token and stash it in API, then do your api call
api.postWithEditToken( params, success, failure );
NeilK (talk) 20:08, 2 March 2011 (UTC)
Your code handles the low-level API interface with much greater sophistication than our current Wikipedia.api class, and it could potentially be a replacement for that class or we could beef up Wikipedia.api accordingly. We've already upgraded Wikipedia.api to use jQuery, but it's still pretty bare bones as it was in the legacy module. While your class does manage the edit token, it doesn't provide any of the other features that we currently have in Wikipedia.page. The only code a caller needs to have to use our current class is:
  ...
  var page = new Wikipedia.page(wgPageName);
  page.setCallbackParameters('Text to add to article goes here');  // an object is passed for multiple parameters
  page.setEditSummary('Edit summary goes here');
  page.setFollowRedirect(true);  // follow up to one redirect
  page.load(pageLoadSuccess);
}

pageLoadSuccess = function(page) {

  // add prepared text to the end of the article
  page.setPageText(page.getPageText() + page.getCallbackParameters());
  page.save();
}
We also support extra options and will be adding more, but you can see that the callers have life very easy. The class automatically recovers from errors due to edit tokens and edit conflicts, among others, with no extra caller support. For this simple case of adding text to the end of a page, the caller will be able to override the action to directly append the text with no callback, but I wanted to show the more general case, which is still dirt simple. I'm thinking about changing the use of params to a callback argument, as you have done, to avoid having the clients stuff anything into the Wikipedia.page object.
I take it that you haven't finished your testing yet. You have a fatal bug in mw.Api.edit.js on line 45. —UncleDouggie (talk) 22:46, 2 March 2011 (UTC)
For a simple append operation, the class now supports:
  var page = new Wikipedia.page(wgPageName);
  page.setAppendText('Text to add to article goes here');
  page.setEditSummary('Edit summary goes here');
  page.setFollowRedirect(true);  // follow up to one redirect
  page.append();
Perhaps a layered approach. With each layer building on the layer below it by providing functions that implement typical usage of the layer below.
  • Layer 1 - Call the API using a given set of parameters and return the XML (by default) result to the callback function. A.k.a,. Wikipedia.api.
  • Layer 2 - A page class that implements common page functions such as Get and Put (or Save) plus a few other common convenience functions that we choose to place at this level. The basic method calls could be kept simple, but options (such as follow redirects, and retry options) could be set as page object properties before calling a method. This is close to UncleDouggie's implementation, but with some elements from TTO's implementation.
  • Layer 3 - One or more more complicated functions such as EditPage that combines the Get and Save functions. (Similar to TTO's implementation.) Convenience functions to find the appropriate insertion point (based on certain known page types), to insert a dated header when needed, or to scan for recent prior activity could be provided.
  • layer 4 - Application-specific functions. (In our case - Twinkle.) A place for miscellaneous reusable code, such as the Twinkle configuration stuff at the top of morebits.js. This could become twinklecommon.js, while the other items above would be part of morebits.
We actually already have a layered approach, but I'm all in favor of building additional common functions if they can be reused and will simplify the code in the main routines. -- Tom N (tcncv) talk/contrib 02:03, 3 March 2011 (UTC)
No worries, it's offered in the hope that it will be useful. Don't change what you're doing if it works for you. This could potentially be a layer beneath your stuff, but there's no rush to merge everything. NeilK (talk) 20:14, 3 March 2011 (UTC)

Wikipedia.wiki class

We plan for this class to go away during the update process. This section is for discussion of general issues encountered with transitioning away from the class.

There are 270 references to the Wikipedia.wiki class in the baseline modules. Ugh! Short straw gets twinklexfd.js. Wait, I see that This, that has already claimed it. Whew. Glad I didn't post the stats too soon.

twinklearv.js:26
twinklebatchdelete.js:17
twinklebatchprotect.js:4
twinklebatchundelete.js:3
twinkledelimages.js:10
twinkledeprod.js:14
twinklediff.js:0
twinklefluff.js:6
twinkleimage.js:13
twinkleimagetraverse.js:10
twinkleprod.js:8
twinkleprotect.js:10
twinklespeedy.js:36
twinkleunlink.js:14
twinklewarn.js:4
twinklexfd.js:95

UncleDouggie (talk) 11:26, 27 February 2011 (UTC)

Although I haven't specifically scanned the above modules, I suspect that most of them contain recurring patterns of:
  • Get latest version of page.
  • Find appropriate insertion point in the text.
  • Insert new content at that insertion point.
  • Save the updated page.
  • (future?)If an edit conflict is detected, retry.
By moving many of the details into the page class discussed above, many of the mainline code changes may be fairly straightforward, repetitive work. -- Tom N (tcncv) talk/contrib 18:33, 27 February 2011 (UTC)

twinklewarn.js

Tom N, please elaborate on your talk page comment regarding your concern that the previously used Wikipedia.wiki class has some extra functionality that you haven't fully analyzed and is absent in your version. Can we add this functionality to Wikipedia.page or is it specific to the warning module? —UncleDouggie (talk) 07:29, 27 February 2011 (UTC)

I noticed code that referenced throttling, lag time, handling loss of session data (expired edittoken) and a few other details. The new code would work without this, but since someone thought it necessary to add such logic in the past, we should take a look to determine if it should be incorporated in the new page class. The logic is not specific to twinklewarn. -- Tom N (tcncv) talk/contrib 18:49, 27 February 2011 (UTC)

morebits.js

Can we rename morebits.js already to something more meaningful? The only reference to the name is in twinkle.js. I've heard options for twinklecommon.js, twinklebits.js and wikibits.js. I like twinklebits.js. What do you think? —UncleDouggie (talk) 08:43, 27 February 2011 (UTC)

Um, I don't think so. morebits.js isn't just used by Twinkle. It's the foundation for many, many Wikipedia user scripts. We certainly can't change its name. Also, we probably cannot remove Wikipedia.wiki for the time being, as other consumers might still be using for non-screen-scraping purposes. — This, that, and the other (talk) 08:55, 27 February 2011 (UTC)
In that case, I recommend that we don't touch the current morebits.js and instead create a new one for Twinkle. No sense disrupting the world. If we are reasonably backwards compatibile, users may be able to just re-home their scripts to the new version, but they'll be able to do this at their leisure with adequate testing. —UncleDouggie (talk) 09:16, 27 February 2011 (UTC)
Also, perhaps wikibits.js is a better name given it's eventual goal of replacing morebits.js for everyone. —UncleDouggie (talk) 09:23, 27 February 2011 (UTC)
I'm in favor of a rename. I find it confusing to have the same name as one of the core mediawiki scripts. My preference is either twinklecommon.js or twinklebits.js. If it becomes the basis for a project-wide standard, we can rename and generalize it as a future project with a wider participation. -- Tom N (tcncv) talk/contrib 18:59, 27 February 2011 (UTC)
twinklecommon.js it is! —UncleDouggie (talk) 02:08, 28 February 2011 (UTC)

Well it looks like I got us into a fine mess with this rename, but there aren't many good solutions. I was running Firebug today and I noticed that User:AzaToth/morebits.js was loaded! It was being invoked from some other user script in my custom js file. It seems like twinklecommon.js is taking precedence, at least for me, because when I put a break point in my Wikipedia.api class, I do hit it. However, this isn't a stable set of affairs, especially with regards to Wikipedia.api, because it exists in both files. I'm not sure how much of the rest of twinklecommon.js is being used by the Twinkle modules. Things are getting more messy because I had to add an extra argument on the Wikipedia.api constructor tonight for proper error handling. I just put it at the end of course. Here are our options:

  1. Go back to morebits.js and force the rest of the world to adapt to whatever changes we need to make to get Twinkle running. They're all about to break anyway when HTML 5 gets turned back on.
  2. Stay with twinklecommon.js, rename the Wikipedia object in it to Twinkle, and remove everything else. We would need to update all modules, but that's just a global replace. Since some modules probably need things from the old morebits.js, we can just include it. Although, it does have the TwinkleConfig object, and we can't rename that!

Another consideration is that from all the pain we're going through to develop Wikipedia.page, it's pretty clear that any user script that wants to live to see another day is going to need to use our new class. The task of converting twinklearv.js looked downright overwhelming last night, but with Wikipedia.page, it's no big deal. I literally converted Tom's twinklewarn.js in 10 minutes. arv has 10 times as many calls, but I'll take 100 minutes any day over the previous nightmare. This would perhaps argue for option 1. To do this, we would need to carefully analyze the error handling in the old Wikipedia.api class and make sure we have a superset of it as opposed to a possibly disjoint set.

When you put in a comment that just says "necessary evil", you can be assured that some hapless programmer is going to have to learn the lesson the hard way all over again. —UncleDouggie (talk) 13:00, 1 March 2011 (UTC)

We have decided to go back to the morebits.js name for now. We may still pull out a few Twinkle unique items into a twinklecommon.js, but that's not our immediate concern. —UncleDouggie (talk) 05:06, 3 March 2011 (UTC)

Integration

I recommend that we all work on local copies for now and not commit anything to the live version or we're sure to have users screaming at us. We don't need the distraction. I think I'll also setup a common beta tree for final testing. We can invite a few users at a time to try out the new stuff and have a way to easily revert them back without messing up the tree.

For our local copies, let's use the convention of "User:username/module.js", with nothing extra on the names like "test". Anything with the name "test" should be for temporary troubleshooting. This way we'll all be able to find each others latest copies anytime.

For the beta tree, let's use "User:UncleDouggie/beta/module.js". Tom can copy into that anytime since he's an admin, so this way we'll have two of us able to do updates when life gets busy. We can then invite people for a test drive by having them turn off their gadget and import User:UncleDouggie/beta/twinkle.js. When we really think we're ready, we can just copy the contents of User:UncleDouggie/beta/twinkle.js to User:AzaToth/twinkle.js some fine morning and cross our fingers. Theoretically, no one will notice the difference. In the very unlikely event that we screw something up, it just takes one revert to User:AzaToth/twinkle.js to make the world happy again. If we can go 48 hours without an eruption at the Village Pump, it will then be a simple matter to copy the entire beta tree to the historical AzaToth tree. Once it's all there, we can switch everyone over with one save so we won't have any downtime at all.

The other nice thing about this approach is that we won't experience problems due to caching on the change from the live tree to the beta tree because they will be different files. Making updates to the beta files could of course cause some issues, but if we can at least get the new morebits.js stable first this shouldn't be a big problem. —UncleDouggie (talk) 10:53, 27 February 2011 (UTC)

I'm running my tests on phantom User talk:100.100.100.100. —UncleDouggie (talk) 16:55, 27 February 2011 (UTC)

Sounds like a good plan. -- Tom N (tcncv) talk/contrib 19:31, 27 February 2011 (UTC)
Sounds good. Let me know when you're ready for testers, since I want to test the "new" Twinkle. SchuminWeb (Talk) 04:16, 28 February 2011 (UTC)
Will do. Although we now have several operational modules that would now survive an HTML5 update, we are still making significant changes to the internals, so we are not yet ready to put it out for beta testing. I've added you to a new Testers section above. Hopefully, others will follow. Thanks. -- Tom N (tcncv) talk/contrib 05:52, 28 February 2011 (UTC)
Awesome. Also, looking at the list of modules you all are working on, don't forget the former Friendly modules as well, since this would be the perfect time to fully integrate the two after we merged the tools. SchuminWeb (Talk) 12:14, 28 February 2011 (UTC)
I was hoping that no one would notice that. ;-) We've got our hands full for the moment at least. —UncleDouggie (talk) 13:17, 28 February 2011 (UTC)
Oh, totally. I just didn't want anyone to forget 'em. I'm satisfied just as long as the ex-Friendly tools are on everyone's radar and don't accidentally fall by the wayside. SchuminWeb (Talk) 21:49, 28 February 2011 (UTC)

Miscellaneous notes

A few notes:

  • (tcn) Unlike the edit window, content text returned by the API lacks a trailing newline, so if you are appending to an existing page, you may need to insert two newlines instead of one to ensure the start of a new paragraph.
  • (UncleDouggie) I was wondering why we had that problem with the aiv.js update. Thanks for figuring it out.
  • (tcn) Some API calls can be made directly through the URL and results viewed in your browser. Leaving off the format=xml parameter yields a more human readable version.
  • (UncleDouggie) This is exactly how I did the aiv.js update. An essential debugging method. Although, I'm little concerned by the fact that I actually know what all that means.

I've seen you have done a great job, and I'm happy this work at last is under way :) Some ideas though I have that could help the work though:

  • move wikipedia.* to a github repo so differences can be traced better.
  • implement the api external of Wikipedia, for example using nodejs and nodeunit for testing (example how to use nodeunit can be found at https://github.com/azatoth/PanPG). Can also use Wikipedia's test server (test.wikipedia.org I believe) instead of working direct on Wikipedia proper.
  • The Status object thingi is rather media dependent, so we might want to abstract it as an generic printer, and the current visual updater.
  • There is also the Mediawiki.page "class" below that might be relevant to combine into the new wikipedia.page logic.
  • should perhaps rename the "class" from Wikipedia to "mw" or similar.

I'm sorry I've not been able to help you guys, have been rather busy here around, I might take a hit at it though in the week or the weekend :)

Lastly, the Simplewindow infrastructure should be removed from the face of the earth, so if someone is good at web design, a new look and feel could be nice :)

Regards, AzaToth 00:11, 3 March 2011 (UTC)

  • We appreciate your thoughts. I'm unclear on the Mediawiki.page class you mentioned. I'm currently reviewing the new mw.Api class from NeilK for applicability to Wikipedia.api and edit token handling. What is Mediawiki.page?
  • We've been avoiding the mw object in our naming to prevent conflicts. Besides, Twinkle is rather specific to Wikipedia.
  • I don't see a compelling case for using github and a test wiki. So much of Twinkle is dependent on en.wikipedia specific functions, such as the existence of templates. I looked at test.wikipedia.org and the templates are 3 years out of date compared to en.wikipedia.org. We haven't busted anything yet and the community has been very supportive of our work. 95% of bugs result in no page edits. As for the other 5%, we keep an eye on our own contributions and cleanup after any accidents. Hopefully I don't loose my clean block log over this project, but that's a risk I'm willing to take.
  • We agree that the GUI needs work, but that's more than we can tolerate at the moment. Perhaps it would be good for a phase 2.
  • We would certainly appreciate more details on your thoughts about the Status object. That's on my list to dig into tomorrow.
UncleDouggie (talk) 04:39, 3 March 2011 (UTC)
A github repo would be good, if anyone can be bothered to set one up. That way we can all contribute to the code, and we know who changed what, when.
I've added an initial repo at https://github.com/azatoth/twinkle - the sync script isn't updated yet, it's the one I made for my test using svn repo back in the days, and requires svn for commit info.
I've also added two branches containing tcncv's and unclesdouggie's changed code AzaToth 22:01, 5 March 2011 (UTC)
The work we're doing in Wikipedia.page is actually not specific to Twinkle or enwiki; the code should work on any MediaWiki wiki that is set up properly (i.e. api.php enabled and functioning as required).
The GUI could perhaps be switched over to jQuery UI - I believe this is used on Commons (?). But that's for later, as UncleDouggie says. — This, that, and the other (talk) 06:37, 3 March 2011 (UTC)

XPath

I wasn't online when the devs turned on HTML5 output here and must confess that I haven't really followed the above discussions and all your work, but I presume that the reason why Twinkle stopped working was mainly because the pages weren't valid XHTML anymore, and Twinkle depended on that in various parts.
The reworked version of twinklefluff is still using XPath queries to find the diff information, and I'd expect that that module would still break. jQuery does understand "basic XPath expressions" (see http://docs.jquery.com/DOM/Traversing/Selectors#XPath_Selectors) so I'd assume that it shouldn't be hard to convert all the screen scraping to jQuery. Not sure if there are pages besides twinklefluff that need to be checked for that. Amalthea 18:28, 3 March 2011 (UTC)

XPath can still be used to parse true XML output retrieved using the API. With HTML 5, we hit errors in the XPath statements, but that was actually because the DOMParser had silently failed. It took us awhile to figure that out, which is why we were down for a whole day. By using the API exclusively, we will no longer have any DOMParser calls by the time we're done. However, all the tags and attributes are different in the API output from that previously provided in the HTML output from index.php. This means that most of the current 81 XPath expressions are no longer valid, the exceptions being some of the calls that were already using the API. Also, all 80 getElementById expressions must be replaced. It should be clear from this just why no one has attempted to migrate the code before now. We have decided to move in the direction of jQuery for the new code with its more intuitive syntax. I wasn't aware that jQuery supported XPath selectors – thanks for the link! This gives us yet another option that can even be combined with other types of jQuery selectors. —UncleDouggie (talk) 20:26, 3 March 2011 (UTC)

Looked in the Archive... didnt see anything

Is there some reason ANI notice is not in Twinkle? The Resident Anthropologist (talk)•(contribs) 01:52, 15 April 2011 (UTC)

I have a feeling that it's not in there because no one gave much thought to putting it in there. However, thinking about it, I don't want automatic ANI reporting included as part of Twinkle. ANI is for the serious and extraordinary, not the routine, and so much like how you can't do a mass deletion nomination with Twinkle, you shouldn't be able to do ANI through Twinkle, either, because taking the bold step of taking an incident to ANI should probably be left to be done fully manually. SchuminWeb (Talk) 03:02, 15 April 2011 (UTC)
eh, I am lazy at times. I was more curious about placing the simply the {{subst:ANI-notice}}. Beleive me I dont want ANI reports filled with Twinkle. The Resident Anthropologist (talk)•(contribs) 03:23, 15 April 2011 (UTC)
I agree that an ANI post should not be automated in the way we automate AIV posts, but ANI notification is practically the opposite! We want people to notify the subjects of ANI discussions, and there is an existing and well known issue with people failing to do it. Why not give editors one more tool to improve the notification rate, and maybe get the link to the proper section added to the template on the first try? VQuakr (talk) 04:08, 15 April 2011 (UTC)
User notification should work, since that's routine. We just need to make sure that all the necessary fields are required for it to go to work. SchuminWeb (Talk) 05:17, 15 April 2011 (UTC)
I think the way we have Template:Talkback set up on twinkle would be a good model. The Resident Anthropologist (talk)•(contribs) 14:40, 15 April 2011 (UTC)
As I'm sure many of you know, Twinkle is being redeveloped off-wiki (on github). It would be fairly easy to implement this as part of the talkback module in this redevlopment. Is there a template that should be used for ANI notification? — This, that, and the other (talk) 04:52, 17 April 2011 (UTC)
i had heard some rumors of that but thats abot it. The template is {{subst:ANI-notice}} The Resident Anthropologist (talk)•(contribs) 19:06, 17 April 2011 (UTC)