Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Para (talk | contribs) at 12:33, 28 March 2010 (→‎What's up with the geogrouptemplate?: toolserver software upgrades). 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 the 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.

Inline template wikitext formatting

Please take a look at Wikipedia:Centralized discussion/Citation discussion#Inline template wikitext formatting and comment, when you have a chance to do so. Thank you. 08:54, 20 February 2010 (UTC−5)

Abnormally fast GIFs

Resolved
 – not a problem with Firefox, but rather with all other browsers and some GIF creation programs. A Greasemonkey script has been created to fix affected files. PleaseStand (talk) 20:24, 22 March 2010 (UTC)[reply]

File:Animated Kaleidoscope.gif GIFs like the one left have been animating abnormally fast lately. Is there a reason why? NERDYSCIENCEDUDE (✉ msgchanges) 22:41, 20 March 2010 (UTC)[reply]

Apparently the Earth is spinning faster. Carcharoth (talk) 23:39, 20 March 2010 (UTC) Clearly I meant your computer is 'spinning' faster, not the Earth... (see below) Carcharoth (talk) 01:10, 21 March 2010 (UTC)[reply]
  • I have in the past made animated gifs that chundered along at a suitable speed and found to my horror that they raced on other machines. The reason was that I'd specified a frame rate that was faster than could be rendered at the clock speed of the machine I made them on. So they bumped along at the maximum speed they could be rendered which looked fine. On running them on a faster machine, the true speed that I'd set in the frame rate became evident. Reediting them to reduce the specified frame rate brought the animation speed to the same in all machines that were fast enough. The effect was particularly noticeable on large pixel-dimension images; length of animation didn't slow them much. Relevant? Trev M 00:58, 21 March 2010 (UTC)[reply]

I can't help with the precise technical issue (other than "oh dude, you're blowing my mind, it's actually the screen revolving around the image" :) but to touch on a pet peeve: why don't we have a Stop button for animated gif's? They're like an over-talkative dating partner - really interesting to start with, but eventually intensely annoying. Has some backing software for a kill-switch ever been mooted? Franamax (talk) 01:51, 21 March 2010 (UTC)[reply]

Maybe because many (most?) browsers stop GIF animations if you hit "escape"? --jpgordon::==( o ) 02:17, 21 March 2010 (UTC)[reply]
Eek! The Earth stopped moving. <phew> I hit refresh and things started spinning/bouncing again! :-) Carcharoth (talk) 12:21, 21 March 2010 (UTC)[reply]
Firefox can stop animated GIFs by hitting escape. Also, the Bouncy Wikipedia Logo has also been bouncing abnormally fast. NERDYSCIENCEDUDE (✉ msgchanges) 03:28, 21 March 2010 (UTC)[reply]
Firefox and IE have the esc control for gifs. Chrome doesn't. ManishEarthTalkStalk 07:51, 21 March 2010 (UTC)[reply]
Pressing Alt in Chrome pauses them for me. But only until you scroll or do something on the page. Not sure if this is an intentional feature by Google. - Kingpin13 (talk) 14:07, 21 March 2010 (UTC)[reply]
Ooh thanks! ManishEarthTalkStalk 14:57, 21 March 2010 (UTC)[reply]
Seems like alt pauses everything, including mouseovers, hovers, tooltips, and flash. Really useful! Thanks again! ManishEarthTalkStalk 15:01, 21 March 2010 (UTC)[reply]
They already have a key-sequence? Nice. :) I suppose I'm just prejudiced against animated GIF's, seeing as how one animation on Red blood cell would take a dial-up user around 7 minutes to load. Franamax (talk) 03:49, 21 March 2010 (UTC)[reply]
Huh, now that I'm editing on an iPhone, the GIFs animate normally. Maybe it's my computer. NERDYSCIENCEDUDE (✉ msgchanges) 03:59, 21 March 2010 (UTC)[reply]

In SVG animations, such as [1], timing issues are easier to correct. Unfortunately I can′t display it here as a non-moving PNG conversion would appear in place of it, but if I wanted to slow it down, I′d need only change the dur="3s" attribute to a higher number using a text-editor.

One also could manipulate it with javascript. Pasting something like this in the address bar while viewing the SVG directly will slow it by 5×:

javascript:for(i = 0; i < (a = document.getElementsByTagName("*")).length; i++) a[i].setAttribute("dur", "15s");

However, javascript cannot access the frames of a GIF or otherwise its animation. Sites which appear able to do this are in most cases changing the src attribute of the <img> tag (causing the browser to load pixels from a different file), or otherwise aren′t using GIFs at all. ―AoV² 04:34, 21 March 2010 (UTC)[reply]

Viewing the above Bouncy Wikipedia Logo on this page in Chrome 4.1.249.1036, Firefox 3.6, and IE 7.0.5730.13 show that Chrome and IE7 are both 2.6 sec per bounce, but Firefox 3.6 is 1.1 sec per bounce. More than twice the speed. --Redrose64 (talk) 14:01, 21 March 2010 (UTC)[reply]
I think it's Firefox that's causing the problem. The animations view correctly in Safari. NERDYSCIENCEDUDE (✉ msgchanges) 14:25, 21 March 2010 (UTC)[reply]
I also think it's Firefox, so I reported it to Mozilla as bug 553968. PleaseStand (talk) 03:26, 22 March 2010 (UTC)[reply]
At least I got a quick response since it turns out that the problem had already been reported (six years ago). (And I thought that I had discovered yet another Firefox 3.6 bug.) Firefox is actually behaving correctly, while others are not and treat delays less than 5 cs as 10 cs delays. So the Firefox developers are basically saying that for compatibility, websites should not use animated GIFs that have delays less than 5 cs (greater than 20 frames/s). I wrote a Greasemonkey script which you should be able to use to make any other files that are too fast the same speed in all browsers. Use the script, right-click the image and do Save Image As, and upload the new version to Wikipedia if appropriate. I just updated the two images shown above and these should now run at the same speed for everyone who sees them. PleaseStand (talk) 20:24, 22 March 2010 (UTC)[reply]
On a side note, I much prefer the Bouncy bouncing along at 1.1 seconds per bounce. --Izno (talk) 03:50, 22 March 2010 (UTC)[reply]
Note also that someone uploaded a faster version in January (but not sure what time scale was being referenced). --Splarka (rant) 08:29, 22 March 2010 (UTC)[reply]
Yes, I also noticed that, but nevertheless, the animation should run at the same speed in all browsers. Remember that the bouncy logo is included in the widely used welcome template {{w-screen}}. I find the faster bounce to be annoying and distracting. PleaseStand (talk) 10:53, 22 March 2010 (UTC)[reply]
I notice that the rate is now 1.9 sec/bounce in Firefox, while remaining at 2.6 sec/bounce in Chrome and IE7. I've recently upgraded from Firefox 3.6 to 3.6.2; maybe these are related? --Redrose64 (talk) 10:08, 26 March 2010 (UTC)[reply]

Make it easier to submit edit requests

Currently, MediaWiki:Protectedpagetext (shown when users try to edit a page they don't have rights to) provides instruction on how to make an edit request for a (semi)protected page. Why not make it a bit easier and just give visitors a prominent button to push? We can use an InputBox to preload the necessary {{editsemiprotected}} / {{editprotected}} text, and provide an explanatory editintro too. The example below, using preload/editintro borrowed from the Article Wizard, shows how.


Good idea? It might encourage frivolous requests, but we'd only know the signal/noise ratio by trying.

On a related note, I think it would be a lot friendlier if (a) the Edit button didn't become View Source when an editor doesn't have permission to edit - it's a missed opportunity to encourage people to find out more about editing and especially how signing up can have benefits and enable editing of semiprotected pages. (b) I don't really see that the average unregistered users actually wants to see the source wikitext; this is probably just confusing. Ditch it and use the space for a bigger, friendlier explanation of protection. Provide a link to the source for those few who really want it. Rd232 talk 21:25, 21 March 2010 (UTC)[reply]

Template:CB-support2 I personally think this is brilliant! Thumbs up! Although, oppose the second idea about the view source button, which I have found useful many times. --JokerXtreme (talk) 21:44, 21 March 2010 (UTC)[reply]
Strong oppose the removal of the "view source" tab. Two reasons:
  • Sometimes, when explaining things to IP users, I have purposefully directed them to a given template, and suggested that they "view source", in order to see how something is done
  • I often use "view source" on protected templates to see what the actual parameters are, and what happens when certain combinations are used. The editors who maintain templates often forget to keep the documentation in synch. As a non-admin, if this were implemented, I would lose the ability to check why my template transclusions don't work as per the documentation.
--Redrose64 (talk) 22:37, 21 March 2010 (UTC)[reply]
If I understand it correctly, what he proposes isn't that you won't be able to look at the source code, just that it would require one more click. Svick (talk) 23:05, 21 March 2010 (UTC)[reply]
Correct. I'm not suggesting removing the ability to see the source, I'm suggesting hiding the source, because for most people it's a confusing distraction at their first point of entry. It could be collapsed on the same page (hidden by default), or there could be a link to the source on a separate page. Rd232 talk 23:07, 21 March 2010 (UTC)[reply]
Also, the argument applies mainly for articles. For protected templates, people who come along probably do actually want to see the source. Rd232 talk 23:18, 21 March 2010 (UTC)[reply]
Oppose part about hiding “View source”. I find it very useful, especially for protected templates. Also, the editnotice on semi-protected articles already explains that creating an account helps. Svick (talk) 23:05, 21 March 2010 (UTC)[reply]

Comment - Well I think it would be useful if it was easy to propose, for instance, a minor change on a protected article, without going through all the fuzz of creating a section on the talk page. --JokerXtreme (talk) 23:15, 21 March 2010 (UTC)[reply]

  • Support adding an input box below the current text of MediaWiki:Protectedpagetext. Although users wishing to edit probably don't often get there in the first place, this surely happens from time to time and we should make it easier for them to request edits. Note that {{TALKPAGENAME}} should be used to make it work in general. Neutral on the rest; I agree with the general idea to make it easier to request edits on protected pages, maybe we should change the text which appears when pointing on view source from "you can view its source" to "you can view its source and request edits", though I think we'd need to ask devs for this. Cenarium (talk) 00:27, 22 March 2010 (UTC)[reply]
    Noting that the editprotected/editsemiprotected template should be contained in the preload. Cenarium (talk) 01:16, 22 March 2010 (UTC)[reply]
  • Template:CB-support2 adding the inputbox. It will help new editors unfamiliar with our policies to submit requests. ManishEarthTalkStalk (continued below)
  • Template:CB-oppose1 "view source" suggestion. "View source" is a useful button, and anyways, an explanation is given on the view source page. ManishEarthTalkStalk 02:32, 22 March 2010 (UTC)[reply]
    • I'm not talking about getting rid of the button, I'm suggesting making the button always say "Edit this page", to make it more inviting for people to click on and get an explanation that yes, they really can edit (but not this page right now). In addition, I'd try and make the explanation friendlier and more welcoming, and part of that might be not showing scary source text which you can't even edit: that seem offputting to me. In principle, there could be another Inputbox which uses the current article text to feed a sandbox, so that people can test editing (with a sufficiently clear explanation, this might work). Rd232 talk 08:06, 22 March 2010 (UTC)[reply]
      • I knew that it wasn't removing the button. Anyways, we have a nice header explaining why it can't be edited. ManishEarthTalkStalk 10:14, 22 March 2010 (UTC)[reply]
        • The MediaWiki:Protectedpagetext message isn't particularly nice for newbies (I might draft a redesign if I have time); and semi-protected pages often only have the small lock icon, so there's no nice message on the page itself. And "View Source" is not exactly reinforcing the "Anyone Can Edit" message. Rd232 talk 10:19, 22 March 2010 (UTC)[reply]
            • We already have a tooltip on it which is quite helpful and it pops up immediately ManishEarthTalkStalk 09:23, 23 March 2010 (UTC)[reply]
              • Yes, it pops up when you put the mouse over the button (also the tooltip just says "you can view the source" ...). What proportion of people do that? Why would they? The issue is sending a message that's right there. We do this as a matter of course with unprotected pages - I don't see we avoid doing this with protected pages. Rd232 talk 11:22, 23 March 2010 (UTC)[reply]
          • See also #Proposed implementation design by Rd232
  • Endorse the inputbox for submit an edit request - great idea. Far too often IPs suggest edits without using the editprotected template, and are thus disenfranchised. –xenotalk 17:54, 22 March 2010 (UTC)[reply]
  • Support, this could also work where an article is fully protected too. Mjroots (talk) 19:20, 22 March 2010 (UTC)[reply]
  • Support, a great idea. Can't imagine any drawbacks to implementing the make-a-request idea, whether for semiprotected pages or for fully protected pages. I have no opinion on the question of hiding the source-text link. Nyttend (talk) 23:35, 22 March 2010 (UTC)[reply]
  • Support, love the idea as well. Lets stick to the editform first, we can deal with the issue of the "view source" tab in a separate discussion. —TheDJ (talkcontribs) 23:56, 22 March 2010 (UTC)[reply]
  • Template:CB-support2 And I make a mental note to give a hand on the design as soon as I have some spare time. Also, the source code should be in a collapsible box. It has to stay efficient and easy to use for us power users. But beginners should notice it only when they need it. It's a good compromise. Dodoïste (talk) 01:49, 23 March 2010 (UTC)[reply]
    • That's a good idea. Can it be done without changing the software? Rd232 talk 11:22, 23 March 2010 (UTC)[reply]
  • Ditto what Nyttend said. Seraphim 02:15, 23 March 2010 (UTC)[reply]
  • Neutral - I might be interested in seeing how a temporary test implementation goes, because I'm worried that making it this easy will cause lots of trivial requests. Currently only people who are seriously concerned will go through the trouble of reading the instructions and making a request, and I think for protected pages only significant concerns should really warrant the attention and effort of an admin. So the commitment required to make a request, so to speak, was always sort of a built-in check against trivial requests. But with this button, anyone who wants to make any edit might use the button since it's so easy. So I'm not sure if this would turn out to be a good thing. Equazcion (talk) 22:33, 23 Mar 2010 (UTC)

Proposed implementation design by Rd232

Please don't vote here on the idea in general, this is about collaborating on a specific design

OK, so User:Rd232/protectedpagetext has a draft redesign, and includes a working preload/editintro for editsemiprotected. Rd232 talk 17:27, 22 March 2010 (UTC)[reply]

Looks nice, but what about fully protected pages? --JokerXtreme (talk) 17:32, 22 March 2010 (UTC)[reply]
That's not a problem. The same principles apply, I suggest we design them 1 at a time. —TheDJ (talkcontribs) 00:11, 23 March 2010 (UTC)[reply]
Probably a good idea, but I've already drafted that too, at User:Rd232/protectedpagetext/sub1. Rd232 talk 01:03, 23 March 2010 (UTC)[reply]
  • The thing is a tad tall this way. I suggest a similar layout as the Help desk. Just 2 columns with text, and then a new row with a request button. 80% of the people don't read that other text anyways. —TheDJ (talkcontribs) 00:11, 23 March 2010 (UTC)[reply]
    I don't quite get that. Can you draft it? Rd232 talk 01:03, 23 March 2010 (UTC)[reply]

I've improved the design a bit, not least using the trick from {{Feedback page}} where the inputbox parameters are plugged into a fullurl link, thus avoiding the format-scrambling inputbox. Rd232 talk 12:07, 23 March 2010 (UTC)[reply]

The format is much better, but it still would be nice to have a button. The edit proposal option now gets kinda lost in there. --JokerXtreme (talk) 12:50, 23 March 2010 (UTC)[reply]
How about an arrow icon (User:Rd232/protectedpagetext/sub1)? Or change things around more dramatically. Rd232 talk 13:47, 23 March 2010 (UTC)[reply]
Hm, I don't think an arrow there makes much sense. How about "you can submit an edit request by clicking the button on the bottom" or something? So that the more experienced users can find the button right away. --JokerXtreme (talk) 14:04, 23 March 2010 (UTC)[reply]
Why doesn't an arrow make sense there? It highlights the key action link. Your suggestion I think could be confusing. More showing and less telling would be helpful in this discussion - let's see what we're talking about; just edit my draft or create your own. Rd232 talk 14:15, 23 March 2010 (UTC)[reply]
Something like that:User:Rd232/protectedpagetext/sub2. The text may need rewriting though, but the layout should look something like this (I think). --JokerXtreme (talk) 14:51, 23 March 2010 (UTC)[reply]
I guess that's OK, but it slightly upsets the priority (unprotection should come last, I think). But it it's an improvement on the status quo either way, and it can always be revised later. What do people think? Rd232 talk 17:33, 23 March 2010 (UTC)[reply]
I like JokerXtreme's suggestion. —TheDJ (talkcontribs) 19:04, 23 March 2010 (UTC)[reply]
Agree, that one is probably my favorite out of both proposals. I have a feeling the button will "click" better with new users who are trying to figure out how to edit the page. I really don't think it upsets the priority either, because it's separate from everything else - i.e., it's not a bullet point. That's how I see it. — The Earwig (talk) 20:10, 23 March 2010 (UTC)[reply]
Fair enough. Let's give it a bit little longer for comments (24hrs?), and then somebody implement it please. Rd232 talk 22:16, 23 March 2010 (UTC)[reply]
I like it too. :) It's much better than the current one imo, well done people. Ale_Jrbtalk 22:25, 23 March 2010 (UTC)[reply]
Rd, what do you mean implement it? I thought it was already finished. It just needs the code from your "edit request" link. The templates probably need to change too. --JokerXtreme (talk) 22:51, 23 March 2010 (UTC)[reply]
I assume he means putting it here, so it actually shows up. :) Ale_Jrbtalk 23:00, 23 March 2010 (UTC)[reply]
Aaah, I see! Well, Rd, I guess you must have the honor :) Are those ok btw? {{editsemiprotected}}, {{editprotected}} Or do they need any change? --JokerXtreme (talk) 23:08, 23 March 2010 (UTC)[reply]
OK, I'll do it then, probably tomorrow morning (probably better anyway that I do it since I split the code across pages to make editing easier, and it needs reintegrating). I don't see that those templates need any changes. Rd232 talk 09:07, 24 March 2010 (UTC)[reply]

checkY Done And implemented - now live. Rd232 talk 11:34, 25 March 2010 (UTC)[reply]

and I see that it's already attracting improper requests --Redrose64 (talk) 00:12, 26 March 2010 (UTC)[reply]
It is too early to say, but I think the proper requests outweigh the improper. --JokerXtreme (talk) 08:20, 26 March 2010 (UTC)[reply]
Define "improper". It appears to be a good faith request relating to John_George_Adair#Adair.E2.80.99s_death, but in the wrong place (death template). Rd232 talk 09:41, 26 March 2010 (UTC)[reply]

Can something be done to encourage editors to use a more descriptive section heading rather than the generic "edit request"? — Martin (MSGJ · talk) 10:17, 26 March 2010 (UTC)[reply]

I guess that could be useful. Maybe it should be added in the tmbox here: [2]. I couldn't find the template for it. But, I think the heading should start with "Edit request -". --JokerXtreme (talk) 10:58, 26 March 2010 (UTC)[reply]
And it should be possible to add the date to the default heading so that if people don't type in their own heading, as least you don't get several identical headings on a page which stops the table of contents working. — Martin (MSGJ · talk) 12:48, 26 March 2010 (UTC)[reply]
The editintro templates are Template:Editsemiprotected/editintro and Template:Editprotected/editintro. — Martin (MSGJ · talk) 12:50, 26 March 2010 (UTC)[reply]
Sounds good. Headings in an "Edit request - (time, date) - " preform, that users will fill in. OK, we need to add a third advice and probably place it first. Something like "Please use a descriptive headline. Fill in further details about the subject of the edit request.". Just throwing this on the table. --JokerXtreme (talk) 13:36, 26 March 2010 (UTC)[reply]
The wording needs to be more clear and easily seen. Already there has been a double or triple in requests, most of them not correct. Emphasis needs to be made on presenting a reliable source to back the change up, as well as a "change X to Y"-format, which may not be clear enough for some people.  fetchcomms 00:21, 27 March 2010 (UTC)[reply]
Indeed. As probably the person who has actioned most semi's in the past few days (as I often do), I've seen about a five-fold increase in the number, but most of them have been crap. Blank requests, garbled junk, vandalism. A few have been partly comprehensible, but of them, most gave no source, and/or didn't make a specific request. I am all for the idea of making the requests easier, but please, could someone make the request thingy clearer - emphasize the need to say exactly what needs to change, and to give reliable sources. Preferably in 6-foot high flashing comic-sans. Ty.  Chzz  ►  08:04, 27 March 2010 (UTC)[reply]
What about increases in good requests? Rd232 talk 09:51, 27 March 2010 (UTC)[reply]
NB requests like this one may not be exactly what we want, but they are an opportunity to engage new users who might otherwise not understand and walk away. It's a chance to explain. Rd232 talk 09:58, 27 March 2010 (UTC)[reply]
Yes, we've had a few of those as well :) But mainly I seem to be telling people to discuss their proposals on the talk page first, which is especially important on fully protected pages. — Martin (MSGJ · talk) 09:56, 27 March 2010 (UTC)[reply]

Well, this was my concern about making the Request button too visible in MediaWiki:Protectedpagetext - it makes it more likely people will just jump to clicking the button to see what it does. I had the Request link more within the text (User:Rd232/protectedpagetext/sub) so people would actually have to read it to find that option. Also, it occurs to me that we should probably remove the button anyway on the main page, replacing it with a pointer to the tutorial perhaps. Rd232 talk 09:51, 27 March 2010 (UTC)[reply]

I think that will rather discourage edit requesting in general. No one will bother to read, I know I wouldn't. I think my proposal below addresses the concerns raised.--JokerXtreme (talk) 10:52, 27 March 2010 (UTC)[reply]

Editintro

I changed the template a little bit. I changed the icon and the instructions. Template:Editsemiprotected/editintroTEST. We could also bold the "follow instructions" here: MediaWiki:Protectedpagetext--JokerXtreme (talk) 09:07, 27 March 2010 (UTC)[reply]

Better, for sure. As I said, I'm all in favour of encouraging editing, and in making it easier. Hopefully they will read that notice; I have a feeling that lack of sources will be the biggest problem - but that's OK; only takes a minute to respond to it explaining why we need sources. We shall see.
I'd like to make a request of my own here: it would be great if the people supporting this could keep an eye on the requests (Category:Wikipedia_semi-protected_edit_requests; bot updates can be transcluded from {{User:VeblenBot/SPERtable}}) and help to action them.  Chzz  ►  15:06, 27 March 2010 (UTC)[reply]
Out of interest, I had a bit of a look. To my knowledge, we've had 44 requests since 25th; 9 of which have been successful. Notes in user:chzz/sper.  Chzz  ►  18:17, 27 March 2010 (UTC)[reply]
I see most of the rejected requests were not referenced. And to tell the truth, no one was asked to provide references in the instructions. Am I wrong? Additionally, some of the requests I declined, did not check for consensus first. We should address that too. --JokerXtreme (talk) 18:21, 27 March 2010 (UTC)[reply]
Personally, I think the consensus thing is a decision that the person dealing with it can make - and the request can be the start of a discussion; I don't see a problem with that. The main thing to drill in is the need for references - as always. Same as at WP:AFC, where I spend hours each day telling people what an RS is, what V really means, and that blogs and press-releases ain't enough for N. References, that's the key. To be honest we're bound to get some rubbish requests, no matter what; if we can somehow make it ultra-clear that refs are needed, that's the best chance we have to increase the good/bad ratio.  Chzz  ►  22:09, 27 March 2010 (UTC)[reply]
Should I publish my editintro draft for a start and see how that goes? --JokerXtreme (talk) 22:23, 27 March 2010 (UTC)[reply]
Sure, why not? I would suggest something in-between the current one and Template:Editsemiprotected/editintroTEST - I don't like the harsh red sign on the latter, I prefer the more friendly informational, but I'd like to see something like, perhaps, the "Please provide reliable sources when possible" highlighted?
Another idea is, how about 2 input boxes - one for their suggestion, and another for the reference?  Chzz  ►  22:39, 27 March 2010 (UTC)[reply]
How about the new version? Template:Editsemiprotected/editintroTEST. Maybe we should just add that sources are necessary in the request form, like here:

--JokerXtreme (talk) 23:38, 27 March 2010 (UTC)[reply]

I've adopted Joker's changes and adapted and expanded on them - see Template:Editsemiprotected/editintro. I've also customised MediaWiki:Protectedpagetext for the Main Page, since an edit request button there doesn't seem useful (check it out by clicking View Source when not logged in). Rd232 talk 01:39, 28 March 2010 (UTC)[reply]

Looks good, let's see how that goes. But, how about having "Edit request - {{currentuser}}" as the default heading? This would fix the problem with multiple ERs messing up the table of contents. --JokerXtreme (talk) 07:45, 28 March 2010 (UTC)[reply]

How can I have the alt text changed on the wiki logo on the top left? Gnevin (talk) 23:16, 21 March 2010 (UTC)[reply]

You mean to change the logo? Or to change the alt text for the logo(the "Visit the main page")?Smallman12q (talk) 23:25, 21 March 2010 (UTC)[reply]
Change the alt text to "Main page" or something similar Gnevin (talk) 23:28, 21 March 2010 (UTC)[reply]
I think only developers can modify those texts (as in the section just above, about view source). A search in Special:AllMessages didn't return anything. Cenarium (talk) 01:19, 22 March 2010 (UTC)[reply]
Actually, it is in MediaWiki:Tooltip-n-mainpage or MediaWiki:Tooltip-n-mainpage-description. Ucucha 02:16, 22 March 2010 (UTC)[reply]
I think he wants an alt text, not a title (tooltip) text for those who have disabled images. ManishEarthTalkStalk 02:52, 22 March 2010 (UTC)[reply]
And no, it isn't. Its at MessagesEn.php (search 'tooltip-p-logo'), changed in rev 55515. ManishEarthTalkStalk 02:57, 22 March 2010 (UTC)[reply]

(edit conflict)Well, the logos not exactly something which you can add an alt to. The image is the background of an a element, which cannot have an alt attribute (You can easily see that the image is not directly shown by right-clicking the logo. The menu which will appear will not have options like "Save image", "Copy Image address", etc). The logo does have a title (tooltip) attribute, though, which can be changed through js. Here's how the HTML of the logo looks:

<div id="p-logo">
<a style="background-image: url(http://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png);" href="/wiki/Main_Page" title="Visit the main page">
</a>
</div>


If you want to change the tooltip text, add this bit of js to Mediawiki:Common.js (you need an admin to do this):

addOnloadHook(function(){
document.getElementById()
document.getElementById('p-logo').childNodes[0].title="TOOLTIP TEXT HERE"

})
<BR/>

On a side (but related) note, the MW devs really should make the logo into an <img> in an <a> with alt text instead of an <a> with a background:

<div id="p-logo">
<a href="/wiki/Main_Page" title="Visit the main page" style="text-align:center">
<img src="http://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png" alt="Some alt text here..."/>
</a>
</div>
<!--Yes, the image gets a teeny bit misaligned, but it's too small to notice unless the code is changed dynamically 
(On my comp, the image jumps a pixel or two to the left and three pixels up)-->


I've always wondered why the logo and the person in the personal portlet are backgrounds and not imgs with alts (I noticed this when I was trying to fix an error in the logo and was trying to find the commons page. The error has been fixed in some of the other wikilogos at commons, but this logo). Hope the devs can answer why they have to use a roundabout method which doesn't allow alt text... ManishEarthTalkStalk 02:52, 22 March 2010 (UTC)[reply]

Using CCS background-image property allows people to use a different image in place of the official Wikipedia logo. I don't believe there's any way to change an img's src using CSS, so this is how they make it happen. Reach Out to the Truth 17:44, 22 March 2010 (UTC)[reply]
By 'people', you probably mean account holders, who can change src through js anyways. Anyways why would someone want to change the logo src for themselves? ManishEarthTalkStalk 03:10, 23 March 2010 (UTC)[reply]
Changing it through CSS would be easier than JavaScript. As for why people would do that, people are crazy. :P Maybe they don't like the logo, or would like to replace it with a free image. Who knows? Reach Out to the Truth 02:02, 28 March 2010 (UTC)[reply]

As noted, the logo cannot have alt text because it's a CSS background-image, not an <img>. I don't know why Gabriel Wicke chose to use a CSS background instead of an image here. It could be changed, I guess, but there doesn't seem to be any strong reason one way or another. If I had to give it alt text, I'd give it empty alt text anyway, because you already have "From Wikipedia, the free encyclopedia" on every page, and there's no point in asking screen readers to read it twice.

If it were an image, you could still change it in pure CSS by simply hiding the image and creating a new one with background-image. So that's not a good reason.

If you want to change the tooltip (not alt text), currently "Visit the main page", you don't need to use JS. The correct message to alter is MediaWiki:Tooltip-p-logo. —Aryeh Gregor (talk • contribs) 18:22, 22 March 2010 (UTC)[reply]

Like I said above, no it isn't (visit the page, its deleted). Its at MessagesEn.php (pagesearch 'tooltip-p-logo'), changed in rev 55515. This means that you need to be a sysadmin to change this inconsequential stuff. Easier with js. ManishEarthTalkStalk 03:10, 23 March 2010 (UTC)[reply]
That file contains the default messages. They can be customized on a per-site basis by editing pages in the MediaWiki namespace. Deleting a page from the MediaWiki namespace causes MediaWiki to use the default messages defined by the software and its extensions. MediaWiki:tooltip-p-logo was deleted, so it uses the default set in MessagesEn.php. That's how it works. Look at the text under the log snippet. That's the default message from MessagesEn.php. Reach Out to the Truth 03:33, 23 March 2010 (UTC)[reply]
To clarify, creating MediaWiki:Tooltip-p-logo will override the default settings in MessagesEn.php OrangeDog (τε) 13:13, 23 March 2010 (UTC)[reply]
Reach Out to the Truth and OrangeDog are correct. Creating the page will change the message's contents as actually used on the wiki. JS would be much more complicated. —Aryeh Gregor (talk • contribs) 18:03, 23 March 2010 (UTC)[reply]

Help using CSS?

I'm trying to perfect my Monobook CSS skin, and I'm having some difficulty. The skin is located here, and I'm trying to figure out how to get things like templates, tooltips, etc. to keep their default background color. Right now, all the backgrounds are transparent, causing problems with tooltips and templates with colored backgrounds. Could someone who is good at CSS take a look at it? Hmmwhatsthisdo (talk) 23:54, 22 March 2010 (UTC)[reply]

Actually, as of now, I have a set background on all of them, but I don't know if something like "#default" exists. Hmmwhatsthisdo (talk) 00:35, 23 March 2010 (UTC)[reply]

You just need to make *{background-color: transparent !important; color: lightgrey !important;} much more specific / less broad. ¦ Reisio (talk) 05:43, 23 March 2010 (UTC)[reply]

Well, I figured out how to have them not blend with each other by using td {background-color: #313131 !important;}

, but this messes up the main page. Any ideas? Hmmwhatsthisdo (talk) 23:05, 23 March 2010 (UTC)[reply]

I'd suggest making background color transparent on a more specific basis rather than making it the default. I'd say that that's how to do it properly. Gary King (talk) 03:09, 27 March 2010 (UTC)[reply]

More CSS help needed...

So, I'm making a skin for Vector in addition to the one for Monobook, and I'm trying to change the image links for the tabs, etc. My code so far (or the relevant part) is here, and I'm trying to change the following things ATM:

1. The Tab border color.
2. The Logo.

However, only the leftmost tab border is changed using the theme, and the logo-changing bit only works if it's used in Stylish. It work in Monobook, It works in Stylish, but not in the Vector css. I'm practically going insane trying to figure out what's wrong with the thing. Any help would be greatly appreciated. Hmmwhatsthisdo (talk) 00:10, 24 March 2010 (UTC)[reply]

There are a couple of problems in your css.
  1. The .vectorTabs line is missing a closing }
  2. It appears the background image is actually attached to .vectorTabs li a not to the parent div vectorTabs
  3. For the logo it looks like you meant to be using the shorthand background: declaration, but instead have used background-image:
Dr pda (talk) 03:20, 24 March 2010 (UTC)[reply]
I posted the fix here. DON'T reply there, just copy the code and tag it with {{U1}} to delete the talk page. ManishEarthTalkStalk 03:44, 24 March 2010 (UTC)[reply]
Oh. OK. May I ask how you found this? I have probably less CSS knowledge than a small green fish, and I have no bloody clue what I'm doing. Essentially, I'm trying to modify the Vector skin to make it a red hue, as opposed to blue. However, the coding part is a lot more difficult than I thought. So far, I've tried just copying the lines of code containing the image paths I'm looking for, and just replacing the image names. I'm here now, so we can all guess how that turned out! So, would either of you be willing to give me some help understanding this? Hmmwhatsthisdo (talk) 06:00, 24 March 2010 (UTC)[reply]
I made the changes according to Dr pda. Explanantion of the points:
  1. Syntax error
  2. The class .vectorTabs applies to sets of tabs. For example, The "Article" and "discussion" tabs are in one div with class .vectorTabs. Giving it a border would have worked, except that it would not have overridden the border of the individual tabs, as they cover the div. So only a part of the colored div was showing. The rest was masked by the tab li's. So, instead of applying the code to .vectorTabs, it should be applied to the li inside .vectorTabs (CSS code: .vectorTabs li {.....})
  3. You were applying the percentage parameters to background-image, which takes only one parameter. You must have meant background:
Why not use Chrome? It has some developer tools (ctrl-shift-i) which give you the CSS properties and allows you to do js stuff, too. Hope this helps! ManishEarthTalkStalk 07:36, 24 March 2010 (UTC)[reply]
So does FF, and Opera. (other browsers are available) OrangeDog (τε) 13:26, 24 March 2010 (UTC)[reply]
FF requires FireBug... But yes, others are availible. I like chrome best for dev'ing, though. For a multitude of reasons. ManishEarthTalkStalk 13:46, 24 March 2010 (UTC)[reply]
I got Firebug, but it's still all Greek to me. I'm trying to figure out which class the 'borders' of the tabs are. I tried #p-namespaces h5, p-namespaces ul, .vectorTabs ul, & .vectorTabs h5. None of them seem to work. Could somebody perhaps, explain where my thinking is going wrong here?
EDIT: Massive breakthrough. I've been using Firebug, and have gotten almost everything done, with the exception of the border, text color, and tab dividers. It turns out that maintaining proper order is imperative to the script working. Hmmwhatsthisdo (talk) 01:34, 25 March 2010 (UTC)[reply]
Another Edit: I have gotten all of the images replaced, spare the tab separators. It turns out that they should be modified with div.vectorTabs li a, but when I change them, the tabs seem to sink down into the page. If needed, I can post a screenshot. Hmmwhatsthisdo (talk) 02:45, 25 March 2010 (UTC)[reply]
Side note: I really like the visual efect of the CSS. Let me know when you're done! ManishEarthTalkStalk 03:40, 25 March 2010 (UTC)[reply]
Well, I'm almost done. I still need to tweak the edit box and fix those darned tab breaks. Here's the (non-working) vector.css with div.vectorTabs li a, and div.vectorMenu h5 a. —Preceding undated comment added 04:07, 25 March 2010 (UTC).

(edit conflict) Comments on script:

  • To make the lines underneath section headings red, add h1{border-bottom-color: red;}
  • To make the selected tab look as it its selected (like in normal vector) use :

div.vectorTabs ul li.selected {background-image:url('http://bits.wikimedia.org/skins-1.5/vector/images/tab-current-fade.png') !important}

  • Looking at the links in the tab bar, its impossible to tell if a page exists or not. Add div.vectorTabs li.new a span{color:#FFAAAA !important}
  • You're missing a closing brace at the end. ManishEarthTalkStalk 04:13, 25 March 2010 (UTC)[reply]
Well, I'm done with the 'main' part, I have only the edit box left to do. However, something appears to be wrong with the tabs. It's kinda hard to explain, but looking at the actual CSS would explain it. Also, if anyone reading this has access to /skins-1.5/vector/images (readonly+view should do it) on bits.wikimedia.org, a readout of what images are stored would help a lot with this.Hmmwhatsthisdo (talk) 00:55, 26 March 2010 (UTC)[reply]

Gallery tags

When galleries are automatically generated in categories of images, a text link to the file is automatically generated and displayed below the image. Is it possible to trigger this behavior outside category space, such as in user space? If not, is it possible to pipe code into the gallery tag via templates? SharkD  Talk  04:44, 24 March 2010 (UTC)[reply]

You could create a template which renders a gallery/table of images up to an arbitrary maximum. However, I think using inline div elements would be better because unlike table cells they would wrap intelligently to the available screen-width. Examples available upon request. ―AoV² 16:41, 24 March 2010 (UTC)[reply]

Yet another Java applet request

Recently a page I've been involved with received a request, from WikiProject Physics, for some additional content. As a result I spent a couple of weeks developing an interactive java applet. This was based on some old published work and was designed to illustrate some of the physics involved.

However when I tried to upload the applet I was very surprised and a little disappointed to learn that Wikipedia does not support applets. I made some enquiries and was directed to these pages. On searching for 'applet' I learnt that there have been earlier requests, i.e. Archive 50/Question 16, but very little progress.

As far as I can tell resistance comes from:

1. Worry about security. But Java applets are run in a sandbox for just this reason.
2. Worry about loading times and cpu use. But this is the same problem as with sound and other media and could be solved in the same way via a javascript box.
3. The people involved in the discussion know little about java applets and that "people would have to know about java". I do not see that this is any different from knowing how to create mp3 files, pdf files or whatever. The wikipedia web pages on Java applet and Java (programming language) are a start.

There was also a suggestion of using Wikiversity which I followed up - but this turned out to have the same applet support as Wikipedia. I then found a link to a wiki/applet project (which I thought was overkill for the changes needed) but even this seems to have run out of steam.

So I am wondering if the question should be put in another form i.e.:

1. Has the applet option been discussed at a formal meeting of wikipedia in recent years?
2. If so, is the written report of the meeting available? Were experts on java applets and representatives of the physics community present at the meeting?
3. How can the question be raised officially at a future meeting?

Regards, David Webb (talk) 09:52, 24 March 2010 (UTC)[reply]

Answering your questions in order:
  1. I doubt it, I don't think there's ever been a huge demand for it.
  2. See #1.
  3. If you want a feature request in MediaWiki, see https://bugzilla.wikimedia.org. Granted, I don't see this getting implemented on WMF sites.
^demon[omg plz] 10:16, 24 March 2010 (UTC)[reply]
Mediawiki should atleast support flash (does it?)... You can make stuff ass good as Java in Flash, and its much easier, too. FLash would be a good addition. It should be sandboxed with no external file access... and maybe only admins can upload to stop people from uploading ads. ManishEarthTalkStalk 12:24, 24 March 2010 (UTC)[reply]
Flash is much more resource-intensive than Java, and doesn't come with built-in Java security. Plus, anything that can be made in Flash can be made more easily (programming-wise) in Java. There is a small need for Java, but no need whatsoever for Flash. OrangeDog (τε) 13:24, 24 March 2010 (UTC)[reply]
Comment: I'm a Java programmer and I used to do flash, and I personally feel that for and interactive thingamabob which has encyclopedia value, Flash makes for easy graphics and interactivity is much easier. In Java, graphics are harder and coding gets heavy for applets. But you're right about the resource stuff. ManishEarthTalkStalk 15:03, 24 March 2010 (UTC)[reply]
And most importantly, Flash is not an open technology. JAVA wasn't either long ago, but now it is (GPL now). Though there still might be some patent issues. Most of all though, it's a matter of who will do the work I think. jmol has been discussed many times before for instance. Last time it was seriously proposed User:User:Ilmari Karon found a JavaScript injection security issue within minutes. Those are the kinds of problems. Also, we have to remember a few other things. Applets don't print for instance, so there would have to be some discussion on that. And applets don't have thumbnails, so what do we present to users before something is loaded ? There is one general applet loader extension that could be used for this. We of course already use the oggplayer extension which loads the Cortado applet. Other extensions that load applets (though not installed here) are IRC chat, GeoGebra, RDFEditor, X3d and many others. —TheDJ (talkcontribs) 14:18, 24 March 2010 (UTC)[reply]

This looks like the start of a good discussion but I would like more advice on how to continue. Given that Moore's Law is still operating it is odd that Wikipedia is not thinking more about the use of java applets to convey information. I am sure that once the facility was available this huge community would find good uses for it.

On the question of Flash or Java I would plump for Java on the basis that it is open source and not two difficult to learn. I found some good cheat sheets on the web and was able to do what I wanted, including bug hunting, in about two weeks starting from scratch. As a died in the wool fortran programmer that wasn't too bad. Re printing, the javascript box could have an associated jpeg representing the applet - the real applet only appearing once it had been clicked on. For anything else the user could copy and print the screen - but I sure that if asked by Wikipedia Oracle/Sun would suggest something better that worked.

Re bugzilla - the bugzilla site is talking about bugs and it is not obvious that anyone would take notice of my present request. Instead would I do better getting WikiProject Physics involved? What other routes are there for getting progress? David Webb (talk) 22:09, 24 March 2010 (UTC)[reply]

What is needed here is a multitude of things.
  1. Demand
  2. Code that actually makes this work
  3. A request to bugzilla to review said code and eventually deploy it.
And unfortunately not all those things come together at the same time. Remember that the software is opensource and mostly a volunteer effort. So if this is something that you want, you will need to evangelize, find a programmer and get Tim Starling to review the code and approve it for Wikipedia operations. I would always make sure by asking in bugzilla first, if there is a chance AT ALL if this will ever be approved for use on Wikipedia. That might save you some wasted effort. —TheDJ (talkcontribs) 22:42, 24 March 2010 (UTC)[reply]
Thanks. When you say 'code that actually makes this work' and 'finding a programmer' - do you mean changes to the wikipedia server code? For that I presume the best route is via Bugzilla or at a Wikipedia meeting. For everything else I would expect the contributers to do the programming. David Webb (talk) 18:14, 25 March 2010 (UTC)[reply]

Just throwing an idea out: it doesn't sound like there will ever be applets on Wikipedia, but would there be a possibility of another Foundation sister project, perhaps even a new one, for free-content audio/visual displays like presentations and applets that can be used to augment 'pedia content? This still would be limited to GPL-type content (Java for example), and likely there would need to be deeper disclaimers that the Foundation assumes no damages for malicious additions. (Of course, we could make it a requirement there that all such applications, since GPL, include the source code as back-end pages, thus allowing for review of malicious claims). Just an idea, as I see the usefulness of more interactive tools for some subjects, just not on 'pedia proper. --MASEM (t) 22:16, 24 March 2010 (UTC)[reply]

We could have a set of high-level trusted users who have disclosed their identity and are good enough at Java to review the code. That might save WMF the time of reviewing it. ManishEarthTalkStalk 03:32, 25 March 2010 (UTC)[reply]
I would hope this would only be necessary for a year or two until trust in Java Applets was established. David Webb (talk) 18:14, 25 March 2010 (UTC)[reply]

What's up with the geogrouptemplate?

Any ideas about what's going wrong with {{GeoGroupTemplate}}? In the last couple of days, any time I select "Map of all coordinates from Google", I get a "File not found at http://toolserver.org/~para...." message, while when I select the Bing option, I get a message of "This content is not available. It may have been deleted by the author." Selecting the other three options on the list, I get a "Can't download this page" popup for the GeoRSS option and the following error for KML:

The server encountered an internal error and is unable to complete your request at this time. If the problem persists, please contact the owner of the tool you are trying to use and inform them of this error, quoting the following information:
Request host: toolserver.org
Request path: GET /~para/cgi-bin/kmlexport
The owner of this tool is: para [at] toolserver [dot] org.

HTTP server at toolserver.org - ts-admins [at] toolserver [dot] org

Only the "map of all microformated coordinates" option is working; it brings up a proper map. Nyttend (talk) 13:49, 24 March 2010 (UTC)[reply]

It was due to toolserver software upgrades on that day. More details at Wikipedia talk:WikiProject Geographical coordinates#GeoGroupTemplate problem.3F. --Para (talk) 12:33, 28 March 2010 (UTC)[reply]

Technical question regarding mms://

Moved from WP:AN

My editing mostly covers radio and television stations and I and my fellow editors are finding that there are several stations (don't have an exact number) whose live stream links begin with mms:// which does not compute into a link on Wikipedia. If it begins in http:// it links no problem, but mms:// does not. How would one suggest what should be an easy change and only affect pages that link to webstreams (particually radio and television station pages). Thanks...NeutralHomerTalk • 09:11, 24 March 2010 (UTC)[reply]

You'll need to get community consensus to add 'mms://' to $wgUrlProtocols and then file a request on Bugzilla for a site configuration change, linking to the consensus. ^demon[omg plz] 10:22, 24 March 2010 (UTC)[reply]
Or we can just change the defaults. If it's useful, I don't see why we wouldn't add it. The Wikipedia article on Microsoft Media Server says it's a Microsoft technology, but also that there's now a publicly available spec, and multiple open-source implementations. As long as there are no scary side effects (there's at least one IM URL protocol where clicking a link can send a message with no further user interaction, IIRC), I don't see why we wouldn't add it. worldwind:// and svn:// are supported by default, although both are non-standard. —Aryeh Gregor (talk • contribs) 16:27, 24 March 2010 (UTC)[reply]
I'm all for erradicating mms indefinitely, but it is relatively common, and I don't think it would hurt to add it to the defaults, possibly making a lot of people happy. —TheDJ (talkcontribs) 17:19, 24 March 2010 (UTC)[reply]
I don't really care either way, we can add it if other people think it's worth it. I just figured people wouldn't by default, so I gave the usual "get consensus then ask the shells" speech ^demon[omg plz] 21:30, 24 March 2010 (UTC)[reply]
So is this consensus or do I need to go elsewhere and get others opinions? Never actively tried to get something added to Wikipedia, so I don't know the process. - NeutralHomerTalk • 04:57, 25 March 2010 (UTC)[reply]
  • We link to the homepage of each station. How many stations fail to link to their live streams from their own websites? There is no encyclopaedic purpose to be served by linking to their live streams as well as their own websites, as far as I can see. Guy (Help!) 14:46, 24 March 2010 (UTC)[reply]
    • Guy, most of the pages are actively updated, so there is a pretty good chance if you click on a livestream link, it is going to the actual live stream and is going to work. I still would like to see it done. - NeutralHomerTalk • 03:54, 25 March 2010 (UTC)[reply]

I added mms:// to MediaWiki defaults in r64220. No idea when it will be live on Wikipedia, might be months from now. Probably not terribly useful for Wikipedia, but it might be useful for other wikis, especially non-Wikimedia ones. —Aryeh Gregor (talk • contribs) 19:08, 26 March 2010 (UTC)[reply]

Thanks! You rock! - NeutralHomerTalk • 22:49, 26 March 2010 (UTC)[reply]

mysterious csd

User:NativeForeigner/Development is showing up in Category:Candidates for speedy deletion by user. Page does not seem to have been edited in three months, and I can't find any tags on the page. I cleared out this cat yesterday so I know it wasn't in it then. So, why is it showing up in this category? Beeblebrox (talk) 17:25, 24 March 2010 (UTC)[reply]

  • I added noinclude tags to the page and that seems to have fixed it, but I still can't figure out why this happened to begin with... Beeblebrox (talk) 17:29, 24 March 2010 (UTC)[reply]
I'm betting one of the userboxes was put up for CSD, and it carried over. Several on the right have been deleted, though who knows when without checking the log. UltraExactZZ Said ~ Did 19:32, 24 March 2010 (UTC)[reply]

Downtime

If the admin log is unavailable to you, use Twitter.

Wikipedia is down for a lot of folks in Europe atm. A problem with the DNS entries or something. More news will follow on http://techblog.wikimedia.org and secure continues to to work for the obsessed. —TheDJ (talkcontribs) 17:45, 24 March 2010 (UTC)[reply]

Seems to be affecting me too (eh?)... Another solution is to place entries in your local hosts file...
208.80.152.2	en.wikipedia.org
208.80.152.3	upload.wikimedia.org
...yes - I'm an addict. –xenotalk 17:47, 24 March 2010 (UTC)[reply]
and the explanation: http://techblog.wikimedia.org/2010/03/global-outage-cooling-failure-and-dns/TheDJ (talkcontribs) 17:55, 24 March 2010 (UTC)[reply]
...of course, attempting to communicate this to folks affected by placing it on the affected site is probably an exercise in futility... –xenotalk 18:38, 24 March 2010 (UTC)[reply]
Geek.
But you'll also need
208.80.152.118 bits.wikimedia.org
:) Amalthea 18:48, 24 March 2010 (UTC)[reply]
Well en.wikipedia seems to be fixed, but I'm not getting any css or js back yet. Or indeed, edit conflict notices. OrangeDog (τε) 18:50, 24 March 2010 (UTC)[reply]
At least this means my computer isn't just going crazy. All I can get is the article-frame, everything else has disappeared. I've changed the header, though - I'm in the U.S. and affected.  :( *sigh* --Philosopher Let us reason together. 19:30, 24 March 2010 (UTC)[reply]
Additionally, the secure server appears to be completely down. --Philosopher Let us reason together. 19:43, 24 March 2010 (UTC)[reply]
No doubt from the additional load. –xenotalk 19:44, 24 March 2010 (UTC)[reply]
Ah, just noticed at the server admin log, it says the secure server got too much extra traffic, so they turned it off. --Philosopher Let us reason together. 19:48, 24 March 2010 (UTC)[reply]
...and en.wikipedia starts working fine as I switch computers. Hmm.... --Philosopher Let us reason together. via alternate account 20:01, 24 March 2010 (UTC)[reply]
Your Operating system and browser might be caching as well. so that might explain it a bit. —TheDJ (talkcontribs) 20:34, 24 March 2010 (UTC)[reply]
I couldn't access Wikipedia (nor some of its sister projects) at all until about 20:02 UTC. Waltham, The Duke of 20:28, 24 March 2010 (UTC)[reply]
Still can't get bits.wikimedia in the UK :( OrangeDog (τε) 21:34, 24 March 2010 (UTC)[reply]
Have you tried flushing your dns cache/editing your hosts file? Ale_Jrbtalk 21:39, 24 March 2010 (UTC)[reply]
Yes, I've manually configured the IP. Just letting you know that my regular DNS (216.146.35.35) still doesn't have bits.wikimedia.org, just in case the information is useful to anyone who can do something about it. OrangeDog (τε) 23:56, 24 March 2010 (UTC)[reply]
I've flushed my DNS, changed the DNS and cleared the cache but still not getting the "normal" Wiki. Bidgee (talk) 02:12, 25 March 2010 (UTC)[reply]

Europe? I'm not in Europe. I'm in North Carolina. I turned on my computer at home at around 19:00 and every time I tried to access Wikipedia, nothing happened. Around 22:00 I finally saw a page but was unable get results if I clicked on anything. While doing other stuff, I got one of the pages to come up after waiting and waiting and waiting, clicked again, did other stuff while waiting and waiting and waiting for another page, and only by 23:00 was Wikipedia operating anywhere close to normally. But I had other stuff to do.Vchimpanzee · talk · contributions · 13:29, 25 March 2010 (UTC)[reply]

Please read it all. The switch after the europe outage was what caused the global outage. —TheDJ (talkcontribs) 20:48, 25 March 2010 (UTC)[reply]
Oh, I see. There's a link. Well, the news made Mike Huckabee's show!Vchimpanzee · talk · contributions · 22:12, 25 March 2010 (UTC)[reply]

Movement in the text box

I am encountering an issue (on IE8) while editing pages (and sections of pages) which contain enough text as to require scrolling the text box: the view (but not the text cursor) jumps around (one jump per action) when I move the mouse cursor over the edit summary box, the "Show preview" button, or the various links ("verifiable", "what's this?", "Cancel", "Editing help"), and when I click the "Show preview" button. I have no idea what could be causing the issue, but it must be fairly recent (I didn't encounter this when editing yesterday). Is anyone else having the same issue? Thanks, -- Black Falcon (talk) 17:46, 24 March 2010 (UTC)[reply]

Yes, I am also experiencing this problem, starting this morning. It's not the first time it's happened, and it's usually gone away within a day or so. Pats1 T/C 19:01, 24 March 2010 (UTC)[reply]

Someone must be playing with the JS again. ¦ Reisio (talk) 00:27, 25 March 2010 (UTC)[reply]

There also appeared to be changes to the size of the text in the "save page" etc. buttons at the buttom. Also to the size of the links in the top-right. Pats1 T/C 14:37, 25 March 2010 (UTC)[reply]

Is having the same problem and its on its 3rd day now. --> Halmstad, Charla to moi 13:36, 25 March 2010 (UTC)

Me too, thought it was just me. Also running Internet Exploder 8. I noticed the text box scrolls down one line for every character I type, or other action, until the cursor is at the bottom of the edit window. So one does not notice typing on the last line, but otherwise, this is a real annoyance. Could somone back out the JavaScript change please? W Nowicki (talk) 21:37, 25 March 2010 (UTC)[reply]
Mine isnt jumping down its jumping up either i click with the mouse or writte something, its especialy annoying since it prevents me from highlighting text in longer texts with the mouse. --> Halmstad, Charla to moi 00:46, 26 March 2009 (UTC)

Thank you for surfacing this issue. We appreciate it and we will be working to resolve this issue ASAP.--Parul Vora (talk) 03:10, 26 March 2010 (UTC)[reply]

We were accidentally serving beta users the (currently a bit unstable) iframe instead of the normal textarea because the code I wrote to prevent this from happening was broken :( Fixed this a few minutes ago. --Catrope (talk) 13:18, 26 March 2010 (UTC)[reply]
The problem has not yet been fixed, as far as I can tell. Typing any text in the textbox automatically scrolls the line you are editing to the bottom of the viewable area of the text book. Anyone else still having this problem? Pats1 T/C 05:23, 27 March 2010 (UTC)[reply]
Speaking of the beta - each time I go to try it (over a period of five+ months), there is always a problem with the "article" and "discussion" etc. links at the top. They aren't treated as links, but a background image, so you can't right click to open them in a new tab/window in IE8. Pats1 T/C 00:36, 27 March 2010 (UTC)[reply]

This jumping around almost completly prevents me from editing on wikipedia, the smalest thing i do makes it jump up, can't use only the keybord. --> Halmstad, Charla to moi 17:13, 26 March 2010 (UTC)

I have opened bugzilla:22983 to track this problem —TheDJ (talkcontribs) 00:34, 28 March 2010 (UTC)[reply]

Subpages

Need expert opinion here of someone who understands one of the following: transcluded templates, subpages. Why: article Vitamin B Vitamin D contains 220+ references, many of which were formatted as {{cite doi}} and {{cite pmid}} templates. A crash in one of those entries effectively removed the whole reference list (which was not evident how to fix, at least to me). After that, I changed all {{cite doi}} and {{cite pmid}} templates to {{cite journal}}, believing this would stabilize the article. My argument is that a large number of {{cite doi}} templates transcludes many subpages/templates which is undesirable (?), and this is the question I am asking here. Sorry for incoherence. Materialscientist (talk) 23:40, 24 March 2010 (UTC)[reply]

I'm not sure I understand the question, but I can say this. if you view the source on any page there is a diagnostic tool - NewPP limit report. on the page in question it reads like this
NewPP limit report
Preprocessor node count: 15117/1000000
Post-expand include size: 214550/2048000 bytes
Template argument size: 114792/2048000 bytes
Expensive parser function count: 8/500
on a random page - Ulverscroft_Priory it reads like this:
NewPP limit report
Preprocessor node count: 1279/1000000
Post-expand include size: 8459/2048000 bytes
Template argument size: 3245/2048000 bytes
Expensive parser function count: 0/500
it's clear that your page is an expensive page to load, though not a horribly expensive one, but if you want to know whether your change was an improvement, take a page out of the history with the old revision and compare the numbers. --Ludwigs2 20:30, 25 March 2010 (UTC)[reply]
Thanks. How can we get to "NewPP limit report" function? The question was when does the page load approaches a level of discomforting an average reader? Two citation styles were alternately used on that page: (i) "cite journal" places all references into the main article, thus increasing its size; (ii) "cite doi/pmid" moves individual references out of the body into individual subpages - in case of this article, the was size almost halved by this, but. (a) An error in one subpage crashed the main page (sure any ref can do that, but such cases are more difficult to debug). (b) I'm not sure whether 200+ of subpages are not causing additional problems I don't know. Materialscientist (talk) 23:16, 25 March 2010 (UTC)[reply]
I've been editing that page: Vitamin D. By using the ref templates that have been brought into use by User:Citation bot and reworking of other links with Reflinks, the post-expand include size is kept within reason. The other templates that were being used, were what was causing the limits to be exceeded. See Wikipedia:Template limits. To see the report for any given page, use the view source command of your browser and look rather towards the end. Note that you can do this during an edit-preview. Also, this edit seemed on-track to bringing the other fork of that page under the limits. In the end, the standard templates that these tools bring into use are the way to go; anything else is pissing into the wind. Cheers, Jack Merridew 00:18, 26 March 2010 (UTC)[reply]

Dialogs are back in Usability Beta

Users of Safari/Chrome/Firefox/Opera might note that dialogs have returned for inserting links, tables and doing Search and Replace. Users who have disabled this in the past might have to go to Special:Preferences and enable it in the section Editing -> Beta Features. —TheDJ (talkcontribs) 00:08, 25 March 2010 (UTC)[reply]

Plus the navigable TOC in editing in Prefs>Editing>Labs features. I wonder when they'll roll out the template resizing... I've tried it out at the sandboxes and it's great! ManishEarthTalkStalk 03:18, 26 March 2010 (UTC)[reply]
Huh? The navigable TOC isn't showing... ManishEarthTalkStalk 03:21, 26 March 2010 (UTC)[reply]
Plus it blocked keyboard shortcuts... ManishEarthTalkStalk 03:22, 26 March 2010 (UTC)[reply]
The navigable TOC is still disabled. It depends on the iframe editor (which was accidently enabled yesterday) which still has too many issues to deploy. —TheDJ (talkcontribs) 19:28, 26 March 2010 (UTC)[reply]

Toolserver Opt-in Requirement

I'm guessing this must be an extremely recent thing, because I don't remember this being there yesterday. My Toolserver edit count has boxes now stating:

"Graphs have been set to opt-in as a result of a single complaint resulting in what is essentially a cease-and-desist letter from the toolserver admins. If you want to see graphs, please create User:Silver seren/EditCounterOptIn.js with any content. Alternatively, you can create meta:User:Silver seren/EditCounterGlobalOptIn.js to opt-in across all Wikimedia wikis."

Whatever's going on here, it sounds ridiculous. But I guess that's something for lawyers to work out. Anyhow, how exactly do I set up this Meta page so that it will start displaying everything again? I know absolutely nothing about code. Nothing. Beyond the basic features I use in making edits and such, I don't know how to do anything related to the mechanics. Can someone help me walk through this (or maybe do it for me?), so I can get this working again? And I sincerely doubt i'm going to be the only user with such a problem. Thanks in advance. SilverserenC 08:48, 25 March 2010 (UTC)[reply]

Create this page User:Silver_seren/EditCounterOptIn.js and write whatever in it. There is a discussion about this in X!'s userpage. --JokerXtreme (talk) 09:52, 25 March 2010 (UTC)[reply]
(e/c)Several editcounters have had opt-in requirements for some data, in my experience. In any case, what you have to do is very simple - just click this link: Special:Mypage/EditCounterOptIn.js and create the new page - it doesn't matter what you put on the page (hence the "any content" above).
If you want to use it on other projects, not just the English Wikipedia, click meta:Special:Mypage/EditCounterOptIn.js and do the same thing. Basically, they're just asking you to verify that you actually want the Edit Counter to show your edits - not unlike what websites do when they have to verify your e-mail address. BTW - I've used the Special:Mypage version of it so anyone can click on the link, not just Silver seren.--Philosopher Let us reason together. 09:57, 25 March 2010 (UTC)[reply]
We've put together a tswiki:List of things to ask WM-DE over edit counter and other weird German laws. Please feel free to correct anything there as I didn't have time to proof read it. Depending on the answer we may have to band edit counters on the Toolserver. German law does not have to be self consistent it just has to "make sense". Example: while you can legally take street view photos and post them to the internet, while anything like Google's street view is illegal. — Dispenser 11:02, 25 March 2010 (UTC)[reply]

Would blanking said page disable the edit-counter, or would one need to delete it? ―AoV² 10:13, 27 March 2010 (UTC)[reply]

Double upload

Moved from Help Desk:

Why does the files that I upload keep doubling itself? Is there a bug or something? This problem only occur when I use Firefox. Please view here & here for example. I have no problem uploading file on commons using firefox. It only happens on this wiki. Please help. Arteyu ? Blame it on me ! 00:20, 24 March 2010 (UTC)[reply]

I'm sorry, I have no idea what you mean. Both images appear normal to me. (I'm using Firefox 3.0.15). --ColinFine (talk) 08:25, 24 March 2010 (UTC)[reply]
The file history indicates the files were uploaded twice in the same minute. I don't know the cause. They only appear once at Special:Contributions/Arteyu. You could try Wikipedia:Village pump (technical). PrimeHunter (talk) 15:00, 24 March 2010 (UTC)[reply]

The double upload still happens to two new files that I've uploaded just now, here and here. If it's a bug, I would need someone to fix it as soon as possible. Thank you. Arteyu ? Blame it on me ! 11:42, 25 March 2010 (UTC)[reply]

The only reason I can think of would be that you're somehow starting the upload twice - doubleclicking instead of singleclicking, for example. The uploads are simultaneous, and don't appear to be different in any way. The descriptions differ, as with File:Torquay United FC.svg (the more "recent" image has three summary headings shown, but only one on the page - the "older" image has only one summary heading), and I don't know what could cause that. It looks harmless - just an extra edit on your contribs, really - but it's still a curious technical glitch. UltraExactZZ Said ~ Did 13:07, 25 March 2010 (UTC)[reply]
I forgot to tell you guys that I've also got a problem with the page edit notice, which can be seen twice on top of page when I tried to edit it, see here for example [3]. Well, I solved both errors anyway by clicking on the "Restore all default settings" panel on "My Preferences" and refreshed the edit page. I went through all the gadgets again after that to know which of them made the error. And I found that it is caused by an editing gadget called "wikiEd". Think someone should fix this bug out so that it won't happen again to other users. Also I want to thank Algebraist and Avicennasis for helping me out on the freenode IRC channel. Arteyu ? Blame it on me ! 14:27, 25 March 2010 (UTC)[reply]
wikEd purposely creates the second editnotice below the preview. Discussion continued here. Gary King (talk) 14:52, 25 March 2010 (UTC)[reply]

Incidentally I believe the upload mechanism should disregard null uploads similarly to null edits, i.e. take no (database) action if the file you submit is identical to the current version. ―AoV² 20:08, 25 March 2010 (UTC)[reply]

On a related note to the above discussion about MediaWiki:Protectedpagetext, I propose that the "edit this page" button should always say "edit this page". It should not become "View Source" on a page the user doesn't have permission to edit.

Reason:

  1. in most cases not having permission to edit is temporary or relatively easily overcome by getting autoconfirmed;
  2. "View Source" unnecessarily weakens the message that anyone can edit. This is a particular issue because many high-profile pages are more-or-less indefinitely semi-protected, and unloggedin users visiting these pages are not getting the "anyone can edit" message.
  3. clicking on "edit this page" provides further information about editing, discussing, and making edit requests, which is not at all obvious from "View Source".

This change can be made easily, I think, by editing MediaWiki:Viewsource. Rd232 talk 11:50, 25 March 2010 (UTC)[reply]

Ok, but make the change so it only applies to the article namespace. The Mediawiki: and WP: namespace are anyways stuff that isn't part of the encyclopedia, so it doesn't weaken the "anyone can edit" message. Anyways, these namespaces are hardly seen by new users except WP:5P and the other welcome pages. ManishEarthTalkStalk 13:01, 25 March 2010 (UTC)[reply]
Well, maybe, but the button is more than just "view source", it's also links to protection logs and the new edit request button. So long as AoV's point below is addressed, it might as well be the same across namespaces. Rd232 talk 14:17, 25 March 2010 (UTC)[reply]
Uggh, I assure you discarding information (namely whether the user can or cannot edit the page) with a change like this will upset more users than it will help. It′s bad enough this state of the button does not take “cascading protection” into account, see bugzilla:11700. Of course being an admin who can edit everything I wouldn′t expect you to understand. ―AoV² 13:45, 25 March 2010 (UTC)[reply]
Protected pages should generally have protection templates which indicate protection status at least with a top-right padlock icon. I take your point though that if people are used to seeing protection status from this change (edit -> view source), then maybe some form of indication in the tab should be maintained. It needs to be visible but non-invasive, so maybe just an asterisk after it, i.e. |Edit this page*|  ? Rd232 talk 14:17, 25 March 2010 (UTC)[reply]
A line through it at least but using completely different words would be much better. Making it say “edit” when one cannot edit is no less inane than showing the “move” tab when one cannot move. If you want to change “view source” to something more people will understand, that′s fine and dandy, but please keep it easily distinguishable from other buttons. ―AoV² 14:30, 25 March 2010 (UTC)[reply]
I would note that on the opposite, there are often people asking in the helpdesk "where is the edit button". So it creates as much confusion as that it provides information I'm guessing. Also I'm not sure if it is possible to use parserfunctions and magicwords in the tabs, to have context dependent contents. —TheDJ (talkcontribs) 14:50, 25 March 2010 (UTC)[reply]
I think that illustrates my point rather well :) I don't see why parserfunctions/magic words can't be used in the tabs (caching?), but I don't quite see what you'd do with it if you can. As I see it, consistency is a basic point of user interface design, and as a result when functions are not available for whatever reason (but in the context the function still makes sense) then this often highlighted in some way, without changing the text - often grayed out. But since the button is still usefully clickable, we should do something else. I think the asterisk solution is a good one, because the button does lead people into ways they can edit the page (even if it means registering first, requesting unprotection, or making an edit request), but it indicates a nonstandard process. Rd232 talk 15:10, 25 March 2010 (UTC)[reply]

I suppose the best approach overall would be to make “edit” and “view source” two completely different &actions. Then it would not matter whether the “edit” button appears in a disabled state, or does not appear at all—and the “view source” button could appear regardless of edit-ability (pointing to &action=viewsource or some-such). ―AoV² 20:04, 25 March 2010 (UTC)[reply]

Thumbnail expand image button improve

I know that this should go to WP:VPR, but I wanted to get a technical opinion first. I'm proposing to tweak image thumbnails so that clicking on them or the "expand image" link will, instead of opening the image page at the File: namespace, will gray out the page and float an expanded version of the image on the page, and that image will link to the File: namespace. For a better explanation of what I mean, see here (click on the image). THis technology is already used for Google Buzz and you see it on many blogs, too. Is this feasable for WP? (I think it can be done through js...will try). ManishEarthTalkStalk 12:07, 25 March 2010 (UTC)[reply]

Uggh, I do hope you′d provide a way to disable it. It′s bad enough I had to write this script which disregards irrelevant links like and restores direct access to the file descriptions in namespace six. ―AoV² 13:28, 25 March 2010 (UTC)[reply]
I once started working on such a Javascript gadget based on lightbox. But never really got it off the ground. I do think it is a good idea however. —TheDJ (talkcontribs) 14:52, 25 March 2010 (UTC)[reply]
Disabling shouldn't be too hard (prefs). Visitors click on thumbs to see a bigger version, not a description page (The description is usually captioned anyways). This will also allow the user to see a bigger version of images than shown on description pages. For example, on Colaba#Present, there's a panorama. A user will click it to get a bigger version, and will be disappointed to see the (relatively) tiny image at File:Colaba_panorama.jpg. The user will most probably overlook the "Full resolution" button. We should make thumbs open in a superimposed layer, with maximum image size, with some space for links to the File description page and the full resolution version. This will make viewing images easy for them, and they'll be wowed by the effect, too. ManishEarthTalkStalk 15:13, 25 March 2010 (UTC)[reply]
A way to disable it is a must. I'm not the only one who hates lightboxing. In the Wikipedia case, however, it should not be attempted at all unless you also can display the license information associated with the image. If you want to see some really nifty zooming stuff, go to the Commons and enable the ZoomViewer gadget. It's still experimental, but looks very promising. Lupo 16:04, 25 March 2010 (UTC)[reply]
I think this is a "reader" UI improvement, but, as an "editor" it would be a disimprovement. As an editor, clicking on the images take the user to the page where the image can be edited, its history can be viewed and its content talked about (which is good). As a reader, I recall form when I first visited Wikipedia, that is quite unexpected. In most cases, as a reader, having images that link anywhere is unexpected.
The question then is thus: is this a "reader" website or an "editor" website. There is an argument to say that this is an "editor" website (so leave things as they are). There is an argument too that says, in purist wiki philosophy, it is both a "reader" and an "editor" website - but in such philosophy, readers are editors, not the other way around (so leave things as they are). There is no argument to say that this is "reader" website, other websites do that (so leave things as they are).
That said, the file page is a visually awful. More could be done to make it prettier and more usable to readers (and editors).
Bear in mind too that the file page contains attribution information, which is necessary to link to in some circumstances for copyright reasons. A lightbox would need to contain that information in order to be copyright compliant in all circumstances. --RA (talk) 16:33, 25 March 2010 (UTC)[reply]
It would be very easy to add a link under the lightbox to the full description page, and even to take the author info from the description page (perhaps even the license with some clever parsing). And editors can be accommodated by using an alt or shift click action to the image that would take you immediately to the page description. —TheDJ (talkcontribs) 20:40, 25 March 2010 (UTC)[reply]
Not to mention that - for better or for worse - the vast, vast majority of visitors are most definitely not editors: they're readers. Generally, if something makes things better for readers (which I actually think this might do) to the (minimal) detriment to editors, it is A Good Thing (in my opinion, anyway). Ale_Jrbtalk 21:25, 25 March 2010 (UTC)[reply]

Perhaps you could make this happen only when one clicks the “enlarge” icon:

<a href="/wiki/File:Foobar.jpg" class="internal" title="Enlarge">
<img src="http://bits.wikimedia.org/skins-1.5/common/images/magnify-clip.png" alt="" height="11" width="15">
</a>

(by adding onClick="overwhelmWindow()" or whatever to the above). ―AoV² 21:41, 25 March 2010 (UTC)[reply]

Really however we should ensure that the target content of each link remains bookmarkable in some easy fashion. The dynamic loading mechanisms of many sites unfortunately do not conform to that. ―AoV² 21:49, 25 March 2010 (UTC)[reply]

Most people don't see the enlarge icon. Anyways, I do agree that image enlarging is pretty useless for editors, just as links to the image description page are useless to readers. But disabling it shouldn't be hard thru prefs. And we seem to already have the coding for making Web 2.0 windows, as is visible by the beta link dialog (I think they've used jQuery). I might start the coding in a week or so... ManishEarthTalkStalk 03:14, 26 March 2010 (UTC)[reply]
There's also User:Zocky/Picture Popups, but that doesn't work in IE6 so its not included as a gadget. — Dispenser 02:43, 26 March 2010 (UTC)[reply]

Obtaining image dimensions

Could someone tell me how to fetch the height and width of a full resolution image on WP? Thx, ManishEarthTalkStalk 03:13, 26 March 2010 (UTC)[reply]

Me too, that way I can simplify Template:Multiple image/doc#Horizontal placement: matching image heights. --Redrose64 (talk) 11:43, 26 March 2010 (UTC)[reply]
like this. Jus replace the image title with whatever you want. And whatever you do, remember that we have some 3000+ pixels wide images. You might want to put a limit on a request. —TheDJ (talkcontribs) 19:26, 26 March 2010 (UTC)[reply]

Citing tool

I've been having problems with the "insert citation" tool over the last few days. Sometimes it works fine, but it has crashed firefox a couple of times when I click to add the citation (very annoying!), at other times it adds the reference at the top of the edit box rather than where I've clicked for it to be added. In this edit it place ref tags at the top and bottom of the article but didn't add the reference at all. It's doing the same things on different computers too. Has anyone else had problems/can anyone suggest how I might fix it? Thanks Smartse (talk) 13:29, 25 March 2010 (UTC)[reply]

Are you using WikEd? I have had the same problem with the sig button when using WikEd - either not working, adding my sig at the top of the page - similar weirdness to yours. Also had unpredictable Firefox crashes too. Disabling WikEd seems to fix it, but it's not a solution. Dang it just did it again! – ukexpat (talk) 03:34, 26 March 2010 (UTC)[reply]
Yea I use WikiEd but too, the benefits of it outweight the annoyance caused by this but it would be good if someone could fix it. When I add citations, the form stays up and filled in instead of collapsing as it should do. Smartse (talk) 13:15, 26 March 2010 (UTC)[reply]

Links from an independant wiki to Wikipedia

Hi guys and guyesses. First time I post here, I hope I do it correctly.

On a wiki, using MediaWiki but not connected to Wikimedia, I need to make links to Wikipedia/Commons pages with automatic conversion (made by a template) of spaces in titles to underscores. In other words, I'm searching for some code able to convert the title as it appears at the top of Wikipedia/Commons page to a correctly encoded URL.

I tried {{urlencode:, {{anchorencode:, {{fullurl:, but none seems to generate a correct URL.

An example is how to convert Wikipedia:Village pump (technical) to http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29, when you are not on a Wikimedia's wiki?

Thanks in advance for your help. --GaAs (d) 18:04, 25 March 2010 (UTC)[reply]

As I don't want to lose your time,
which all three don't work, and
  • {{fullurl:
works only here, as it adds the local site prefix. --GaAs (d) 18:15, 25 March 2010 (UTC)[reply]
You will have to include the namespace Wikipedia: to make a link to this page.
I don't know for sure whether localurl will do the same on your wiki. PrimeHunter (talk) 19:22, 25 March 2010 (UTC)[reply]

You may wish to try mw:Manual:Interwiki to allow links like [[w:Village pump (technical)|foobar]] instead of the “external” link syntax above. This will handle all necessary url-encoding. ―AoV² 19:58, 25 March 2010 (UTC)[reply]

I knew this answer. But it's no possible to implement it at the moment (for "political" reasons). If anyone has another idea... --GaAs (d) 21:58, 25 March 2010 (UTC)[reply]
What does the localurl example produce on your wiki? PrimeHunter (talk) 03:11, 26 March 2010 (UTC)[reply]

Dumb question about the symbol menu

I know this comes up every so often but I can't think of a search term for the archives. When I change the pick in the drop-down menu under the edit window, say from "Symbols" to "Latin", the pickable special characters don't change. My monobook.js is fully commented out. Can anyone heave a sigh and tell me what I'm doing wrong? Franamax (talk) 19:43, 25 March 2010 (UTC)[reply]

What browser/OS? I'm jumping back and forth between all the options (and specifically between Symbols and Latin) and it's behaving correctly for me. EVula // talk // // 19:58, 25 March 2010 (UTC)[reply]
D'ohh! IE8 v8.0.6001.18702 on fully patched WinXP MCE SP3. And the PC case is black. ;) Franamax (talk) 20:01, 25 March 2010 (UTC)[reply]
Do you have cookies blocked ? Or perhaps you have some Gadgets enabled in your preferences ? —TheDJ (talkcontribs) 20:43, 25 March 2010 (UTC)[reply]

Stuck RfC re actor pages and their hard-coded formatting

nb: admin review requested at WP:AN, which garnered a comment that this would be a useful page to seek input at.

An RfC that involves a lot of technical issues is rather stuck at:

It would be helpful if uninvolved folks could review and suggest an appropriate route forward? It's a long read; maaf.

There are on the order of 30,000 pages involved, so it would be good to get on it. Sincerely, Jack Merridew 22:44, 25 March 2010 (UTC)[reply]

Mixed content: HTTP mixed with HTTPS

When using Wikipedia in SSL mode, I keep getting warnings from Firefox that all the pages I visit on Wikipedia have mixed content. I tracked it down to two links that are present in every page: link rel="apple-touch-icon" href="http://en.wikipedia.org/apple-touch-icon.png" and a style="background-image: url(http://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png);". These links are forced to non-SSL (HTTP) transfer and Firefox complains that the page is mixed secure and non-secure items. How can I set Wikipedia to always give HTTPS links and thus remove the annoying warnings? Note: That I know I can simply turn off the warning in Firefox but I don't want to do that since that will lower my security. I prefer to keep the warning so that I know when something bad is happening. It is preferable if Wikipedia can be set to not generate mixed content. HumphreyW (talk) 23:03, 25 March 2010 (UTC)[reply]

This is not possible. See also bugzilla:18496. Currently Wikipedia does not have the resources to give priority to this problem. —TheDJ (talkcontribs) 23:06, 25 March 2010 (UTC)[reply]
Do you mean it is not possible because of lack of resources, or that is is not possible because of technical reasons, or perhaps both? HumphreyW (talk) 23:12, 25 March 2010 (UTC)[reply]
Well technically, it requires making sure that some servers (the media server and the CSS/JS/icon server) get an SSL layer and that this properly works with the main servers. Then that all has to be implemented, configured, tested whatever. So that is a lot of work, that only few people can do. —TheDJ (talkcontribs) 23:28, 25 March 2010 (UTC)[reply]
Good, so it is just a technical problem with a known solution. So when has it been scheduled to be fixed? HumphreyW (talk) 07:27, 26 March 2010 (UTC)[reply]
It isn't. One day in the future when someone gets really really bored, he might do it. —TheDJ (talkcontribs) 11:53, 26 March 2010 (UTC)[reply]
So is there some way to have the priority of this problem raised? It seems to me that a secure connection is needed for a number of reasons. To stop my cookies leaking to third parties. To solve the problem with the transparent proxies at my ISP. To avoid my government/employer/man-in-the-middle tracking my usage. etc. To me these reasons are important. How can I convince the Wikipedia people of the same? It is frustrating to see that it requires someone to be "really really bored". It doesn't appear to be very encouraging.
Most sites with HTTPS simply use the same URLs for both secure and non-secure access. I am curious to know why Wikipedia decided to use an entire set of different URLs when using the HTTPS protocol? HumphreyW (talk) 12:10, 26 March 2010 (UTC)[reply]
Yes, it's possible for the priority to be raised. No, it probably won't happen. Wikipedia doesn't have any particularly good reason to support SSL at all, which is why the implementation is so hacky. It's unlikely anyone is going to want to go to the effort of setting up a MITM attack to steal your Wikipedia login or spy on your browsing habits. As such, other things are much more important. I'm sure it will get fixed someday. —Aryeh Gregor (talk • contribs) 18:59, 26 March 2010 (UTC)[reply]
And to answer your question as to "why don't we have SSL certs for all the domains?" I think the original reason was cost...it wasn't worth the money to buy certificates for all the top-level domains, so they got one for secure.wikimedia.org. I don't think cost is so much the issue anymore, as now it's a matter of implementation. But like Aryeh says, it's not ultra-high on the priority list. ^demon[omg plz] 11:45, 27 March 2010 (UTC)[reply]
I thought that once the main domain was paid for then all sub-domains are essentially free (or at least of very low cost) with just logging in to the cert issuers site and generating a new cert automatically based upon previously registered credentials. Anyhow, I guess it doesn't matter how the certs are issued since the main problem seems to be inertia, time management and motivation, rather than finances. HumphreyW (talk) 12:17, 27 March 2010 (UTC)[reply]
As a temporary measure to avoid the problem I found that using the add-on NoScript there is an option under Advanced/HTTPS/Behavior/Force the following sites to use secure (HTTPS) connection: where I added upload.wikimedia.org. This forces Firefox to try using an SSL connection. The connection fails of course, but the warnings about mixed content are gone. The down side is that no pictures can be displayed when using HTTPS connections to Wikipedia. Not an ideal solution, but those annoying warnings and the potentially risky mixed content is gone. HumphreyW (talk) 10:26, 26 March 2010 (UTC)[reply]
Well, *.wikimedia.org has a certificate, so they just have to create https://upload.wikimedia.org (WHich they probably have reserved under *.wikimedia.org anyways). ManishEarthTalkStalk 12:29, 27 March 2010 (UTC)[reply]
And also to change the links so that HTTPS users get HTTPS link and HTTP users get HTTP links. HumphreyW (talk) 12:34, 27 March 2010 (UTC)[reply]
Shouldn't be hard... Will create a massive server lag (I think), but otherwise it requires a tiny change in coding for securewiki. ManishEarthTalkStalk 12:42, 27 March 2010 (UTC)[reply]

Looks like Gregory Maxwell determined that protocol-relative urls work fine on all clients tested in 2008. [4]AoV² 01:22, 27 March 2010 (UTC)[reply]

For what it's worth, there's still some places in the software that need cleanup. I did fix relative URLs in interwiki links just recently. Meaning if one day there's a https://en.wikipedia.org/ then the 'es' interwiki link can be '//es.wikipedia.org' for both sites and not require hacking to work right :) ^demon[omg plz] 11:43, 27 March 2010 (UTC)[reply]
We've got lots of SSL issues, by the look of it.wikitech: https://wikitech.wikimedia.org/view/ leads to an ssl site which has issued itself a certificate. Makes me wonder why the interwiki link leads to the https: page instead of http://wikitech.wikimedia.org/view/, which works fine. I've posted a message here, but no one's listening :(. ManishEarthTalkStalk 11:59, 27 March 2010 (UTC)[reply]
Update: Interwiki link fixed, though wikitech SSL still has an invalid certificate. ManishEarthTalkStalk 12:20, 27 March 2010 (UTC)[reply]

Stable Toolserver link breakage

FYI you might notice that a lot of our toolserver links are giving errors right now. It seems the old stable.toolserver.org server was shut down, and apparently no one around here follows the toolserver list or no one bothered to mention it in this forum at least. I'm fixing the links as fast as I can. —TheDJ (talkcontribs) 00:17, 26 March 2010 (UTC)[reply]

I do (ACC), it's just hard to keep track where people put links, WP:ACC was updated a while ago (yes, I'm too lazy to query extlinks). Q T C 00:25, 26 March 2010 (UTC)[reply]
OK, I think i fixed the most important cases now. There are still a lot of transcluded uses in archives, but they don't really matter much. Geohack was the most glaring issue. —TheDJ (talkcontribs) 00:31, 26 March 2010 (UTC)[reply]
My guess is that the largest number of broken links came from the coords-related URL? I mentioned this awhile ago (I think in an IRC channel) and would have fixed it myself, but I've got no superpowers here. Oh well. Though, really, unless there's some issue with redirecting, stable.toolserver.org should still be an alias/redirect/whatever. The intention was to have a stable environment, after all, and it's poor form to needlessly change or break a URI without implementing a redirect. --MZMcBride (talk) 00:33, 26 March 2010 (UTC)[reply]
See JIRA TS-535. Stable GeoHack URL should continue to work per JIRA TS-368 so no fixing is required. However, if your changing them anyway consider the possibly using the new Short URL. — Dispenser 02:21, 26 March 2010 (UTC)[reply]

Upcoming interface changes starting April 5

The usability Beta will be going live very soon. Please read the blogposts foundation and by the techteam. —TheDJ (talkcontribs) 01:27, 26 March 2010 (UTC)[reply]

Oh, noes.  fetchcomms 02:34, 26 March 2010 (UTC)[reply]
Uh oh. VPT-meltdown day approaches. OrangeDog (τε) 12:26, 26 March 2010 (UTC)[reply]
Fasten your seatbelts—it's gonna be a bumpy night! – ukexpat (talk) 19:43, 26 March 2010 (UTC)[reply]

RefToolbar script for new toolbar ready for testing

I was planning on waiting until the weekend, but with the above announcement, I think sooner may be better than later. The current RefToolbar script does not work on the enhanced toolbar created by the Usability Initiative. refToolbar 2.0 is a complete rewrite of the script designed based on the new toolbar and using lessons learned from the old script. Unfortunately, the script was only able to work on Wikimedia sites since about 24 hours ago when the dialog features of the new toolbar were turned back on, so I haven't been able to test it extensively myself, so I could use some brave beta testers to work out any bugs and provide feedback. The new script is more customizable than the old one, though it does not yet support some of the new features added by Apoc2400 in the "refToolbarPlus" script. Please leave any comments, bug reports (making sure to note what browser you are using), and feature requests on the script's talk page. Mr.Z-man 03:17, 26 March 2010 (UTC)[reply]

Volume stuck with OGG

Please see Template talk:Listen#Increasing the width of this box and Template talk:Listen#Volume stuck with OGG. The problems are probably related but not identical. bugzilla:22538 was raised concerning the first, but could an expert check the second issue and maybe expand on the bug description or raise another one? This problem affects Firefox users and in my opinion this requires more than a "Normal enhancement" because it effectively disables the volume control, which I am sure was working before. -84user (talk) 04:36, 26 March 2010 (UTC)[reply]

I think this is a bug in Firefox. See also [5]. —TheDJ (talkcontribs) 12:11, 26 March 2010 (UTC)[reply]

secure.wikimedia.org Proxy Error 502

I'm getting a lot of these over the last three days. I am signing off secure.wikimedia.org and signing in to en.wikipedia.org in order to accomplish anything. Any others with this problem? Is there a better place to determine the status of secure.wikimedia.org? Many thanks, Darrell_Greenwood (talk) 18:43, 26 March 2010 (UTC)[reply]

Me too. It happens when I try to get diffs, edit (it'll make the edit but not return the proper screen), and even when I'm just reading a page. I've had to go to the unsecure server too.RlevseTalk 19:16, 26 March 2010 (UTC)[reply]
Yes, the same for me. It seems to happen with any large page, one that has a lot of data to load. Clearing my browser cache does not help. It seems to have started just after the server failure a few days ago, and is very annoying. Have the secure servers not yet been fully restored? --Tryptofish (talk) 21:02, 26 March 2010 (UTC)[reply]
I concur, it seems to mainly happen on large pages, and the problem started with the failure noted here "Update 21:32 UTC: Our SSL gateway, secure.wikimedia.org, was disabled due to overload issues, but is now back up." Thanks for your comments, as they make it unlikely that the continuing problem is mine. (Parenthetical remark, whilst troubleshooting, I came across a comment that European users can bypass the Amsterdam servers when those servers are down by logging into secure.wikipedia.org because it is in Florida. If enough people are still doing that... overload?) I haven't been able to find a web status indication for secure.wikipedia.org. Darrell_Greenwood (talk) 21:33, 26 March 2010 (UTC)[reply]
OK, but can something be done to fix this now?RlevseTalk 23:59, 26 March 2010 (UTC)[reply]
The problem is continuing for me. I've left a message at User talk:Tim Starling. It's not really clear to me where one can report what appears to be a hardware problem. --Tryptofish (talk) 21:38, 27 March 2010 (UTC)[reply]

In case it helps, here are further details of the 502 error message: Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 PHP/5.2.4-2ubuntu5.7wm1 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at secure.wikimedia.org Port 443. --Tryptofish (talk) 21:49, 27 March 2010 (UTC)[reply]

bugzilla:22982 was opened to track this issue. —TheDJ (talkcontribs) 00:29, 28 March 2010 (UTC)[reply]
Thank you, TheDJ. --Tryptofish (talk) 00:47, 28 March 2010 (UTC)[reply]
Yes, I am getting the same error:
Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /wikipedia/en/w/index.php.

Reason: Error reading from remote server

Apache/2.2.8 (Ubuntu) mod_fastcgi/2.4.6 PHP/5.2.4-2ubuntu5.7wm1 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at secure.wikimedia.org Port 443

--Ancheta Wis (talk) 00:36, 28 March 2010 (UTC)[reply]

Edit box typing line jumps

Hi. I'm not sure when this new error was implemented, but today when I edit, the line that is being typed in automatically jumps to the bottom of the edit box if all the text being edited takes up more space than the height of the box. I do not like this feature, as it is distracting and easy for the editor to get lost. Is there any information avaliable on this recent development in editing? Thanks. ~AH1(TCU) 21:44, 26 March 2010 (UTC)[reply]

  • I've had the same problem. It has slowed in the last couple days and has stoped at present. Have no idea the cause Mlpearc MESSAGE 21:48, 26 March 2010 (UTC)[reply]
Just wanna let you guys know your not the only ones, read abit up under the headline Movement in the text box. --> Halmstad, Charla to moi 22:04, 26 March 2010 (UTC)
Is it the same problem described here: WP:Help desk#Editing window scrolls automatically if certain keys are used? – ukexpat (talk) 22:05, 26 March 2010 (UTC)[reply]
To Ukexpat, yes sounds the same. I reset all default preferences, cleared the browser a couple times, but I, by no means say this solves the problem. Mlpearc MESSAGE 22:16, 26 March 2010 (UTC)[reply]
The problem is apparently currently still apparent. ~AH1(TCU) 00:09, 27 March 2010 (UTC)[reply]
Yep. Definitely still a problem. As I commented in the Help Desk link provided above, it looks like an old problem has come come back. Despite User:Catrope saying "Fixed now", it is still a problem. While I don't have a fix, I do have more information: If you compare this screen capture to one I took a couple of weeks ago, you might notice the newer one has the "broken page icon" in the address bar. Somehow IE8 or Microsoft are convinced Wikipedia pages are now broken and should be viewed in "compatibility mode". I think either the Wikipedia software guys have made a change, or Microsoft have added Wikipedia.org to the compatibility list in C:\Program Files\Internet Explorer\iecompat.dll. Considering that my iecompat.dll dates from 18 Feb 2010 (ver: 8.0.6001.18902) and does not list wikipedia.org amongst the sites, I think this is more likely to be something the Wikipedia software guys have introduced within the past week. Astronaut (talk) 00:34, 28 March 2010 (UTC)[reply]
I wonder... a sitenotice has been running the past few days. perhaps the problem is there ? Then all pages sould have the "broken page icon". If it is just the edit page, then it is likely that the problem is with the code of the usability team. —TheDJ (talkcontribs) 00:39, 28 March 2010 (UTC)[reply]
Sitenotices in that past have not caused this. The annoying cursor jumping only appears in the edit box. As previously described: edit box jumps to put current line at the foot of the scroll region, and when popups would appear the edit box jumps up a few lines so the line with the current cursor position disappears off the bottom of the scroll region. Astronaut (talk) 00:57, 28 March 2010 (UTC)[reply]

I have opened bugzilla:22983 to track this problem —TheDJ (talkcontribs) 00:37, 28 March 2010 (UTC)[reply]

Thanks. Would be great if they could (temporarily) revert whatever was they set out to fix while they come up with another solution - the cursor jumping is getting really annoying (every time I drag the cursor back to the save button, the text box jumps a few lines - especially if I pass over a link that will make POPUPS leap into life). Astronaut (talk) 00:45, 28 March 2010 (UTC)[reply]
Did you check if this was a problem of popups btw (or another gadget of course) ? It's not really actively supported on IE. —TheDJ (talkcontribs) 00:51, 28 March 2010 (UTC)[reply]
I only noticed the possible popups link while typing here. I'll test turning it off, if it will catch up with my typing (is that a new problem with each character taking 0.5 sec to appear). Gahhh! Astronaut (talk) 00:57, 28 March 2010 (UTC)[reply]
Partial success when I turned off popups in my monobook.js (ie. not the gadget in preferences). The random scrolling when popups would appear has stopped, but the scroll region still annoyingly jumps to the last line when inputting text. Not so annoying when contributing to talk pages and such like because you normally add text to the end of a discussion, but a major annoyance when contributing to articles and you want to pop back and forth in the edit box or read the text in the paragraph below the cursor while typing. And I just spotted another thing, a random jump when you delete some selected text in the edit box.
FWIW, I have found popups really useful, particularly when checking history/diffs during anti-vandal work. It is one of the few addons that works with IE and has worked successfully for me for some years.
Oh, the slow typing has fixed itself - probably a temporary problem at my end :-) TBH, I don't see why the "broken page icon" has suddenly appeared. Something has changed very recently to cause these problem to appear. Astronaut (talk) 01:24, 28 March 2010 (UTC)[reply]

Skype formatting - topic reopened

Re-opening the topic mentioned here. Today I noticed a few posts with this from diverse editors so I think we may need the interface to filter out these text:

  • begin_of_the_skype_highlighting
  • end_of_the_skype_highlighting

Example edits:

  • In this one it appears to be in a hidden field so it isn't messing up the visible article but is likely affecting some other aspect of the infobox or other coding.

Looking for others now with AWB.  7  23:07, 26 March 2010 (UTC)[reply]

Two more examples with worse results (formatting ISBNs) [6] and [7]  7  23:16, 26 March 2010 (UTC)[reply]
Ok - I can't run AWB on my current machine but it looks like there are 70+ other occurrences of this out there if someone is willing to take a look.  7  23:24, 26 March 2010 (UTC)[reply]
I just corrected about 20 cases using [8] (not so useful right now as search lags the corrections already made). Sometimes it even appears twice for the same number.[9] --Rumping (talk) 00:38, 27 March 2010 (UTC)[reply]
I think we've gotten them all now - but may still be worth blocking the edits in the interface.  7  13:32, 27 March 2010 (UTC)[reply]
We might want to have an abusefilter looking at this ? Warning people before they save ? —TheDJ (talkcontribs) 00:14, 28 March 2010 (UTC)[reply]
Good idea TheDJ. I suggested it there.  7  02:25, 28 March 2010 (UTC)[reply]

Global file usage

Do we need all those global file usage links at the bottom of commons-hosted files ? This seems like a lot of irrelevant links for readers and most users, and also makes file pages unnecessarily long, while many are already quite long and for navigability images should be as quick as possible to load - then close. The commons description page is linked anyway and we can add a link to Special:Globalusage in MediaWiki:Linkstoimage, which is certainly good enough for curious users. Cenarium (talk) 23:34, 26 March 2010 (UTC)[reply]

Should we file a bug, or not ? Cenarium (talk) 16:33, 27 March 2010 (UTC)[reply]
Can't say that I really see any problem. From what I can tell, it doesn't add significantly to the loading time of the page, since there's a cap on how many instances it shows; see File:Wikipedia-logo.png (very likely the most heavily used image in the WMF system) for an example. As for it making the page longer... so what? Aside from the fact that you can just hit the "end" key to get to the very bottom of any page, the only thing below Global Usage is the Metadata and Categories; the latter doesn't (usually) exist for Commons-only images. The Metadata section being displayed above the "Global file usage" and "File links" sections wouldn't be a bad idea, though... EVula // talk // // 16:48, 27 March 2010 (UTC)[reply]
This is one of the things that the multimedia usability project might look at at some point. There have been ideas to move all history and maintenance stuff like this into the page history file for instance. But it will be a while (if ever) before guillom gets around to that. There are more important issues to solve before he focuses on this. —TheDJ (talkcontribs) 00:12, 28 March 2010 (UTC)[reply]

Allowing users to see where they've logged in from

I think that users should be able to see the IP's that they've recently logged in as. Gmail has it image here. This will enable users to see where they've logged in from in the past and make sure that their account hasn't been hacked. Additionally, Gmail introduced an automatic warning system which warns you if your account was accesses from the other side of the globe, for users who don't check the IP table continuously More info here I don't think it should be hard to implement, a user can be allowed to checkuser himself (Maybe in a limited way, only see last month's IPs). Comments or thoughts? ManishEarthTalkStalk 01:44, 27 March 2010 (UTC)[reply]

Please see wmf:Privacy policyxenotalk 02:32, 27 March 2010 (UTC)[reply]
But privacy to oneself? Thats absurd. You and only you log in to your account, so its OK to make your data available to you. ManishEarthTalkStalk 04:22, 27 March 2010 (UTC)[reply]
I would prefer that WMF keep as little information as possible. And if your statement "You and only you log in to your account" is true, then your proposal is unnecessary. Per Z-Man below, this solution is in search of a problem. –xenotalk 16:54, 27 March 2010 (UTC)[reply]
I think that's a good idea, but still, if someone hacked into another person's account, that person's IP would be known (for example, if Y hacked into X's account, Y can find out what X's IP is). --Hadger 04:27, 27 March 2010 (UTC)[reply]
Then how 'bout we just calculate if the acct was accessed from far away. If the system detects that X logged in from Chicago, and then half an hour later X logs in from London, the system can block X, and tell him to check his email to unblock himself. In his email will be an unblock link. Anyways, if X's account is hacked, he will probably have greater things to worry about... This can also be extended to inactive accounts. If an account is inactive for more than a year, it will be blocked and the user can unblock it thru email. ManishEarthTalkStalk 04:47, 27 March 2010 (UTC)[reply]
The hacker might be your next door neighbour, or your work colleague, or your employee. There is nothing to guarantee that a hacker is going to be far away from you. HumphreyW (talk) 04:52, 27 March 2010 (UTC)[reply]

Something's better than nothing... At the moment we have no protection. Protecting yourself from the 5 billion people who don't live near you is better than not being protected at all. Just hope that the remaining one billion don't try to hack you. ManishEarthTalkStalk 04:57, 27 March 2010 (UTC)[reply]

It would be even better to emailnotifyandblock a user regardless of the time difference. For example, If I edit from a different country, even if I do so after a week, I should be emailnotifiedandblocked. Frequent fliers should be given an option to turn this off except where the time difference is too little (logging in from different hemispheres within half an hour or so). ManishEarthTalkStalk 05:01, 27 March 2010 (UTC)[reply]
No thanks. Using proxies would then get you blocked. Some companies have strange routing setups and you can suddenly be using an IP from thousands of kilometres away without knowing it. And for people that don't register an email address there would be no way to unblock oneself. HumphreyW (talk) 05:17, 27 March 2010 (UTC)[reply]
Reply below ManishEarthTalkStalk 05:47, 27 March 2010 (UTC)[reply]

I've thought of this before. It's a good idea though. Maybe it could be setup on the toolserver and users log in to see their IPs, thus protecting them from others seeing their IPs. Kevin Rutherford (talk) 05:17, 27 March 2010 (UTC)[reply]

It could only protect other from seeing if the toolserver uses SSL connections. HumphreyW (talk) 05:20, 27 March 2010 (UTC)[reply]

Sounds like a solution in search of a problem to me. Mr.Z-man 05:28, 27 March 2010 (UTC)[reply]

Better to be safe than sorry... ManishEarthTalkStalk 05:31, 27 March 2010 (UTC)[reply]
So because I have no protection from ninjas rappelling from my roof and breaking through my 8th floor window, I should run out and put steel bars over my window just in case? Wikipedia accounts almost never get "hacked" because 99.94% of accounts have no special access that a hacker couldn't get just by creating their own account. There is virtually no personal information that can be stolen by hacking into a normal (non-admin) account. No evidence has yet been presented that A) Wikipedia accounts getting hacked is a serious problem and B) The current system for dealing with it (having a checkuser get the information) is failing somehow. Mr.Z-man 16:41, 27 March 2010 (UTC)[reply]

(edit conflict) Good idea. That way a hacker won't come to know your IP unless he logs into toolserver (which he probably won't know about). The tool should have a strict "3 logins per day" thing, though, after which you have to login thru a link in your email. The toolserver should also have a separate password. What about the autoblockandemailunblocklink proposal? ManishEarthTalkStalk 05:31, 27 March 2010 (UTC)[reply]

"autoblockandemailunblocklink" is a a bad idea. See my response above. HumphreyW (talk) 05:40, 27 March 2010 (UTC)[reply]
Oh I didn't see that. Keep it disabled by default. Let users with email enable it (I would), with some options like: "Would you like to autoblock if its accessed from somewhere else, or just recieve a notification", and "I'm changing my location, please do not bother me for the next x days" ManishEarthTalkStalk 05:45, 27 March 2010 (UTC)[reply]
...you lost me at "hackers logging into the toolserver". "lolwut?" was pretty much my reaction. I believe Mr.Z-man had it right: this is a solution in search of a problem. EVula // talk // // 16:55, 27 March 2010 (UTC)[reply]

Cascading protection

Is there a way to add cascading protection to a template, but not to protect its documentation subpage? For example, could noinclude sections be excluded from the protection? — Martin (MSGJ · talk) 11:29, 27 March 2010 (UTC)[reply]

Well, you can put the main contents in a separate template, which is cascadeprotected, then transclude that to the main template page which is protected (non-cascading). Thus the doc stays unprotected. ManishEarthTalkStalk 11:51, 27 March 2010 (UTC)[reply]
I have always thought that the cascade protection does not influence templates that are transcluded inside a <noinclude> block. See {{!}}. Ruslik_Zero 12:33, 27 March 2010 (UTC)[reply]
The page Template:! is not itself cascade protected. It is within the cascade of the main page, but the documentation is obviously not transcluded there. Martin is asking whether it is possible to apply cascading protection to a template page and yet exclude the documentation; the answer to which is no. Manishearth's suggestion is the only viable method. Happymelon 10:49, 28 March 2010 (UTC)[reply]

Not working file redirect

I moved a number of files, but discovered that one of the redirects does not work: File:617044877897062.jpg. I do not know what happened. Ruslik_Zero 12:26, 27 March 2010 (UTC)[reply]

The lonk you've given is a "do not redirect" link which makes sure you won't be redirected when you visit the page. File:617044877897062.jpg should work ManishEarthTalkStalk 12:32, 27 March 2010 (UTC)[reply]
Thanks but I know. It does not work as an image link. See Fanny_and_Alexander. Ruslik_Zero 12:34, 27 March 2010 (UTC)[reply]
Wrong redirect syntax. You should have typed: #REDIRECT [[:File:617044877897062.jpg]] not #REDIRECT [[File:617044877897062.jpg]] (Notice the extra colon). Actually, that should be fixed. There's no reason someone will use #R syntax for a file(without the linking colon) except for a redirect. ManishEarthTalkStalk 12:44, 27 March 2010 (UTC)[reply]
Other redirects work fine. For example File:Enos_Throop.gif. In addition I did not create the redirect as it was created automatically. The system should probably create redirects with colon. Ruslik_Zero 12:49, 27 March 2010 (UTC)[reply]

Maybe because it had no letters and only images? File a bug report. ManishEarthTalkStalk 13:54, 27 March 2010 (UTC)[reply]

Now it works without the colon too. Ruslik_Zero 14:07, 27 March 2010 (UTC)[reply]
This happens sometimes. A purge seems to clear the issue usually. Probably the redirect is accessed before the target has propagated on al the servers. So the server thinks it is a broken redirect and caches that result. —TheDJ (talkcontribs) 00:09, 28 March 2010 (UTC)[reply]

How to list subpages and subdirectories?

Is there any tool or other procedure to view the subdirectories and the subfiles rooted at a given WP page? For example, my page has a section containing a list of links to subpages that I created. How can I list all subpages, including pages other people may have created? David Spector 13:13, 27 March 2010 (UTC)[reply]

See Special:PrefixIndex. Ruslik_Zero 13:14, 27 March 2010 (UTC)[reply]
Indeed - can be transcluded as well: {{Special:PrefixIndex/User:David spector}}. –xenotalk 17:00, 27 March 2010 (UTC)[reply]

Thanks, it works! Gotta love WP: it has everything. David Spector 17:15, 27 March 2010 (UTC)[reply]

To list subpages
addOnloadHook( function () {
  addPortletLink("p-tb", wgServer+wgArticlePath.replace("$1", "Special:PrefixIndex/"+wgPageName+"/"), "Subpages", "t-subpages", "See all subpages of this page");
});
To delete subpages
  • Add {{db-user}} to any of your pages to request deletion.

---— Gadget850 (Ed) talk 09:29, 28 March 2010 (UTC)[reply]

Create protection after page is created?

After deleting a file talk page that had been created for the third time, I salted it indefinitely with semiprotection, because all three creations were by IPs who simply added graffiti. If (for some odd reason) an autoconfirmed editor recreates the page for good reason, will that end the semiprotection, or will non-autoconfirmed editors still be unable to edit the page? I don't see anything discussing the subject at WP:SALT. Nyttend (talk) 14:07, 27 March 2010 (UTC)[reply]

The 'create' protection is separate from edit protection which will be set to allow all users after it is created. –xenotalk 17:03, 27 March 2010 (UTC)[reply]

Consensus building templates

I'd like to draw the community's attention to this Tfd:Wikipedia:Templates_for_discussion/Log/2010_March_27#Template:CB-support2. This concerns some other perennial (although not formally) request. Please post there, to keep the discussion in one place. --JokerXtreme (talk) 17:56, 27 March 2010 (UTC)[reply]

TFD discussion closed as speedy delete per WP:CSD#G4 and Wikipedia:Deletion review/Perennial requests#Template:Support. --BrownHairedGirl (talk) • (contribs) 18:24, 27 March 2010 (UTC)[reply]
I think that G4 does not apply in this case. G4 was probably made with article content in mind. Thiis is just one of the reasons I think it does not apply. I ask you to reconsider as I did in your talkpage. --JokerXtreme (talk)
If it were intended for articles only it would be an "A" criteria. –xenotalk 19:44, 27 March 2010 (UTC)[reply]

Any talk page

Why is it that if you edit a talk page when logged out you can only see the edit box, whilst logged in you can see the whole page? This applies to "edit this page". This is definitely a recent change. IMO for the worst. Simply south (talk) 20:51, 27 March 2010 (UTC)[reply]

Whoa, that is new. I can't imagine that being of any benefit at all. Gavia immer (talk) 21:58, 27 March 2010 (UTC)[reply]

I don't understand the problem description. More info required. screenshots might help. —TheDJ (talkcontribs) 00:05, 28 March 2010 (UTC)[reply]
This is something that can be enabled in preferences, if "Show preview on first edit" (in the "Editing" section) is selected. snigbrook (talk) 01:09, 28 March 2010 (UTC)[reply]

For those who don't know...

Where was the discussion on these changes (a bit ironic eh?) Simply south (talk) 01:14, 28 March 2010 (UTC)[reply]

Possibly an option in your preferences. Take a look at the editing tab and see if the tick is on "Show preview on first edit". Astronaut (talk) 01:32, 28 March 2010 (UTC)[reply]
Okay, possibly it's just so old that I've forgotten there was ever a choice. That's the same as "new", right? Gavia immer (talk) 02:18, 28 March 2010 (UTC)[reply]

Template help - Internet Archive author

Resolved

Could I get some help getting {{Internet Archive author}} working, please. I've based it on {{gutenberg author}}, but when using it find it produces "George_Aaron_Barton" Works by George Aaron Barton at the Internet Archive. rather than the desired link. Example:

Works by or about George Aaron Barton at Internet Archive

contrast with

Works by George Aaron Barton at Project Gutenberg

Thanks --Tagishsimon (talk) 21:07, 27 March 2010 (UTC)[reply]

got it - it just needed the query portion of the link urlencoded. --Ludwigs2 21:51, 27 March 2010 (UTC)[reply]
Thanks, Ludwigs2 - but there's still an issue. Looks like query= is being made into query%3D, which causes it to fail.
Works by or about Jules Verne at Internet Archive
gives a url of
http://www.archive.org/search.php?query%3Dcreator%3A%22Verne_Jules_1828-190%22
which fails. A working URL is:
http://www.archive.org/search.php?query=creator%3A%22Verne_Jules_1828-1905%22
Tagishsimon (talk) 22:08, 27 March 2010 (UTC)[reply]
Sorry, put the URLENCODE in the wrong place. this seems to do it, though it looks like you may need to play with the search term a bit. --Ludwigs2 22:51, 27 March 2010 (UTC)[reply]
Thanks. Will do. --Tagishsimon (talk) 22:56, 27 March 2010 (UTC)[reply]
twiddled with it a bit more - think I go it--Ludwigs2 22:59, 27 March 2010 (UTC)[reply]
That's very promising indeed :) --Tagishsimon (talk) 23:01, 27 March 2010 (UTC)[reply]

Sukhoi/HAL FGFA

Is Sukhoi/HAL FGFA (with a slash) correctly named? If not, what should it be? (There's an article at Sukhoi.) Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:32, 27 March 2010 (UTC)[reply]

Subpages are intentionally disabled in mainspace for this reason (note the lack of a link back to Sukhoi at the top). I don't see any issue with the name being the way it is. --Shirik (Questions or Comments?) 07:42, 28 March 2010 (UTC)[reply]
Depends only upon whether the sources use this name. Cf. Face/Off which is the proper name of a feature film (good) and Trentino-Alto Adige/Südtirol which is nobody′s proper name for anything (bad). ―AoV² 09:31, 28 March 2010 (UTC)[reply]