Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by TheOldJacobite (talk | contribs) at 17:38, 2 October 2011 (→‎Server error: ---Response.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

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

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212


Creating pages with preloaded content

Hi. I asked this at the Help desk yesterday but have gotten no response, so I thought I would ask here. If I need to ask somewhere else, please direct me.

I would like to be able to create a page from a redlink with preloaded content. this section on WP:RFA does it with an input box using the |preload=page parameter, but I would like to do it with a redlink. There are redlinks in Template:NRHP Article Archive and Template:NRHP Picture Archive that users click on to archive new pictures/articles every month. Each month's archive has the same basic formatting: archive header at the top, followed by a search box, followed by a link to the opposite archive (i.e. picture archives link to article archives and vice versa), then an h2 heading, followed by the list. I've successfully moved a lot of this into the two templates above, but when a user clicks on the redlinks, I would like for the resultant pages to preload the template call, as well as the month/year heading seen on all the archive pages in the above templates. Specifically, I would like the new pages to be preloaded with the following content:

Article archives
{{NRHP Article Archive}}

== {{subst:SUBPAGENAME}} ==

Picture archives
{{NRHP Picture Archive}}
AFAIK, it is not (strictly speaking) possible to preload with a redlink. But you could do some fancy template stuff to make it happen if you really want to. — This, that, and the other (talk) 10:14, 26 September 2011 (UTC)[reply]

Language Select

Why is Language select not working? Is it disabled? ~~Ebe123~~ (+) talk
Contribs
10:44, 23 September 2011 (UTC)[reply]

Are you referring to the Language field at Special:Preferences? Please specify which language you try to select, whether you do it there and click Save, and where it is not working. I saw many messages change when I tried German and Danish at Special:Preferences but not everything is translated. PrimeHunter (talk) 17:58, 23 September 2011 (UTC)[reply]
The language selection in Preferences has a large number of selections, but defaults to en. Changing the language does not translate pages; for example, setting en-gb for British English does not change color to colour.
The language selection allows localization for messages. Many system messages that appear in the Wikipedia interface are stored in the MediaWiki namespace. Each of those pages has a version for each language selection. Many of those interface pages do not exist by default or have been heavily customized for the English Wikipedia. Only a very few of the non-en pages have been customized. You can view system messages through Special:AllMessages and select the desired language.
Frankly, I don't see the language selection as very useful. Even if all messages were translated, the article content would be untouched. ---— Gadget850 (Ed) talk 19:09, 23 September 2011 (UTC)[reply]
I'm talking about:
<div class="multilingual">
<div class="lang-en" lang="en">...</div>
<div class="lang-fr" lang="fr">...</div>
</div>

. It is not working. My selected language is English. ~~Ebe123~~ (+) talk
Contribs
20:35, 23 September 2011 (UTC)[reply]

This refers to a feature at meta:Meta:Language select. I haven't heard of it before and don't know how it works. I'm not sure of the point in using it at the English Wikipedia or other wikis for a specific language. PrimeHunter (talk) 22:33, 23 September 2011 (UTC)[reply]
This is implemented in commons:Template:LangSwitch, for instance. It's not useful here. – Adrignola talk 00:15, 24 September 2011 (UTC)[reply]
I know, but it could be useful here too. ~~Ebe123~~ (+) talk
Contribs
10:06, 24 September 2011 (UTC)[reply]
Go to http://te.wikipedia.org/wiki/ప్రత్యేక:గుంపుహక్కులజాబితా and tell me whether Bureaucrats on the Telugu Wikipedia are able to remove administrator rights (a perfectly reasonable question). Now go to http://te.wikipedia.org/wiki/ప్రత్యేక:గుంపుహక్కులజాబితా?uselang=en and tell me the same thing. That's what the language selector is for. Happymelon 11:11, 24 September 2011 (UTC)[reply]
Your Telugu links are for an automatically generated special page called Special:ListGroupRights here. A chosen language for special pages and interface messages can be useful but does the displayed language in these have anything to do with the feature Ebe123 is asking for? I thought Ebe123's feature request was for text written by editors on normal pages. I think editors will rarely bother to write text in multiple languages at a Wikipedia for a specific language, and if the feature exists then there are potential problems such as language-specific vandalism or gross errors that may never be discovered because it's never seen by an editor who knows the language and bothers to fix it. Even with well-meaning editors, it also seems a big work to maintain a page in multiple languages and keep the language versions in sync. PrimeHunter (talk) 13:39, 24 September 2011 (UTC)[reply]
That is why we have Wikipedia in multiple languages, and the interlanguage link feature. If I want to write in English about the city of Oxford, I do it at en:Oxford; if I want to write in French, I do it at fr:Oxford. When editing that French page, the stuff around the edit box is all in French, unless I set my language to English, when some of it gets translated - including, crucially, the "Save page", etc. buttons. These are not always in the same places as on English Wikipedia; the Chinese Wikipedia, for instance, doesn't present the "Save page" button until you have already tried "Show preview". --Redrose64 (talk) 18:07, 24 September 2011 (UTC)[reply]
Precisely; why would you want the English wikipedia to host content in a language other than english? We even have a CSD criterion for such material, IIRC. The interface language selector exists to make it easier to work and edit on wikis in languages that are not your native tongue. Happymelon 17:51, 24 September 2011 (UTC)[reply]

In fairness to the OP, it's more a matter of "that's not how we do that" than "it's not useful/a good idea". Indeed there are pages on en: where it would be useful, I'm thinking, for example, of the "please do not post content in Klingon without translating them first" templates, and maybe pages around intertanslatewiki. Rich Farmbrough, 22:19, 26 September 2011 (UTC).[reply]

Edit summary max length and behaviour

Hello,

I encounter an annoyance and a bug in the English Wikipedia.

The edit summary has a max length a bit too short.

I am typing some text, and I reach the max length. So I select a few characters, and I type the letter "y". This must replace the characters by a "y". This does not. I guess that the culprit is some crappy ayatollesque JavaScript input restriction.

Please improve and correct that. Thanks.

--Nnemo (talk) 21:01, 24 September 2011 (UTC)[reply]

I can confirm this in Firefox 6.0.2 and Chrome 14.0.835.186. Ucucha (talk) 21:04, 24 September 2011 (UTC)[reply]
The maximum length was increased in February 2011 and is unlikely to be increased again. In cases as described above, the workaround is to select the text, then press either "Delete" or the backspace key; and then type in your new text. --Redrose64 (talk) 21:11, 24 September 2011 (UTC)[reply]
Yet why should that workaround be necessary? To be clear, this bug happens when you are at the maximum edit summary length and try to replace a series of characters in the input box with a single character (so you are not going past the maximum length). That ought to be possible. Ucucha (talk) 21:55, 24 September 2011 (UTC)[reply]
Without access to the low-level source I can't be certain, but I might guess that it tries to insert the new text before the old is actually deleted. This is probably a question to ask at MediaWiki, who deal with the user interface. --Redrose64 (talk) 22:01, 24 September 2011 (UTC)[reply]
I suppose so, and in that case the problem is more likely to be in the browser than in MediaWiki. Ucucha (talk) 22:02, 24 September 2011 (UTC)[reply]
Oh no, the problem does not lies in the Web browser, but in the Web site. I had first believed my Web browser was wrong, so I tested him, and he is perfectly innocent.
--Nnemo (talk) 22:41, 24 September 2011 (UTC)[reply]
I'm sorry for the incorrect assumption. Ucucha (talk) 12:46, 25 September 2011 (UTC)[reply]
The code is available at http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/resources/jquery/jquery.byteLimit.js?view=co. The problem is that it doesn't take into account the length of the selected text that will be deleted when checking to see if the new character will fit. It appears that determining the selected range must be done differently on different browsers.
FYI, the maximum length is 250 bytes (not characters) because the underlying database field has a maximum length of 255 bytes; the limit on the edit summary field was formerly lower because an HTML input field's maxlength property works in characters and no javascript was being used to determine the byte length of the characters entered, so it had to be pessimistic. Anomie 04:59, 25 September 2011 (UTC)[reply]
I can confirm this is the intented behaviour: once you reach the limit only special keys (like del or backspace) are accepted. The source that's live now is probably this one; later it was moved to jquery.byteLimit.js (not live yet). I suspect that the code to allow you to paste-then-undo would have to be much more complicated. — AlexSm 04:48, 25 September 2011 (UTC)[reply]
This is bug #29467. You can vote for it if you have an account on Bugzilla. Helder 22:26, 25 September 2011 (UTC)[reply]

Preferences → Gadgets → Allow up to 50 more characters in each of your edit summaries. ---— Gadget850 (Ed) talk 12:13, 25 September 2011 (UTC)[reply]

I've noticed that strange setting. Is there a brief explanation somewhere? How can ticking a box provide room for 50 more characters? Johnuniq (talk) 12:22, 25 September 2011 (UTC)[reply]
I think it has to do with what Anomie said: the hard (database) limit on the size of the field is 255 bytes, but the HTML used to limit the size of the edit summary measured in characters, which may be more than one byte long. Therefore, the standard maximum length of the edit summary is set at 200 instead of 255 to allow some room for multibyte characters. However, with JavaScript it is possible to check not just the character but also the byte count, so it is safe to go up to 250 characters. Ucucha (talk) 12:46, 25 September 2011 (UTC)[reply]
Yes. I dug up the discussion at Wikipedia:Gadget/proposals/Archive 2#Long edit summaries.
That gadget has had no effect since the rollout of MediaWiki 1.17 in February 2011 - whether it's set "on" or "off", the limit is always 250 chars. --Redrose64 (talk) 13:18, 25 September 2011 (UTC)[reply]

Is this *ever* going to be fixed?

I find it incredible that a massive and popular site like Wikipedia still suffers from this stupid bug whereby stale pages are regularly shown and/or pages are incorrectly shown as uneditable until one adds that stupid "?action=purge" thing to the URL. What a total load of nonsense. There is even a page somewhere I think that explains this "purging" crud as if it was some kind of a beneficial feature rather than a ridiculous bug that should have been fixed years ago.

The usual disclaimers that I know WP is free, built mostly by volunteers, etc., etc., all apply, so there is no need to trot all that out. Just someone PLEASE fix it!!! 109.151.36.98 (talk) 00:30, 25 September 2011 (UTC)[reply]

It appears nobody filed a bugzilla request after my above post at #Article appears protected when it isn't. I will probably file one next week when I have more time if it hasn't been done by then, but I don't know how hard it would be to solve the problem. By the way, the purge function is old, has other uses and was not created to fix instances of this problem but is able to do it. PrimeHunter (talk) 00:44, 25 September 2011 (UTC)[reply]
(That section link is now WP:Village pump (technical)/Archive 93#Article appears protected when it isn't.) --142.205.241.254 (talk) 22:27, 26 September 2011 (UTC)[reply]

Who can fix a table?

I am reworking some lists and would like to have two tables on the page look alike. The top one, at User:GeorgeLouis/Sandbox3#1889.E2.80.931909_.28nine_wards.29, should look like the bottom one, at User:GeorgeLouis/Sandbox3#1925_and_after_.28fifteen_districts.29. In other words the "wards" table should have the names aligned at the top of the columns instead of being repeated, as they are now. Who can assist? Beseechingly, I am GeorgeLouis (talk) 07:52, 25 September 2011 (UTC)[reply]

 Done -- John of Reading (talk) 10:51, 25 September 2011 (UTC)[reply]

Edit link on sections doesn't appear

Resolved

Hi, in this project page the "Edit section" link doesn't appear as it should. Can't figure out why. Also the TOC didn't appear automatically as it should then I forced it with the "_TOC_". Anyone knows why is this happening? --Tachfin (talk) 11:42, 25 September 2011 (UTC)[reply]

Wikipedia:WikiProject Morocco/Tabs includes __NOTOC__. There is probably a template that includes __NOEDITSECTION__ ---— Gadget850 (Ed) talk 11:59, 25 September 2011 (UTC)[reply]
The problem seems to be in the templates placed at the top in fact. When I remove them the "edit section" link appears. I suspected that before and tried to solve the problem with <noinclude> but didn't work. I verified the templates they don't include the _NOEDITSECTION_ Tachfin (talk) 12:23, 25 September 2011 (UTC)[reply]
Special:ExpandTemplates is your friend. It turns out that the project page is transcluding Template:Box-header about four levels deep, which puts __NOTOC__ and __NOEDITSECTION__ on the page. I'll try to fix it. Ucucha (talk) 12:51, 25 September 2011 (UTC)[reply]
Yes that seems to be the source of the problem. From template:Box-header, what does this do "{{#if: {{{TOC|}}} | |__NOTOC__}}{{#if: {{{EDIT|}}} | |__NOEDITSECTION__}}"? Tachfin (talk) 13:02, 25 September 2011 (UTC)[reply]
It sets __NOTOC__ if the |TOC= parameter is not set, and does the analogous thing for |edit=. Ucucha (talk) 13:05, 25 September 2011 (UTC)[reply]
Your edit worked I restored them. I changed the template transcluded on projects page before I guess that's why you reverted your edit...Thank you! Tachfin (talk) 13:17, 25 September 2011 (UTC)[reply]

bits.wikimedia.org

In particular http://bits.wikimedia.org/meta.wikimedia.org/load.php?debug=false&lang=en&modules=jquery%7Cmediawiki&only=scripts&skin=monobook&version=20110912T172820Z:1 - this page (or bits in general) takes a load of downloading (32k, apparently with every WP page) and often stalls the browser trying to execute. What's it supposed to be doing, and how can I turn it off. (Incidentally I'm not terrifically happy with cross-site scripting, even if it is in the same second level domain.) Rich Farmbrough, 15:21, 25 September 2011 (UTC).[reply]

It's all the javascript for jQuery, the core mediawiki script loader, and the scripts for the monobook skin. It's not downloading every page request, because your browser will cache it (unless your browser is stupid/broken). It is the basis for all javascript execution on wikipedia pages. It cannot be disabled, other than by fully disabling Javascript for the entire website I think. The reason it is on a different server is actually that it has an entirely different caching architecture. —TheDJ (talkcontribs) 16:17, 25 September 2011 (UTC)[reply]
(The caching is Varnish rather than Squid (I believe) for anyone interested.) It may be two distinct issues, then. One is that the script is not "responding" according to Firefox, basically it's some sort of resource hog. Secondly I certainly see "waiting for bits.wikimedia.org" regularly when I open a page. Rich Farmbrough, 23:16, 25 September 2011 (UTC).[reply]
Must say I get the same thing and the loading stops for ages at that point. Keith D (talk) 23:54, 25 September 2011 (UTC)[reply]
Digging a little more, I notice a couple of anomalies. Firstly it also calls for the Chick/main.css. Secondly each of the connections (5 to bits, 2 to text and 1 to wikimedia-lb (all at esams.wikimedia.org)) was closed with a RST, which seems most odd. Rich Farmbrough, 01:27, 26 September 2011 (UTC).[reply]

Javascript help

I have tried to narrow down the problem, to no avail. Just to note, I am not that experienced with Javascript, but I cannot for the life of me tell what is wrong with my addtool.js script. Any help with the javascript code I have used would be greatly appreciated.

P.s. I think I may know one or two possible reasons for the problem, but I can't exactly figure it out. LikeLakers2 (talk | Sign my guestbook!) 22:50, 25 September 2011 (UTC)[reply]

Could you tell us what the script is supposed to do and what is going wrong? That makes it a lot easier to debug. In looking over your code, it seems as if you're using rather more code, especially more functions, than you really need. It looks like you could do pretty much all the processing you do with a few switches and variable assignments. Ucucha (talk) 23:28, 25 September 2011 (UTC)[reply]
It is basically a easy toolbox tool adder. This code:
addtool("tb","javascript:Asteroids()","Play Asteroids2","ca-testtool-tb","Test tool");
Is supposed to work the same as:
addPortletLink("p-tb", "javascript:Asteroids()", "Play Asteroids2", "ca-testtool-tb", "Test tool", "");
But apparently, something in the code is making MediaWiki not want to do that. I don't know what it is that is causing it. LikeLakers2 (talk | Sign my guestbook!) 23:39, 25 September 2011 (UTC)[reply]
Also, the functions are basically to split it into parts. LikeLakers2 (talk | Sign my guestbook!) 23:39, 25 September 2011 (UTC)[reply]
Sometimes splitting code into parts isn't a good idea—here, it makes the code only less readable to me.
Running this code in Firebug tells me that "addtool2 is not defined". So, the reason your code isn't executing is presumably that you're using an object "addtool2" that doesn't exist. Ucucha (talk) 23:52, 25 September 2011 (UTC)[reply]
So it would have been better as step2(), step3(), etc.? That seems to be what you are saying. LikeLakers2 (talk | Sign my guestbook!) 23:58, 25 September 2011 (UTC)[reply]
That might make it work, yes. It wouldn't be very good coding, though. Ucucha (talk) 00:02, 26 September 2011 (UTC)[reply]
Having undone the edit I thought was related to what you said, as seen here, it still doesn't seem to work, apparently. Mind rerunning it through FireBug, but with the current code? LikeLakers2 (talk | Sign my guestbook!) 00:04, 26 September 2011 (UTC)[reply]
Firebug doesn't return any errors, which means it parses correctly. However, when I make it execute addtool(), it still complains about addtool2 not being defined; I guess I have it cached somewhere. Ucucha (talk) 00:23, 26 September 2011 (UTC)[reply]
After figuring out that Internet Explorer already has a javascript debugger, I've finally figured it out. I apparently need to wrap the addtool functions around in a onloadhook function, like so:
addOnloadHook(function(){
addtool("tb","javascript:Asteroids()","Play Asteroids2","ca-testtool-tb","Test tool");
});
That apparently makes it work. LikeLakers2 (talk | Sign my guestbook!) 00:26, 26 September 2011 (UTC)[reply]

Broken Flag Box

Can anyone determine what is the bug when you put the Northern Mariana Islands into this user box?

This user has visited Northern Mariana Islands.

There is a flag icon present, as an SVG but the box doesnt link to it. This is the only region I've had trouble creating the userbox. Thank you! -OberRanks (talk) 04:37, 26 September 2011 (UTC)[reply]

The flag SVG is File:Flag of the Northern Mariana Islands.svg; see the following. It uses a redirect, but the flag shows. --Stemonitis (talk) 07:48, 26 September 2011 (UTC)[reply]
This user has visited the Northern Mariana Islands.
I have added the flag name to the userbox [1] so both versions display the flag now. PrimeHunter (talk) 10:18, 26 September 2011 (UTC)[reply]
Thank you very much! I was starting up a Travel Log for my user page and this was the last box to add. It looks great! -OberRanks (talk) 16:09, 26 September 2011 (UTC)[reply]
Resolved
 – Redrose64 (talk) 17:49, 26 September 2011 (UTC)[reply]

As I often do on school IP pages with a history of vandalism, I attempted to collapse the bulk of the previous warnings and block notices as they clutter the page. The idea being that students will see the notice to create an account at home and use it to edit at school. Anyway, for some reason in this instance it seems to have made a complete copy of all the notices and placed them inside the collapsed area, adding to the clutter instead of reducing it. What's up with that and how can it be fixed? Beeblebrox (talk) 16:51, 26 September 2011 (UTC)[reply]

 Fixed, see here, also Wikipedia:WikiProject user warnings/Usage and layout#Archiving warnings for anonymous users. --Redrose64 (talk) 17:49, 26 September 2011 (UTC)[reply]
Oh, cool. Actually I've seen that before but never used it myself. Still curious as to why normal collapsing didn't work, but thanks for the fix! Beeblebrox (talk) 17:57, 26 September 2011 (UTC)[reply]
I think that there is an imbalance between opening <div> and closing </div>. Kralizec! (talk · contribs) issued a {{subst:uw-vblock}} at 16:18, 4 November 2008, and that template begins with an opening <div class="user-block"> then a Image:Stop x nuvola with clock.svg; if I add a second opening <div> immediately before those, your version seems to work. To be certain I would need to analyse the page properly; ideally I would then check the various warning templates against their originals to see if one of them has a <div>...</div> imbalance. --Redrose64 (talk) 19:27, 26 September 2011 (UTC)[reply]

Weird new look?

The editing box just changed its look-the buttons are now above where the used to be and I don't have my special toolbar anymore. Also, the search box's font is larger and changed. What just happened? Also, the toolbar functionality is horrible and I don't have a reference button anymore. How do I switch back? HurricaneFan25 17:07, 26 September 2011 (UTC)[reply]

Me too. Cite and link options vanished in the blink of an eye. As I type this, the "Page notice" at the top repeats itself. I have Firefox 3.6.22 with Windows XP. Maile66 (talk) 17:16, 26 September 2011 (UTC)[reply]
Also, on Google Chrome, there are no 'show' tags in the WikiProject boxes... – Plarem (User talk contribs) 17:25, 26 September 2011 (UTC)[reply]
Me also (Firefox). I have the clock gadget for refreshing pages, and that appears only on my watchlist but not anywhere I want to edit. I suspect some incomplete software update is happening, and isn't finished, so that some functionality is lost. This happened a few days ago too, then went back to normal. --Tryptofish (talk) 17:29, 26 September 2011 (UTC)[reply]
For me, it went back to normal just as I saved the comment above. --Tryptofish (talk) 17:30, 26 September 2011 (UTC)[reply]
Mine just went back to normal, too. System must have hiccuped. Maile66 (talk) 17:31, 26 September 2011 (UTC)[reply]
Mine still looks like the time I changed it to monobook. I am using Firefox 3 on a MacBook Air. HurricaneFan25 17:33, 26 September 2011 (UTC)[reply]

See #What's going on with the servers?, below, for what is probably the answer. --Tryptofish (talk) 00:04, 27 September 2011 (UTC)[reply]

Templates not transcluding at Barack Obama

(Please see Talk:Barack Obama#Templates) Transclusion of the final thirteen templates at Barack Obama has failed and, instead, regular links to the templates are being displayed. What could be causing this? Thank you, -- Black Falcon (talk) 17:13, 26 September 2011 (UTC)[reply]

Probably Wikipedia:Template limits—the page is transcluding too many and too large templates. Ucucha (talk) 17:21, 26 September 2011 (UTC)[reply]
Specifically, it's the post-expand include size:
NewPP limit report
Preprocessor node count: 282439/1000000
Post-expand include size: 2048000/2048000 bytes
Template argument size: 879412/2048000 bytes
Expensive parser function count: 24/500
(Those numbers are in the HTML source of the page.) Ucucha (talk) 17:22, 26 September 2011 (UTC)[reply]
Thank you, that clarifies the cause of the problem. I noticed, too, that the article now appears in Category:Pages where template include size is exceeded. Can anything, other than removing a few templates from the article (possible but not ideal), be done to correct this? -- Black Falcon (talk) 23:48, 26 September 2011 (UTC)[reply]
It's either that or making the templates smaller. {{Navbox}} and its subtemplates, for example, are huge and could perhaps be streamlined. Ucucha (talk) 23:54, 26 September 2011 (UTC)[reply]

I have offered a possible fix at Talk:Barack Obama#Templates), which reduces the template processing counts to:

NewPP limit report
Preprocessor node count: 205464/1000000
Post-expand include size: 1572569/2048000 bytes
Template argument size: 673222/2048000 bytes
Expensive parser function count: 10/500

As this fix may cause problems in future maintenance, I have not implemented it immediately, but described it on Talk:Barack Obama#Templates, so that editors there can decide what they want to do.

--NSH001 (talk) 15:50, 2 October 2011 (UTC)[reply]

Wikipedia is a phising site?

So when I try and log in at English Wikipedia, I get this message in the log in screen:

You are viewing this page on //en.wikipedia.org, which might be a proxy or phishing site. This site can intercept your password; you are strongly advised to log in from en.wikipedia.org.

So, I logged in at Meta. Is this something new or a problem with me? My IP hasn't changed (this didn't occur yesterday or when I logged in my alternate account earlier today) and I haven't reconfigured any settings. Elockid (Talk) 20:17, 26 September 2011 (UTC)[reply]

What browser are you using? I wonder whether this might be related in some way to protocol-relative URLs. Ucucha (talk) 20:23, 26 September 2011 (UTC)[reply]
I tried it on Firefox (6.0.2) and Chrome (14.0.835.186). Elockid (Talk) 20:26, 26 September 2011 (UTC)[reply]
I am experiencing the same issue with Firefox 6.0.2. The secure site login is fine. mc10 (t/c) 20:31, 26 September 2011 (UTC)[reply]
I experienced this same issue. I was logging in from the login screen, and got this message in a red box:

You are viewing this page on //en.wikipedia.org, which might be a proxy or phishing site. This site can intercept your password; you are strongly advised to log in from en.wikipedia.org.

-download ׀ talk 20:29, 26 September 2011 (UTC)[reply]
Was logging in from [2] with Firefox 6.0. -download ׀ talk 20:30, 26 September 2011 (UTC)[reply]
See the thread directly above this. Killiondude (talk) 20:31, 26 September 2011 (UTC)[reply]
I get the same message. It's apparently made by MediaWiki:Loginend because {{SERVERNAME}} currently returns //en.wikipedia.org and not en.wikipedia.org. At the time this page is rendered, {{SERVERNAME}} returns en.wikipedia.org. PrimeHunter (talk) 20:32, 26 September 2011 (UTC)[reply]
I see. Thanks for the info. So, nothing to worry about then? Elockid (Talk) 20:38, 26 September 2011 (UTC)[reply]
No. This edit by WOSlinker (I was about to do the same thing) should fix the issue. Ucucha (talk) 20:40, 26 September 2011 (UTC)[reply]
This may be related to the impending MediaWiki 1.18 rollout. One of the new features is that omitting the http: from a full URL will detect whether you're coming from the normal server or the secure server, and adjust the URL accordingly. See mw:MediaWiki 1.18#Protocol-relative URLs. --Redrose64 (talk) 20:40, 26 September 2011 (UTC)[reply]
Thanks guys for the quick responses. Elockid (Talk) 20:41, 26 September 2011 (UTC)[reply]
Confirm it is fixed now. Thanks all. Geoff Who, me? 21:29, 26 September 2011 (UTC)[reply]
Reported in bugzilla:31176. 62.140.137.139 (talk) 23:14, 26 September 2011 (UTC)[reply]
{{SERVERNAME}} has been fixed. It returns en.wikipedia.org at the time of writing, as it should. It returns en.wikipedia.org at the time of rendering.
But I think there is still an issue with {{SERVER}}. At the time of writing it returns //en.wikipedia.org. At the time of rendering it returns //en.wikipedia.org. As far as I know it returned http://en.wikipedia.org before yesterday and is supposed to return that. I haven't found a way to search for instances of "{{SERVER}}" so I don't know whether this change affects the English Wikipedia. If you think you know a search method that would catch {{SERVER}} but it doesn't find any occurrence then try whether the method can find the old known occurrence of {{SERVERNAME}} at MediaWiki:Loginend. PrimeHunter (talk) 14:29, 27 September 2011 (UTC)[reply]
You should read the first comment of the bug report. "{{SERVER}} which is supposed to output the protocol and host)" the protocol is now protocol relative, so correctly returning //en.wikipedia.org, which indeed is different from before, nevertheless correct and expected behavior. —TheDJ (talkcontribs) 22:28, 27 September 2011 (UTC)[reply]
Thanks for the explanation. PrimeHunter (talk) 23:59, 27 September 2011 (UTC)[reply]

What's going on with the servers?

I keep getting messages today that the servers are having technical problems. The info at the bottom of the message is of the following sort (from the most recent time I got this):

Request: GET http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical), from 208.80.152.71 via sq65.wikimedia.org (squid/2.7.STABLE9) to () Error: ERR_CANNOT_FORWARD, errno (11) Resource temporarily unavailable at Mon, 26 Sep 2011 22:48:41 GMT

What's going on? LadyofShalott 22:54, 26 September 2011 (UTC)[reply]

They are preparing the databases for the 1.18 upgrade. For this they need to switch around something with the master databases. Two of these switches failed and took everything down for a few minutes. Earlier today there was another problem, where someone accidentally unplugged an entire rack of Apache servers :D (source #wikimedia-tech and the server admin log ) —TheDJ (talkcontribs) 23:01, 26 September 2011 (UTC)[reply]
Thanks. Any idea when things will be back to normal... save for random tripping over plugs? LadyofShalott 23:10, 26 September 2011 (UTC)[reply]
The final stage of the MW 1.18 rollout is scheduled for Tuesday, October 4, and things will probably settle down within a day or so thereafter. ~ 14:19, 27 September 2011 (UTC)

"edit toolbar" vs "enhanced editing toolbar"... slowness of the enhanced toolbar

There are two editing toolbar that are selectable under the "editing" tab in preferences. It seems like selecting the enhanced toolbar overrides the "edit toolbar". This is a little confusing when both are selected and you unselect the "edit toolbar" and nothing changes.

Also, the "enhanced toolbar" loads unacceptably slow under Firefox 3.6.22. It takes as long as 5 seconds sometime. Any edits made before the page finishes loading, and sometimes you forget to wait, are lost. (Firefox 3.6 is not an obsolete browser so I'm preemptively saying so.) It interferes with editing. This is on a very fast machine running Ubuntu 10.04 LTS fully patched. This problem has existed since Vector was launched. Maybe it's gotten worse but I don't know. I've a"sucked it up" until now but I have to complain about it. Jason Quinn (talk) 23:21, 26 September 2011 (UTC)[reply]

Per comments on bug 27620, this slowness is because bug 27488 is still not fixed. You can vote for it!
See also the links provided on mw:Thread:Talk:ResourceLoader/Version_2_Design_Specification/Top-loaded_site_scripts. Helder 00:52, 27 September 2011 (UTC)[reply]
There is no need to vote on it. That bug is added to the RL 2.0 project which means it will be taken care of by the time RL 2.0 is ready, which is a high-priority project on itself. The order in which the specification items are done is not really of importance here since it will be deployed as a whole anyway. Right now the RL2.0 developers (including me) are working on the new and improved gadget repositories allowing shared gadgets and a nice visual gadget manager. The next thing is likely going to be the research into top loading and changing the loader system from a "top/bottom" separation (where "top" is a list of blocking loads in the <head> and "bottom" is a list of async/simultaneous loads in the bottom of "<body>"), to a system with "head/other", where "head" is a list of blocking loads in the <head> and "other" queue starts loading asynchronously as soon as the <body> tag opens and is executed right away or on document ready (decided by the module).
The most notable change is that instead of starting to download after the document is ready and then executing it, it will download simultaneously while the body contents are downloaded as well and executed right away as soon as the bottom is reached (instead of starting the download when the bottom of the body is reached). Krinkle (talk) 16:59, 27 September 2011 (UTC)[reply]
Wow! Thanks, Helder. After I wrote my comment, I thought that perhaps my comment is too vague for anything to be done about it or for other editors to know what I meant. I regretted posting it. But... your reply was just about exactly what I was looking for without even knowing what answer I hoped to get! I know now that's it's a known issue and where to watch to follow any updates. Thanks a lot! Jason Quinn (talk) 15:25, 27 September 2011 (UTC)[reply]

This gadget no longer works; see #Edit summary max length and behaviour above, and try the gadget out for yourself - it makes no difference.

Could an admin please delete these two pages and remove the gadget's entry from MediaWiki:Gadgets-definition (second entry under "editing" section)? There is no need to fool users into believing they can obtain longer edit summaries when they in fact cannot. — This, that, and the other (talk) 03:51, 27 September 2011 (UTC)[reply]

Done. Ucucha (talk) 11:28, 27 September 2011 (UTC)[reply]
There is no need to delete MediaWiki:Gadget-LongEditSummaries and MediaWiki:Gadget-LongEditSummaries.js. Can you please undelete those so that the code can still be seen by others ? The existance of those pages alone doesn't have any influence on the Gadgets system. Assuming you want someone to be able to fix/redo that script... Krinkle (talk) 17:06, 27 September 2011 (UTC)[reply]

Insert Link target icon on toolbar

Another hiccup in the system, I think. On the Edit toolbar, there is an icon for Insert. "To a wiki page" and "To an external web page" are at the bottom when you use this icon. Normally, if you copy a Wikipedia URL and paste it there, a secondary box will pop up and ask you if you want an Internal or External link. Indicating Internal will give you a link like this: National Register of Historic Places listings in Shelby County, Tennessee. As of today, if you do that, the box does not pop up asking you what kind of link. So, you pre-select wiki page button at the bottom, and you get this: [Register of Historic Places listings in Shelby County, Tennessee]. Sometimes the copy and paste is preferable to typing in a name, just to insert a link. What's different today in how it works? Maile66 (talk) 15:43, 27 September 2011 (UTC)[reply]

Gadgets

Where do I find out who maintains the gadget "Adds two new dropdown boxes below the edit summary box, with some useful default summaries"? It does not input a logical summary when you use a minor edit summary. Thanks--Gilderien Talk|Contribs 19:48, 27 September 2011 (UTC)[reply]

Start on Special:Gadgets, look for description above, find MediaWiki:Gadget-defaultsummaries.js, check history. — AlexSm 20:08, 27 September 2011 (UTC)[reply]

Template Question, time since last edit

Is it possible to have a template add a page to a category based on how long it has been since the page was edited? For example, if the template is placed on a page at the time of page creation, would it be technically possible for it to add the page to a category 30 or 90 days after the last edit to the page by anyone? If so, will the category addition occur even if no one ever again accesses the page, or would the cached version, with no category, remain until the first time it was accessed after the timer ran out? Monty845 23:56, 27 September 2011 (UTC)[reply]

Yes, I think this could be done using two of the magic words, {{REVISIONTIMESTAMP}} and {{CURRENTTIMESTAMP}}. But the software would not realise that the page needed to be re-built and re-categorised after N days, so the idea wouldn't work especially well. Also, depending on what you were hoping to use the template for, the scheme might be broken by an automated/semi-automated "gnome" edit that didn't affect the part of the page you had in mind. -- John of Reading (talk) 11:54, 28 September 2011 (UTC)[reply]
Thanks for the reply, the lack of re automated rebuilding would stop the idea from working, which is what I feared. Monty845 18:59, 28 September 2011 (UTC)[reply]
You could employ a bot to make null edits on those pages every day, I know we have such a bot in my home wiki. — AlexSm 20:03, 28 September 2011 (UTC)[reply]
This kind of bot has been proposed before and rejected. There is a reason the software works in the way it does, using null-edits to force updates is not the correct way to go about things. - Kingpin13 (talk) 20:20, 28 September 2011 (UTC)[reply]
You shouldn't need null edits for this - I recently added this exact feature to create Category:Stale Userspace drafts - and the category filled up with 12k pages in no time. Avicennasis @ 14:34, 1 Tishrei 5772 / 14:34, 29 September 2011 (UTC)[reply]
Your edit to {{Userspace draft}} made the software re-cache all the pages using that template. Going forwards I think you will have to make a monthly edit to the template to make the software rethink the categories for each draft. -- John of Reading (talk) 15:39, 29 September 2011 (UTC)[reply]

Is it possible to remove automatic new line after image using template:wide image?

Why?
"
Planets and dwarf planets of the Solar System. Sizes are to scale, but relative distances from the Sun are not.
The above image is taken from Wikipedia's entry on the Solar System, and I'll give you five seconds to point out as many flaws as you can. All done? Where do we start? Clearly our sun is dying, its once-dazzling surface now an ember, and there's some other star, several times larger / closer / brighter than our own sun, tucked just out of view in the upper right frame. To be honest, I find that kind of geocentrist shading interesting more than anything else, but it's not what we're here to discuss. Similarly, I'm going to ignore the presence of "dwarf planets", which everyone knows is a concession by International Astronomical Union to keep Arizona happy. No, I'm talking about the fact the planets seem to be breathing down one another's necks, Jupiter within fist-bumping distance of Mars, the asteroid belt apparently slipped from the gaunt hips of our emaciated sun. Now, there's a very good reason that the planets are often presented squished up together like this: it's because black ink is really expensive. Given the choice between illustrating planets as pixel-sized dots on a single page, or going all-in on a 30 page wide fold-out showing planets in all their glory and scale, most artists prefer to cut out all that "empty" space and bring celestial bodies into frame. It's an obvious design solution, but one that nevertheless impacts upon the public's understanding of astronomy. Even though the Wikipedia page makes pains to point out that the scale in this image has been messed about, the industry-wide practice of moving planets about trickles down into public consciousness." From Five iconic science images, and why they're wrong

Template:Wide image is unusable with multiple images (see User:Bulwersator/test2) User:Bulwersator/test is better but it is ugly and results in wiiiiiideeeeee page (pl:User:Bulwersator/test is only ugly). Is it possible to remove automatic new line after image using template:wide image? Bulwersator (talk) 07:24, 28 September 2011 (UTC)[reply]

That template is not intended for multiple images. You want something like {{Multiple image}}. ---— Gadget850 (Ed) talk 10:54, 28 September 2011 (UTC)[reply]

edits not showing up

Hi,

I am trying to update the page for my organisation which is rather badly out of date.

I've made the updates, and clicked Save, but now I visit the page, twenty minutes later, the old version of it has come up.

How do I get my edits to last?

James Murphy Director of Communications National Youth Orchestra

Page in question: http://en.wikipedia.org/wiki/National_Youth_Orchestra_of_Great_Britain — Preceding unsigned comment added by NationalYouth Orchestra (talkcontribs) 09:48, 28 September 2011 (UTC)[reply]

Your addition was automatically reverted.[3] You have other issues and I am taking them to your talk page. ---— Gadget850 (Ed) talk 10:42, 28 September 2011 (UTC)[reply]

"Decent Article" symbols for iw links

What is the current standard for adding little status symbols for iw links? FA and GA symbols are added, how about the "decent article" status that's used in da, fi and sv Wikipedias. The status equals roughly the B quality in here, being a status with more relaxed standards and more casual promotion process than GA or FA. Pitke (talk) 14:11, 28 September 2011 (UTC)[reply]

Just worked this out. You are referring to the {{link GA}} and {{link FA}} templates which put and symbols on the left of the "languages" list (or, if in MonoBook skin, the templates which amend the style of the bullets in the same list), as seen against "Deutsch" and "Español", etc. on Vietnam war. This seems to be done via css; the effect of {{link FA|es}} is to add an empty HTML element: <span id="interwiki-es-fa"></span> so I personally can't do anything to add the equivalent for this class (which seems to be exclusive to the Danish, Finnish and Swedish Wikipedias). --Redrose64 (talk) 19:36, 29 September 2011 (UTC)[reply]
Ok, thanks. All that remains is to probe whether such symbols would be welcome in a wiki that doesn't use the classification itself. Kinda. Pitke (talk) 10:39, 30 September 2011 (UTC)[reply]
Have found in MediaWiki:Common.js that there is function LinkFA() - this seems to be highly relevant here. At the top of that function there is a note that it's maintained by R. Koot (talk · contribs), so you could try contacting him. --Redrose64 (talk) 23:33, 1 October 2011 (UTC)[reply]

there is no attribute "class"

The W3C Markup Validation Service is giving this error on every page:

<poem<

there is no attribute "class"

<html lang="en" dir="ltr" class="client-nojs" xmlns="http://www.w3.org/1999/xhtml"...

</poem>

I am guessing this is part of the RTL/LTR updates? ---— Gadget850 (Ed) talk 21:03, 28 September 2011 (UTC)[reply]

It looks like our DOCTYPE doesn't allow a class on the html element. The following also generates an error in the validator:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html class="foo" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Title</title>
</head>
<body>
<p>Text</p>
</body>
</html>
(The DOCTYPE is copied from Wikipedia.) Possibly recent changes to MediaWiki introduced a class for the html element. Ucucha (talk) 21:22, 28 September 2011 (UTC)[reply]
I didn't think you could have a class= on the <html> - after all, the CSS files are brought in during the <head>...</head> (in our case, with the <link /> elements), which hasn't been parsed yet. --Redrose64 (talk) 21:31, 28 September 2011 (UTC)[reply]
I don't see class listed as an attribute for <html>.[4] ---— Gadget850 (Ed) talk 23:43, 28 September 2011 (UTC)[reply]
See bug 30497. Reach Out to the Truth 00:34, 29 September 2011 (UTC)[reply]
Hi, I'm the developer who created that patch. There's no technical reason why you can't have a class tag on the <html> tag, CSS is applied to all elements, no matter what their position. I wasn't aware that it would cause a failure in validation, so I'm happy to fix it so that it will be applied to <body> instead. Johnduhart (talk) 01:15, 29 September 2011 (UTC)[reply]

large numbers are rendered differently by various servers, leading to number formatting errors.

Large numbers, such as 82000000 are getting rendered as 8.2E+7 by some server (srv*) and as 82000000 by others (wm*). The 8.2E+7 notation causes templates that format numbers (such as {{val}}) to fail and pages using these templates to be rendered incorrectly. It seems obvious that all server should return the same results in order to be able to create reliable rendering of large numbers. Assuming there is no use case for 8.2E+7 notation, I'd like to get all servers to return 82000000 when you type 82000000.

To test this, you can install this Chrome extension I created: it takes the name of the server that rendered each Wikipedia page from the comments inside the HTML and makes it visible at the bottom of the page. Alternatively, you can use view-source to see this information manually. Then try refreshing this page to see how the below test is rendered by various servers:

{{#expr:82000000}} = 82000000

Any help in tracking down people that can help resolve this is appreciated.     SkyLined (talk) 21:55, 28 September 2011 (UTC)[reply]

NB: I just found that not all srv* server render it as 8.2E+7: some do, some don't.    SkyLined (talk) 21:57, 28 September 2011 (UTC)[reply]
This is a known issue, I believe; some of the servers are configured differently than others, and this causes some math operations to return different values depending on the server. Ucucha (talk) 00:43, 29 September 2011 (UTC)[reply]
This is, AFAIK, ultimately down to features of the operating system and hardware, since MediaWiki uses PHP maths functions, PHP uses the system's native C functions, and the C functions use direct OS/assembler-level maths. Some of the modern servers are 64-bit architecture while the older ones are 32-bit, which probably makes a substantial difference. Essentially not something which is likely to be resolved. Happymelon 20:57, 29 September 2011 (UTC)[reply]
A long time ago (three years ago, or some such), I recall being told that many changes like this would go away once all the servers were updated to run the same version of PHP, which apparently wasn't the case at the time. Is there any way to tell which version(s) of the infrastructure software are being run currently? Dragons flight (talk) 21:30, 29 September 2011 (UTC)[reply]
If you want faster/consistent servers, visit foundation:Fundraising. --Redrose64 (talk) 21:27, 29 September 2011 (UTC)[reply]
Helpful, Redrose, except for the complete and utter absence of any analysis of a connection between a lack of funding for servers and the issue under discussion. Is there a bugzilla bug filed on this subject, does anyone know? "Not something which is likely to be resolved" somewhat lacks the can-do spirit --Tagishsimon (talk) 21:31, 29 September 2011 (UTC)[reply]
Funny, that. They are more likely just hire more HR people. Or perhaps another storyteller! Killiondude (talk) 23:01, 1 October 2011 (UTC)[reply]
My half-informed guess is that this is likely to be caused by the lucid upgrade. This upgrade is being rolled out to all servers in a staggered fashion, so if we don't fix it, this problem will only get worse over time, as the probability that you'll hit a server that wrongly formats 82000000 as 8.2E+7 rises and eventually becomes 100%. I tried to ping the guy who's doing the lucid upgrades so he can take a look, but since he's not around and since I should really go to sleep now, it's probably best to file this as a bug in Bugzilla. We like bug reports for tracking purposes anyways. --Catrope (talk) 23:14, 29 September 2011 (UTC)[reply]
I'm happy to file a bug if you'll tell me where to find the Bugzilla.     SkyLined (talk) 23:19, 29 September 2011 (UTC)[reply]
Nm; found it using google at [5]     SkyLined (talk) 23:26, 29 September 2011 (UTC)[reply]
Filed bug 31259.     SkyLined (talk) 23:37, 29 September 2011 (UTC)[reply]

5,000-revision deletion limit counted incorrectly

On List of Wrestling Observer Newsletter awards, the page said that there were "3,734 deleted edits" while deleted, but when undeleted (or before it was deleted) says that it has over 5,000 revisions and can only be deleted by a steward. What is the reason for this discrepancy? -- King of ♠ 22:40, 28 September 2011 (UTC)[reply]

Wikipedia:Village pump (technical)/Archive 84#Upper page limit for deletions may answer your question. Jenks24 (talk) 22:49, 28 September 2011 (UTC)[reply]

Bing isn't updating urls

I moved Bunker (golf) to Hazard (golf) on 14 May 2009. Although Bing has updated the article title in its search results, clicking the link still takes you to the redirect. How do we get Microsoft's attention on this? Marcus Qwertyus 08:42, 29 September 2011 (UTC)[reply]

  • Redirecting from Bunker to Hazard is OK on "bunker golf" search, but "Hazard golf" search also links to redirect. Anyway, I think it is rather Bing problem. Bulwersator (talk) 09:32, 29 September 2011 (UTC)[reply]

Amazon Elastic Compute Cloud cache of WP

In this arstechnica piece on the Kindle Fire they mention an X-ray read-ahead cache of related Wikipedia content. Does this mean that we should expect Amazon Elastic Compute Cloud to be caching WP from now on? If so, does it open up any new performance possibilities? Just wondering... LeadSongDog come howl! 18:41, 29 September 2011 (UTC)[reply]

Creating new usernames

A current WP:ANI discussion about a longterm anticontributor leads me to wonder: how does one create an account? I thought that there were only two ways to create accounts (either by creating the account with itself, as I did, or by becoming an AccountCreator), but he's obviously figured out some other way to do it, since surely we didn't give a longtime vandal the AccountCreator right. Nyttend (talk) 04:58, 30 September 2011 (UTC)[reply]

If I'm right, the Account Creator flag simply removes a limit of 6 accounts/IP address/day. Any user that isn't blocked with "account creation blocked" enabled can create accounts, but anyone who wants to make more than 6/IP address/day needs to have the flag.Jasper Deng (talk) 05:01, 30 September 2011 (UTC)[reply]
Indeed. Any account which isn't ACB blocked can register more just by visiting signup whilst logged in. -- zzuuzz (talk) 06:09, 30 September 2011 (UTC)[reply]
It's that signup page I've never before seen. Is it linked from somewhere? I can't get useful results from WhatLinksHere. Nyttend (talk) 11:24, 30 September 2011 (UTC)[reply]
Special:UserLogin/signup also. The signup is just a version of, and linked from, Special:UserLogin. It's linked specifically from some username block templates, and more generally Special:SpecialPages. However all you need to do is have a browser tab open where you aren't logged in and you can copy-paste or click the link into a new tab all you like (up to the account limit). I expect this vandal also has it has a bookmark. -- zzuuzz (talk) 11:38, 30 September 2011 (UTC)[reply]
The main problem with trying to use Special:WhatLinksHere in this manner is that it it doesn't work for virtual namespaces - those with a negative number, such as Special: pages. Another problem is that it only lists links established using wikilinks, not the http: form. --Redrose64 (talk) 14:44, 30 September 2011 (UTC)[reply]
The first problem is bug 17597. You can vote for it. Helder 17:15, 30 September 2011 (UTC)[reply]

Someone in there, there seems to be a problem with a colspan being one greater than it should be. Specifically, if you render United Kingdom general election, 2005 in PDF, the map seems to span one column more than candidates.

I've been trying to figure out where this extra column is comning from for the last few hours, to no avail. Can someone confirm/deny if the colspan is set to 4 throughout the infobox? Headbomb {talk / contribs / physics / books} 06:33, 30 September 2011 (UTC)[reply]

There is no column span problem, and no extra column. It appears that the PDF renderer ignores the CSS width specified on the tables. So while the browser displays the nested tables at 100% of the width of the outer table, the PDF version sizes it to fit its content and (since the cell content is left-aligned) it leaves empty space on the right. This sounds like something to bring up on Help:Books/Feedback. Anomie 11:49, 30 September 2011 (UTC)[reply]
Ah nested tables. Should have known. Headbomb {talk / contribs / physics / books} 15:39, 30 September 2011 (UTC)[reply]

dual wikipedia pages

I am in a discussion about the aspartame controversy at NPV. If I do not sign on the discussion is not visible. It appears when I sign on. Is this normal? Do you have dual pages? — Preceding unsigned comment added by Arydberg (talkcontribs) 07:16, 30 September 2011 (UTC)[reply]

No, we don't have dual pages, but sometimes an old version gets cached incorrectly. I have purged the page so that the latest version will be copied again to all the Wikipedia servers. You could also try bypassing your browser cache. -- John of Reading (talk) 08:02, 30 September 2011 (UTC)[reply]
Logged in users are accessing pages using a more frequently updated server while IPs use a server that relies more heavily on cached content. Killiondude (talk) 22:50, 1 October 2011 (UTC)[reply]

DNS entry hacked?

Did the main DNS entry get hacked? It whois now shows it as

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
WIKIPEDIA.ORG.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
WIKIPEDIA.ORG.IS.WRONG.GO.4.GULLI.COM
WIKIPEDIA.ORG

And you can't connect. Vegaswikian (talk) 18:57, 30 September 2011 (UTC)[reply]

It came back for a few and then went down again. Vegaswikian (talk) 19:08, 30 September 2011 (UTC)[reply]
Where do you get that? whois.org and command-line whois wikipedia.org show normal results for me, and connecting to the site works fine. Ucucha (talk) 19:23, 30 September 2011 (UTC)[reply]
That's known as "whois spam", and has nothing to do with DNS. Some methods of querying the whois database search for any record containing the entered text (rather than just an exact match), so some spammers include the names of high-profile websites in their own records in some strange attempt to get traffic to their sites. Anomie 19:25, 30 September 2011 (UTC)[reply]
I got that from SamSpade. http://www.internic.net/whois.html also seems to be having trouble finding the site with their whois function. But still no access. Vegaswikian (talk) 19:28, 30 September 2011 (UTC)[reply]
For a period commencing approx. 19:00 UTC I was unable to access any Wikipedia page - the error generated by Firefox was something like "Firefox is unable to locate the server at en.wikipedia.org" and the usual "make sure it's spelled correctly" stuff. --Redrose64 (talk) 19:46, 30 September 2011 (UTC)[reply]

Secure login link

I think the secure login link on the login page needs to be changed: it gives https://secure.wikimedia.org/wikipedia/en/wiki/Special:UserLogin.

However, when switching between wikipedias (interwiki), it goes to a simple https://xx.wikipedia.org --- and therefore logs me out. Choyoołʼįįhí:Seb az86556 > haneʼ 04:10, 1 October 2011 (UTC)[reply]

The cross wiki problem is a known issue. I have changed the Login page to point to the new urls. There is one snag, I don't think there is a replacement atm for the "{{#ifeq: {{SERVERNAME}} | secure.wikimedia.org" trick that we used to change the content between secure and insecure servers. If anyone has an idea for a replacement, please do share. —TheDJ (talkcontribs) 11:11, 1 October 2011 (UTC)[reply]
That line is added dynamically in MediaWiki:Loginend when a user is not on secure.wikimedia.org. Unfortunately, there is no magic word to query the used protocol (there is $wgProto, but no {{SERVERPROTO}}), meaning that check will have to be removed. Edokter (talk) — 11:15, 1 October 2011 (UTC)[reply]
bugzilla:31293 proposes to simply split up the user message for the Special:UserLogin page from the server side. That would fix this specific problem. —TheDJ (talkcontribs) 22:20, 1 October 2011 (UTC)[reply]
Great. I hope this will be done for all wikipedias. Choyoołʼįįhí:Seb az86556 > haneʼ 02:35, 2 October 2011 (UTC)[reply]

Bandwidth throttling

Does wikipedia use bandwidth throttling, and if yes which conditions engage/disengage it ? Gzilirion (talk) 07:00, 1 October 2011 (UTC)[reply]

To my knowledge, there is no throttling of any kind. Edokter (talk) — 11:20, 1 October 2011 (UTC)[reply]
Wikipedia:Database_download#Sample_blocked_crawler_email Bulwersator (talk) 11:23, 1 October 2011 (UTC)[reply]

Suggestion re some images

Would it be feasible to have a prefference option so that stuff tagged as {{badimage}} will not display, thumbnail or make http requests for the image at all?

This would be of great assistance to certain users that don't want to see that sort of content. Sfan00 IMG (talk) 10:52, 1 October 2011 (UTC)[reply]

https://bugzilla.wikimedia.org/show_bug.cgi?id=31298 - I've put in an 'enhancement' request.. Sfan00 IMG (talk) 19:04, 1 October 2011 (UTC)[reply]

Auto-include talk header template

I suggest that the wiki software auto-included {{talk header}} at the top of every talk page at the moment of its creation. It's a really good reminder for experienced editors and a good intro for new editors. Maybe even create a bot to add it at the top of every page that lacks it now. Thanks for listening! Woz2 (talk) 17:10, 1 October 2011 (UTC)[reply]

If we want that thing on every page, let's do it in some sensible way—sitewide JavaScript or a MediaWiki message—not by transcluding a template on every single talk page on this project. Ucucha (talk) 17:13, 1 October 2011 (UTC)[reply]
The documentation currently states "This template should be used only when needed. There is no need to add this template to every talk page." Has consensus changed on that? I hope not. Anomie 17:31, 1 October 2011 (UTC)[reply]
It also states that it is "intended to be used on particularly active talk pages that attract commentary from inexperienced editors, and/or high levels of debate from everyone", none of which can possibly apply to non-existent pages. --Redrose64 (talk) 18:18, 1 October 2011 (UTC)[reply]

Hmmm... What's the downside of including it? Woz2 (talk) 17:39, 1 October 2011 (UTC)[reply]

Clutter. At one time, absent talk pages were commoner than talk pages that existed; so the "discussion" link being coloured blue could be seen as an indicator that discussion had started. Then WikiProject banners were invented, and so the red "discussion" link is a rarity. Many talk pages (like this one) consist of nothing but project banners, there is no discussion as such. These are tolerated, but I doubt that a general use of {{talk header}} would be. --Redrose64 (talk) 18:18, 1 October 2011 (UTC)[reply]

Ok Thanks! Woz2 (talk) 18:23, 1 October 2011 (UTC)[reply]

Server error

I keep getting the following error message when I attempt a contributions search in the Wikipedia Talk namespace:

Proxy Error

The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /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.12wm1 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at secure.wikimedia.org Port 443

Does anyone have any idea why this is happening? ---RepublicanJacobiteTheFortyFive 18:12, 1 October 2011 (UTC)[reply]

I am still waiting and hoping for an answer to this question, because I am still getting this error message when I attempt to do a contributions search in the Wikipedia Talk namespace. I have not been able to conduct such a search in days, and it is rather frustrating. ---RepublicanJacobiteTheFortyFive 16:30, 2 October 2011 (UTC)[reply]
Try using the new HTTPS servers NEW server. —TheDJ (talkcontribs) 17:02, 2 October 2011 (UTC)[reply]
Yeah, that connected right away. Thanks! ---RepublicanJacobiteTheFortyFive 17:38, 2 October 2011 (UTC)[reply]

Edit notice on BLP articles

Resolved
 – With many thanks for the friendly help from David Göthberg, TheDJ, Anomie, Edokter, and Redrose64. Now all BLP edits show the important notice, rather than just a minority of them. First Light (talk) 15:04, 2 October 2011 (UTC)[reply]

There is a very helpful edit notice that was created for Biographies of Living Persons, but unfortunately it only shows up when you click the "edit this page" at the top of the article. Never when you click to "edit" a section of a BLP article. Go to Fareed Zakaria, the most recent BLP I edited, to see what I mean. All BLP articles exhibit this bug. Since the vast majority of edits are made to individual sections, can this be fixed so that the edit notice appears on all edits made to BLP articles? Thanks, First Light (talk) 19:43, 1 October 2011 (UTC)[reply]

This is a known problem, and it's been mentioned before. The relevant JavaScript is MediaWiki:Common.js and the notice is Template:BLP editintro; the doc page for that states "this edit intro is shown automatically when editing a page categorized as either Category:Living people or Category:Possibly living people, provided that the edit page is accessed through the main edit tab". See also WP:EDITINTRO and MediaWiki talk:Common.js/Archive 16#BLP editintro. --Redrose64 (talk) 20:08, 1 October 2011 (UTC)[reply]
I see. Too bad, since it does very little good the way it stands. If this could be fixed, it would help with one of Wikipedia's worst problems (certainly the worst public relations problem): people using Wikipedia articles to attack their enemies. See an example here.[6] First Light (talk) 20:43, 1 October 2011 (UTC)[reply]
If somebody is determined to defame another, they will ignore the {{BLP editintro}} whether it's shoved in their face or not. Wikipedia:Vandalism gives advice on spotting and dealing with cases like this. --Redrose64 (talk) 21:27, 1 October 2011 (UTC)[reply]
But for new editors and vandals, it will make them think twice, or maybe find a reference. I've also seen both new and long-time editors unknowingly violate BLP policies. As far as the PR issue, it only confirms to the press that we aren't doing everything we can to protect the reputations of innocent people. Though I do very much appreciate what we are doing on Wikipedia with limited volunteer technical time and expertise. First Light (talk) 21:47, 1 October 2011 (UTC)[reply]
Well, I see two ways we can fix this:
1: We could use a for-loop: Currently the code in MediaWiki:Common.js looks for Category:Living people and Category:Possibly living people and if they exist then adds "&editintro=Template:BLP_editintro" to the edit link at the top of the page. This happens when we view the page, before we click the edit link. As far as I can see we can add a for-loop that locates all the section edit links since they are clearly marked with <span class="editsection">, and then add the same "&editintro=Template:BLP_editintro" to all those section edit links.
2: We could use a hidden category and an ajax call: I have noticed that hidden categories are visible on the edit page even if we edit another section than the one that adds the category. So we could add a hidden BLP category to all BLP pages (perhaps automatically by using the infoboxes). Then we can use javascript that runs when we edit the page (not before we edit the page) and checks for that category and then uses an ajax call to render {{BLP editintro}} and inserts it.
I prefer method one above (for-loop) since it is simpler to implement, it costs less server resources, and I am sure it will work. While I don't know enough about ajax coding to even be sure that method two would work. However, my javascript skills are too rusty and I am semi-retired from Wikipedia so you guys need to ask the experts over at MediaWiki talk:Common.js to implement it.
--David Göthberg (talk) 23:21, 1 October 2011 (UTC)[reply]
Thank You! A possible solution for something that is worth solving. I'll put a note over there, including a paste of your message, to see what they can do. Regards, First Light (talk) 23:39, 1 October 2011 (UTC)[reply]
Done. —TheDJ (talkcontribs) 12:37, 2 October 2011 (UTC)[reply]
Well done, and thanks. First Light (talk) 14:57, 2 October 2011 (UTC)[reply]

Hmmm, how do I disambiguate royalty to royal family in Template:WikiProject Royalty? I am not seeing it linked there... --Piotr Konieczny aka Prokonsul Piotrus| talk to me 01:51, 2 October 2011 (UTC)[reply]

It uses {{WPBannerMeta}}, which automatically generates the link (and all the rest of the box). In this case, you'd want to use |MAIN_ARTICLE=[[Royal family|Royalty]] (if there is consensus for the change, of course). Anomie 02:00, 2 October 2011 (UTC)[reply]
Similar to this edit which I did for WikiProject Mills over a year ago. --Redrose64 (talk) 12:47, 2 October 2011 (UTC)[reply]

Show recent edits to pages I've edited

I'd like a page that can do something like "show me all recent edits to pages I've edited in the last n days", where "recent" is defined as "since the last time I edited that page". For bonus points, it could exclude pages where the only edits I made were marked as minor. Does anyone know of such a thing? Toohool (talk) 05:41, 2 October 2011 (UTC)[reply]

Use " Add pages I edit to my watchlist"? Bulwersator (talk) 05:52, 2 October 2011 (UTC)[reply]
The problem with that is that I don't want to watch those pages forever. If I leave a message on someone's talkpage, for example, I don't want to see every message that someone else leaves until forever. Toohool (talk) 06:03, 2 October 2011 (UTC)[reply]
See Wikipedia:Village pump (proposals)/Archive 77#Functionality on "my contributions" for a discussion of User:Markhurd/hidetopcontrib.js, which approaches the functionality you want.-gadfium 07:49, 2 October 2011 (UTC)[reply]

Recently, a new line was openned by Israel Railways. Unfortunately, I doin't quite undrstand how to edit {{Tel Aviv suburban railway map}} correctly. Please update it in the following way:

  1. The line from HaRishonim ends at TA Savidor Central.
  2. The line from Hod Hasharon Sokolov goes to the end of Tel Aviv (Tel Aviv HaHagana), and then goes to the following stations (all new, not accessable):
    1. Holon Junction Railway Station
    2. Holon-Wolfson Railway Station
    3. Bat Yam-Yoseftal Railway Station
    4. Bat Yam-Komemiyut Railway Station
    5. Rishon LeZion Moshe Dayan Railway Station

An updated map on the company's site can be found at http://rail.co.il/HE/Stations/Map/Pages/RouteMap.aspx. עוד מישהו Od Mishehu 15:02, 2 October 2011 (UTC)[reply]

 Doing... I'll take this - I've amended many RDTs in the past. --Redrose64 (talk) 15:27, 2 October 2011 (UTC)[reply]
 Done Five new stations, but only three new rows required. --Redrose64 (talk) 16:19, 2 October 2011 (UTC)[reply]

I can't access mobile.wikipedia.org since October 1, 2011. My browser gives me a parser error.

I am using a Samsung SCH-U430 cell phone to access the moblle version of Wikipedia. The URL that I have always used is http://mobile.wikipedia.org. All of a sudden the link won't work today, I get the error message "Parser Error". My phone is using Obigo Browser Q04C1-1.22 built on Apr 27 2010. I have tried other URL's such as m.wikipedia.org, en.mobile.wikipedia.org, and en.m.wikipedia.org. They still give me the same parser error. I also notice that that mobile Wikipedia site is a beta version. Can anybody help me out to get mobile Wikipedia working again on my phone? All my other bookmarks and other websites that I go to work as before. — Preceding unsigned comment added by 70.81.58.142 (talk) 16:34, 2 October 2011 (UTC)[reply]

This is because the old WAP 1.0 server (mobile.wikipedia.org) was switching to the new m.wikipedia.org mobileFrontend. This mobile frontend does support wap, but it only paginates per header, not by a fixed size. So likely the server is sending way too much data towards the user, and probably invalid WML as well, causing these errors. I think this switch should be undone, the new fronted is totally not ready to support WAP yet, as I have told the team multiple times. —TheDJ (talkcontribs) 17:07, 2 October 2011 (UTC)[reply]