Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Kotniski (talk | contribs) at 13:55, 1 August 2011 (→‎Linking from "Search" to "Help:Search"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at BugZilla.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.


Huggle experiment

Hi everyone. I just wanted to post a notice on-wiki about a short experiment the WMF Community Dept. is running with the cooperation of Huggle developers.

This is a project of the Summer of Research team at the WMF. The quick explanation: for a few days we’re trying an experiment where we test level 1 warning templates that are explicitly more personalized and set out to teach new editors more directly, rather than simply pointing them to policy and asking them not to do something. (We based the new content partially on the experience of people who've done lots of vandalfighting on the team, as well as the work of our researcher who is a professor of rhetoric and composition.)

In order to get a statistically significant sample size, we’re using a randomized template generator through Huggle to apply one of eight templates. All of them can be seen here, but the rundown is that set is A/B testing the standard level 1 warnings compared to three variants:

  1. Instructional messages (that teach the new editor a little about the community and what to do going forward to improve their editing)
  2. Personalized messages (that introduce who reverted them, why, and what they should do to improve their editing or get answers to questions)
  3. All the templates with or without images (because we don't know what effect they have)

The templates are applied randomly and seamlessly through Huggle; people using the tool to revert and warn will not notice a difference at all. (We did a pre-test with an active Huggler to try them out initially.)

It’s only going to run for a few days (starting tomorrow if all goes as planned), since at full steam that’s enough Huggling for us to get a proper sample size. Then we’ll revert back to the standard Huggle templates and analyze the data to see if the people warned with the new templates were comparatively less likely to keep making mistakes and instead actually do constructive things like leave edit summaries and use the Sandbox.

Please let me know if you have any questions about the test, the templates themselves, or how to replicate it in other areas warning templates are used. If you want to try the same style of alternative warning styles in other areas outside Huggle, give a shout and the research team is happy to help. If you want to opt out for the few days of the test, you can add the following to Special:MyPage/huggle.css: warning1:{{subst:huggle/warn-1|1=$1|2=$2}}

Thanks, Steven Walling at work 00:12, 19 July 2011 (UTC)[reply]

Should a template similar to {{z1}} be added to the warnings, so we can track how many warnings were delivered? --Σ talkcontribs 05:46, 19 July 2011 (UTC)[reply]
That is a great suggestion. We were working on a different tracking system, but now also have:
{{z49}} → {{Uw-vandal-rand1}} case 0
{{z50}} → {{Uw-vandal-rand1}} case 1
{{z51}} → {{Uw-vandal-rand1}} case 2
{{z52}} → {{Uw-vandal-rand1}} case 3
{{z53}} → {{Uw-vandal-rand1}} case 4
{{z54}} → {{Uw-vandal-rand1}} case 5
{{z55}} → {{Uw-vandal-rand1}} case 6
{{z56}} → {{Uw-vandal-rand1}} case 7
Thanks again Σ. :) I'll make sure that the list of users is readily available on-wiki so anyone else interested can take a look at the effect they had. Steven Walling at work 17:51, 19 July 2011 (UTC)[reply]
This template needs some debugging. For starters, I don't think you can nest "includeonly" tags inside "includeonly" tags; but there seem to be other problems as well. -- John of Reading (talk) 18:19, 19 July 2011 (UTC)[reply]
Stu seems to have fixed the includeonly problem. If there are other specific ones, let us know. Steven Walling at work 18:31, 19 July 2011 (UTC)[reply]
Well, I stripped out all the interior includeonly tags and replaced them with noincludes that split up the subst functions, but that didn't work out. We did test the version of the template that had multiple nested includeonly tags, and it worked. Were there any other problems? StuGeiger (talk) 18:34, 19 July 2011 (UTC)[reply]
Looks like I was fooled by the mess at the foot of Template:Uw-vandal-rand1. It all seems to work if you subst it. -- John of Reading (talk) 20:03, 19 July 2011 (UTC)[reply]
I've removed the inner includeonly tags, but did not replace them with noinclude tags. This should work fine. mc10 (t/c) 02:48, 20 July 2011 (UTC)[reply]
Well, the attempt to be less bitey seems to have failed on this user. Oh well. --Σ talkcontribs 01:05, 22 July 2011 (UTC)[reply]
Heh, that user seems like a lost cause, at least for a few more years. :) I do think his response points to an interesting challenge -- making these templates more personal could also increase the risk that patrollers will be personally called out and attacked.--Eloquence* 08:01, 22 July 2011 (UTC)[reply]
Stu Huggled a bit with these templates before we set up the test to try and get a feel for it. Turns out that out of ~25: he got one incident of vandalism directed at his userpage, but that resulted from the standard level 1 warning. :) From the friendly template, he got an incident where a good faith editor (who probably otherwise would've been blocked for violating WP:NFCC) asked him a question and managed to upload a file to Commons in their first few edits. Anyway, we'll definitely have to see at the end of the test whether there is statistically significant increase in personally-directed vandalism. Steven Walling at work 16:55, 22 July 2011 (UTC)[reply]
  •  Question: Thanks, this is badly needed. Actually, I wish there were a way to ensure that I always used the friendlier templates, since the harshness of many Huggle templates puts me off to using them. Not uncommonly I'll take the time to warn in Twinkle because of that. Is this possible, or would it skew your data? causa sui (talk) 23:34, 25 July 2011 (UTC)[reply]
You can create copies of those templates in your userspace and exclude the {{z}} trackers. Except getting them into TW would be problematic, a bit. --Σ talkcontribs 02:43, 26 July 2011 (UTC)[reply]
After this test I will probably make some customizations of revert configuration in huggle to let users choose which kind of templates they would like to use. There are users who like evil templates and there are also users who like friendly (like me, that is why I also implemented welcome templates) unfortunatelly any enforcement in the usage always ended up in huge dispute which kind is better. Petrb (talk) 06:15, 26 July 2011 (UTC)[reply]
I'd agree that it shouldn't be enforced, and I'd be happy if there were a switch I could flip to use the nice templates. But... opt-in is a way of encouraging productive behaviors without offending anyone's sensibilities by taking away choices. Just sayin'. :-) causa sui (talk) 17:18, 26 July 2011 (UTC)[reply]

Quick Feedback on Editing Experience: New Editors

Hey everyone,

I just wanted to give people the heads-up that we'll be rolling out an experimental feature aimed at collecting feedback on the editing experience of new editors. Currently called MoodBar (it's not a great name -- if anyone has anything better, please let us know), the feature will appear as a small link in the upper left hand corner for new editors that have tried to make an edit. Technically, this means users that have registered for an account after the launch date of the feature who have also clicked on an edit link (regardless of whether they've successfully completed the edit). We hope to get quick feedback from users on their early editing experience, ranging from reactions to the editor/wikitext, interactions with the community, feelings of success/frustration, etc. This feature is part of the set of New Editor Engagement projects.

We don't know whether this feature is going to provide meaningful feedback. We certainly hope it does, but I'm expecting a fair amount of noise as well (I'm sure there will be plenty of "Wikipedia Rocks!", which is nice, but not that helpful). For starters, we'll be publishing anonymized CSVs containing the data. If the feedback proves meaningful, we'll develop a dashboard to make viewing feedback easier.

We're going to be pushing to prototype soon, so please feel free to test the feature. To test the feature, create a new account, click on any edit link, and the invitation should appear. I'll put date this post once the feature is up on prototype.

If all goes well with prototype testing, we'll be rolling out this feature early next week.

Disambiguation note: Article Feedback Tool = feedback from readers on article content. MoodBar = feedback from new editors on their early editing experience.

Feedback on the feedback tool? Please post on the feature discussion page. Howief (talk) 21:36, 21 July 2011 (UTC)[reply]

Howief, thanks for notifying us about this. I have posted a pointer to this discussion on WP:AN. Seeing this extension made me sad because:
  • Wikipedia is not Twitter.
  • If the feedback given has a very low signal to noise ratio, will the extension be pulled?
  • Otherwise, what are the means for dealing with abusive comments, excessive personal information and other unwarranted crap? Will this result in an increase in administrative workload?
  • Will there be a new prompt every time the edit button is clicked, even if the extension is dismissed? Is the extension hard disablable via preferences or turns off when the editor (say) becomes autoconfirmed?
I appreciate the motivation behind this but I prefer something that is obviously separate from the encyclopedia. MER-C 04:10, 22 July 2011 (UTC)[reply]
As a bit more background, this extension was inspired by the Firefox Feedback Program. Mozilla has learned that by asking users to provide small, quick bits of categorized feedback, they can use data mining to surface trends in the data, in spite of the noise. See e.g. Aakash Desai's original presentation and update for more info about it.
The current implementation is a quick & dirty hack to just see what the s/n ratio is like and what kinds of feedback we can expect. If it's useless, we'll ditch it pretty quickly, which is why we're not making a fuss about this early deployment. As for crap, FF has implemented a few crap filters (as well as e.g. phone number pattern detection), which we'll also need to do if we get more serious about it. But having a certain level of noise in the data would be acceptable for the purpose this serves, and the data would never be encountered by anyone not looking for it, just like you've probably never heard of the FF feedback data.
The current implementation is dismissable with a single click, after which it disappears, but the hide code just uses a cookie, so it's imperfect. If all goes to plan, it'll only show up for new users.--Eloquence* 08:13, 22 July 2011 (UTC)[reply]
I think this is an excellent idea that, better than the article feedback tool, actually focuses on a point where significant difficulty is likely to arise, asks the right question and aims to give us meaningful feedback on that aspect of the editing process. I'll be interesting to see how it works out. Wikipedia is not Twitter; I can't help feeling this misses the point of the tool entirely :S --Errant (chat!) 09:05, 22 July 2011 (UTC)[reply]
"new editors that have tried to make an edit." - hit edit and escaped without saving? On first edit? After first edit? Bulwersator (talk) 11:11, 22 July 2011 (UTC)[reply]

Just to clarify, at least for our first experiments, feedback is not currently going to be immediately viewable by anybody outside the Foundation. This means that there won't be any need for administrative work, and it's definitely not "Wikipedia twitter" (do we seriously have a "Wikipedia is not Twitter" page?) — it's just about letting us at the Foundation know how new users experience Wikipedia. If we find that the feedback is actually useful and has a good S/N ratio, then (according to my understanding of the plan) we MIGHT start thinking about surfacing this information to the community. — Andrew Garrett • talk 17:45, 22 July 2011 (UTC)[reply]

Yes, we seriously have a "Wikipedia is not Twitter" page/shortcut - it links to a content policy page and is part of Wikipedia's Five Pillars. Jezebel'sPonyobons mots 15:53, 23 July 2011 (UTC)[reply]
Actually, we do intend to surface the feedback to the community. It will just be done via CSV file instead of a dashboard. We didn't want to over-build this feature since we don't know whether the feedback will be useful. We wanted to get a feel for the quality of the data first before building out the feature.
To answer Bulwersator's question -- the invitation is activated upon clicking edit. A user who clicks on the edit but doesn't successfully submit the edit will still get the invitation. We'd like to collect feedback from anyone who's attempted to make a contribution, successful or not.
There's still an issue with the feature on prototype, so I'll let everyone know when there's something up that people can check out. Howief (talk) 19:45, 22 July 2011 (UTC)[reply]
The feature is up on prototype now. There are still a few kinks we're ironing out, but feel free to play around with the feature:
    • Go to http://prototype.wikimedia.org/release-en/Main_Page
    • Create an account. Check "Remember me (up to 30 days)". There is a bug on prototype that requires checking this box to stay logged in. Note: Existing accounts on prototype will not work since the feature is only enabled for new users (i.e., users who create an account after deployment of feature.
    • Go to a random article.
    • Click Edit.
    • You should see the Moodbar invitation in the upper left hand corner.
Please let us know what you think on the feature talk page. Thanks! Howief (talk) 22:35, 22 July 2011 (UTC)[reply]

Note to users without javascript, this feature requires javascript to function. - Hydroxonium (TCV) 05:02, 23 July 2011 (UTC)[reply]

Our deployment has gone ahead successfully, and the MoodBar is now being shown to new users who have viewed the edit page. — Andrew Garrett • talk 23:16, 25 July 2011 (UTC)[reply]

Let displaytitle use other names

The magic word DISPLAYTITLE allows users to change the visible title of a page, without changing the actual title, so that articles can have titles not possible in mediawiki, such as eBay (lowercase first letter). However, the template only allows page titles that resolve to the same titles; i.e. you have to be able to type the title as it is displayed on the page in the search bar and have it take you to the correct page. this page specifies that this is "under the current software configuration." Does anyone know if this is actually a setting that could be easily changed by a developer to allow titles that don't resolve to the normal pagename? If it is, then I plan to start an RFC about it, so that some articles can get the proper name - such as Cyberbu//y. Quinxorin (talk) 00:39, 22 July 2011 (UTC)[reply]

I have no answer to your question, but I think you meant to link to Cyberbully (film) rather than to Cyber-bullying. ​—DoRD (talk)​ 01:05, 22 July 2011 (UTC)[reply]
There's going to be a resurgence in Willy-on-Wheels-ish vandalism, by simply using {{DISPLAYTITLE|(insert page name here) on wheels}} instead of having to move the page. --Σ talkcontribs 01:10, 22 July 2011 (UTC)[reply]
I've already occasionally seen "new" users vandalizing pages with {{DISPLAYTITLE:I EAT PENIS ~ ~ ~~(----8!!!}}. Reaper Eternal (talk) 13:29, 26 July 2011 (UTC)[reply]
I guess you mean Cyberbully (film) although your piped link doesn't go there. Cyberbu//y is a valid page name and I have redirected it to Cyberbully (film) so I don't see a need for DISPLAYTITLE here. If we wanted to call the page Cyberbu//y then we could just move it. The problem with changing the displayed title is not copy-pasting to the search box. You don't need to do that if you are already on the page. The problem is copy-pasting to a wikilink on another page. Editors do that all the time when they interlink pages and I think it should create a valid link. It is controlled by mw:Manual:$wgRestrictDisplayTitle and could easily be changed by a developer. See also mw:Manual:$wgAllowDisplayTitle. PrimeHunter (talk) 01:21, 22 July 2011 (UTC)[reply]
Just to clarify, I don't think copy-pasting the displaytitle is the only problem. Other problems include displaytitle vandalism, and confusion when the displayed title isn't shown in categories, searches and other places showing the actual page name. PrimeHunter (talk) 01:28, 22 July 2011 (UTC)[reply]
I agree, I don't think that display hacks like this are a particularly good idea: changing the colour is OK if it satisfies WP:CONTRAST, but removing (or adding) characters is not. I have seen similar things done on other User: pages, but I can't remember whose - and this one popped up on my watchlist today. --Redrose64 (talk) 11:55, 22 July 2011 (UTC)[reply]
Indeed.
I personally use the following JS snippet to undo this kind of changes on user pages:
if ( $.inArray( mw.config.get( 'wgNamespaceNumber' ), [ 2, 3 ]) > -1
	&& $.inArray( mw.config.get( 'wgAction' ), [ 'view', 'purge' ]) > -1
	&& mw.config.get( 'wgTitle' ).indexOf( mw.config.get( 'wgUserName' ) ) === -1
) {
	$(function () {
		var html = $('#firstHeading').html();
		if ( html !== mw.config.get( 'wgPageName' ) ) {
			// Restore the original userpage name
			$( '#firstHeading' ).html( mw.config.get( 'wgPageName' ).replace(/_/g, ' ') );
		}
		// Repositions fixed images used on user pages, such as those from
		// [[commons:Category:Wikimedia related application icons]]
		$('#bodyContent *').filter(function(index) {
			//MediaWiki doesn't insert fixed content inside of #bodyContent
			return $( this ).css( 'position' ) === 'fixed';
		}).css( 'position', 'static');
	});
}
Helder 13:59, 22 July 2011 (UTC)[reply]
My little protest (per rev:49330). --Splarka (rant) 09:04, 23 July 2011 (UTC)[reply]
<3 Killiondude (talk) 19:30, 23 July 2011 (UTC)[reply]

"v-d-e" into "maintenance" or "m"

Now that we've grown up, should not the "v-d-e" {{navbar}} be simplified into "maintenance" (or similar: "m"). It should link to the template page, and from there everything is the same. -DePiep (talk) 20:45, 23 July 2011 (UTC)[reply]

  • I propose to replace the template (navbar) "v-d-e" linking set with "maintenance" (or "m", or ...). It would have the "v"-link effect. (added later here for clarity, -DePiep (talk) 23:47, 23 July 2011 (UTC))[reply]
You seem to be under the impression that v-d-e were added so that we could fill out pages. Is that correct? I was under the impression they are for convenience… --Izno (talk) 20:49, 23 July 2011 (UTC)[reply]
I don't get your meaning of "fill out pages". For us at VPT & technically minded, it is ok this way. But we write for readers and other editors, and they might think different. (Again, what is "fill out pages"?) -DePiep (talk) 21:10, 23 July 2011 (UTC)[reply]
What is the issue? Has a problem been reported? ---— Gadget850 (Ed) talk 21:47, 23 July 2011 (UTC)[reply]
I personally oppose the VPT suggestion. --Ancheta Wis (talk) 22:23, 23 July 2011 (UTC)[reply]
The v-d-e links seem fine to me? They are for convenience for technically savvy editors. The links are small enough so as to not be distracting, and people would typically only click on them when they already know what they are since they don't provide much context. Gary King (talk · scripts) 22:07, 23 July 2011 (UTC)[reply]
Gadget850: No, there is no problem. I think it would be an improvement. After all, the main page has tabs for "Discussion" and "Edit", why should a template on that page have its own 3 links?
Gary King: "seems fine to me" -I prefer discussion, not individual experience. Of course me too knows what the v-d-e is about. I am at the tech-VP. My point is: we are not editing for our fellow techs. For a wiki-reader, the v-d-e code is strange at least. So when we techs agree (and then WP/Policy will follow ;-), let alone the view-minded WP/Misc), we can improve the Wikipages. A wikireader does need nor like these codes. And we can help him/her. -DePiep (talk) 22:28, 23 July 2011 (UTC)[reply]
I don't follow. What's being proposed here, exactly?
— V = IR (Talk • Contribs) 22:33, 23 July 2011 (UTC)[reply]
A change to the menu links in the info boxes from v-d-e to m and attendant changes to the logic of displaying the info boxes. --Ancheta Wis (talk) 22:36, 23 July 2011 (UTC)[reply]
(edit conflict) I propose to replace the template (navbar) "v-d-e" linking set with "maintenance" (or "m", or ...). It would have the "v"-link effect. -DePiep (talk) 22:42, 23 July 2011 (UTC)[reply]
OK, I sorta thought so. Please don't. At the very least, create a new "navbar" instead of changing the existing one, and switch the new in for the old where there's actually support for that. I'd oppose such a switch almost universally though, simply for the fact that the "v-d-e" links are extremely useful. Why force people to click twice (once to the page, then again to do what they actually want) when a single click gets them to where they want to go with no side effects? I don't understand what the problem with the "v-d-e" links are.
— V = IR (Talk • Contribs) 23:19, 23 July 2011 (UTC)[reply]
I don't understand what the problem[s] ... are. Neither do I. Who said there was a problem? (please).
Ohms law: by alternative template(-switch) would be nice. My main point is that not every link needs a three-way link. (Hey, why not add "h" for history too? And, why not three links somehow for every wikilink? -- right, there is a reason for that). Of course every savvy editor wants to go to the "Edit" page right away. But how many are they, compared to the unsavvy editor, and more relevant: compared to number of readers? The v-d-e buttons are there for our minority (tech savvy editors) only. For a reader they are confusing at least (I say intimidating). -DePiep (talk) 23:47, 23 July 2011 (UTC)[reply]
OK, how about this: I don't understand what the motivation for this proposal is. Is the... er, "problem" that templates are being made to be too easy to edit or navigate to the talk page?
— V = IR (Talk • Contribs) 00:35, 24 July 2011 (UTC)[reply]
I honestly think it's just fine the way it is. I understand that it might not be the most helpful answer in the world, but I honestly don't see the benefit in switching, especially for a non-intuitive "m" for "maintenance". EVula // talk // // 23:58, 23 July 2011 (UTC)[reply]
I think I had already been an admin for some months before I figured out how to easily access templates without copying the header and using Special:Search. I honestly wouldn't mind turning "v-d-e" into "view-discuss-edit", but that might be too much I suppose. NW (Talk) 00:09, 24 July 2011 (UTC)[reply]
I agree with EVula; how would an "m" be any less confusing than "v-d-e". There's no problem with the current format. BigDom 08:29, 24 July 2011 (UTC)[reply]
Of course, the "m" is not essential. It could be "T" (for template), or a symbol. What I want to introduce is: why should every template on a page have these multiple links? Hey, why not add "history" too? Those of us who know what it's about, can go ahead. The reader, most and most of our public, have no message in these details. Right in the middle of a serious page: they (and me) can do with a single "view the template" link. -DePiep (talk) 21:50, 24 July 2011 (UTC)[reply]
I fail to see how a "T" or a symbol would be less confusing; it's doubly confusing, given your appeal to the needs of the reader after suggesting something even more cryptic. (and I don't think there's a history link because it's not as readily needed) What articles are you reading that there's a template "right in the middle" that has that trio of links? Every time I've seen it, it's been on a navbox at the bottom of an article. EVula // talk // // 01:41, 25 July 2011 (UTC)[reply]
If you use the big words, then it will be intrusive. v · d · e works fine for me, and if I forget what they mean, then the mouseover display will remind me. ---— Gadget850 (Ed) talk 03:38, 25 July 2011 (UTC)[reply]
Here are some that are right in the middle. As for turning "v-d-e" into "view-discuss-edit", something very similar is very easily done: just remove the |mini= parameter from the {{navbar}} and you get "[view · talk · edit]". --Redrose64 (talk) 12:12, 25 July 2011 (UTC)[reply]
Ah, okay; I don't think I'd ever seen that before. (but then again, I never look up English railway topics...) However, I still don't think it's an issue, or something that would be "fixed" by implementing a more cryptic alternative. EVula // talk // // 14:00, 25 July 2011 (UTC)[reply]

How nice to turn this into "full words or abbreviations?". I maintain that a template only needs one link to that template (be it "v", "m", "t" or a symbol). From there, any editor can move further. Just as with any other link: we don't have "v-d-e" (.. history etc) links with a regular wikilink in the text, do we? -DePiep (talk) 21:16, 27 July 2011 (UTC)[reply]

How about giving a demo? The other editors indicate they are content. The prospect of a swirl of UI changes to the main implementation based on one editor's aesthetic requires consensus. It does not require consensus to implement a suggestion if you build a parallel demo. Then a thumbs up/down response to the demo. You could use the test wiki as your test platform. --Ancheta Wis (talk) 22:28, 27 July 2011 (UTC)[reply]
...and I maintain that stripping down the links to just a single letter or symbol is counter-intuitive. Suggestions that we need to change a standard practice must present a viable argument in favor of the new system; nothing personal, but I (and apparently several others) aren't convinced. The "v-d-e" links aren't particularly analogous to regular inline wikilinks, so trying that approach isn't going to work. I think Ancheta Wis' suggestion of testing it out somewhere is a good one. EVula // talk // // 22:50, 27 July 2011 (UTC)[reply]
I agree. Additionally, as I said above, please create a new template to test this out with, and see if it gains approval. I'd hate to see most of the "v-d-e" links suddenly change.
— V = IR (Talk • Contribs) 23:13, 27 July 2011 (UTC)[reply]
This sub is an inviting tone & talk, thank you. I'll get to an example. And hey, if I really wanted to trick something, would I start it here in the VP/T-home? I just wanted to check my idea head on. Now as said, thank you. More here later on. -DePiep (talk) 23:13, 28 July 2011 (UTC)[reply]

permanently hiding the notices and such on Watchlist

I don't care about meetups or crat rights. Can I just turn that off forever?TCO (reviews needed) 03:36, 25 July 2011 (UTC)[reply]

Add
#watchlist-message {display: none}
to Special:MyPage/common.css. Ucucha 12:11, 25 July 2011 (UTC)[reply]
Done. Thanks. We might want to make it a profile setting. I bet a lot of people want to turn that stuff off.TCO (reviews needed) 13:02, 25 July 2011 (UTC)[reply]
That would be a very bad idea in my opinion. People should be informed about important things such as crats being authorized to take away administrator rights. We should not encourage people to 'not be informed'. —TheDJ (talkcontribs) 16:47, 25 July 2011 (UTC)[reply]
It's fine if it is the default setting. But people should have the option to turn it off if they want. We all edit with different reasons and committments and should be able to tune out some of the spam if we choose. Others may want more...and you can see them with RFA notice thingie on their userpage. Chacun a con gout.TCO (reviews needed) 16:56, 25 July 2011 (UTC)[reply]
Of course; people turning it off should also lose any rights to complain about social/community/policy changes that they miss because of it :) --Errant (chat!) 17:08, 25 July 2011 (UTC)[reply]
Agreed...and if they do, tease them.TCO (reviews needed) 17:58, 25 July 2011 (UTC)[reply]

JavaScript Problems

I placed code on my common.js page that was on my vector.js page, and now that code is not working! I'm going to move the code back to my vector file until I find an answer. Please help. --Nathan2055talk 00:53, 26 July 2011 (UTC)[reply]

Uh oh. Now all of my scripts have stopped working after the moves! HELP!!!!!!!!!!!!!!! --Nathan2055talk 02:20, 26 July 2011 (UTC)[reply]
 Done Apparently, against all known wiki laws, JavaScript pages break if moved. You have to cut-and-paste move, then nominate the old page for CSD U1. Weird. --Nathan2055talk 16:54, 26 July 2011 (UTC)[reply]
Probably a caching issue, or the fact that there was a redirect. I don't think JS should be redirected using the wiki format. :^) --Izno (talk) 18:04, 26 July 2011 (UTC)[reply]
Redirects on normal pages are wikicode. The .js pages are for JavaScript, not wikicode. Thus it's highly unlikely to work. If #REDIRECT is a valid token in JavaScript, it's not necessarily going to do the same as a MediaWiki redirect. It's unlikely to be the same, given that the hash sign has a completely different meaning in JavaScript. --Redrose64 (talk) 19:05, 26 July 2011 (UTC)[reply]
Reported on bug #30074. Helder 19:38, 26 July 2011 (UTC)[reply]
Is there a way to do a move without making redirects? --Nathan2055talk 21:02, 26 July 2011 (UTC)[reply]
Yes: but you need to be an administrator or better, see WP:R#SUPPRESS. --Redrose64 (talk) 21:06, 26 July 2011 (UTC)[reply]
Which is why I didn't get problems doing this. Ucucha 21:47, 26 July 2011 (UTC)[reply]

help...all my toolbar addins are not working

(I am not technically minded.)

I added a cite toolbar, some thingie from Commons that makes images easy to add when editing, and then a smiley thingie. Now none of that stuff is working. I really need the cite toolbar back please. — Preceding unsigned comment added by TCO (talkcontribs) 05:45, 26 July 2011 (UTC)[reply]

Without more detail, it's hard to say what exactly is going wrong. However, it looks like some script is interfering with another. You should probably try turning off all the scripts you added recently (such as by reverting this edit) and then turning them on one by one to see what causes the problem. Ucucha 12:34, 26 July 2011 (UTC)[reply]
I just went and nuked everything on the .js and .css pages, but still cite toolbar is missingTCO (reviews needed) 12:54, 26 July 2011 (UTC)[reply]
Did you re-add the cite toolbar after blanking the page? If not, then go re-add only it. --Nathan2055talk 16:57, 26 July 2011 (UTC)[reply]

I have posted in detail about a similar problem; see Wikipedia:Village_pump_(technical)/Archive_90#My_gadgets_are_gone_most_of_the_time. My problem was never resolved. Cleaning out my .js and .css had no effect. Apparently bits.wikimedia.org frequently times out, and bits is evidently the server that feeds the browser the necessary core javascript functions so that toolbars and gadgets can work.

I suggest to Ucucha to look at that report I linked and click on the example links to bits.wikimedia.org. Then try looking at your browser's status message bar to see if it's hanging when trying to access bits. I use Google Chrome, and the message "Waiting for bits.wikimedia.org" appears -- when this appears for several seconds I know I'm not going to get any of my gadgets. ~Amatulić (talk) 17:08, 26 July 2011 (UTC)[reply]

To create any of this stuff, I just followed instructions from people to cut and paste stuff to these strange pages. Is it possible for others to edit these pages of mine? In which case, I just ask that someone fix it, please? (Sorry if that is pathetic.)TCO (reviews needed) 17:41, 26 July 2011 (UTC)[reply]
Yes, admins can edit your .js pages. However, I wouldn't know exactly what to do. Did you turn anything on in your gadgets (via Special:Preferences)? Also, in User:TCO/common.css (now blanked), you should not have had the texts "<source lang="css">" and "</source>", but that probably didn't cause your problems.
Amatulic, those links work fine for me. Ucucha 21:56, 26 July 2011 (UTC)[reply]
I had turned on the multimedia beta (for adding images). Could it have conflicted with the smilie code? Just turned it off now. Would like to get something back though. Right now, I'm stripped bare. At least the cite toolbar... — Preceding unsigned comment added by TCO (talkcontribs) 22:09, 26 July 2011
By cite toolbar, do you mean the citation expander? --Nathan2055talk 22:31, 26 July 2011 (UTC)[reply]

It's like up where the advanced characters and all that are. But I'm missing it. Actually it is back now. Maybe the image multimdia beta thing was conflicting with it (go in same spot). I turned that off in prefs. Would like to go reload all my .js and .css now.TCO (reviews needed) 23:21, 26 July 2011 (UTC)[reply]

Upload file

I have created a upload form for myself there. Is there some way that the "Upload file" links to my upload form? Sir Armbrust Talk to me Contribs 12:01, 26 July 2011 (UTC)[reply]

Add the following to Special:Mypage/common.js:
$( document ).ready( function() {
   $( 'a', '#t-upload' ).attr( 'href', '/wikipedia/en/wiki/User:Armbrust/Upload' );
});
If you're not using the secure server, remove "/wikipedia/en". Ucucha 12:11, 26 July 2011 (UTC)[reply]
Thanks. Sir Armbrust Talk to me Contribs 12:41, 26 July 2011 (UTC)[reply]
Even better, use the function wikiGetlink provided by MW 1.17:
$( 'a', '#t-upload' ).attr( 'href', mw.util.wikiGetlink( 'User:Armbrust/Upload' ) );
and it will work both on secure and unsecure servers. Helder 14:41, 26 July 2011 (UTC)[reply]
Thanks; I wasn't aware of that function. Ucucha 21:48, 26 July 2011 (UTC)[reply]

SVG Maps

Forgive me, but I do not understand the point of these SVG maps. Coming from three diffent pages, including Cape Breton Island and Mira River, I followed links from maps with proper labels and red dots marking the locations in question, yet arrived in all three cases at the same generic unmarked "Canada Nova Scotia location map 2.svg" map. In other words, in all three cases I followed the links, loaded the higher-resolution images (on a dial-up connection, as I am in a very rural area), and came to maps with LESS pertinent information than the thumbnails I had started from!

Is this how the standard Wikipedia mapping system is now supposed to function? Why have a link from the thumbnail version at all? Common sense dictates that the higher-resolution image should have the same location-marking dot, and ideally the same image label, all in a higher-resolution image. That would provide MORE information.

I mean no criticism of the editors, but I do believe there is some deficiency in the new mapping system if this is what it produces.


Heavenlyblue (talk) 00:30, 27 July 2011 (UTC) — Preceding unsigned comment added by Heavenlyblue (talkcontribs)

The mapping system works by placing one image over another. It's a very useful system, because it doesn't require a separate file for each location of the dot. I agree though that it has the drawback you describe; I suppose it should be possible to have the image link to a larger version of the same map with the dot on it, so that you can see the location of a place more precisely. Ucucha 01:55, 27 July 2011 (UTC)[reply]
While that may be indeed useful, I'm not sure how could that be done without creating new page for every map or using a special extension for that. The only way I could imagine this could work in the short term would be using JavaScript (with the obvious disadvantage that it wouldn't work for users without JS). User<Svick>.Talk(); 20:54, 31 July 2011 (UTC)[reply]
Creating separate bespoke maps would be an absolute nightmare. Consider Wembley Stadium railway station: in the infobox, there is a SVG map with the position of the station indicated by a red snooker ball. This is a generic map, used on over one thousand pages. Therefore, to incorporate specific markers, over 1000 different SVG maps would need to be drawn just for the Greater London area, and I am sure that Nilfanion (talk · contribs), who has produced most of these generic maps, has better things to do.
There is a much easier alternative. Most articles which deal with a static feature will have the relevant latitude/longitude coordinates, usually at upper right. These are clickable and take you to a page listing various mapping services of greater or lesser accuracy. Some of these do add a relevant marker, some do not. Try clicking the coordinates on Wembley Stadium railway station - for convenience, here is the link: 51°33′15″N 0°17′11″W / 51.5543°N 0.2863°W / 51.5543; -0.2863 Go there, and try any of the links in the "Bing Maps" rows - these all have markers; by contrast, the lnk after "Ordnance Survey Get-a-map" does not. --Redrose64 (talk) 21:54, 31 July 2011 (UTC)[reply]

LaTeX equation problems

Resolved
 – Redrose64 (talk) 12:28, 30 July 2011 (UTC)[reply]

Today there seems to be a problem with the LaTeX equation editor. If I copy an equation as is from an article, it parses properly, as for example.

However if I make a small change such as replacing each n (except the one in "int" of course) by an m, I obtain the message Failed to parse (unknown error). If I change back to the original equation it works again.

This is annoying because it makes it very difficult to edit equations. In this case I wanted to change all the n in this equation to m because n has another meaning in the article Entropy of mixing. Another editor told me he had similar problems (see Talk: Entropy of mixing# Notational confusion and LaTeX problems ). Can anyone help? Dirac66 (talk) 02:33, 27 July 2011 (UTC)[reply]

P.S. This is a new problem. I have made similar edits to equations before without problems. Dirac66 (talk) 02:49, 27 July 2011 (UTC)[reply]
P.P.S. I have just discovered that the problem is browser-dependent! I get a Failed to parse error with Internet Explorer (version 7.0.5730.11), but I can edit the equation correctly with Mozilla Firefox (version 3.6.3). It still should be fixed to work with any browser of course. Dirac66 (talk) 03:16, 27 July 2011 (UTC)[reply]
I am able to edit the equation using IE9. If it's an option, try upgrading to IE8 (obviously I don't know if IE8 works) to see if that will serve as a workaround. --Izno (talk) 05:22, 27 July 2011 (UTC)[reply]

Sounds like the problem is that you're still using internet explorer for some reason. —SW— gossip 18:38, 29 July 2011 (UTC)[reply]

Dirac66 was using IE7 (7.0.5730.11), but I had no trouble with IE7 (7.0.5730.13). Dirac66 seems unable to reproduce the problem, and has since amended the article satisfactorily, so it's all sorted now. The "for some reason" may be that Dirac66 edits from work - many employers have a strict policy on which software may or may not be installed. --Redrose64 (talk) 12:28, 30 July 2011 (UTC)[reply]

Broken 'Contact us' link

The following is the message I see at the top of my watchlist:

Wikipedians of Columbus: A professor at the IUPUC is looking for Wikipedia Campus Ambassadors for the upcoming fall semester! Contact us if you are interested. [hide]

The above message returns 'The action you have requested is limited to users in the group: Users'.

The link worked, I thought on the weekend, when I replied to it for a different location, but the link does not work right now. My browser is Chrome 12.0.742.122

The symptoms and message do not appear at all for Firefox 5. It adds up to something I ought to ignore for now? --Ancheta Wis (talk) 04:24, 27 July 2011 (UTC)[reply]

The watchlist message is a Wikipedia:Geonotice from MediaWiki:Geonotice.js. The link on "Contact us" goes to http://en.wikipedia.org/wiki/Special:EmailUser/Etlib. Logged out users will see the message you quote: 'The action you have requested is limited to users in the group: Users'. Logged in users without email enabled will see the more informative message at MediaWiki:Mailnologintext: 'You must be logged in and have a valid authenticated e-mail address in your preferences to send e-mail to other users.' Perhaps the same message should be shown to logged out users if possible. PrimeHunter (talk) 04:48, 27 July 2011 (UTC)[reply]
There's a similar message here in Bloomington, for that matter. When I clicked it, I was sent to an email-this-user for the same user, an IUB librarian. Nyttend (talk) 17:04, 27 July 2011 (UTC)[reply]
Filed bugzilla:30127 for this UI experience problem. —TheDJ (talkcontribs) 12:11, 30 July 2011 (UTC)[reply]

Search results page proposal

For many years now Ive been wondering why there is no button on the search results page (when no article is found!) that allows you to search for the same entry in a different language. I often search for articles on the Dutch wikipedia, and when an article doesnt exist there should be a faster way of searching for the same thing in the English version (which is more likely to exist in most cases). Anyone else annoyed by this? A "search in different language" dropdown thingy with all (or most popular) languages would be rewarded with my eternal gratitude! — Preceding unsigned comment added by 94.65.26.37 (talk) 11:44, 27 July 2011 (UTC)[reply]

Until such a proposal is implemented, the quickest way is just to change the "en" in the URL to the language code of the wiki you want to search, e.g. change http://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=Bryste to http://cy.wikipedia.org/w/index.php?title=Special%3ASearch&search=Bryste to search the Welsh Wikipedia. Thryduulf (talk) 12:53, 27 July 2011 (UTC)[reply]
You can put the interwiki prefix (usually a language tag, but can be other things) into the search field itself as a shortcut between projects. For example, search for "fr:Wikipédia:Accueil principal" and you'll jump straight to the French Wikipedia's Main Page, or "s:de:Osymandias" or read Shelly's Ozymandias on the German Wikisource.
As for the initial post, I don't think there's an option because a lot of times, searching for the exact phrase is pointless. Look at Earth. It is also called Aarde, Земя, Erde, Γη, Jörðin, 地球, Мушар, Zemlja, Daigdig, and Kalibutan (just to name a few). Even for some biography articles, how each language handles each person's name can be different; I bet you can't tell who バラク・オバマ, باراک ئۆباما, 巴拉克·奥巴马, or 贝拉克·奥巴马 are without clicking on the links. (all the same person) EVula // talk // // 15:08, 27 July 2011 (UTC)[reply]
Other Wikipedias could add a link to the results page "try this search on en.wp | de.wp | es.wp | ... |" by editing the relevant MediaWiki page on their wiki (MediaWiki:Searchmenu-new / MediaWiki:Searchmenu-exists I think), and particularly for smaller Wikipedias that would make a lot of sense. You'd have to propose that on each wiki (not least because each wiki would probably have different choices, eg a Germanic language would probably link de.wp but an Asian one probably wouldn't). Searching across many Wikipedias at once would require maybe a toolserver tool or a MediaWiki change. Rd232 talk 13:46, 27 July 2011 (UTC)[reply]

js to add watchlist pages

I currently have in my monobook.js a link to User:R3m0t/handywatch.js to add pages listed at Special:unwatchedpages to my watchlist. I would like to add all the RfD daily log pages to my watchlist (Wikipedia:Redirects for discussion/Log).

If I placed a copy of R3m0t's script as User:Thryduulf/rfdlogwatch.js and changed the line if (thisLink.href == 'http://en.wikipedia.org/wiki/Special:Unwatchedpages') { alert("Finished! " + counter + " pages added."); return; } to use the url http://en.wikipedia.org/wiki/Wikipedia:Redirects_for_discussion/Log, and then included a link to this script from my monobook.js (I use the monobook skin), would it do what I want? If not what would work? (I'm no programmer, so please don't get too technical)

Sorry if this isn't the place to ask, but R3m0t appears to be inactive currently. Thryduulf (talk) 12:46, 27 July 2011 (UTC)[reply]

Interesting. I was under the impression that Special:Unwatchedpages did not exists due to WP:BEANS issues. It seems to me that this is the last list we would want available for anyone with less than noble intentions to get their hands on... --Jezebel'sPonyobons mots 19:58, 27 July 2011 (UTC)[reply]
Its not beans, Special:Unwatchedpages is only available to sysops. ΔT The only constant 20:08, 27 July 2011 (UTC)[reply]
Ah ha, well that would explain why I am now able to view it. --Jezebel'sPonyobons mots 20:11, 27 July 2011 (UTC)[reply]

While the above might be interesting, it doesn't answer the question! Is there a way to do what I want to do? Thryduulf (talk) 11:29, 31 July 2011 (UTC)[reply]

Being redirected to mobile

Recently, when I clicked my watchlist and contribs links, they redirected me to the mobile site, and the disable mobile site function and view on regular wikipedia functions failed. I believe this is a server bug.Jasper Deng (talk) 19:45, 27 July 2011 (UTC)[reply]

I also got this bug, although it seems to have passed now. Monchoman45 19:56, 27 July 2011 (UTC)[reply]
I was also getting this. --Kumioko (talk) 20:01, 27 July 2011 (UTC)[reply]
Were on this. This was due to single box squid testing that we were doing with the operations team. Its has now been disabled while we fix the redirect. When we got back up .. we'll make sure to have a feedback page in place so that we can lets people know what UA's are still getting caught. Tfinc (talk) 21:22, 27 July 2011 (UTC)[reply]
Just as background ... these changes are meant to fix https://bugzilla.wikimedia.org/show_bug.cgi?id=24859. Come join us on #wikimedia-mobile if you have any questions. — Preceding unsigned comment added by Tfinc (talkcontribs) 21:24, 27 July 2011 (UTC)[reply]
I got a weird-looking screen while editing and copied and pasted to an email but it looked perfectly normal in the email. I do remember a "disable mobile site" button.Vchimpanzee · talk · contributions · 21:47, 27 July 2011 (UTC)[reply]
I'm having his issue too, on an intermitent basis! Dric dolphin (talk) 21:06, 29 July 2011 (UTC)[reply]
If you haven't yet .. please let us know what browser your using and we'll get it fixed. Tfinc (talk) 03:16, 30 July 2011 (UTC)[reply]

Interlanguage link

I just created the following new article: Ibn Abi al-Shukr which does not contain any interlanguage links but for some reason, I'm seeing a link to the Portuguese wiki under "Languages", which links to a template not an article. Please note that the new article includes the following template: Template:Islamic mathematics which has a Portuguese version. Is this a bug ? Al-Andalusi (talk) 04:29, 28 July 2011 (UTC)[reply]

The iw link was outside the <noinclude>s. Fixed. --Izno (talk) 04:53, 28 July 2011 (UTC)[reply]
Thanks ! Al-Andalusi (talk) 14:41, 28 July 2011 (UTC)[reply]

Combining parent and child templates

Does anybody have a fancy tool for combining child and parent templates (and grandparent templates)? Heyzeuss (talk) 16:12, 28 July 2011 (UTC)[reply]

Could you give an example of a template relationship you are talking about? --Kumioko (talk) 16:16, 28 July 2011 (UTC)[reply]
Template:Str right, which calls up more than 20 other templates. They won't let me import the template into Wiktionary, so I was thinking of rolling up the whole thing and moving it to my user space there. It's a server -expensive template, so I would only use it with subst, I promise. Heyzeuss (talk) 16:26, 28 July 2011 (UTC)[reply]
Special:ExpandTemplates? Ucucha 23:37, 28 July 2011 (UTC)[reply]
That was my first thought but I don't see how to use it on a template which should still be able to take input parameters. PrimeHunter (talk) 23:43, 28 July 2011 (UTC)[reply]
Really the only way to do this is using Special:Export, but Special:Import is usually only usable by administrator (and for good reasons). —TheDJ (talkcontribs) 11:51, 30 July 2011 (UTC)[reply]
Is there any quick and dirty way to take the network of templates and collapse them into one huge, grotesque stand-alone template? Heyzeuss (talk) 03:30, 31 July 2011 (UTC)[reply]

In edit, no tag-checking?

In my Edit-screen, I have the colored text parts (must be CSS mode). What I don't understand is, why cannot the CSS color mark uneven tags? Like, when I use <div>, a closing </div> can be checked, not? (Sure, my next question will be about curled brackets, but hey - if I don't understand this one, I'll leave the subject). -DePiep (talk) 22:59, 28 July 2011 (UTC)[reply]

It sounds like you're using WP:WikEd, for which you should probably ask at User talk:Cacycle/wikEd. --Izno (talk) 17:32, 29 July 2011 (UTC)[reply]

feed for external links

Is there a real-time(or near real time) web feed for external links added?Smallman12q (talk) 01:44, 29 July 2011 (UTC)[reply]

did the site-installed fonts change?

I don't get how fonts work on Wikipedia (in terms of the gritty details) -- I personally I thought it was all localside, but I had to change the font I used for an Emily Dickinson poem I was displaying on my userpage cuz the "Bell MT" font was rendering awfully -- and I tried this across several computers. The appropriate revision is here -- where the font is now a nasty bold. Funny thing is, it rendered fine a week ago, across a multitude of computers. Now it renders wrong, across a multitude of computers. Is it something site-specific? Did something happen to one of the sitewide stylesheets? elle vécut heureuse à jamais (be free) 03:54, 29 July 2011 (UTC)[reply]

Font looks fine in that revision, despite not being the default one. The default font across the site hasn't changed from what I can see. Perhaps your computer's fonts have become corrupted? Here's a page that might be useful; I don't use Windows myself, so I wouldn't know. For Macs you'd have to clear the font cache. Gary King (talk · scripts) 06:33, 29 July 2011 (UTC)[reply]
There are only site installed fonts for Math and for SVG images. The rest is always client side. At least for now. In the future, we likely will have WebFonts that can be used to force specific fonts to be loaded for certain foreign languages for instance, but that is not a reality just yet. —TheDJ (talkcontribs) 11:50, 30 July 2011 (UTC)[reply]

Mediawiki search engine confused by spaces in prefixes

It appears that search handles prefix queries differently for "prefix:A_B" vice "prefix:A B". Is there some justification for this behaviour, or is it just a bug? e.g. [1] LeadSongDog come howl! 16:46, 29 July 2011 (UTC)[reply]

It seems to only affect searches which use "prefix:". The prefix allows you to filter your search by only showing pages whose titles start with the prefix string. However, since the prefix is always specifically applied to page titles, and since page titles can't include the _ character, I think it is reasonable to say that it should be smart enough to filter out the underscores and replace them with spaces. —SW— chat 18:13, 29 July 2011 (UTC)[reply]
That's about what I thought. Thank you for confirming in isn't just local weirdness with my browser.LeadSongDog come howl! 18:30, 29 July 2011 (UTC)[reply]
Filed as bugzilla:30125. Remember, issues that are not reported in bugzilla are guarenteed to not get fixed. Bugzilla might not be ideal, but it is the one central place where bugs and feature requests are tracked. —TheDJ (talkcontribs) 11:47, 30 July 2011 (UTC)[reply]
Indeed, and thanks for filing it. But I'm sure you'll agree there's value in prior discussion to reduce the number of unnecessary or incorrect bugs... :) Rd232 talk 23:12, 30 July 2011 (UTC)[reply]

Finding blocked users

Is there a way to easily check a list of users to see who in that list is (indefinitely) blocked? The scripts don't seem to fully work for me. Avicennasis @ 18:03, 27 Tamuz 5771 / 29 July 2011 (UTC)

Special:BlockList —SW— gossip 18:05, 29 July 2011 (UTC)[reply]
Unless I'm missing something, I can only search one user at a time with that. I'm looking to check some rather large lists of users. Avicennasis @ 18:08, 27 Tamuz 5771 / 29 July 2011 (UTC)
What format is your list in? There isn't any way that I know of to query a list of users and get a response on all of them. You'd probably need a bot to do that, or an SQL query on toolserver. I can probably help you with that if it's just a one time thing, or you can ask at WP:BOTREQ to see if someone is willing to build a tool that will allow you to do this whenever you want. —SW— spill the beans 18:14, 29 July 2011 (UTC)[reply]
Categories (and listified categories.) I'm looking for something I can run once a day. I know I could use the API, however I'm not sure how to easily strip away the blocks with an expiration date. (I'm looking for indef blocks, specifically.) Avicennasis @ 18:23, 27 Tamuz 5771 / 29 July 2011 (UTC)
There isn't going to be a way you can format your API query so that it only returns users that are blocked with an expiry of infinity. You'd have to get the full list and then filter out any entries that don't have expiry="infinity". If this is something you want to do on a daily basis, you'll need to request that a bot be made for it or get a database report created for it. —SW— communicate 18:34, 29 July 2011 (UTC)[reply]
It looks like you already have some bot experience. Can't you just get the full list of users and their block lengths, and then filter out the entries that don't have expiry="infinite" using a script? —SW— gossip 18:35, 29 July 2011 (UTC)[reply]
It looks like I'll have to do that. I was hoping I could take the lazy route, and that someone else would already have something like this. :-) Oh well. Avicennasis @ 18:44, 27 Tamuz 5771 / 29 July 2011 (UTC)
If you add importScript('User:Ronhjones/strikeblocked.js'); to your monobook.js (assuming you use that skin), then all blocked users names on history and talk pages are struck through. (It's not my code - I "borrowed" it from somewhere else - I think it was the Russian WP, which slowed the page loads down, hence I went for a local copy).  Ronhjones  (Talk) 19:29, 29 July 2011 (UTC)[reply]
Looks like a version of ru:MediaWiki:Gadget-markblocked.js, which is the same as in the script I linked to above. :-) Avicennasis @ 20:08, 27 Tamuz 5771 / 29 July 2011 (UTC)

Contribution search tools

I have recently created two toolserver tools which I believe could be useful for searching through page histories and contribution histories. I'm looking for comments on whether these tools would be helpful to add to the "External Tools" area on the History page and the "User info" pane at the bottom of a user's Special:Contributions page. Here are some links and a brief explanation of how the tools work:

  • User contribution search - Searches through a page's history for edits by a particular user. In other words, it filters a history page by user.
  • Edit summary search - Searches through a user's edit summaries by keyword.

Any comments or suggestions are appreciated. I created these tools only a few days ago, so I'm sure they still have some bugs to work out, and could use some visual improvements. —SW— confabulate 23:23, 29 July 2011 (UTC)[reply]

Only for en wiki? Would be great if its extended. I like the edit summary tool especially. Srikanth (Logic) 00:53, 30 July 2011 (UTC)[reply]
Those seem pretty useful. Could you strip trailing spaces and make the page name box wider? (Also, check the spelling of the page title on the results page :) where it also says "max pages" instead of "max edits" ) Rd232 talk 01:14, 30 July 2011 (UTC)[reply]
Yes! Thank you. The things I would suggest are to display the number of matches and to disable the "next X results" link if there are no more results.Orange Suede Sofa (talk) 01:17, 30 July 2011 (UTC)[reply]
Much easier than playing with the API. :-) I like it. Great work! Avicennasis @ 01:38, 28 Tamuz 5771 / 30 July 2011 (UTC)
All good suggestions. I will see what I can do to implement them. Thanks! —SW— prattle 05:57, 30 July 2011 (UTC)[reply]
Bugs? Active SQL injection (try anything with a double quote), XSS attacks, stored XSS attacks, hard-coded namespaces, confusing number and strings, incorrect Unicode support and problem when using the new HTTPS (but that new so I can't blame you). Read tswiki:Tool considerations and contact me on IRC for assistance in fixing these problems. — Dispenser 11:55, 30 July 2011 (UTC)[reply]

String manipulation

Is there any way to strip one character off the beginning of a string, like {{trunc}} but the opposite? That is to say, something like

{{strip|Hello|1}}

that would yield

ello

I've tried a bunch of the templates in Template:String templates see also text, but they have a lot of limitations (the string I intend to strip characters off of is a string that would include a WP user signature, so it exceeds the length limit of most of those templates, and includes characters that makes those templates upset). mw:Extension:StringFunctions looks useful but doesn't seem to be enabled on en-wiki. Any other ideas? rʨanaɢ (talk) 04:01, 30 July 2011 (UTC)[reply]

The opinion of the developers is that if you need this stuff, 'you're doing it wrong'. These templates are rather complex and intensive and the string functions extension, will further complicate the mediawiki parser language in a way that is not desirable. In almost all cases, what is needed here instead is either a special extension or people just being less crazy in what they want to program into an encyclopedia. :D —TheDJ (talkcontribs) 12:01, 30 July 2011 (UTC)[reply]
Try {{Str right}} -- WOSlinker (talk) 12:05, 30 July 2011 (UTC)[reply]
  • To substring with special characters (in signatures), try Template:Strr, but it stops at 100 characters, so we need a longer version. Also, consider if chopping a tail-substring is really needed. Meanwhile:
  • Using: {{strr|....:....1....:....2....:....3....:....4....:....5....:....6....:....7....:....8....:....9....:...10....:...11....:...12....:...13....:...14....:...15....:...16....:...17....:...18....:...19....:...20....:...21....:...22....:...23....:...24....:...25....:...26|4}}
  • Gives:
....1....:....2....:....3....:....4....:....5....:....6....:....7....:....8....:....9....:...10....:...11....:...12....:...13....:...14....:...15....:...16....:...17....:...18....:...19....:...20....:...21....:...22....:...23....:...24....:...25....:...26
The processing in {strr} is very complex and intensive, whereas a left-side substring is almost instaneous (perhaps 1,000x faster): {{str_left|HITHERE|2}} → HI. However, if the truncation is done only rarely, then being "1,000x" slower is okay, just avoid using it zillions of times. Note, those {{cite web}} templates, used to format source footnotes, are currently 1,500x slower than using 1 instance of Template:Convert (yes, one thousand five hundred times slower! ...because they use 523 parameters). So, there are some much bigger problems to fix, about speed issues, in formatting popular articles. We need a set of {Cite_quick} templates. -Wikid77 (talk) 19:18, 30 July 2011 (UTC)[reply]
Thanks for the input, everyone. Yeah, I think what I was trying to do isn't going to be possible. It's not really necessary, I was just trying to find a way to have one parameter in a template do the work of two. There are other ways to handle it though. rʨanaɢ (talk) 20:11, 30 July 2011 (UTC)[reply]
The worst thing is that Wikimedia is not clear about this. If string manipulation is undesired/bad, we could & would have read that. We are strangled by proxy through techniques. String manipulation is core to stream (PHP!) processing. Now, in earlier days, we were told: "article size doesn't matter (don't worry)". Correctly. (Article size now is limited by readability -- so on editor's side. Good). If server and version and such aspects are relevant, then why not write so? Why does TheDJ here have to write an (incomprehensible) explanation? -DePiep (talk) 20:41, 30 July 2011 (UTC)[reply]
" String manipulation is core to stream (PHP!) processing." exactly. So what that means is: learn to write mediawiki extensions to bring the logic to the backend. If you want a better unit converter/citations/notes/etc etc, people should write a proper MediaWiki extension to do that, instead of endlessly dabbing around with templates. Writing extensions is actually easier than some of the optimizations that Wikid77 has done to most of the complex templates. The hard part is getting everyone to agree on the specific stuff that the new extensions should support and getting it approved for production, but doing more trickery with templates is not the way forward. —TheDJ (talkcontribs) 01:09, 31 July 2011 (UTC)[reply]
Thank you for spending time on this/me: I wasn't that kind. Follow up below is quite interesting. -DePiep (talk) 21:31, 31 July 2011 (UTC)[reply]
  • Documenting the performance concerns: Part of the problem might be trying to "prove" to the readers how the string-manipulation templates, for right-side strings, create such complex operations. We would want a formal performance guideline to have the specific details. Meanwhile, Template:Strr is such a complicated set, of 12 deeply nested templates, that I, honestly, cannot say if {strr} is 1,000x, or 10,000x times slower than {str_left}. It takes some indepth mathematical analysis to prove the processing-speed warnings, to clearly state the results as being "official" to users. For Template:Citation/core, being 32kb (with 523 parameters), and used 100x times in many major articles, it took me several days to collect the impact data. I think "professional articles" (using those {cite xx} templates) contain 95% cite-template markup language. Yes, a popular article which uses those cite templates will contain 19x more cite-markup text than total actual good-article text. Reworking those {cite-xx} templates might reduce the overhead in WP by 75% less, to 25% of the former processing used to reformat popular articles, but such performance concerns might be overshadowed by other elephant-in-the-room concerns, instead. My attempts to "talk about efficiency" have been severely criticized with "WP:Don't worry about performance" so that is another reason few of us "even dare speak" about the processing-speed. Improving the performance takes all of us working together, as efficiency experts, typesetters, editors, developers, and others. -Wikid77 22:54, 30 July 2011 (UTC)[reply]
    • I think we should start worrying about performance when the performance becomes worrying, and that is certainly the case with the cite templates, which form such a large part of the parsing and HTML output for high-quality articles. We should either get a MediaWiki extension to handle this, or optimize the templates. Ucucha 23:08, 30 July 2011 (UTC)[reply]
When I use these kinds of templates, and I am editing large numbers of articles over at Wiktionary, I use subst to avoid permanently transcluding them into articles, greatly reducing loads on servers. Heyzeuss (talk) 03:26, 31 July 2011 (UTC)[reply]
There is a discussion about converting cite templates archived at Wikipedia:Bot_requests/Archive_42#Bot_to_convert_from_citation_templates_to_non-citation_templates. Rd232 talk 21:42, 31 July 2011 (UTC)[reply]
Converting what into what? These are bots, you know. -DePiep (talk) 21:47, 31 July 2011 (UTC)[reply]
Wikid77 is (I met them before here at VP/T) is the smartest editor not yet employed by wikimedia.org/office. Now why is wikimedia.org not present here? We communicate through bugreports? Why do I get the impression that impressive editors like TheDJ knows much more that they write here? As TheDJ writes above (my words): "Just write extension[-code], it is wanted. The only problem is agreement & getting it into production". Yeah. Like peace in Israel/Palestine. -DePiep (talk) 21:57, 31 July 2011 (UTC)[reply]

Problem with Archive.org

Hello, I have a problem with the article Wario World. When I go to the link which is the reference of the game's sales (ref. 28), I go to Archive.org, on an error page ! What to do if I want the correct reference please ? MicroCitron (talk) 13:37, 30 July 2011 (UTC)[reply]

Tag it as dead, that is, add a dated {{dead link}} inside the <ref>...</ref> tag, but outside of the {{cite web}} template, so that the last part of the ref looks like this in the wikicode:
|accessdate=2007-01-11}}{{dead link|date=July 2011}}</ref>
Hopefully, somebody skilled in the art of dead link recovery will spot this and point it at a different archive which still hosts the page. --Redrose64 (talk) 14:28, 30 July 2011 (UTC)[reply]
Thank you, this is done ! MicroCitron (talk) 14:37, 30 July 2011 (UTC)[reply]

Outstanding accessibility fix

Could we get some eyeballs on this long-standing accessibility bug, for which a simple fix has been described? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:57, 31 July 2011 (UTC)[reply]

It looks like this change was applied but then reverted recently. Ucucha 11:16, 31 July 2011 (UTC)[reply]
Thank you, I'd missed that. I've restored the fix, with a link to the discussion in my edit summary. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:35, 31 July 2011 (UTC)[reply]
Interesting to see how you simply keep repeating every controversial thing you propose every 3 months, until you get your way. —TheDJ (talkcontribs) 16:35, 31 July 2011 (UTC)[reply]
Allow me to repeat this: WP:NPA. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:25, 31 July 2011 (UTC)[reply]

HotCats suggestion

Hi all - apologies if this is the wrong place to ask this (it's been a while since I visited VP... this may be a bugZilla thing) With the Search function, if you search for a nonexistent article (say you've mis-spelt what you're looking for), then a message will pop up saying "we don't have an article of that name, do you mean Foo?" Is a similar sort of feature possible with hotcats, so that if you accidentally mis-spell a category name it doesn't automatically save your mistake? Grutness...wha? 11:23, 31 July 2011 (UTC)[reply]

Return key in Edit summary box

Currently if you hit the "return" key while typing an edit summary, the software pretends you have hit the "save page" button. Is there a way to turn this off? This isn't the first time I've saved a duff edit summary while trying to hit the "backspace" key. (Windows, Firefox 4.0.1, Vector skin). -- John of Reading (talk) 13:23, 31 July 2011 (UTC)[reply]

You have mentioned something I consider a small annoyance, mentally filed away as 'don't do that' and had not thought about again until your note. I wonder how many other things of this ilk consume my brainpower? Probably more than 10 and less than 100. Upon reflection, I find that my mental note is "always hit the 'preview' button" rather than a negative 'don't do that'. --Ancheta Wis (talk) 14:08, 31 July 2011 (UTC)[reply]
I believe that it's the default behaviour in a web page form that the "return" key means "finished entering all items". I suppose it may be possible to disable it for this specific entry item on a per-user basis, by writing some CSS that produces special behaviour for class="mw-summary". I wouldn't want to try though; nor would I like it to be disabled for all users. I find it very convenient - type in the edit summary and hit Return. All done. --Redrose64 (talk) 14:55, 31 July 2011 (UTC)[reply]
No, I'm only hoping for some magic I can put in my Vector.js. I'm a cautious editor and like to preview my edit summaries, especially if I'm trying to include wikilinks. -- John of Reading (talk) 15:17, 31 July 2011 (UTC)[reply]
In which case $(".mw-summary").keypress(function(e){ if (e.which == 13) { return false; } } ); should do the trick. I haven't tried it though. - Jarry1250 [Weasel? Discuss.] 16:41, 31 July 2011 (UTC)[reply]
Excellent, that seems to work fine! -- John of Reading (talk) 16:55, 31 July 2011 (UTC)[reply]

PROD where previous AfD was a different subject

I have just PRODded The Hate List. There was a previous AfD on an article with this title, but it was about a different subject - a film, whereas this is about a book. Is there any way to stop the PROD template displaying the warning about the previous AfD? JohnCD (talk) 16:09, 31 July 2011 (UTC)[reply]

Problem avoided, because it turned out the book's title was different ("Hate List" without "The"); but I'd be interested to know if there is an answer. JohnCD (talk) 20:53, 31 July 2011 (UTC)[reply]
{{Proposed deletion/dated}} is coded with #ifexist:Wikipedia:Articles for deletion/{{PAGENAME}} to always display the warning if there is an AfD for the pagename. You could suggest an optional parameter to omit the warning at Template talk:Proposed deletion/dated, but it is probably a rare problem and if there was an option to omit the warning then it might be used inappropriately in some cases. By the way, the AfD was for an alleged upcoming film based on the book (still no sign of the film actually coming). PrimeHunter (talk) 03:16, 1 August 2011 (UTC)[reply]

How to tell if a page is transcluded by another page

Is there any easy way (e.g., a parser function or some such, which could be used for conditional expressions) to tell whether a page is transcluded by another page? What I have in mind is something along the lines of

  • IF this page is transcluded by the page I'm interested in, THEN do nothing
  • ELSE add [[Category:Pages not yet transcluded in that other page]]

I thought AfD had a category like this, but I can't find it right now (and I don't remember if it was populated by a bot or what). rʨanaɢ (talk) 21:46, 31 July 2011 (UTC)[reply]

{{#ifeq: {{PAGENAME}} | <name of the template> | THEN | ELSE}}. Ucucha 00:56, 1 August 2011 (UTC)[reply]
Thanks; that is useful. However, I don't think it will work for what I'm trying to do; sorry I wasn't specific enough in my previous post. The pages I'm thinking about are not templates but subpages of Template talk:Did you know, which are both transcluded on a main page but also used by themselves (hence my comparison to AfD pages); what I'm trying to do is get them to show up in the category if no one has transcluded them onto T:TDYK yet. In your code, the the transcluded version of it (e.g., what you see when you open T:TDYK) will trigger the ELSE (e.g., if the ELSE is to add a category, T:TDYK will be what's added to the category), whereas the non-transcluded version (what you see when you open the subpage directly) will trigger the THEN.
I guess what I need is something that tests whether the main page it's meant to be transcluded on (T:TDYK) includes the text {{Template talk:Did you know/<this page>}}, and if it doesn't, puts [[Category:Pages not yet transcluded in T:TDYK]] onto the subpage. Sounds like it's not likely to be possible, but i figured it wouldn't hurt to ask... rʨanaɢ (talk) 01:11, 1 August 2011 (UTC)[reply]
Sorry for misunderstanding you; I agree that what you're asking for is probably not possible just using templates. I think the best way forward would be to have a bot detect new T:TDYK subpages and put them on T:TDYK automatically. I believe DumbBOT (talk · contribs) does something similar on AFD. Ucucha 01:15, 1 August 2011 (UTC)[reply]
Thanks. It looks like DumbBOT is what I was looking for earlier and couldn't find. rʨanaɢ (talk) 01:33, 1 August 2011 (UTC)[reply]

Linking from "Search" to "Help:Search"

Someone has asked why Special:Search does not have a link to Help:Searching. I guess this is the best noticeboard to make it happen. -- John of Reading (talk) 09:44, 1 August 2011 (UTC)[reply]

Another point is that clicking on "Advanced" on the search page brings up only a set of check boxes for namespaces; it doesn't provide access to all of the available functions (intitle searching and so on). This is misleading, as I suspect readers would assume that "Advanced" is as advanced as it gets (i.e. they'll conclude that no other functionality is available, and won't bother clicking on the help link to discover the extra stuff, even if there is such a link).--Kotniski (talk) 09:53, 1 August 2011 (UTC)[reply]
Those options are nice! I had no idea they existed, must have been asleep when they were introduced. One easy measure would be to change MediaWiki:Searchmenu-new and MediaWiki:Searchmenu-exists: instead of "For search help, please visit Help:Searching" we could have "For search help and an explanation of advanced options, please visit Help:Searching." But I agree that the "advanced" tab should be renamed "free namespace selection" or provide non-namespace based advanced options. —Kusma (t·c) 10:11, 1 August 2011 (UTC)[reply]
This is bug 21988. MER-C 10:39, 1 August 2011 (UTC)[reply]
The currently blank MediaWiki:Search-summary is displayed at the top of Special:Search. I agree that the former version [2] was bloated, but I suggest simply saying Help:Searching, similar to the German Wikipedia: de:MediaWiki:Search-summary (they use a piped link). PrimeHunter (talk) 13:32, 1 August 2011 (UTC)[reply]
That would be an improvement, certainly, but I don't think the previous version was much too bloated - precisely because of the fact that the extra functions are not available under "Advanced" or any other link where they would be expected to be (and since that's a bugzilla matter, we can't expect it to change any time soon), we ought to say explicitly that there are advanced options available, otherwise no-one will know to look for them.--Kotniski (talk) 13:55, 1 August 2011 (UTC)[reply]