Wikipedia talk:Twinkle/Bugs/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

TW-B-301

Status:  Resolved

Resolution:  Fixed

ARV menu non functional when name contains quotation marks --Wuhwuzdat (talk) 02:11, 16 June 2009 (UTC)

Just tried to ARV User:Chef "Yes Chef" for a username violation (promotional), and could not get TW to open the ARV menu. ARV Menu is still functional on "normal" usernames. Wuhwuzdat (talk) 02:11, 16 June 2009 (UTC)

Y Fixed, plus one related problem. Thanks, Amalthea 11:18, 16 June 2009 (UTC)

TW-B-302

Status:  Resolved

Resolution:  Fixed

Twinkle failed to fully rollback several instances of vandalism, instead only rolling back one to the same vandal's last edit.[1][2][3][4] ---- Collectonian (talk · contribs) 00:59, 21 June 2009 (UTC)

Weird. Possibly because of the apostrophe in the user name. Amalthea 00:01, 24 June 2009 (UTC)

YFixed, was the apostrophe. Amalthea 16:48, 4 July 2009 (UTC)

TW-B-303

Status:  Closed

Resolution:  Dupe of #278.

Twinkle won't post {{db-f8}} instead of {{nowcommons}}. --Ipatrol (talk) 21:16, 23 June 2009 (UTC)

TW-B-304

Status:  Resolved

Resolution:  Fixed

Twinkle is no longer properly adding RPP reports to WP:RPP. Dialog says it is doing it and the page is being added to my watchlist, but when you check RPP, no new report. I tried to file one hours ago for List of InuYasha characters and it didn't take. Just tried two more times with the same result, and finally had to manually add the report myself. Looking at RPP's history, the last successful use of twinkle to add a report was on June 22 at 23:58[5], and since at least one other person has noted Twinkle was "broken" and they were manually adding reports[6] -- Collectonian (talk · contribs) 01:07, 24 June 2009 (UTC) ---- Collectonian (talk · contribs) 01:07, 24 June 2009 (UTC)

Fixed, thanks. Next time that happens, Twinkle will at least inform that it wasn't able to figure out where to place the request on WP:RFPP, and not fail silently. Amalthea 10:00, 24 June 2009 (UTC)

It is now informing, but also continuing to fail every time. -- Collectonian (talk · contribs) 03:19, 26 June 2009 (UTC)

Works again.
Tools always have a hard time figuring out where to place requests on such pages. In this case, Twinkle is looking for the heading and the template beneath it, and fails if it isn't exactly how it expects it to be. VoABot fixed the problem a short while after you tried, it's apparently built to make sure that the markers stays recognizable. Twinkle quite certainly could be made a bit more robust, but those tests will always fail if the markers are changed. :\ Amalthea 10:47, 26 June 2009 (UTC)

TW-B-305

Status:  Resolved

Resolution:  Fixed, or workarounded at least.

The Twinkle tabs at the top of the page don't show up when using the new Vector skin. About all I do get is the "rollback" links when looking at diffs and Special:Contributions. Matt (talk) 05:31, 3 July 2009 (UTC) --Matt (talk) 05:31, 3 July 2009 (UTC)

Not really surprising... Vector is probably going to require lots of scripts to be updated to work properly in it. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 07:17, 3 July 2009 (UTC)

Here's some relevant HTML code (from a random article):

Click "show" to view code (stretches screen horizontally) - - - - - - >

<div id="left-navigation">

	<!-- namespaces -->
	<div id="namespaces">
		<h5>&amp;lt;namespaces&amp;gt;</h5>
		<ul lang="en" xml:lang="en">
			<li  id="ca-main" class="selected"><a href="/wiki/Ralph_Coates" ><span>Page</span></a></li>
			<li  id="ca-main_talk"><a href="/wiki/Talk:Ralph_Coates" ><span>Discussion</span></a></li>
		</ul>

	</div>
	<!-- /namespaces -->
	<!-- variants -->
	<!-- /variants -->
</div>
<div id="right-navigation">
	<!-- views -->
	<div id="views">
		<h5>Views</h5>

		<ul lang="en" xml:lang="en">
			<li id="ca-view" class="selected" class="selected"><a href="/wiki/Ralph_Coates" ><span>Read</span></a></li>
			<li id="ca-edit"><a href="/w/index.php?title=Ralph_Coates&amp;action=edit"  title="You can edit this page. &#10;Please use the preview button before saving. [e]" accesskey="e"><span>Edit</span></a></li>
			<li id="ca-history"><a href="/w/index.php?title=Ralph_Coates&amp;action=history"  title="Past versions of this page [h]" accesskey="h"><span>View history</span></a></li>
		</ul>
	</div>
	<!-- /views -->

	<!-- actions -->
	<div id="actions">
		<h5><span>&amp;lt;actions&amp;gt;</span><a href="#">&nbsp;</a></h5>
		<div class="menu">
			<ul lang="en" xml:lang="en">
				<li id="ca-delete"><a href="/w/index.php?title=Ralph_Coates&amp;action=delete"  title="Delete this page [d]" accesskey="d">Delete</a></li>
				<li id="ca-move"><a href="/wiki/Special:MovePage/Ralph_Coates"  title="Rename this page [m]" accesskey="m">Move</a></li>

				<li id="ca-protect"><a href="/w/index.php?title=Ralph_Coates&amp;action=protect"  title="Protect this page [=]" accesskey="=">Protect</a></li>
				<li id="ca-watch"><a href="/w/index.php?title=Ralph_Coates&amp;action=watch"  title="Add this page to your watchlist [w]" accesskey="w">Watch</a></li>
			</ul>
		</div>
	</div>
	<!-- /actions -->
	<!-- search -->
	<div id="search">

		<h5 lang="en" xml:lang="en"><label for="searchInput">Search</label></h5>
		<form action="/w/index.php" id="searchform">
			<input type='hidden' name="title" value="Special:Search"/>
			<input id="searchInput" name="search" type="text"  title="Search Wikipedia [f]" accesskey="f"  value="" />
			<input type='submit' name="go" class="searchButton" id="searchGoButton"	value="Go" title="Go to a page with this exact name if one exists" />
			<input type="submit" name="fulltext" class="searchButton" id="mw-searchButton" value="Search" title="Search Wikipedia for this text" />
		</form>
	</div>

	<!-- /search -->
</div>

The various tab IDs have changed, as you can see (as have quite a few others, judging by how distinctly uncustomized my edit screen now is). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 07:33, 3 July 2009 (UTC)

This is not the biggest problem; a simple patch can fix this, see zh:MediaWiki:Gadget-vectorskin-thunks.js. The biggest problem is that Twinkle doesn't send data to server via api.php but index.php. However, response of index.php may vary on skin, and is not as stable as api.php. Now vector skin's response cannot be parsed by Twinkle to get data for article modification etc. --Liangent (talk) 11:54, 3 July 2009 (UTC)

Yet another reason for someone to switch Twinkle (and Friendly, which I suspect has many similar issues on Vector) over to the API, vis-a-vis bug 257... 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 16:21, 3 July 2009 (UTC)

{{sofixit}} :) _→AzaToth 16:37, 3 July 2009 (UTC)

Ha! I wish... I don't know enough Javascript to even *think* of doing something like that. =P 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:02, 3 July 2009 (UTC)

Just a minor edit to morebits.js can fix this, see the diff at zhwiki. Now it works well on vector skin.--Jimmy xu wrk (talk) 09:52, 4 July 2009 (UTC)

Vector skin thunks is now also available as a gadget on en.wp. —TheDJ (talk • contribs) 10:01, 4 July 2009 (UTC)

Sysops please change the morebits.js per the diff shown above, thanks.--Jimmy xu wrk (talk) 10:13, 4 July 2009 (UTC)

← Gross, but pretty effective workaround. Done, thanks.
Since apparently Skin devs are doing their best to create all skins incompatible to each other, the most robust way would probably be an additional layer to abstract the differences away, to provide one common skin API for all of them. Until then, we have to live with this hack.
With the compatibility gadget enabled, both Twinkle and Friendly seem to be working as before, so I'm going to close this. If people find additional issues, or features that don't work after all (I didn't test them all), please note them here or at WT:TW.
Thanks all, Amalthea 11:47, 4 July 2009 (UTC)

• P.S. when the vector skin does become the default, I do expect scripts to support the CSS id's of the Vector script, and to remove the Gadget. At most it should be a temporary aid during the development of Vector in my opinion. —TheDJ (talk • contribs) 22:52, 4 July 2009 (UTC)
  • I would agree in principle, but there are lots of scripts that break on Vector and that aren't actively supported any more - it could be months or even years before these scripts are properly updated, completely broken by further future changes, or simply phased out altogether in favor of newer scripts. Simply removing the thunks gadget after Vector becomes the default skin should therefore be avoided, and instead a discussion would be appropriate where we attempt to enumerate the scripts which still rely on it to function in Vector, and whether it's worth the time and energy to attempt updating them. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 22:57, 4 July 2009 (UTC)
    • They are easy fixes, and if you keep things like this around, no one will ever fix them. Fixing scripts should be encouraged, esp in combination with the default skin. —TheDJ (talk • contribs) 23:05, 4 July 2009 (UTC)
    • I agree with TheDJ, this script a gadget should only be temporarily a gadget, if at all. The last thing we want is special support gadgets for every available skin. Making this script a gadget will possibly backfire in that script maintainers will not fix their scripts, that skin developers will not be asked not to change id's without need, or that the issue will be addressed in a better way (such as adding this to a site/skin script). Therefore, and because this script is mainly targeted at a handful of persons that develop for the new skin, it should probably be used as a normal user script.
      I am disappointed about the way it has been (re-)installed as a gadget while knowingly ignoring the current, long established process, thereby avoiding any (critical) discussion on Wikipedia:Gadget/proposals (please see User_talk:Dinoguy1000#Re-addition_of_undiscussed_script_as_gadget). Cacycle (talk) 03:39, 5 July 2009 (UTC)
      • Please see the bug report that I have just filed. Cacycle (talk) 04:03, 5 July 2009 (UTC)
      • I too am disappointed by this, this could have been handled with way more class and less reverting. We have time with the vector skin, as TheDJ pointed out, and all scripts are still useable with the default skin. I can agree that an absolute prerequisite to discuss a supposedly uncontroversial gadget before adding it is WP:BURO, and can be WP:IARed at times. However, once someone disagrees, always fall back to talk (WP:BRD, WP:WHEEL, and stuff).
        Anyway, it's done, no harm done, moving on.
        All gadgets should always work without dependencies in the default skin (in reasonably standards-compliant browsers). The Vector skin is intended as the default skin down the road, so all Gadgets need to be made compatible with it before then.
        We need to wait a couple of days to see how those bugs turn out, but after that I agree we should make all highly used scripts compatible without relying on crutches. Once we're confident that the most important ones are fixed, we should remove the compat gadget again. That shouldn't be put off for too long, so that once Vector is made the default skin, enough early adopters have dropped in at WP:VPT or wherever with bug reports of the remaining scripts.
        I don't know the timetable for Vector, but what the thunks workaround can be easily patched in the scripts; I'd hope that we can get this done by the end of the month. The more difficult question is whether we should attempt a more long-term solution, like an abstraction layer in the skin scripts. Amalthea 11:22, 5 July 2009 (UTC)
        • Looking at it now, after a day or so, I agree that I acted far more immaturely than I should have, and I apologise (in particular to Cacyle) for my behavior; this is definitely something I'll be more careful about from now on (and I wouldn't mind an occasional tap if someone notices me slipping =) ). Back to the matter of the gadget itself, though, I really didn't explain myself properly; I never expected for the gadget to be left in indefinitely (if that was the case, given that Vector is set to become the new default skin, the script would be better off added to MediaWiki:Vector.js), but merely long enough for most of the commonly-used scripts to be switched over. I feel there is little point in retaining the gadget once the script switch is done; at that time (if it hasn't been done already), the gadget should simply be removed to force any lazy script authors to update their scripts (or complain until someone else does it for them =) ). And personally, I kind of like Amalthea's idea for a layer of abstraction between skins and scripts; it would help out script authors quite a bit in not having to worry so much about testing their scripts across the various skins. One last note, anyone feel like adding some Vector stuff to the CSS catalog? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:33, 6 July 2009 (UTC)

TW-B-307

Status:  Resolved

Resolution:  Resolved

When using Twinkle to automatically add files for deletion, the "logs" link is added using an extra '}', causing the link to malform. See example at Wikipedia:Files for deletion/2009 July 18#File:Breaker.jpg - note the URL of the 'logs' link has a '}' attached. Should be simple enoug to fix for someone who knows how - I, simply put, lack the knowledge. Mnmazur (talk) 07:04, 19 July 2009 (UTC)

I looked briefly through User:AzaToth/twinklexfd.js, but couldn't find the problem code myself. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:34, 21 July 2009 (UTC)

That's because it wasn't a Twinkle bug. Y Fixed. Amalthea 21:12, 21 July 2009 (UTC)

Aah, good catch. I really need to take the time to finish tagging templates Twinkle makes use of one of these days... 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:01, 22 July 2009 (UTC)

TW-B-308

Status:  Resolved

Resolution:  Fixed

When leaving a talkback notice, if you fill in the optional linked section, and then change the target page selection (e.g. from "My talk page" to "Other user talk page"), the linked section field gets blanked. Is there any way to prevent this? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:33, 21 July 2009 (UTC)

Well, it can be done manually in the friendlytagCallbackChangeTarget function of User:Ioeth/friendlytalkback.js, by prefilling the value with the value of the respective input box of the old "tab". It's pretty easy if you want to give it a try. :) Amalthea 07:46, 23 July 2009 (UTC)

Hmm... I'll look into it, but from a brief glance, my head's already swimming... @_@ (specifically, what holds the old tab's content, and how do I access it?) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:40, 23 July 2009 (UTC)

Y Fixed! Friendly no longer eats your form input when changing the radio selection. Ioeth (talk contribs twinkle friendly) 16:09, 23 September 2009 (UTC)

Nice, thanks! (seeing the changes you made, yeah... that would have been waaay out of my current skill range -_-;; ) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:02, 23 September 2009 (UTC)

It's funny, because yesterday I made a similar change to the twinklewarn.js interface yesterday, so doing this one was just a copy of that. Ioeth (talk contribs twinkle friendly) 19:07, 23 September 2009 (UTC)

TW-B-311

Status:  Resolved

Resolution:  Resolved

When I try to place a speedy deletion tag on a page, clicking one of the radio buttons under the CSD tab does absolutely nothing. This seems to have only started since the gadgets feature was activated on WP. I use Mac OS X Leopard running Firefox 3.51 --- 2 ... says you, says me 15:39, 24 July 2009 (UTC)

 Works for me on Google Chrome 2.0.172.37 on XP, and I'm using the gadget version myself. Just so you know, though, gadgets have been around since 2007, so maybe you meant to say it's only started since you began using the gadget version (not that I'm trying to put words in your mouth or anything)? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:40, 24 July 2009 (UTC)

Well yes,  Works for me in my Firefox 3.5.1 on Windows 7 RC as well. Two, can you try it again in some sandbox and have a look at your javascript console afterwards, and post anything Twinkle-related here? I notice you could use Twinkle to start AfD discussions, so it appears to be a pretty narrow problem. Amalthea 20:55, 24 July 2009 (UTC)

My error console gave me this when I attempted to speedy the Sandbox...

"Error: TwinkleConfig.notifyUserOnSpeedyDeletionNomination is undefined. Source File: http://en.wiki.x.io/w/index.php?title=User:AzaToth/twinklespeedy.js&action=raw&ctype=text/javascript Line: 1230"

Does this help at all? - 2 ... says you, says me 03:31, 25 July 2009 (UTC)

Yep, that helps. That tells me that you are using an old-style config which is prone to such errors in combination with the gadget on certain browsers (I think FF on Windows is good, but on a Mac it apparently isn't), and that you've most probably activated Twinkle both as a Gadget and in your monobook.js.
I've modified your monobook to reflect the new configuration style, and thrown out all values that are either outdated or the same as the default. Can you bypass your browser cache and try again? Amalthea 08:59, 25 July 2009 (UTC)

It's working now! Thanks for the help. - 2 ... says you, says me 14:06, 25 July 2009 (UTC)

TW-B-312

Status:  Resolved

Resolution:  Fixed

Moved from Dino's comment at #311, hope you don't mind:
On a related note, {{db-u1}} requires a rationale parameter when tagging user talk pages - Twinkle probably needs to be modified to check whether it's a talk page being tagged under U1 and, if so, request a rationale from the user 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:40, 24 July 2009 (UTC)

Nope, I don't mind... just too lazy to do a new bug report myself ;P 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:59, 24 July 2009 (UTC)

Y Fixed! Ioeth (talk contribs twinkle friendly) 15:28, 23 September 2009 (UTC)

TW-B-313

Status:  Resolved

Resolution:  Fixed

When marking a page for CSD as an attack page, Twinkle removes the content in addition to adding {{db-attack}}. Tckma (talk) 14:02, 27 July 2009 (UTC)

As designed, to reduce the chance that the libelous content is indexed by search engines, but I've changed the logic to automatically add {{courtesy blanked}} in that case. Amalthea 14:25, 27 July 2009 (UTC)

TW-B-314

Status:  Resolved

Resolution:  Resolved

When using TW to report name to WP:UAA, edit fails, TW reports "Processing UAA request: Failed to retrieve edit form" --WuhWuzDat 14:19, 27 July 2009 (UTC)

YFixed. Amalthea 14:52, 27 July 2009 (UTC)

Bug has re-occured, same symptoms, clearing cache did not help. WuhWuzDat 16:53, 29 July 2009 (UTC)

Y Repaired again. Clearing the cache won't ever help in those cases, the invalid XHTML needs to be fixed.
One of these days I'll find the time to fix this properly ... Amalthea 19:30, 29 July 2009 (UTC)

By finally switching Twinkle over to the API? =D 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 21:07, 29 July 2009 (UTC)

I Wanted really to wait for jQuery to be live before converting to full API (have made an prototype implementation on test.wiki.x.io _→AzaToth 16:12, 31 July 2009 (UTC)

Aah, I see... how much does jQuery simplify stuff? (gah... so... small...) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 21:47, 31 July 2009 (UTC)

A lot! _→AzaToth 18:25, 9 August 2009 (UTC)

Ooh, sounds like fun ^_^ 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:20, 11 August 2009 (UTC)

I've actually made an initial API implemetation at testwiki:User:AzaToth/monobook.js _→AzaToth 19:10, 11 August 2009 (UTC)

Hooray for progress (and vanishingly small text that just keeps getting smaller)! 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 21:36, 11 August 2009 (UTC)

What happened to these comments?--Jimmy xu wrk (talk) 18:35, 22 August 2009 (UTC)

Just having a little fun, I think. (whoever tries to read these once this big is archived is gonna want to kill us, though =D ) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 16:32, 24 August 2009 (UTC)

TW-B-315

Status:  Closed

Resolution:  Dupe of #235

AfD creates the deletion discussion, but doesn't tag the article itself
I'm performed exactly two operations with TW. A csd worked as expected, but then sending GetPlus_Transfer_Manager to AfD did a bunch of stuff whose progress msgs I didn't pay enough attention to, but there's not template on the article, but there is a deletion discussion. If I closed the TW dialog box before all of its tasks were completed, would that interrupt it? Perhaps I'll make a feature suggestion about displaying up front all the tasks to be done, and then indicating progress for each of them as it goes. --Petershank (talk) 20:10, 27 July 2009 (UTC)

Yes, that happens from time to time I'm afraid. It's already reporting the progress of all four steps, but it has trouble when it encounters any errors and doesn't recover. If you nominate another in the future, please try and have a look at what Twinkle reports back.
There's a bug report above, at #235, and another related one, so I'm closing this as a duplicate. Amalthea 20:22, 27 July 2009 (UTC)

Thanks, I should have recognized it as a dupe. Keep up the good work. Petershank (talk) 20:08, 28 July 2009 (UTC)

TW-B-317

Status:  Closed

Resolution:  Invalid

Tagging an article for AfD deletes the content of the article in addition to adding the AfD template. Tckma (talk) 18:48, 5 August 2009 (UTC) --Tckma (talk) 18:48, 5 August 2009 (UTC)

No, it doesn't. Amalthea 19:01, 5 August 2009 (UTC)

TW-B-318

Status:  Resolved

Resolution:  Fixed

diff - FfD files are referred to as "images". Not a big deal, obviously. Might be the case with speedies and PUF too. --▫ JohnnyMrNinja 23:05, 9 August 2009 (UTC)

 Done. Amalthea 10:13, 18 August 2009 (UTC)

TW-B-319

Status:  Closed

Resolution: not a bug

I don't know if anyone's allowed to edit this template, seeing how it has a very short history, and I see that you changed it before based on a bug report, so I'll ask here. Should {{Db-spam-notice}} also mention something about WP:REQ for those who aren't willing to learn wikipedia policies, but still want an article created about their page? Just asking. ηoian ‡orever ηew ‡rontiers 00:48, 12 August 2009 (UTC)

I have no opinion on that, feel free to edit it on your own. If you want to discuss it first you can bring it up at WT:CSD, if you find it uncontroversial just add it. I think WP:BFAQ already mentions WP:REQ though. Amalthea 06:48, 12 August 2009 (UTC)

TW-B-320

Status:  Closed

Resolution: not a bug

When rolling back an article or warning a user the page gets added to my watchlist even though I've included the following in my monobook.js file:

TwinkleConfig.watchRevertedPages = false;

TwinkleConfig.watchWarnings = false,

I have the settings for adding pages I edit, move and create to my watchlist unchecked in my preferences as well. --~Fenrisulfr (talk · work) 13:24, 12 August 2009 (UTC)

I just realized I'm running wikipedia beta so that may have something to do with it... ~Fenrisulfr (talk · work) 13:49, 12 August 2009 (UTC)

"Running the beta" means you're using the Vector skin. However, you have only configured Twinkle in your monobook.js, not in your vector.js. Amalthea 18:04, 12 August 2009 (UTC)

One reason I never understood why the devs didn't give us a userspace version of Common.css/js, since not everyone knows how to use importScript() and importStylesheet() to the same effect. =P 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:37, 12 August 2009 (UTC)

Er... On zhwiki we've got this gadget, on bugzilla we've got this bug. See if those can be used for workaround.--Jimmy xu wrk (talk) 18:33, 22 August 2009 (UTC)

You can propose a new gadget right here, or an addition to Common.js over there. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 16:35, 24 August 2009 (UTC)

TW-B-321

Status:  Closed

Resolution:  Dupe of TW-B-229 and others

Twinkle SD notifications erase the rest of the page; eg [7] Triplestop x3 16:50, 14 August 2009 (UTC)

This is a known issue - see bug 229 and others listed by bullet point 3 in the Known issues section. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:24, 14 August 2009 (UTC)

TW-B-323

Status:  Resolved

Resolution:  Fixed

A variable is misused in twinklefluff, this caused a div without id. A patch is provided below:

Index: twinklefluff.js
===================================================================
--- twinklefluff.js	(revision 300255047)
+++ twinklefluff.js	(working copy)
@@ -213,7 +213,7 @@
			if( TwinkleConfig.showRollbackLinks.indexOf('diff') != -1 ) {
				vandal = document.evaluate( 'a', document.getElementById('mw-diff-ntitle2') , null, XPathResult.STRING_TYPE, null ).stringValue.replace("'", "\\'");
 
				var revertNode = document.createElement('div');
-				revertToRevision.setAttribute( 'id', 'tw-revert' );
+				revertNode.setAttribute( 'id', 'tw-revert' );
 
				var agfNode = document.createElement('strong');

--Jimmy xu wrk (talk) 18:25, 22 August 2009 (UTC)

Y Done, thanks! Amalthea 10:22, 23 September 2009 (UTC)

TW-B-324

Status:  Closed

Resolution: notabug

This relates to "AFDM - Hiding Instructions" below, which is marked "resolved." There is still a redlink problem. I created an AFD [8] and the link to the AFD discussion was red, making someone think there was no link to the AFD discussion from the article. I compared the AFD to one with a non-red link, and found that mine had the characters |help=off in the link. When I removed these, the AFD link looked correct: [9] They were automatically added in the Twinkle AFD creation, and cause confusion to readers: [10] Please take a look, and advise if I am doing something wrong or if the Twinkle code needs a tweak, or if AFD is screwed up. Also, I could not get this bug notice to display properly here with the "subst" and all. It just showed the form and "subst" without implementing the template. Thanks. Edison (talk) 15:59, 7 September 2009 (UTC)

This is a result of Twinke not having any type of timing mechanism for its edits - it pushes everything through at once without waiting for any given edit to finish first. As a result, often the AFD notice will be saved before the AFD page is created, which means the link will appear red until the server cache of the page has been cleared. This is what happened when you removed "|help=off" - the act of saving the page forced the server to refresh its cached copy of the page (the presence of the parameter itself had nothing to do with it). In the future, you can fix this simply by purging the server cache, and if that doesn't work, a null edit should suffice (if not, you should check and see if Twinkle actually created the AFD page - it has been known to choke on this in the past). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:35, 8 September 2009 (UTC)

TW-B-326

Status:  Closed

Resolution:  Fixed

Not sure if it's a twinkle issue, but ever since the WP site software upgrade about 20 min ago Twinkle and Friendly scripts die at "User talk page modification: data loaded..." step - and I've refreshed and purged and rebooted. Happens in multiple browsers.  7  00:10, 17 September 2009 (UTC)

Screenshot File:Twinkle-frozen-7.jpg. Happens on CSD with twinkle and warning (friendly?).  7  00:18, 17 September 2009 (UTC)

Also - UAA is broken (different error) - it quickly comes back with: Processing UAA request: Failed to retrieve edit form.  7  00:39, 17 September 2009 (UTC)

In case this isn't Twinkle's issue it is also being discussed with other software update related problems here.  7  00:39, 17 September 2009 (UTC)

I found the cause. The problem is in the source html after the new software update. Informing the developers now. <label for='wpMinoredit'Array> breaks the XML parser. —TheDJ (talk • contribs) 00:47, 17 September 2009 (UTC)

Thanks - quick work!  7  00:48, 17 September 2009 (UTC)

Good to know it's not just me! Any chance of updating the main TW page with a status of up or down? Might help with the repeat questions. Basket of Puppies 00:55, 17 September 2009 (UTC)

Appears to be fixed.  7  01:16, 17 September 2009 (UTC)

Issue is fixed. Please report other "new" bugs in separate reports if you run into them please. —TheDJ (talk • contribs) 01:17, 17 September 2009 (UTC)

TW-B-327

Status:  Closed

Resolution:  Dupe of #229. Amalthea 10:13, 23 September 2009 (UTC)

Addition to PUF causes deletion of old nomination. [11] [12]. Please note this is somewhat of a repeat of 229. I use Google Chrome browser now; then I used FF 3.x. Magog the Ogre (talk) 23:51, 20 September 2009 (UTC)

TW-B-328

Status:  Resolved

Resolution:  Fixed

{{uw-username}} expects a value to be passed for the reason; the warning UI does not indicate how to do this. As a result, by default the use of this warning produces a big red NO REASON GIVEN error on the user talk page. [13] The UI should indicate where to include the reason, and prevent submission if none is given. Chris Cunningham (not at work) - talk 10:56, 21 September 2009 (UTC)

YFixed Hacked. Amalthea 11:38, 21 September 2009 (UTC)

TW-B-329

Status:  Closed

Resolution:  Fixed

Since about a week ago, the "rollback", "good faith rollback", etc. buttons haven't been appearing above the "current version" preview in diff pages such as this. In Firefox, the "restore this version" link is still there, but there aren't any Twinkle links in Internet Explorer. Note that I'm using the vector beta skin. However, I have Twinkle in my vector.js file and enabled in my gadgets. Timmeh (review me) 02:15, 23 September 2009 (UTC)

You definitely won't see any Twinkle links in Internet Explorer; the two aren't compatible. Also, you may have had an error on this line in your vector.js file when configuring Twinkle:

watchRevertedPages              :       [false]

I changed it to:

watchRevertedPages              :       []

to disable any reverted pages from being watched. Please do a cache-clearing refresh (CTRL + F5) in Firefox and give it another whirl. Ioeth (talk contribs twinkle friendly) 02:28, 23 September 2009 (UTC)

It still doesn't work. Is anyone else having this problem? Timmeh (review me) 11:40, 23 September 2009 (UTC)

In Firefox? After bypassing your cache? If so, please have a look into your javascript error console, and paste any twinkle related messages here. Amalthea 13:32, 23 September 2009 (UTC)

Here's the error message that comes up:

Error: TwinkleConfig.showRollbackLinks is undefined

Source File: http://en.wiki.x.io/w/index.php?title=User:AzaToth/twinklefluff.js&action=raw&ctype=text/javascript

Line: 213 Timmeh (review me) 19:34, 23 September 2009 (UTC)

Ah, you were using an outdated way to set up your Twinkle configuration. I've fixed it, please bypass your browser cache again, and it should work. I'll be optimistic and close this. Cheers, Amalthea 19:55, 23 September 2009 (UTC)

It's fixed. Thanks for the help. Timmeh (review me) 21:01, 23 September 2009 (UTC)

TW-B-330

Status:  Resolved

Resolution:  Resolved

Speedy delete nominations for files on commons are causing a duplicate "File" eg {{db-nowcommons|1=File:Retreat of the Helheim Glacier, Greenland.jpg}}

which results in (text)

This page may meet Wikipedia’s criteria for speedy deletion. This picture/multimedia file is available in the same format, and in the same or better quality/resolution on Wikimedia Commons as Image:File:Retreat of the Helheim Glacier, Greenland.jpg, and satisfies certain additional conditions. See CSD F8.

as in this diff [14] by User:Ciphers

(ps I don't use twinkle, just delete stuff) Graeme Bartlett (talk) 06:22, 4 October 2009 (UTC)

YFixed the template, same as #343. Amalthea 12:20, 28 November 2009 (UTC)

TW-B-331

Status:  Closed

Resolution:  Dupe of #330

The CSD F8 option adds the commons link on the template as image:file:imagename.extension witch gets translated to file:file:imagename.extension.This is related to bug Wikipedia:Twinkle/Bugs#TW-B-278 as the {{nowcommons}} template requires the file name to be file:imagename.extension but the {{db-f8}} automatically adds the file: part so it requires the file name to be imagename.extension .--IngerAlHaosului (talk) 08:01, 4 October 2009 (UTC)

• on closer examination this appears to be a duplicate of Wikipedia:Twinkle/Bugs#TW-B-330--IngerAlHaosului (talk) 08:04, 4 October 2009 (UTC)

TW-B-332

Status:  Resolved

Resolution:  Fixed

Notice: Review spelling, etc. does not work. It is called subst:uw-spellcheck and I tried inserting it using TW here. --Law Lord (talk) 00:16, 8 October 2009 (UTC)

Yes, it was deleted at WP:Templates for deletion/Log/2009 September 12#Template:Uw-spellcheck, so I removed it from Twinkle. Amalthea 20:31, 13 October 2009 (UTC)

TW-B-333

Status:  Resolved

Resolution: disabled functionality, see also #285. Amalthea 19:49, 13 October 2009 (UTC)

When using TW to tag images with the "di-no fair use rationale", TW is adding an extra | mark in front of the "deletable image caption" when tagging the image in the article in which it is used, such as this edit causing the caption of the image to be deleted and only the deletion notice to remain visible. If the extra | mark was not added then the caption would remain displayed. Perhaps this is on purpose but I have been criticised for this edit by one admin but it is not really my doing per se and told to do it manually instead but that takes much more time considering that Twinkle tags the image, the uploader and the article all with one button click. I have not checked if the other functions under the di button are doing the same thing or not. I will report if the same issue exists. ww2censor (talk) 03:21, 8 October 2009 (UTC)

I can confirm that "di-no licence", "di-no permission", "di-no source" and "ifdc" all produce the same result. ww2censor (talk) 03:33, 8 October 2009 (UTC)

Twinkle tagging image usages has been disabled now (1 2), since Wikipedia:Bots/Requests for approval/Sambot 12 supposedly takes care of marking the image usages. See #285 above for more. Thanks, Amalthea 19:49, 13 October 2009 (UTC)

TW-B-334

Status:  Closed

Resolution: no bug

Sorry to be a bother, as this is very minor, but perhaps it's a symptom of something more. I seem to get this message in the Firefox Error Console on every page: "Error: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMXPathEvaluator.evaluate]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: https://secure.wikimedia.org/wikipedia/en/w/index.php?title=User:AzaToth/twinklefluff.js&action=raw&ctype=text/javascript :: anonymous :: line 172" data: no]". I use Firefox 2.0.0.20. (Twinkle's features seem to be present and working despite the error message. Actually I came to this page because I'd lost the "[rollback (AGF)] || [rollback] || [rollback (VANDAL)]" and "[restore this version]" links, but I've managed to get them back now after reverting from Modern to MonoBook. Maybe that's a bug too.) • Anakin ^(talk) 03:31, 14 October 2009 (UTC)

Not to sound rude or fanboyish, but is there any reason you haven't upgraded to Firefox 3 (or, better yet, 3.5)? 3 fixes quite a few bugs, uses less memory, and is generally faster than 2, and it *may* fix the uncaught exception you're having here. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:33, 14 October 2009 (UTC)

Not rude, it's a very good question, but the answer is a sad tale. I've upgraded at least thrice, but found many problems and objections with the way Firefox 3.0/3.1/3.5 decides to do things, and always seem to end up tragically unhappy with it (although yes, it's certainly faster).

I've found the Modern→Monobook compatibility library under Special:Preferences/Gadgets -- it fixes the Twinkle rollback links above diffs though not on user contrib pages. On further investigation, turns out that that option also smartly removes the exceptions I was getting (which were also only happening under Modern). Guess that explains that. My apologies for being a complete waste of time. • Anakin ^(talk) 22:27, 14 October 2009 (UTC)

All right, all that makes sense, I guess. =) Cool to see you got a solution on your own, too. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 16:28, 15 October 2009 (UTC)

TW-B-335

Status:  Resolved

Resolution: dupe of #343

When tagging files as F4 (no licensing info), it correctly tags the image but has issues nodifying the uploader. "File:" is prepended twice when linking to the image from the talk page, as seen a bunch of times here. Can this be fixed? About a hundred of my notifications are janked up already. ZooFari 16:01, 24 October 2009 (UTC)

The same problem occurs when I attach the F6 (missing non-free use rationale) tag to an image. SoCalSuperEagle (talk) 19:34, 5 November 2009 (UTC)

Y See #343. Amalthea 12:25, 28 November 2009 (UTC)

TW-B-336

Status:  Closed

Resolution:  Fixed

--- twinkleprotect.js	r300218243
+++ twinkleprotect.js	Working copy
@@ -429,7 +429,7 @@
 
 			if( self.params.type != 'unprotect' && self.params.expiry != 'indefinite' ) {
 				self.params.tag += '|expiry={{' + 'subst:#time:F j, Y|+' + self.params.expiry +'}}';
-				if( this.params.small ) {
+				if( self.params.small ) {
 					self.params.tag += '|small=yes';
 				}
 			}

--Jimmy Xu (talk) 14:02, 25 October 2009 (UTC)

Doesn't look like a problematic change, but could you provide a brief explanation for those of us who aren't quite so technical-minded? =) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:11, 26 October 2009 (UTC)

Well, this. makes the "Iconify" option useless, since the "small" parameter cannot be passed to the function. Works fine on zhwiki after the change. (I merged some Twinkle module to Friendly there) ( http://zh.wiki.x.io/w/index.php?action=view&diff=11473506 ).--Jimmy Xu (talk) 15:39, 27 October 2009 (UTC)

Done, please point out if I managed to screw this fix up somehow. =) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:51, 27 October 2009 (UTC)

TW-B-337

Status:  Resolved

Resolution:  Fixed

The timestamp for {{db-t3}} doesn't properly populate using Twinkle. See {{CheckedPuppeteer}} for an example where the time had to be manually fixed to allow the template to work.--Doug.^{(talk • contribs)} 19:36, 26 October 2009 (UTC)

YFixed: The user passed in "Sockpuppeteer|blocked|checked=yes" as the template that {{CheckedPuppeteer}} was redundant to, which lead to the following code:
{{db-t3|1=06:11, 26 October 2009 (UTC)|2=Sockpuppeteer|blocked|checked=yes}}
Due to the way the MediaWiki parser combines explicitly and implicitly named numbered parameters, the date got overridden by the "blocked" parameter, which resulted in an invalid date.
Proper way would be to start escaping the user input, but there are so many ways to break the template language so that's nigh impossible. But it's good enough the way I fixed it.
Amalthea 14:33, 28 November 2009 (UTC)

TW-B-338

Status:  Closed

Resolution:  Dupe of #235

When tagging a page for MfD no discussion was created or listed. --MrStalker ^(talk) 09:49, 28 October 2009 (UTC)

Sounds like bug 235. Can you give a link? --Dinoguy1000 (talk · contribs) as 72.251.164.58 (talk) 01:20, 29 October 2009 (UTC)

TW-B-340

Status:  Resolved

Resolution:  Fixed

On the page protection pop-up window, the "iconify" check box is sometimes grayed out. It becomes grayed out whenever the expiration parameter is changed but is restored whenever the type of protection parameter is changed. Possibly this is connected with bug fix 336. SpinningSpark 19:10, 11 November 2009 (UTC)

Seems nothing to do with bug 336, because the "enabled" preference is not set there. Maybe more "AND" is required to handle all these statements...--Jimmy Xu (talk) 16:09, 13 November 2009 (UTC)

A patch:

--- twinkleprotect.js	r322406633
+++ twinkleprotect.js	Working copy
@@ -189,7 +189,7 @@
 		root.noinclude.disabled = false;
 		root.cascade.disabled = false;
 		root.expiry.disabled = false;
-		root.small.disabled = false;
+		root.small.disabled = ( root.expiry.value == 'indefinite' ? false : true );
 		if( userIsInGroup( 'sysop' ) && root.request_only.checked ){
 			root.small.disabled = true;
 			root.noinclude.disabled = true;

Works fine on zhwiki: http://zh.wiki.x.io/w/index.php?diff=11617440 .--Jimmy Xu (talk) 16:22, 13 November 2009 (UTC)

I was about to patch this, but is this really how it's supposed to behave? Why don't we want to add the pp templates if it's not an indef protection? Those templates have an expiry parameter, so it should be set accordingly, right? Amalthea 16:15, 27 November 2009 (UTC)

Does not root.small.disabled = true; just stop the template from being iconified (i.e., it will be displayed full size). What template is twinkle using for indef protection? {{pp-semi-indef}} will not accept a small parameter and hard codes it to small=yes. I know nothing about code so you should probably disregard me, but I cannot follow the logic of that patch. The line that is being deleted sets root.small.disabled = false, so cannot be the cause of the problem reported. Changing it to code that might change this to true under some circumstances is only going to result in more situations where the box is grayed out, and in any case, is the opposite logic to that required if {{pp-semi-indef}} is the template bing called. SpinningSpark 17:21, 27 November 2009 (UTC)

Maybe there is some difference between zh- and en-wiki. I have to say that the policy on zhwiki forced us to add a banner while doing temporary protections. So this just worked there.--Jimmy Xu (talk) 13:51, 28 November 2009 (UTC)

Is the cause really this line of code?

   event.target.form.small.disabled = value != 'indefinite';

I don't see the point of having this, since by changing the category field and then changing it back this statement is by-passed and Twinkle can be made to do it anyway. It seems to work ok on the vandalism protection template (I have not tried it on other types) so I suggest just getting rid of this flawed piece of logic altogether. SpinningSpark 15:02, 18 December 2009 (UTC)

The original reason for this was that only indefinite protections should be allowed to be iconified, though it might have been changed and thus broken. _→AzaToth 23:07, 21 January 2010 (UTC)

Not sure why ? Yes, please allow for iconify for non-indefinite protections. I rarely use indef, but I often apply 3, 6, 12 months protection which should be iconified. –xeno^talk 14:17, 2 February 2010 (UTC)

The status at the top says "feedback required" - are you really still waiting for feedback and if so on what. It seems to me that the feedback has been given and "iconify" should now be allowed on semi-pp. It is often done this way outside Twinkle in any case. SpinningSpark 19:07, 22 April 2010 (UTC)

Just outdated, sorry for the confusion. Amalthea 21:05, 22 April 2010 (UTC)

TW-B-341

Status:  Resolved

Resolution:  Fixed

Notification of pending deletion of File:WAFN_logo.png was sent to User talk:RadioFan2 (usurped), rather than to User talk:RadioFan. This is, of course, due to the fact that the file's history shows that "RadioFan2 (usurped)" was the uploader. However, the file's page shows that RadioFan was the uploader. Some files have a list of uploaders as well. I don't know if there is any way to resolve this problem. Thanks! Plastikspork _―Œ^(talk) 13:47, 14 November 2009 (UTC)

I'm sure there would be, but:

1. Typically, the original uploader and the creator of the description page are the same person. Even if you enter no summary, the description page is created (as far as I know)
2. sending the notice to the initial uploader instead has significant problems if select file revisions get deleted (which happens more frequently than select file description page revisions getting deleted), most notably with non-free images that get a resolution reduction: the original file upload is deleted, and the person who supplied the reduction would now get the notification.

It *might* make sense to send notification to both the editor associated with the initial file description page revision and the editor associated with the initial file revision, but a number of editors who regularly work in that area might be pissed if they suddenly get the notifications of all the problems fair use images run into regularly.
The case you mention looks like a pretty weird one anyway, and might actually be a MediaWiki bug: the uploader should be the renamed "usurped" account as well, I think? Does that happen with other renamed accounts as well, or is this merely the known bug that renames sometimes only re-associate part of ones contributions?
Amalthea 10:31, 21 December 2009 (UTC)

In this particular case, the talk page states that this "user account" is "not registered". I don't know if this is a common problem that happens during renaming, or if it just happened in this case. According to Wikipedia:Changing_username, the process can take some time, but this has been quite awhile so something may have gone wrong. Would it be a good idea to make sure the talk page is for a registered user, and/or possibly follow redirects? Plastikspork _―Œ^(talk) 19:48, 21 December 2009 (UTC)

Renaming an account by default leaves the old account name unregistered, yes (although crats have the option to re-register it). Normally, all contribs are transferred, but that is known to be buggy, and regularly leaves (or used to leave, at least) some behind. I'm not sure it's worth it to actively workaround that MediaWiki bug where an unregistered account has contributions – but following redirects when leaving notifications, right, that's an issue worth fixing, that happens regularly and has annoyed me in the past, too, and as you said will almost always help with those cases as well. :) Amalthea 20:18, 21 December 2009 (UTC)

Per #357, user talk page redirects are now followed when placing user notifications, so I consider this  Fixed. Remaining weirdness with this image seems to be a bug with user renaming. Amalthea 15:16, 3 May 2010 (UTC)

TW-B-342

Status:  Resolved

Resolution:  Fixed

When welcoming with {{W-short}}, twinkle erroneously passes in the username of the user as a parameter like so {{W-short|Gigs}}. It should probably not pass any parameters, since that parameter is intended to be for extra comments and is appended near the end of the template. Gigs (talk) 14:20, 24 November 2009 (UTC)

Y That got a workaround back in June. Amalthea 15:26, 28 September 2010 (UTC)

TW-B-343

Status:  Resolved

Resolution:  Resolved

When tagging files for speedy deletion, Twinkle adds an extra "File:" into the user talk page message. See this diff where I manually edited out the extra text in the link. Thanks. – ukexpat (talk) 20:01, 26 November 2009 (UTC)

Resolved by making the templates smarter so that they accept all variants, using brand new "[[:{{file title | {{{1}}} }}]]". Amalthea 15:19, 27 November 2009 (UTC)

This is a duplicate of TW-B-330, is that resolved too? Graeme Bartlett (talk) 11:40, 28 November 2009 (UTC)

Now it is. :) I had only tweaked the di-* notice templates, didn't check any db-f*. The others of the series can probably use the same treatment. Amalthea 12:22, 28 November 2009 (UTC)

TW-B-344

Status:  Resolved

Resolution:  Fixed

Using csd A10 {{Db-a10}} results in [[:{{{article}}}]] on both the user page and the article page even if the original article is entered. Nick Wilson (talk) 08:54, 4 December 2009 (UTC)

[15] should fix it. (Ex: [16], [17]) Can someone do the edit? Tim Song (talk) 04:34, 6 December 2009 (UTC)

Extra tweak here to also insert a header consistent with other CSDs. Tim Song (talk) 05:25, 7 December 2009 (UTC)

Y Grmbl, darned non-standard notices. Amalthea 15:39, 11 December 2009 (UTC)

TW-B-346

Status:  Resolved

Resolution:  Invalid

I have just tried to PROD The Morning Chef using Twinkle. I clicked the PROD tab and filled in the rationale as usual, but rather than adding the dated PROD banner, the edit resulted in an SUBST template that was not executed. I'm not sure if this is a problem with {{prod}} or with Twinkle (or just user error on my part). I am using Firefox 3.5.6 and Windows Vista. Cnilep (talk) 21:49, 1 January 2010 (UTC)

The problem appears to have been user error on my part. Sorry. Cnilep (talk) 22:01, 1 January 2010 (UTC)

TW-B-347

Status:  Closed

Resolution:  Invalid

There are no twinkle links on pages without a dropdown menu in Vector skin, for example, an autoconfirmed user on a move=sysop protected page. --Liangent (talk) 04:43, 6 January 2010 (UTC)

Hmm, no, that shouldn't happen. If the dropdown has no elements, it's hidden due to the "emptyPortlet" css class. Twinkle calls addPortletLink, which will remove that class from the dropdown, thereby unhiding it. And it works for me, just checked it with my alternate account on e.g. WT:Twinkle, which is move protected, so I need more information. What browser are you using, are you seeing any Twinkle-related messages in you javascript console? If you are on a page with a hidden dropdown and paste

javascript:void(addPortletLink("p-cactions", "javascript:alert('test')", "Test"))

in your address bar and confirm it with Return, do you see the dropdown then? If not, any new error messages from that?
Amalthea 13:46, 6 January 2010 (UTC)

Oh, Twinkle doesn't work here on any page. I selected Twinkle in Special:Preferences-Gadgets, but there's nothing on any page. IE6@WINXP here. --Liangent (talk) 04:32, 7 January 2010 (UTC)

I seldom use IE, so I don't know how to do script debugging in it. --Liangent (talk) 04:34, 7 January 2010 (UTC)

Twinkle doesn't support IE anyway... Timotheus Canens (talk) 06:19, 7 January 2010 (UTC)

Exactly. Amalthea 09:10, 7 January 2010 (UTC)

TW-B-349

Status:  Closed

Resolution: Interference by Opera popup blocker

since I came back from wikibreak, I get a different behavior from twinkle. using 'rollback vandal' I can effectively rollback changes to a page, but for some reason twinkle then takes me back to the fixed page - it doesn't open the user talk page and set up the vandal warning template box the way it used to. there have been no changes in my user preferences (except a couple I made a moment ago, which were inconsequential). what gives? --Ludwigs2 20:35, 21 January 2010 (UTC)

Close your browser and reopen it again. Twinkle uses a named target to open the talk page and set up the vandal warning box, and this can sometimes get screwed up client-side. Ioeth (talk contribs twinkle friendly) 20:58, 21 January 2010 (UTC)

no, I tried that - same problem. it's possible I have a setting wrong in twinkle settings, or that one of the other javascript gadgets is conflicting (though no errors are showing up in Safari's error console). --Ludwigs2 22:50, 21 January 2010 (UTC)

Is this still happening? I notice that you changed your monobook.js only a few minutes before making this bug report, switching openTalkPageOnAutoRevert from false to true. Is it possible that you just didn't bypass your browser cache?
Is it possible that you simply block popup windows (in Safari, check Menu → Edit → Block popup windows).
Is Twinkle even claiming that it would open the talk page (i.e. it outputs "Info: Opening user talk page edit form for user [...])?
Amalthea 13:59, 18 May 2010 (UTC)

TW-B-350

Status:  Resolved

Resolution:  Fixed

I am using Firefox. When initiating a sock puppet investigation from a user's talk page, Twinkle experiences an error if there has already been a sockpuppet investigation of the user previously. Rather than writing a new report to the existing page, Twinkle, returns errors that it is unable to find a place to write the new socks and evidence. Redfarmer (talk) 16:18, 27 January 2010 (UTC)

Fixed with #384. T. Canens (talk) 11:37, 19 October 2010 (UTC)

TW-B-351

Status:  Closed

Resolution: beta feature was removed, even on http://usability.wikimedia.org, let's see what the revised version brings, if there ever is one.

Importing morebits.js into my vector.js stops beta's navigable TOC from working. I got the following error in Error console:

Error: $("<div></div>").attr("href", "#").addClass("section-" + structure[i].index).data("textbox", context.$textarea).data("position", structure[i].position) is undefined
Source file: http://bits.wikimedia.org/w/extensions/UsabilityInitiative/js/plugins.combined.min.js?68
Line: 156

I use FF 3.6. Svick (talk) 10:45, 27 January 2010 (UTC)

Asked for feedback, might have been some random fluke. Amalthea 17:16, 17 May 2010 (UTC)

TW-B-352

Status:  Resolved

Resolution:  Fixed

I'm not sure this exactly qualifies as a "bug," as I assume that the feature was never implemented, but it's definitely a problem involving reporting a user to WP:AIV. When linking to the last page a user vandalized, if that page happens to be a file, Twinkle will link to the page as [[File:FILENAME]], which causes the actual file to appear on the page, rather than linking to it. Here's an example. I would think making it link to as [[:File:FILENAME]] would fix the problem. Thanks, ~SuperHamster Talk Contribs 22:37, 1 February 2010 (UTC)

Actually that used to work once, but wasn't made aware of the Image→File namespace renaming. YFixed. Amalthea 14:01, 13 April 2010 (UTC)

TW-B-353

Status:  Resolved

Resolution:  Fixed

Rollback links will show when I first navigate to a users contribs page, but will disappear if I hit the reload button. my settings are standard - TwinkleConfig.showRollbackLinks = [ 'diff', 'others' ]; - and it works fine for the most part. it's just a pain to have to navigate back to the user page and reclick the contributions link. --Ludwigs2 19:07, 15 February 2010 (UTC)

Is that still happening? What browser? Any messages in your javascript error console? Amalthea 13:58, 13 April 2010 (UTC)

Using the Safari browser (4.0.5) on Mac OS 10.6.x. The problem still occurs, yes, and does not occur in Firefox on the same machine. error console is clear on the fist load of the page, but when I hit the reload I get a string of warnings and errors:

ajax.js - Resource interpreted as other but transferred with MIME type application/x-javascript.
mwsuggest.js - Resource interpreted as other but transferred with MIME type application/x-javascript.
centralnotice.js - Resource interpreted as other but transferred with MIME type application/x-javascript.
warning: index.php - Resource interpreted as other but transferred with MIME type text/javascript.
warning: index.php - Resource interpreted as other but transferred with MIME type text/css.
warning: index.php - Resource interpreted as other but transferred with MIME type text/javascript. (repeated 8 times)
error: index.php:1 - ReferenceError: Can't find variable: twinkleConfigExists
error index.php:67 - ReferenceError: Can't find variable: isIPAddress

--Ludwigs2 14:28, 13 April 2010 (UTC)

This might be fixed with the recent timing changes, waiting for feedback. Amalthea 15:45, 18 May 2010 (UTC)

TW-B-354

Status:  Closed

Resolution:  Invalid

In ARV, I can never select the “Evidently a vandalism-only account”-checkbox. Is there some magic condition for it or is it simply broken?--Oneiros (talk) 20:05, 22 February 2010 (UTC)

That option is not selectable when using ARV on anonymous users since an IP address is not an "account". It is not grayed out if you ARV an actual user account. Ioeth (talk contribs twinkle friendly) 20:34, 22 February 2010 (UTC)

Thanks, but I think in the days of static IPs many IPs on Wikipedia can be considered an "account".--Oneiros (talk) 22:06, 22 February 2010 (UTC)

TW-B-356

Status:  Closed

Resolution:  Invalid

Hi, I am from Bengali wikipedia I add this my user:Jayantanth/monobook.js page following script

document.write('<script type="text/javascript"' +
'src="http://en.wiki.x.io/wiki/User:AzaToth/twinkle.js' +
'&action=raw&ctype=text/javascript&dontcountme=s"></script>');

But twinkle tab is not coming for me. - - Jayanta Nath ^{(Talk|Contrb)} 19:53, 28 February 2010 (UTC)

Not a bug. But a fivefold multiposting, see WT:Twinkle#Twinkle for Bengali wikipedia. Amalthea 10:49, 2 March 2010 (UTC)

TW-B-357

Status:  Resolved

Resolution:  Fixed

Messages are left on talk pages that are #redirected - I'm specifically thinking about bot talkpages. Follow the redirect first. Josh Parris 00:51, 4 March 2010 (UTC) Example: http://en.wiki.x.io/w/index.php?title=User_talk:WildBot&curid=25358825&action=history Josh Parris 00:53, 4 March 2010 (UTC)

This is getting very annoying for me, especially for User talk:Marudubshinki. --Gwern (contribs) 13:31 3 May 2010 (GMT)

Should be  Fixed.
AzaToth added that feature with his MAJOR update back in September 2007 – in principle. However, it still had a bug, and it was never turned on as the default behavior (with explicit exceptions defined for deletions, protections, ...). Two and a half years later, I'm very hesitant to just switch it on as default behavior, since I don't really know which other tools are using the Twinkle base library, and whether they have added the explicit exclusions as well, so I have left it turned off by default, fixed the bug, and explicitly instructed user talk page notifications (and some other things) to follow redirects it finds.
Long story short: Fixed, but 1) I might have missed some notifications (please tell me if you notice them), and 2) it will take a few days for all Twinkle users to download the new script, so please be patient.
Amalthea 15:09, 3 May 2010 (UTC)

TW-B-358

Status:  Closed

Resolution: none

I tagged an article for CSD, and it placed two notifications on the contributor's talk page. NerdyScienceDude :) (✉ click to talk • my edits • sign) 00:47, 5 March 2010 (UTC)

Diff? Tim Song (talk) 00:52, 5 March 2010 (UTC)

First, it notified here, tagged article here, and then notified again here. NerdyScienceDude :) (✉ click to talk • my edits • sign) 01:43, 5 March 2010 (UTC)

No idea how that could happen, except by calling the script twice. User notification is triggered first, maybe the script got interrupted after the notification was triggered, but before the tagging happened, and you just called it again? Anyway, since I haven't heard that problem from anyone else thus far, I'm just going to write it off as a random fluke for now. If it happens again, please reopen to the bug or leave a notice on the talk page. Amalthea 13:57, 13 April 2010 (UTC)

TW-B-359

Status:  Closed

Resolution:  Dupe of #229

With consecutive FfD nominations with short time between them, nominations seem to disappear. See here and here. This may already be outdated, as the date of this was January 28th. עוד מישהו Od Mishehu 12:34, 7 March 2010 (UTC)

I have found one from February 2nd - [18]. עוד מישהו Od Mishehu 12:50, 7 March 2010 (UTC)

My guess is that it's got something to do with server lags...Tim Song (talk) 20:39, 19 March 2010 (UTC)

Here's a much more recent case: [19]. עוד מישהו Od Mishehu 06:22, 11 April 2010 (UTC)

From the looks of it this is the same as #229. Amalthea 17:06, 17 May 2010 (UTC)

TW-B-360

Status:  Closed

Resolution:  Dupe (bug TW-B-36)

When restoring an earlier version, if the earlier version contains a (now) blacklisted external link, then the page is not rolled back and no error message appears. It's only when you check the page that you find it is still the current page. This just happened on Alice in Wonderland (2010 film), where the old page had a link to theexaminer.com.  Ronhjones  ^(Talk) 01:22, 11 March 2010 (UTC)

Duplicate of TW-B-36. Ioeth (talk contribs twinkle friendly) 19:09, 11 March 2010 (UTC)

TW-B-362

Status:  Closed

Resolution:  Dupe of #235.

Nominated article for deletion and {{subst:afd1}} template was not placed at the top of the article. Possible change in template name? AfD discussion and article-creator-notification was fine. –Kerαunoςcopia^◁_galaxies 04:40, 3 April 2010 (UTC)

I couldn't find the article listed on the AfD discussion page either, so I had to add it in. – Kerαunoςcopia^◁_galaxies 23:41, 4 April 2010 (UTC)

TW-B-363

Status:  Resolved

Resolution:  Fixed

The rollback and rollback vandal links no longer appear in the contributions list. I'm using Firefox 3.6.2 on two different PCs and seeing the problem. The links do appear in the diff view. I notice this off and on.-- Mufka ^{(u) (t) (c)} 20:59, 4 April 2010 (UTC)

Örks, turns out MediaWiki underwent a trivial change that pulled out a space from a span content (changed " (top)" to "(top)"), so Twinkle didn't find those markers anymore. YFixed. Amalthea 09:17, 13 April 2010 (UTC)

The links now show up, but they don't work. Clicking them just brings you to the page history. -- Mufka ^{(u) (t) (c)} 02:03, 15 April 2010 (UTC)

Ah, thanks. Another MediaWiki change, the order of the diff and hist links in the contribs page changed, so Twinkle hits the wrong one (as do I since the change). Y Fixed, too. Amalthea 09:12, 15 April 2010 (UTC)

That's a relief! I was wondering why, out of the blue, I kept hitting the hist link instead of diff. I didn't even realize they were swapped. -- Mufka ^{(u) (t) (c)} 11:12, 15 April 2010 (UTC)

TW-B-364

Status:  Resolved

Resolution:  Resolved

When I report sockpuppets with the ARV tool, it fails to post the SPI case to WP:SPI, even though it said in the window it did. NERDYSCIENCEDUDE (✉ message • changes) 23:47, 4 April 2010 (UTC)

IIRC that was the job of SPCUClerkbot (talk · contribs). However, it's been down since quite some time. I'll try to find out whether it's expected back up anytime soon. Amalthea 12:04, 6 April 2010 (UTC)

There's a new bot in town. Amalthea 09:50, 27 August 2010 (UTC)

TW-B-365

Status:  Closed

Resolution:  Resolved

Twinkle Tab not appearing when I try to warn users. I tried on two different computers. It was working fine yesterday. Please leave a message on my talk page if there's a fix. DragonZero (talk · contribs) 00:25, 6 April 2010 (UTC)

I assume this is related to the issue raised at WT:TW#Deletion Options, related to a menu change in the vector skin. Try bypassing your browser cache, please. Amalthea 11:47, 6 April 2010 (UTC)

TW-B-367

Status:  Resolved

Resolution:  Fixed

RPP has stopped working Josh Parris 00:49, 14 April 2010 (UTC)

The RFPP page sections are slightly different now, which required a change to Twinkle. Was already done earlier today, you'll just need to bypass your browser cache or wait a while.
Amalthea 01:16, 14 April 2010 (UTC)

TW-B-369

Status:  Closed

Resolution: Can't reproduce.

When I use the "revert VANDAL" feature, it stops at "Reverting page: data loaded..." and doesn't actually revert the page. The only thing I changed in the configuration is that none of the pages I use Twinkle on are watched, and that the ad message is changed from ' using [[WP:TW|TW]]' to ' (using [[WP:TW|Twinky]])'.--Newbiepedian 14:38, 16 April 2010 (UTC)

Are you getting any Twinkle related error messages in your browser's javascript console?
BTW, you'll need to remove the image from your signature, per the signature guideline. You might find an equivalent unicode character you can use though.
Amalthea 12:08, 20 April 2010 (UTC)

No, I don't (re error message).--Newbiepedian (Hailing Frequencies) 23:52, 8 May 2010 (UTC)

Please tell me exactly what you are trying to do, on what page. Are you pressing that link on a diff page, or on a contributions page? What browser are you using?
For testing, please do the following (assuming you are using Firefox):

1. Press Ctrl+Shift+F5 to bypass your browser cache, reloading all Twinkle files.
2. Open your javascript console (Ctrl+Shift+J).
3. Press the "All" button, then press the "Clear" button
4. Follow this link (nobody else, please): [vandalism]. Does it revert? If not, switch back to the javascript console. What does it show?
5. Go to this diff and use the "rollback (VANDALISM)" link there. Does it work? If not, switch back to the javascript console. What does it show?

Amalthea 10:08, 10 May 2010 (UTC)

Feedback not forthcoming, user no longer active → closing this. Amalthea 18:37, 29 September 2010 (UTC)

TW-B-371

Status:  Resolved

Resolution:  Fixed

When using the deli-batch function to mass delete files (displayed on a non-category page) rendered in gallery format (with <gallery> tags), Twinkle only loads data for the first 10 files. It would be much appreciated if someone could remedy this. Thanks in advance, FASTILY_sock^(TALK) 04:30, 2 May 2010 (UTC)

Y Fixed. Amalthea 17:23, 4 May 2010 (UTC)

TW-B-373

Status:  Resolved

Resolution:  Invalid

Twinkle failing to function at all in vector skin on IE8. I know Twinkle isn't officially supported for IE, but it has worked up to now. However, on IE, it's only currently working in the monobook skin, not in Vector. I have checked for the dropdown menu mentioned, and it's simply not there. Is there anyone who could look at this externally, since IE isn't technically supported please? :) BarkingFish ^{Talk to me} | _{My contributions} 01:22, 14 May 2010 (UTC)

Not a bug, you weren't importing the scripts in your Vector skin script file, User:BarkingFish/vector.js. Amalthea 20:42, 14 May 2010 (UTC)

TW-B-375

Status:  Closed

Resolution:  Works for me

I am unable to report foreign language usernames with non-latin characters to UAA. On a whim, I looked at the new users' log, and decided to run a Google Translate on User:沈彥良的陰莖太小，讓許瑜真非常不滿意！. Turns out it's an offensive username in Chinese, so I tried to report it to UAA. My report did not show up and I had to make a manual report. Tckma (talk) 13:21, 27 May 2010 (UTC)

Worked for me. What browser are you using, any error messages in your javascript console (WP:TW/DOC#Trouble)? Amalthea 13:51, 27 May 2010 (UTC)

This worked for me later. For future reference, Firefox 3.6.3. I didn't see any relevant error messages in the javascript console. Tons of Wikipedia-related warnings about unknown properties and when certain properties should and should not be used, but nothing seemed relevant to this issue. Tckma (talk) 19:48, 27 May 2010 (UTC)

Seems to work for you, too. Closing this. Amalthea 14:38, 27 May 2010 (UTC)

TW-B-376

Status:  Closed

Resolution:  Dupe of #235

When I report a nonsense redirect to WP:RFD, it fails to add the redirect deletion discussion to today's list. Décembër21st2012Freâk ^Talk at 02:18, 30 May 2010 (UTC)

See #235. It's my impression that most of the time people just don't wait until all components of the AfD listing are finished. Amalthea 10:09, 9 June 2010 (UTC)

TW-B-377

Status:  Closed

Resolution:  Dupe of #235

When submitting imedix for AfD the AfD was created and the original creator notified but no tag was placed on the articles page. --Wintonian (talk) 20:02, 31 May 2010 (UTC)

See #235. It's my impression that most of the time people just don't wait until all components of the AfD listing are finished. Amalthea 10:09, 9 June 2010 (UTC)

TW-B-380

Status:  Closed

Resolution:  Invalid Not Twinkle's fault.

Using twinkle can cause the cursor to flash from different types in Firefox. Not sure if it is TW, but I just noticed it while using it.  A p3rson ‽ 02:08, 9 June 2010 (UTC)

I don't understand this report. "cause the cursor to flash from different types" – what does that mean? Amalthea 10:11, 9 June 2010 (UTC)

TW-B-381

Status:  Closed

Resolution:  Invalid

When I want to report a user, I go on their contributions page.I then click on the twinkle tab at the top of my page. I then click the button AIV.I type a reason and it says report completed.Then it says would you like to go to the AIV page. I click on it but my report hasn't been submitted. Gobbleswoggler (talk) 15:30, 12 June 2010 (UTC)

Please look at WP:TW/DOC#Trouble for everything you need to tell me so that I can even begin to look into this. In particular, your browser version and the output from your javascript error console. Amalthea 15:45, 12 June 2010 (UTC)

Appears to work for you without issue. I would have expected you to follow up on this, and not let me keep looking into it while it was resolved for you. Amalthea 20:22, 16 June 2010 (UTC)

TW-B-382

Status:  Resolved

Resolution:  Fixed

Typo when requesting semiprotection of a high-visibility template: RPP request says "high-visiblity template" (missing an I in "visibility"). Diff. Chris Cunningham (not at work) - talk 12:44, 22 June 2010 (UTC)

Y Fixed. Amalthea 12:49, 22 June 2010 (UTC)

TW-B-383

Status:  Resolved

Resolution:  Fixed

Simple enough; Twinkle still says "bit-for-bit identical copy" for CSD F8, but F8 now allows for lower resolution/cropped versions of identical images. Could this please be changed so that everyone is on the same page? ▫ JohnnyMrNinja 17:26, 27 June 2010 (UTC)

Y Fixed. Thanks. — This, that, and the other (talk) 09:06, 22 February 2011 (UTC)

TW-B-384

Status:  Resolved

Resolution:  Fixed

Twinkle sometimes does not detect correctly if an existing SPI case page has an open SPI case. To reproduce:

1. Go to User:Tnaniua (randomly selected blocked user with an existing SPI case page)
2. Try to use Twinkle to file an SPI report
3. Twinkle erroneously thinks that there's an SPI case open, and attempts to merge the case to the existing case, and fails without filing anything.

Suggested fix: either (1) always file a new case regardless of whether there is an open case; or (2) fix the open case detection algorithm, which only seems to work if the SPI case page contains only the {{SPIarchive notice}} template. T. Canens (talk) 23:44, 28 June 2010 (UTC)

Experienced the same when trying to do an SPI on User:Tdi7457‎. -- AnmaFinotera (talk · contribs) 21:44, 11 July 2010 (UTC)

 Fixed this myself, along with support for the new SPI updates; it also uses a new centralized SPI report template ({{SPI report}}). I picked option (1), since merging cases is a pretty rare scenario anyway. T. Canens (talk) 05:04, 18 July 2010 (UTC)

TW-B-386

Status:  Closed

Resolution: Can't reproduce

Sorry if this has been posted before, but when I just used twinkle to start an AFD it overwrote the previous AFD for that article (from 2005, so actually a VFD). relevant diff [20] Yoenit (talk) 20:43, 18 July 2010 (UTC)

That is extremely odd. I can't say why that happened for you. It shouldn't, and it works for a dozen folks every day. When I try reproducing it with that page I get a proper API response telling me all AfD pages, and it would correctly continue with a 3rd nomination.
I'm going to write it off as a random fluke. If anyone else ever notices that (and note that this is a different problem here than other "Twinkle overwrites warnings/MfDs" bugs) please open a new bug. Amalthea 15:21, 28 September 2010 (UTC)

Amalthea, don't be surprised by the fact that this bug report was filed in three months ago, and things probably have changed since then, so it may have been fixed later on after this report, but Yoenit maybe haven't noticed it, or (s)he didn't post a notice here saying it has already been fixed. HeyMid (contributions) 17:33, 28 September 2010 (UTC)

TW-B-387

Status:  Resolved

Resolution:  Fixed

Today, when I tagged a page for speedy deletion and Twinkle gave the page creator a welcome message in addition to the speedy deletion notification (since the page creator didn't have any previous messages), the section header for the speedy deletion notification appeared on the same line as the final line of the welcome message. As a result, the section header did not display correctly and I had to manually fix it. This is an example of what I'm talking about. --SoCalSuperEagle (talk) 17:37, 24 July 2010 (UTC)

Y Fixed, thanks. Was a template issue, not directly a problem with Twinkle. Amalthea 19:26, 24 July 2010 (UTC)

TW-B-388

Status:  Closed

Resolution:  Won't fix

Restored version information incorrect. This shows an IP edit and my revert, but with the IP details of the previous editor. Strange, have not seen this previously. gonads³ 22:41, 26 July 2010 (UTC)

I don't see any revert by you in that diff? Amalthea 22:50, 26 July 2010 (UTC)

That's my point. TW reported success, but my revert appears as them. Somehow can't quite believe that the IP editor reverted their own revision, especially considering the intention. Could this be expected behaviour if they did? If so, why the success message? gonads³ 23:07, 26 July 2010 (UTC)

If you reverted the same thing the IP reverted shortly before then yes, it's expected behavior. You'd actually get the same result if you would have undone the edit manually instead of with Twinkle: The supposed edit conflict from the two overlapping edits would have been handled by MediaWiki since it would have been able to merge the two edits.
You're quite right that Twinkle shouldn't show a "success" message. Twinkle handles most unexpected situations rather poorly, and rarely gives Feedback of anything like that. I'm afraid that won't be changed though, at least not until someone finds the time to do a quite complete rewrite.
Amalthea 21:05, 27 July 2010 (UTC)

Thanks for the response. gonads³ 21:09, 27 July 2010 (UTC)

TW-B-389

Status:  Closed

Resolution:  Invalid

There may be problems with edit conflicts in Pending Reviewed Changes. Please see Wikipedia:Pending_changes/Feedback#Confusion_on_Narendra_Modi for a detailed description of the potential issue. Tckma (talk) 20:12, 27 July 2010 (UTC)

This is actually the expected Twinkle behavior. If you look at a diff of two non-consecutive revisions, like e.g. this one, MediaWiki gives you the "(XX intermediate revisions not shown)" hint to indicate that there are revisions between the two revisions that you don't immediately see. However, that doesn't change the behavior of Rollback (both Twinkle and MediaWiki): If you press Rollback on the right-hand revision, you will not rollback all the way to the left-hand revision. Instead, you only rollback all consecutive edits by the editor of the right-hand revision. If you want to restore the left-hand revision, youe the "restore this revision" link.
I've never thought about this, but I agree that it is bad. You will not know what the rollback links actually do unless you previously checked the history (explicitly or with navpop). If you want that changed, I'd ask you to discuss the best behavior at WT:TW first.
Amalthea 21:40, 27 July 2010 (UTC)

TW-B-391

Status:  Closed

Resolution:  Invalid

Sockpuppet notice clears other information from page. See this edit; why did twinkle remove all that information from the page when it was only necessary to add the appropriate text? — Timneu22 · talk 18:27, 2 August 2010 (UTC)

This is almost certainly not a bug in Twinkle, but the server serving outdated information to it. T. Canens (talk) 11:44, 19 October 2010 (UTC)

TW-B-393

Status:  Resolved

Resolution:  Fixed

When trying to use TW to tag User:Mendaliv/infosandbox with {{db-u1}}, TW returns an error that {{{dbi|}}} is already on the page. I was experimenting with template parameters and had one that, incidentally, started with "db". I understand that this might not be fixable without causing problems (my immediate thought would be "what about the common situation where someone puts one too many braces when manually tagging?"), but thought I'd bring it to the attention of you good folks, as you might have a better solution. I'm going to leave the page up for the time being rather than manually tag it in case you want to see what happens firsthand. —/Mendaliv/^2¢/_Δ's/ 16:27, 18 August 2010 (UTC)

You're quire right that we can't ever completely fix this. The best way to recognize SD tags would usually be to look at the rendered output and pick up signs there, but that has other drawbacks.
Anyway, I've tweaked the regex a bit to have fewer false positives. It won't now pick up on {{dba1}} anymore, but so what – we should certainly err on the side of fewer false positives here, they are far less annoying.
Thanks, Amalthea 15:06, 28 September 2010 (UTC)

TW-B-395

Status:  Closed

Resolution: Not a bug, feel free to modify the template.

When a user is 'welcomed', Twinkle does not put the welcome into a == Section ==. [21] [22] [23] WP:FRIENDLY does [24] - it actually 'knows' if the specific welcome does or does not have a section heading, and if not, it adds one. WP:HUGGLE always makes a heading too.

Putting the 'welcome' message into a headed section gets them used to the concept more quickly, and avoids confusion down the line. It gets users off to a good start; if the welcome is not in a section, it leads them to think that is normal on a talk page.

Very often, we respond to {{helpme}} where it has a bold Welcome instead of == Welcome== and, very often, such users do not create section headings when asking things.

So, please, could Twinkle make sure it always puts comments on talk pages into sections. Thanks,  Chzz  ►  01:12, 25 August 2010 (UTC)

Twinkle uses {{Firstarticle}} for those welcomes. Feel free to change the template to use a sectioned header. If people there disagree feel free to come back and we'll pass a parameter to switch on it in the template, or something like that. Amalthea 14:42, 28 September 2010 (UTC)

TW-B-396

Status:  Resolved

Resolution:  Fixed

When tagging my user subpage User:Train2104/Brooklynbustest as U1, I get a prompt to enter a reason to delete this user talk page, when this is not a talk page. — Train2104 (talk • contribs • count) 17:37, 27 August 2010 (UTC)

It no longer aborts if I don't enter a rationale, but it shouldn't prompt AT ALL on a userpage. —Preceding unsigned comment added by Train2104 (talk • contribs) 01:26, 15 September 2010 (UTC)

The template requires a rationale on base user talk pages, which is why a mandatory rationale was added in response to #312.
Y Fixed so that it now only asks there. It's mandatory on those though, the template would complain otherwise. Amalthea 14:39, 28 September 2010 (UTC)

TW-B-397

Status:  Closed

Resolution:  Dupe of WP:TW/BUGS#340

If I semi protect and click the "iconify" box, I don't get the small padlock display - see Kirkcaldy High School for example, I had to manually edit and add small=yes  Ronhjones  ^(Talk) 21:57, 27 August 2010 (UTC)

TW-B-398

Status:  Closed

Resolution:  Invalid

Today, Twinkle seems to be failing to open the user talk page after a vandalism rollback. For example, this reversion failed to open the IP's page, even though Twinkle said it was about to do that. SpinningSpark 09:30, 5 September 2010 (UTC)

No longer happening. SpinningSpark 10:32, 17 September 2010 (UTC)

TW-B-399

Status:  Closed

Resolution:  Invalid

When I am looking at the page history of an article Twinkle's rollback buttons do not seem to appear at all next to the list of revisions. Please tell me if there is a fix for this. Thanks. Usb10 ^Connected? 14:42, 6 September 2010 (UTC)

 Invalid It's absolutely normal. When you look at the page history for an article/page, you shouldn't see them, nor is Twinkle set/programmed to do so. However, if your language preferences is set to "en - English", you should be able to see the "[rollback]" and "[vandalism]" buttons in a user's contributions page (like mine), excluding your own contributions page. However, these buttons only apply to the latest edit an user has made to a specific article.

Also, you should be able to see the buttons "[rollback (AGF)]", "[rollback]" and "[rollback (VANDAL)]" in a diff page, like this one, at the right side, no matter which language you have set your preferences to. However, if that edit is not the latest one made in that specific article/page, you will only see the "[restore this version]" button at both the left- and right side.

Because of all of this, I have marked this bug report as closed and invalid.

/HeyMid (contributions) 13:41, 17 September 2010 (UTC)

TW-B-400

Status:  Closed

Resolution:  Invalid

It seems that this evening, Twinkle is no longer refreshing a page after it has been tagged for speedy deletion. One occasion today, it notified a user that a page has been tagged for speedy deletion but the tag wasn't on the page. Superchrome (talk) 16:05, 6 September 2010 (UTC)

Appears to have been fixed. Superchrome (talk) 16:12, 8 September 2010 (UTC)