Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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.

« Archives, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

Having problems implementing custom CSS

I'm trying to fix the problem of IPA text being rendered in a barely legible font by changing the font to Lucida Sans Unicode. I use the Monobook style. I run Firefox 5.0 on Windows XP SP 2. (Incidentally, this problem only occurs on my desktop computer at home. Strange.)

I first tried adding the appropriate CSS to User:Athelwulf/monobook.css and reloading one article (Quebec French phonology) to see if it worked. Nothing changed, even after purging the server cache and bypassing the browser cache. I double-checked that my CSS was right, and even tested it by trying display: none;, again with no changes even after purging and bypassing. Consulting Help:User style didn't help.

What's that one critical detail that I'm sure I'm missing? — Athelwulf ^[T]/_[C] 22:26, 17 July 2011 (UTC)

Oh, to clarify: The problem of IPA being barely legible (not the problem with implementing custom CSS) only occurs on my computer at home, in case that's an interesting detail to anyone. — Athelwulf ^[T]/_[C] 22:32, 17 July 2011 (UTC)

Most probable cause is that .ipa should be all caps: .IPA. Does it work now? — Edokter (talk) — 19:05, 18 July 2011 (UTC)

Not exactly. It's strange, as the page loads, I see the font correctly rendered, but as soon as the page is finished loading, the font changes back to the almost illegible font. This completely baffles me. Is there a reason it would do this? — Athelwulf ^[T]/_[C] 06:25, 21 July 2011 (UTC)

Glacial Loading Speed

I have spent more than 10 minutes many times today waiting for a page (Watchlist, Ref Desk, this one) to download. Is there a problem bigger than just my ISP and/or computer? Anyone else having problems today? Bielle (talk) 23:55, 17 July 2011 (UTC)

Was it loading slowly on other websites? If so, it had to be your ISP/computer. Drewno (talk) 20:15, 24 July 2011 (UTC)

Enabling download/information bar for images

Hi all, as you may be aware, in Firefox and Chrome, all Commons images include a bar above the image with several links reading "Download, Use this file, Use this file, Email a link, Information". Per discussion at User_talk:Dcoetzee#Image_size, I want to enable this bar for images on the English Wikipedia, including En pages showing images that are actually on Commons such as File:Mona_Lisa,_by_Leonardo_da_Vinci,_from_C2RMF_retouched.jpg. My primary motivation for this is that I upload some very large images, up to 100 MB, and it is not useful for most users to download the full-size image (and for some, prohibitively costly), so I wish to provide Download links for reduced-resolution thumbnails. Some of these images are uploaded locally for copyright reasons, such as File:František Kupka - Katedrála - Google Art Project.jpg. I would also like to figure out what it would take to get this working in Internet Explorer (I'm a coder and can help but have no idea what this feature is called or where it's implemented). Thank you! Dcoetzee 18:38, 18 July 2011 (UTC)

Where is this "download/information bar"? I have looked at several Commons hosted images and cannot see anything like that. --Redrose64 (talk) 20:45, 18 July 2011 (UTC)

It's default for logged out users and opt-in for logged in users. Killiondude (talk) 21:59, 18 July 2011 (UTC)

Opt-in how? --Redrose64 (talk) 22:05, 18 July 2011 (UTC)

I think it's in user preferences, but I honestly can't find the setting. It's also not available in Internet Explorer right now, as I mentioned. Dcoetzee 19:45, 19 July 2011 (UTC)

It doesn't seem to appear when in the Monobook skin (at least for me) - it is replaced by a bar giving links to

File              File history                   File links            Global file usage             Metadata

which might be the reason why you don't see it, Redrose? I wasn't able to find the setting to enable/disable it either. --Kateshortforbob _talk 15:42, 20 July 2011 (UTC)

You are correct: the "File/File history/File links/etc." bar appears to be the equivalent of a TOC for file pages. Curiously, I need to be both viewing the file on commons and using Vector skin for the "Download/Use this file/Use this file/etc." bar to appear instead. Compare these four views of the same file: (i) en.wp, Monobook; (ii) en.wp, Vector; (iii) Commons, Monobook; (iv) Commons, Vector - the "Download/Use this file" thing only appears on the last one. I use Firefox under Windows XP, but these four links should allow comparison from any platform/browser combination. --Redrose64 (talk) 16:33, 20 July 2011 (UTC)

Correct, it is only enabled on the default skin of MediaWiki Commons. Not on english wikipedia, and not on monobook. —TheDJ (talk • contribs) 22:31, 20 July 2011 (UTC)

Have just noticed: when you go to a commons image under Vector skin, the page initially displays with the Monobook-style "File/File history/etc." bar, and inside a second it changes to the "Download/Use this file/etc." bar. I suspect that is related to one of the other things that annoyed me so much about Vector and made me go back to Monobook: clicking "Edit" shows the Monobook-style edit window with toolbar, and a split second later both change their format and position, as per #Turning off the "helpful" editing bar? below. --Redrose64 (talk) 23:00, 20 July 2011 (UTC)

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)

Should a template similar to {{z1}} be added to the warnings, so we can track how many warnings were delivered? --Σ ^talk_contribs 05:46, 19 July 2011 (UTC)

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)

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)

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)

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)

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)

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)

Well, the attempt to be less bitey seems to have failed on this user. Oh well. --Σ ^talk_contribs 01:05, 22 July 2011 (UTC)

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)

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)

•  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)

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. --Σ ^talk_contribs 02:43, 26 July 2011 (UTC)

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)

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)

irrelevant Interwiki links

In the article Swietlan Kraczyna the interwiki links are for the category in which the article falls, not for the actual article itself. How were they generated? How should they be removed? DGG ( talk ) 07:21, 19 July 2011 (UTC)

They have been fixed with this edit. Quite simply, the category pages were transcluded instead of being linked. This is possibly as a result of misunderstanding, see this edit. --Redrose64 (talk) 13:39, 19 July 2011 (UTC)

Advanced InterWiki template

Hi. The Wikibooks has the best InterWiki horizontal template - b:Template:Associated Wikimedia. I look in the Wikipedia there is the Template:Sister project links. Is there more useful template (horizontal or vertical)? Could you please create a new template similar as the b:Template:Associated Wikimedia template? --Averaver (talk) 15:31, 19 July 2011 (UTC)

It's a good template for Wikibooks, but I'm not sure a template like b:Template:Associated Wikimedia would work here: it looks similar to the navboxes that are at the bottom of most articles, and this would just be clutter (versus the smaller sidebar version). EVula // talk // ☯ // 16:05, 19 July 2011 (UTC)

Grammar Mistake on Rate This Page Feature

Moved to Wikipedia talk:Article Feedback Tool

 – Subsection is Wikipedia talk:Article Feedback Tool#Grammar Mistake on Rate This Page Feature Helder 16:20, 20 July 2011 (UTC)

Narrow tabs gadget?

I've already ticked the "Gadget: Appearances" to get "+" instead of "New Section". But with the addition of the Wikilove heart (yes, I know I could choose to suppress it), at my preferred page width the "View History" is hidden on a dropdown menu. Is there an existing Gadget, or could someone write one, to reduce the width of various tabs: I'd prefer "History" or "Hist" for "View History", "Talk" for "Discussion" (I think that used to be the case?). Or lose the "Read" tab which seems redundant (yes, I know it's been discussed elsewhere, but to me it serves no useful purpose). Can anyone help, please? PamD (talk) 10:37, 20 July 2011 (UTC)

I've just found a partial solution by ticking another gadget: "Display the drop-down menus for page actions, such as 'Move', as tabs (Vector skin)". That moves both "Move" and "View History" back into sight, at the cost of losing... "Read", which I don't need anyway. But if there's one more tab introduced (like Wikilove), this solution won't work at this page width unless I can get narrower tabs. PamD (talk) 10:42, 20 July 2011 (UTC)

I'm currently working (99% finished actually) which lets you collapse each tab section seperately. It may not be exactly what you need, but in the future it may contain an option to shorten the tabs. See the MenuTabsToggle script on my user page. — Edokter (talk) — 11:17, 20 July 2011 (UTC)

Might I suggest that you switch back to Monobook? The tabs are smaller, and there's more room for them too, because they don't get squeezed over by the search box (that being in the left margin). --Redrose64 (talk) 11:36, 20 July 2011 (UTC)

In preparation of a gadget (or other solution), here's a script to put in your vector.cssjs:

/* Compact Vector tabs */
$( document ).ready( function() {
  $( 'a', '#ca-addsection' ).text( 'Add' );
  $( 'a', '#ca-history' ).text( 'History' );
  $( 'a', '#ca-viewsource' ).text( 'Source' );
});

— Edokter (talk) — 14:28, 20 July 2011 (UTC)

• Thanks for the various replies.

• Edokter's work-in-progress sounds useful - I await developments.
• Redrose64: helpful suggestion, but I think I'd rather stay with Vector as the default as it makes it easier to explain things to most other WP readers if we're using the same skin. (And I've got used to the search box in its new place, after some time!)
• I tried creating my vector.css with the code here, but it doesn't seem to have had any effect. Maybe I need other stuff in the vector.js too? But thanks for trying to help. Having found my own partial solution I'm OK for now. Thanks. PamD (talk) 18:34, 20 July 2011 (UTC)

• My bad... it should indeed go in vector.js. It should work now. — Edokter (talk) — 19:04, 20 July 2011 (UTC)

• Thanks, that's great. I've even abbreviated "History" further to "Hist". It all makes for a better editing experience than I've been having lately. Thanks. PamD (talk) 22:30, 20 July 2011 (UTC)

See also Wikipedia_talk:Twinkle#friendlytabs.3F if using monobook  Ronhjones  ^(Talk) 22:26, 20 July 2011 (UTC)

Turning off the "helpful" editing bar?

Sorry to sound like a noob, but when I edit a page, at first I just have a large textbox to type in. Then, one second later, a bar appears across the top of the editbox, with stylized B and I and Link icons, etc., and at the same time the text in the textbox changes size. (I'm using Chrome, with Vector skin.) The trouble is, sometimes I've already clicked in the editing textbox and have begun typing, and when the bar appears, my textbox loses focus. I don't ever use it that bar... is there any way to turn it off? (Perhaps in my common.css or something?) Thanks, – Quadell ^(talk) 12:53, 20 July 2011 (UTC)

You can turn off the editing bar in Special:Preferences in the "Editing" tab - uncheck "Show edit toolbar (requires JavaScript)," and then click the "Save" button at the bottom. Logan _Talk ^{Contributions} 12:58, 20 July 2011 (UTC)

Thanks! (It so happens that I had to uncheck the "Enable enhanced editing toolbar" checkbox as well.) That worked. – Quadell ^(talk) 13:31, 20 July 2011 (UTC)

"View history" > "History"

There are a lot of people asking for ways/scripts/gadgets to maximize the real estate used by the Vector tabs. I think a small way to help is to change the "View history" tab to simply read "History"; this is just as clear and would IMO not hurt usability in any way. — Edokter (talk) — 13:59, 20 July 2011 (UTC)

People who 'want to maximize real estate' are 0.2% of the users that do a lot of administrative work. They can use a Gadget to change this very easily. We shouldn't compromise on usability here. 'History' is a rather confusing term for most common reader, the original usability study showed. Reading and Editing are concepts they know, but 'history' is totally unfamiliar to many users as a concept, and people were afraid to 'change history' of the article for instance. 'view' invites people to click, because it is a 'readonly' action. —TheDJ (talk • contribs) 22:26, 20 July 2011 (UTC)

I don't buy that. "Article History" might convey more meaning than "History", but the word "View" adds little if anything to the understanding. I'm with Edokter. -- — Preceding unsigned comment added by Tagishsimon (talk • contribs) 22:30, 20 July 2011 (UTC)

As I said above, I wasn't seeing "View History" displayed at all when using my preferred window width (desktop-proportioned window rather than the full width of my laptop). I think a short visible name is probably much more usable than a long name hidden in a dropdown menu. PamD (talk) 22:37, 20 July 2011 (UTC)

I concur with Tagishsimon. A friend of mine asked me to “go to the view history”. He thought it was a noun: the history of the view. Clearly the term is very confusing. It should read “article history” or “previous versions” or “previous edits” or something similarly unambiguous. — Timwi (talk) 13:21, 21 July 2011 (UTC)

changes view not showing changes

In Google Chrome on Mac OS X Snow Leopard when I view changes (such as here) the unchanged version is still what shows in the page below the changes panes. Is anybody else experiencing this problem? — Fourthords | =Λ= | 18:03, 20 July 2011 (UTC)

Yep. Windoze XP, Firefox. --Redrose64 (talk) 18:42, 20 July 2011 (UTC)

Fixed after purging. — Edokter (talk) — 19:01, 20 July 2011 (UTC)

Hiding empty value template rows

I made a template for another media wiki project, which I have placed here to look at: http://en.wikipedia.org/wiki/User:MattGagnon/template

Basically, all I really need is help with making this template hide the rows that do not have any information provided in them. In other words, if I leave something blank, such as office 2, 3, 4, 5, etc..., I don't want those rows to show up. Currently, when I leave those blank, the information still shows up. I am not a professional at this, and I did find http://en.wikipedia.org/wiki/Wikipedia:Conditional_tables but I think that the jargon and descriptions are JUST a tad over my head for me to get it working myself.

Would really appreciate some help fixing this template. I'm assuming it doesn't take much more than the insertion of a little code here and there. Help? — Preceding unsigned comment added by MattGagnon (talk • contribs) 00:09, 21 July 2011 (UTC)

I suggest you use {{Infobox}}. –droll [chat] 05:05, 21 July 2011 (UTC)

You misunderstand, I'm basically asking for technical help on MAKING an infobox, and as I said this is for another media wiki project... however I have had this same need a number of times when making new templates on Wikipedia, so if anyone can help me, it will be a significant help to me in making infobox templates here, as well as there.

I'm assuming this isn't a difficult solution. I'm willing to do the grunt work of editing my template, if I could at least get some more straight forward instructions on how to create conditional rows. What I found was slightly over my head, as I said. MattGagnon (talk) 13:14, 21 July 2011 (UTC)

You need to test if the parameter (office 2) has a value and only perform the output if it is set using -

{{#if: {{{office 2|}}} | Action if set | Action if not set }}

Keith D (talk) 23:37, 21 July 2011 (UTC)

Please unblock www.vbs.tv or explain why it’s blacklisted

While attempting to create a new article I was blocked from linking to my only source for the information because its domain is blacklisted. The message that informs the user about the blacklisting should also list the reason(s) for the blacklisting. Otherwise it is like saying “No, you can’t add that, because we say so. Go away.” Not very nice. Please remove the domain from the blacklist or explain why it’s on the blacklist and why this link should not be added. Thanks! — Timwi (talk) 13:18, 21 July 2011 (UTC)

See WP:BLACKLIST for general information. The actual blacklist is at MediaWiki:Spam-blacklist and as you can see, it's quite lengthy and has no provision for explanations. --Redrose64 (talk) 13:44, 21 July 2011 (UTC)

That's not entirely true. The notice at the top of the page states all changes must be logged at MediaWiki talk:Spam-blacklist/log. One time I forgot to log a change I had made and someone else was kind enough to log it. I think people try to keep on top of the log. Killiondude (talk) 21:03, 22 July 2011 (UTC)

Blacklisted four years ago after a report at Wikiproject Spam: http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Spam&oldid=170439306#Long_term_Spamming_of_vbs.tv --Carnildo (talk) 23:06, 21 July 2011 (UTC)

"No provision for explanations". Hogwash. b:MediaWiki:Spam-blacklist shows clearly that you can comment next to an entry, with information as to why it was added and when. – Adrignola talk 17:55, 23 July 2011 (UTC)

OK so I was going by the first several pages where none of the websites show anything at all in the way of explns. --Redrose64 (talk) 18:13, 23 July 2011 (UTC)

The blacklisting notice lists some relevant message boards for requesting removals from the blacklist. I've started a discussion at one of them regarding this url. The thread is MediaWiki talk:Spam-blacklist#vbs.tv. --- Barek (talk • contribs) - 21:03, 23 July 2011 (UTC)

Article assessment not updating

I'm pretty sure this is not because of the Job Queue, which does not seem overloaded. Yesterday at 17:24, I reassessed John Karlen to upgrade it from a Stub class to a Start class. It still says Start class on the Talk page. However, the main page is still showing as Stub class. I'm wondering why the upgraded rating does not show on the main page. In the past, it was a job queue issue, but can't be that now. Maile66 (talk) 14:01, 21 July 2011 (UTC)

The stub tag on the article page and the stub ratings on the talk page are independent of eachother. Someone removed the stub tag, though (after your post here). –xeno^talk —Preceding undated comment added 14:33, 21 July 2011 (UTC).

(edit conflict) It's not the job queue, which is behaving at the moment. Article quality assessments in talk page banners are independent of stub templates on the article page. That said, a bot might set a talk-page class to stub because of the presence of a stub templates on the article page, but there is no reverse process.

You need to locate the stub template (it should be between the categories and the inter-language links), and remove it manually, like this. --Redrose64 (talk) 14:33, 21 July 2011 (UTC)

Got it. Thanks. Maile66 (talk) 14:43, 21 July 2011 (UTC)

Google's crawling of secure.wikimedia.org.

Searching the English Wikipedia with google for "foo" <http://www.google.com/#q=site:en.wikipedia.org+foo> gives 15 200 results, but doing the same search on the secure site <http://www.google.com/#q=site:secure.wikimedia.org+foo> gives only 1 hit. I expected the latter to give many more since it would be for all the languages, and that I'd have to include a "inurl:/en/" like: <http://www.google.com/#q=site%3Asecure.wikimedia.org%20inurl%3A%2Fen%2F%20foo>.

Turns out that <https://secure.wikimedia.org/robots.txt> requests no crawling. Anyone know why, and why there is still 1 hit (searching for anything seems to show only 1 hit). -- Jeandré, 2011-07-21t14:22z

Is it to prevent articles coming up twice: once for en.wikip and once for secure.wikim? -- Jeandré, 2011-07-21t14:22z

I for one appreciate that Google is not loading down the secure server. --Ancheta Wis (talk) 14:26, 21 July 2011 (UTC)

The pages visible through the secure server should mirror those seen through the normal servers. I don't see why you would need to search them separately. --Redrose64 (talk) 14:38, 21 July 2011 (UTC)

I only log into secure, but do searches using Google "site:en.wikipedia.org %s" because it's better than WP's own search engine (except for pages like deletion discussions not crawled, for which I have to use WP search). If I then want to edit the page found, I have to copy the page title and go to its secure version. -- Jeandré, 2011-07-21t15:13z, -- Jeandré, 2011-07-21t15:14z

I see no reason we should ask search engines to index duplicate content. The secure server can handle less traffic and we shouldn't let search engines crawl it and direct their searchers there. Google respects https://secure.wikimedia.org/robots.txt and doesn't crawl it. The reason it appears at all in Google results must be that Google is indexing pages on other domains with links to secure.wikimedia.org. This is the situation where you would see "These terms only appear in links pointing to this page" on Google's cache of a page, but Google obviously doesn't cache pages they don't crawl. Another way to see Google didn't index the actual page is adding a search term which has always been on the page. For example, http://www.google.com/#q=site:secure.wikimedia.org+foo+origins gives no result although https://secure.wikimedia.org/wikipedia/en/wiki/Foo_was_here has always contained "Origins". PrimeHunter (talk) 16:32, 21 July 2011 (UTC)

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)

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)

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)

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)

"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)

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)

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'sPonyo^{bons mots} 15:53, 23 July 2011 (UTC)

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)

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)

Note to users without javascript, this feature requires javascript to function. - Hydroxonium (T•C•V) 05:02, 23 July 2011 (UTC)

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)

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)

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)

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. --Σ ^talk_contribs 01:10, 22 July 2011 (UTC)

I've already occasionally seen "new" users vandalizing pages with {{DISPLAYTITLE:I EAT PENIS ~ ~ ~~(----8!!!}}. Reaper Eternal (talk) 13:29, 26 July 2011 (UTC)

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)

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)

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)

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)

My little protest (per rev:49330). --Splarka (rant) 09:04, 23 July 2011 (UTC)

<3 Killiondude (talk) 19:30, 23 July 2011 (UTC)

i want to know what wikipedia is currently using for text search.

i want to know what wikipedia is currently using for text search. I know it is based on mediawiki which has search built in, however ive read as well that wikipedia uses a lucene based search engine for English wikipedia.

Can someone tell me exactly what wikipedia is currently (July 2011) using for search?

thank you for your time. — Preceding unsigned comment added by 131.137.245.206 (talk) 14:02, 22 July 2011 (UTC)

mw:Extension:MWSearch —TheDJ (talk • contribs) 16:48, 22 July 2011 (UTC)

Help:Searching also provides some info on the features available. Killiondude (talk) 20:57, 22 July 2011 (UTC)

Typosquatting

I ran into a typosquatting website [1] (which I would not recommend necessarily going to) which seems to misrepresent itself as being affiliated with Wikipedia while directing them to click on a box which says they have won a prize. The cancel button does not work; you basically end up having to kill the browser. I would not be surprised if it installs malware too. I read the typosquatting article and looked around but could not find any way to let the wikimedia foundation know that yet another mole has popped up to whack. I did read the archived discussion here about similar sites, which didn't sound like anything actually happened then, but as noted here Wikimedia foundation has previously been successful in going after malicious typosquatters, so I would imagine if they knew about it they might actually do something. So how does one report these kinds of things to the right place? Rifter0x0000 (talk) 19:13, 22 July 2011 (UTC)

I would suspect this is something for the legal people at Wikimedia Foundation, but don't know how to notify them. Have you tried asking at WP:AN? They're the next layer up from common or garden editors like you or me. --Redrose64 (talk) 19:42, 22 July 2011 (UTC)

The delete log (2006) for m:Squatted Wikimedia domains says its been moved to an internal wiki. Does anyone have more current information? — Dispenser 19:53, 22 July 2011 (UTC)

You could send an email or talk page note for Philippe or Mdennis, probably. At the very least they'd know who to forward it to. Killiondude (talk) 20:56, 22 July 2011 (UTC)

Infobox and image location question

An editor asked a question at the help desk that no one has been able to answer - effectively how does one place images where they belong; it looks to me like the first image after an infobox is forced to start below the lower edge of the infobox. Can that be fixed? The question is here, the article is Economy of Canada--SPhilbrickT 21:04, 22 July 2011 (UTC)

Answered there. --Redrose64 (talk) 21:44, 22 July 2011 (UTC)

Ratings boxes

Is there a way to make those ghastly ratings boxes not appear? They look awful and are seriously stopping me from contributing at the moment; for the last week or so I've been over at Wiktionary instead. It was alright when they were only on a few pages, but putting them on all new articles is too far. I am using Firefox 5 if it helps. BigDom 21:47, 22 July 2011 (UTC)

• Preferences - Appearances - "Don't show the Article feedback widget on pages" looks as if it's what you want. PamD (talk) 21:53, 22 July 2011 (UTC)

Ah, that was simple! I looked at the preferences but didn't see that there, so thanks. They're still ghastly though. BigDom 22:00, 22 July 2011 (UTC)

FYI: They are not shown in all new articles. See this section of the FAQ which explains the criteria used to determine which pages can be rated. Helder 23:43, 22 July 2011 (UTC)

Fair enough, they just seemed to be on every page I looked at or created so I assumed every article must have them. BigDom 16:20, 23 July 2011 (UTC)

"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)

• 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))

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)

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)

What is the issue? Has a problem been reported? ---— Gadget850 (Ed) ^talk 21:47, 23 July 2011 (UTC)

I personally oppose the VPT suggestion. --Ancheta Wis (talk) 22:23, 23 July 2011 (UTC)

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)

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)

I don't follow. What's being proposed here, exactly?
— V = IR (Talk • Contribs) 22:33, 23 July 2011 (UTC)

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)

(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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 "". --Redrose64 (talk) 12:12, 25 July 2011 (UTC)

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)

BLP-prodded template needed

Could somebody well familiar with templates please create a BLP-prodded counterpart for Template:Prodded? Currently Template:Prodded is actively used by various deletion sorting lists to record both regular and BLP-prodded articles. However, a WP:BLPPROD tag has a 10 days expiration period, whereas a regular WP:PROD tag has a seven day expiration period, so it would be useful to have a separate template for listing BLP-prodded articles in deletion sorting lists. Thanks, Nsk92 (talk) 00:27, 24 July 2011 (UTC)

I started the template for you at {{BLP prodded}}.
— V = IR (Talk • Contribs) 00:39, 24 July 2011 (UTC)

Great, thanks! Nsk92 (talk) 00:42, 24 July 2011 (UTC)

Semi-protection doesn't work?

I've just noticed that there seems to be something wrong with the semi-protection. The Amy Winehouse article is semi-protected, but still some unregistered users are able to do edits. Check the history for 2011-07-23 and 2011-07-24.Thomas Blomberg (talk) 01:11, 24 July 2011 (UTC)

Looks like there was some confusion about setting the protection in place, but it appears to be sorted now. I see no indication that protection isn't working, since the time that it was actually enacted.
— V = IR (Talk • Contribs) 01:55, 24 July 2011 (UTC)

There have been no edits by unregistered users since it was semi-protected 16:39, 23 July 2011 (UTC): [2]. If you see unregistered edits on 2011-07-24 then you must have a different time zone (or you might be confusing redlinked user pages with unregistered users). PrimeHunter (talk) 02:06, 24 July 2011 (UTC)

Preformatted text

I was wondering if anyone could help me get my head around

preformatted text

It does what it's supposed to do, but the HTML tag doesn't normally change the text like that (from my understanding); this is something that occurs on MediaWiki software. Correct? So why does the font change and why is it boxed? Is it possible to modify the way it's displayed in any way? Swarm 04:01, 24 July 2011 (UTC)

Some info on the PRE tag. The font is supposed to change, but the box is indeed added by MediaWiki. You can modify it however you like for yourself by modifying Special:MyPage/skin.css and adding CSS rules for the PRE tag. Gary King (talk · scripts) 05:05, 24 July 2011 (UTC)

I use the {{pre}} template as it wraps text making it more readable. — Preceding unsigned comment added by Gadget850 (talk • contribs) 01:05, 25 July 2011 (UTC)

Firebug tells me that the reason the box is added is the following piece of CSS:

pre {
  background-color: #F9F9F9;
  border: 1px dashed #2F6FAB;
  color: black;
  line-height: 1.1em;
  padding: 1em;
}
pre, code, tt, kbd, samp {
  font-family: monospace,"Courier New";
}

As Gary said, you can modify the appearance of the box by adding to your personal CSS. For example, pre { border: none; } will remove the border. Ucucha 01:53, 25 July 2011 (UTC)

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)

Add

#watchlist-message {display: none}

to Special:MyPage/common.css. Ucucha 12:11, 25 July 2011 (UTC)

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)

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 (talk • contribs) 16:47, 25 July 2011 (UTC)

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)

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)

Agreed...and if they do, tease them.TCO (reviews needed) 17:58, 25 July 2011 (UTC)

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. --Nathan2055^talk 00:53, 26 July 2011 (UTC)

Uh oh. Now all of my scripts have stopped working after the moves! HELP!!!!!!!!!!!!!!! --Nathan2055^talk 02:20, 26 July 2011 (UTC)

 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. --Nathan2055^talk 16:54, 26 July 2011 (UTC)

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)

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)

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 (talk • contribs)

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)

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)

Did you re-add the cite toolbar after blanking the page? If not, then go re-add only it. --Nathan2055^talk 16:57, 26 July 2011 (UTC)

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)

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)

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)

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)

Thanks. Sir Armbrust ^{Talk to me} _Contribs 12:41, 26 July 2011 (UTC)

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)