The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to securitywikimedia.org.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Hi. At Talk:Main Page, a couple of users are reporting that the site is rendering for them as 22 Jan, despite them living in Europe, where it's currently 23 Jan. Hence, they're seeing yesterday's TFA. NB I live in the UK and all seems fine to me. --Dweller (talk) 11:58, 23 January 2013 (UTC)[reply]
Yes, I was the first poster on main page, the Main Page definitely doesn't update for me. Firefox 9.0.1 and 10.0.2 here. Windows XP 2002 SP3. France. F5, CTRL+F5, restarting the computer doesn't work, and I have this problem on different computers. I'm stuck on Jan 22, which was a rather miserable day for me :D BTW is this problem related to the one I have on Commons ? The Commons Main Page doesn't update regularly for me either, I have to force it by switching to mobile view and back. Thank you, have a nice day. 130.79.37.169 (talk) 12:11, 23 January 2013 (UTC)[reply]
I'm having the same problem and I'm in the UK. The main page should be 23rd January. Why is yesterday's page loading instead? I've never had this problem on Wikipedia before. TurboForce (talk) 14:41, 23 January 2013 (UTC)[reply]
Thanks. While this glitch may be annoying for those it's affecting, it's remarkable that the migration has had such little impact. Virtual coffee and chocolate to all the developers from me. (I presume that American IT people depend on similar foodgroups to their British cousins). --Dweller (talk) 14:46, 23 January 2013 (UTC)[reply]
This was a routing problem relating to page purges, and it's now been fixed (and primarily affected European users). Any affected pages can be purged and should show up properly for all users. ^demon[omg plz]15:02, 23 January 2013 (UTC)[reply]
Concur with Dweller. I can honestly say that if I hadn't read about the migration, I wouldn't have noticed a thing. Well done! An optimist on the run!15:16, 23 January 2013 (UTC)[reply]
This problem is still ongoing, at least for me here in the UK. Many pages will show their 22 Jan version in read mode even if later edits have been made. The edits can be seen in edit mode, but will not appear in normal read mode. Neither do they show up in the history view. It's the same for the talk pages. 78.146.235.71 (talk) 04:04, 24 January 2013 (UTC)[reply]
The problem is still ongoing, I posted to Talk:Main Page about one of the sections not updating. and was pointed to here. (The DYK section is not updated for unlogged visitors.) It's probably not just the front page. Yesterday I made 2 edits to an article. I could see them in my contributions, but they weren't present in the article's revision history and in the article itself. (Even when I was logged in.) When I returned to Wikipedia today, they were there. --Moscow Connection (talk) 05:08, 24 January 2013 (UTC)[reply]
By the way, when I log out, no recent modifications on any pages seems to be shown. In the revision history too, I see an older version without newer edits. I try to purge pages, but nothing helps. When I log in, I can see everything. --Moscow Connection (talk) 05:50, 24 January 2013 (UTC)[reply]
This glitch is still active in Germany. Although our location is 0730 UTC on 24 Jan the main page shows 1630 UTC 23 Jan. And the Talk page shows a completely different UTC. Purging the pages does not work at all. — Preceding unsigned comment added by 155.56.68.216 (talk) 06:47, 24 January 2013 (UTC)[reply]
Issue is still active as of 1530 GMT 24 January in Netherlands on IE and Firefox, purging etc. no effect. Site still is showing 23 January information. This seems to only be the case with en.wikipedia.org, nl, fr and de versions working fine. — Preceding unsigned comment added by 94.210.0.175 (talk) 15:35, 24 January 2013 (UTC)[reply]
The glitch is still ongoing (for those not logged in). Many pages still shown in their January 22 or 23 state. This must be causing pretty serious problems. What is being done about it? 78.146.235.71 (talk) 21:40, 24 January 2013 (UTC)[reply]
I then went to one of these articles, followed links to about five pages deep, then backed out to the main page - and saw that it was now showing the correct information for January 25 (TFA - Pinguicula moranensis; DYK - 2012 Race of Champions, Abel Schr›der/Vester Egesborg/Undløse/St Martin's, Make the World Move, Thomas Aquinas Dictionary, Dima Yakovlev Law, Ian McKeever, Detroit's population increased over 1,000 times). --Redrose64 (talk) 13:50, 25 January 2013 (UTC)[reply]
This is geting ridiculous. This morning (25th) the main page was showing the correct date and I thought that at last all the problems had been fixed. This afternoon I visit it again, and its back to showing the 23rd! Come on, guys. You're losing technical credibility, here. — Preceding unsigned comment added by 195.59.43.240 (talk) 14:33, 25 January 2013 (UTC)[reply]
I actually had an issue with safari on mac just now... was switching in and out of private mode for work at WP:OP and noticed that I was seeing different versions of that page depending on whether I was logged in or logged out.... The last edit visible was from Jan. 18, but there were no edits to the page between then and the 22nd. One interesting commonality is that both the main page and WP:OP both use subpages..... Sailsbystars (talk) 18:22, 25 January 2013 (UTC)[reply]
It also affects the Japanese Wikipedia. I've just noticed. I can't see the latest edits and the latest enties in the edit history when I log out. Two examples:
Getting this when accessing the main page while not logged in using Safari v6.0.2 on MacBook Pro running OSX v10.8.2.
Hitting refresh initially gave the page from 24th, but subsequent refreshes bring up the page from the 23rd.
A Windows 7 Professional PC, on the same router, running Firefox v18.0.1 shows the correct page when not logged in.
Pendleboater (talk) 20:17, 25 January 2013 (UTC)[reply]
Well spare a thought for us closer to the international date line! Here in New Zealand we ALWAYS have to wait about 12 hours to get an update for the new day for ALL of the wiki sites. Do you here all of us complaining about it? NO you don't (well I did mention somewhere that we should change the server time to the date line time). . -- Alan Liefting (talk - contribs) 20:44, 25 January 2013 (UTC)[reply]
I'm from Germany and I notice this problem also in de.wp es.wp en.wp ... It is not just a problem with the main page. In a lot of articles I see old versions and an old revision history without edits from 25th and 24th January. --93.209.87.114 (talk) 21:09, 25 January 2013 (UTC)[reply]
Maybe you should stop telling in the headline that this is just a problem with the main page (who looks every day at the main page and who really cares if the main page shows an older version?). If the problem would be that just the main page is not updated, this would not be a big problem. But I (and apparently a lot of other people) can not see the new versions of millions of articles in all languages. I already saw an article with vandalism which was reverted but I have to see the vandalised version of the article and can not fight it because of this problem. This seems to be a very serious problem and I would feel better when someone of the technical team would explain what is happening here and if they can fix the problem. Ironically I can see the new version of a page (for a limited period of time) after I have edited it. --93.209.69.102 (talk) 21:44, 25 January 2013 (UTC)[reply]
The main page problem began very recently, and has affected many users whether logged in or not. By contrast, users who are not logged in have always been served cached copies of most pages, primarily for reasons of speed. --Redrose64 (talk) 21:54, 25 January 2013 (UTC)[reply]
But now even when the cache is purged 2 day old versions of articles are shown. I read and edit in a lot of languages of Wikipedia since years and this never happened before. --93.209.69.102 (talk) 21:58, 25 January 2013 (UTC)[reply]
I have experienced this problem in the UK as well for the last couple of days, and it's still active. Best way I found of viewing most recent updates, which works, is by going around all cache records on my computer. In other words, refreshing the page won't work. But going around cache does, which, while the problem lasts, can easily be done by pressing Ctrl+F5. Whichever page you're viewing should refresh properly and display the latest updated version. The same thing works for Talk pages and View History. It has worked for me consistently since the problem started, which seems to indicate that the cause is a temporary misinteraction of WP pages with cache. Just refresh with Ctrl+F5 each time you open a page, and the content will be updated. I hope this helps. — Preceding unsigned comment added by 94.170.99.72 (talk) 22:20, 25 January 2013 (UTC)[reply]
For what it's worth, Squid has had issues for weeks (maybe months). Logged-out users are constantly served old versions of pages and it doesn't have anything to do with the recent data center migration. I suspect the reason the issues have persisted for so long is that most editors (read: people capable of properly complaining) are logged in. But if you look at any reasonably active page (think: noticeboard) while logged out, you'll quickly notice discrepancies between the date of the most recent edit and the "this page last modified" timestamp. --MZMcBride (talk) 22:23, 25 January 2013 (UTC)[reply]
I reported a related squid issue in August 2011[1]. I didn't say it at the time, but the <ahem> educational pages like ANI served a couple days old content (up to week old for RFA)... it would have sounded a bit strange to complain that ANI was doing re-runs. I don't think I have had to use the history tab to bypass the cache since spring 2012, maybe. In any case, the cache oddities go back a long way. 88.148.249.186 (talk) 05:59, 26 January 2013 (UTC)[reply]
This has been going on for days now and it isn't getting any better! Why haven't those trying to fix this at least posted some update about what they are doing about it? 92.24.102.136 (talk) 00:00, 26 January 2013 (UTC)[reply]
I am told that this should now be fixed (just got the email), they asked if we could take down the notice but I'll leave that up for others if it seems like we're all set in the purge catch up. If people are still seeing issues please let me know. I'm told that it was a "evil multicast forwarding router bug" Jalexander--WMF01:32, 26 January 2013 (UTC)[reply]
This is still going on. For example: FC Barcelona - the last edit I can see in the revision history is from 21 January. I never had this problem before. Most articles which where edited since 22 January are not shown with their recent versions. Even purge does not help. Only editing. Crazy thing: When I edit a page (or when I make a 0-edit) I can see the recent revisions. But when I delete the cookies in my browser the recent revisions disappear. --79.216.49.235 (talk) 02:21, 26 January 2013 (UTC)[reply]
An anonymous browser request just now for Main page (lowercase "p", which redirects to Main Page) from Europe is still showing 22 January:
Extended content
HTTP request:
GET /wiki/Main_page HTTP/1.1
Cache-Control: max-age=0
If-Modified-Since: Tue, 22 Jan 2013 02:02:00 GMT
HTTP response:
HTTP/1.0 304 Not Modified
Date: Tue, 22 Jan 2013 02:34:05 GMT
Last-Modified: Tue, 22 Jan 2013 02:02:00 GMT
Age: 351590
X-Cache: HIT from amssq39.esams.wikimedia.org
X-Cache-Lookup: HIT from amssq39.esams.wikimedia.org:3128
X-Cache: MISS from knsq29.knams.wikimedia.org
X-Cache-Lookup: MISS from knsq29.knams.wikimedia.org:80
HTML source:
<!-- Saved in parser cache with key enwiki:pcache:idhash:15580374-0!*!0!!*!4!* and timestamp 20130122020202 --><!-- Served by srv275 in 0.165 secs. -->
For comparison, the actual main page (Main Page, capital "P") is showing 26 January when requested anonymously, but still showing the MediaWiki:Sitenotice even though the notice was blanked 2.5 hours ago:
<!-- Saved in parser cache with key enwiki:pcache:idhash:15580374-0!*!0!!*!4!* and timestamp 20130126011833 --><!-- Served by mw1094 in 0.170 secs. -->
Is this related to the relatively large job queue (currently around 400,000 and risen over the past few hours)? Not sure if the cache will now be updated routinely as the job queue is processed in due course, or if the stale pages indicate an ongoing fault.
Yep, I still have to rely on versions from January 22/23 and then forward diff by diff to get the later changes - I purged the browser: no effect, neither on en.wp nor de.wp or es.wp, regards --Jan eissfeldt (talk) 08:54, 26 January 2013 (UTC)[reply]
Nothing got better. A lot of pages are just visible until 22/23 January and some pages updated but then they stopped again at 24 or 25 January (like probably the main page stops at 26 January?) For example the Main page of the French Wikipedia has also still this problem. But this problems concerns not just the unimportant mainpages. It concerns the about 1 billion pages in all wikipedia languages When you edit a page OR sign in you see the current version. But as soon as you delete your cookies you see again versions which are outdated since up to four days. --93.209.82.159 (talk) 10:26, 26 January 2013 (UTC)[reply]
I'm in the US and I had the outdated pages problem only when I was not logged in. When I was logged in, I didn't notice any problem. --Bob K31416 (talk) 12:18, 26 January 2013 (UTC)[reply]
Re Redrose64's comment, "The main page problem began very recently, and has affected many users whether logged in or not. By contrast, users who are not logged in have always been served cached copies of most pages, primarily for reasons of speed." — How often are cached copies updated? --Bob K31416 (talk) 13:54, 26 January 2013 (UTC)[reply]
The revision history is often more outdated and does not show the revision which appears. But also the revision which appears is often outdated since days. --Yoda1893 (talk) 19:40, 26 January 2013 (UTC)[reply]
Hi folks - I'm the person who solved the problem before. Our purging infrastructure works by sending multicast purge requests to the cache boxes. To purge between the US and Europe, since we have private IPs plus we can't use private multicast ranges across other peoples networks, we have a relay that converts the multicast requests to unicast. Basically what happened is that one of the routers in Tampa had a stale entry in its multicast forwarding table, preventing the multicast tree for that group from being built up to the new datacenter in Ashburn. When we switched the mastership over, purge requests were then sourced from Ashburn, showing us this "fun" bug. This means that all purge requests that should have been sent to Europe had been basically "black holed." Since the relay machine saw no traffic, it was unable to relay those requests, and the nature of purge requests means that the servers which request the purges aren't waiting for an "ack." Therefore all of the purge requests have been lost in time, and wil not be "caught up." All new purge requests will be sent properly. Purging stale pages should fix the problem. This problem should only have been seen in the European caching center and therefore only visible to visitors from Europe. If see a stale page, please append ?action=purge to the page, forcing a purge. If this still does not fix the issue, please file a bug on bugzilla https://bugzilla.wikimedia.org/LeslieCarr (talk) 17:03, 26 January 2013 (UTC)[reply]
The problem is still alive and kicking, LeslieCarr. For instance, I can only see your preceding entry on this page in edit mode. It does not show up in the ordinary article. Refreshing with "?action=purge" has no effect, either on this page or any other I try. Unfortunately, I'm not sufficiently technical to understand how to file a bug on bugzilla. (I'm probably not alone in this!) The worst effect of this problem isn't the minor inconvenience that articles are slightly out-of-date but that the history revision pages aren't updated (the "?action=purge" command isn't even recognized there!). This must be causing absolute havoc with conflicting edits, especially by the many editors who might still be completely unaware of this problem. 92.24.97.99 (talk) 17:50, 26 January 2013 (UTC)[reply]
The main page of en.wp did not update to January 27 (when not logged in and without cookies) until now. The problem which concerns all pages in every language concerns now again also the main page of en.wp. purge does not work. --79.216.49.61 (talk) 03:05, 27 January 2013 (UTC)[reply]
Just so you know, I am seeing January 26, 2013 (UTC) as the current date in the "On this day..." section while not logged in. Refreshing nor purging the page seems to have an effect on what I see. It is currently January 27, 2013, 10:06 here in the Czech republic, so the correct UTC time should be January 27, 2013, 9:06 UTC. I am running Firefox 18.0.1 on Mac OS X 10.6.8. I also checked the Czech and Slovak main page, however they both seem to show the correct date, so the problems appears to be specific to the English Wikipedia. 83.208.213.135 (talk) 09:06, 27 January 2013 (UTC)[reply]
Okay, so right after I posted that comment, I went back to the main page, refreshed it, and now it shows January 27 for me. I don't know what caused it, but it must have happened in the last ten minutes maximum. The only thing that comes to my mind is the actual action of previewing and posting the previous comment here. Couldn't that have affected the process and somewhat forced the main page to purge when ?action=purge didn't? 83.208.213.135 (talk) 09:14, 27 January 2013 (UTC)[reply]
When your cookies are deleted or you use another browser it will be again January 26 on the main page and a lot of articles will show you revisions from January 26, January 25, January 24, January 23 or January 22. For example at List of Spanish football transfers winter 2012–13 the current version contains transfers until January 26. But as European IP (without having edited or when you edit and delete cookies) you can only see transfers until January 24 and the revision history shows only edits until January 22. --79.216.48.157 (talk) 10:45, 27 January 2013 (UTC)[reply]
Its still ongoing here - even with purging. And its not only the main page - its all pages. One reason that many people might not be reporting this is that its hard to see whats going on or not, as this discussion is only visible once you edit the entire page. There is a lot of not quite right information going around, as everyone is seeing a slightly different view of the problem. FWIW, Firefox 10.0.07, Debian testing, cookies disabled, javascript disabled.46.115.99.15 (talk) 10:24, 27 January 2013 (UTC)[reply]
I don't know whether this is related, but Wikipedia:Today's featured article/Tomorrow is currently showing me the Featured Article from January 24 (i.e. it's showing what it should be showing on January 23) and nothing I can do (refresh, purge etc.) can fix it. This also occurs when I am logged out, and I've also just tried it on my phone (via 3G, so a different IP address) and it's the same there as well. Black Kite (talk) 11:00, 27 January 2013 (UTC)[reply]
I'm getting the correct January 28 one (about Jane Austen). I think that the reason that some Europeans are reporting "still broken" where others are reporting "no, it's all OK now" is because there is more than one server, some of which are fully up to date - and of those that are stuck in the past, they are not all "behind" to the same degree. If you retrieve a page which is clearly out of date, it might have come from a particular server (let's call it "A"); then if you go away and come back (or somebody else retrieves the same page), it might now come from server "B" which yields a different cached copy, which may be up to date. So, "A" needs maintenance whereas "B" might not. --Redrose64 (talk) 15:02, 27 January 2013 (UTC)[reply]
Relate or not, it become impossible to update old .svg. No purge method seems to work. On Commons, en, fr. Thumbs generated remain unchanged. file description page keeps the 6 year old png (from SVG). Update histories do not always include recent updates. Any infromation / advise welcome - thank you [Firefox and Chrome on XP) Eurocommuter (talk) 15:44, 27 January 2013 (UTC)[reply]
I can confirm this (SVG uploads not working). I am trying to edit (remove drop shadow) from File:GOP Logo1.svg, a file hosted on WP for licensing reasons. I can locally confirm that the rsvg library and Firefox render the new SVG source correctly. But after I first uploaded the fixed version to WP, the cached PNG thumbnail did not update. Before, I've encountered this with malformed SVGs, so I optimized the SVG to make it very simple and again verified it renders with Firefox and rsvg. After uploading the second .SVG source, the first upload's PNG thumbnail did suddenly refresh, however. But it does not help, because the most recent file's PNG cache remains un-updated. I am editing from Europe through the .NL servers --hydrox (talk) 00:33, 28 January 2013 (UTC) ed Sweet, purging the server cache worked! --hydrox (talk) 23:39, 28 January 2013 (UTC)[reply]
Unfortunately I'm in no position to immerse myself into this. Just want to report that the problem persists here. Both articles and histories are up to at least two days old, but just in some pages, and the "edit" tabs seem to be updated. I've purged, tried different browser, all of that. 83.253.228.202 (talk) 18:28, 28 January 2013 (UTC)[reply]
content not refreshing from Hungary, using ipv6.
Hi,
I have tried firefox, opera, chrome, reload, private browsing, f5, ctrl-f5, but i still see the state of the main page as it was on the 23rd of january. It seems that a squid needs a kick.
Extended content
GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: hu-HU,hu;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: centralnotice_bucket=1-4.2; clicktracking-session=HBszflapTPzHCS9W0J1TpTXaa5HZfSrvq; mediaWiki.user.bucket%3Aext.articleFeedback-tracking=10%3Atrack; mediaWiki.user.id=57FUr6tSm2LJWGc2cBerv7Qv2Qrl8UCD
If-Modified-Since: Wed, 23 Jan 2013 14:58:51 GMT
HTTP/1.1 304 Not Modified
Server: nginx/1.1.19
Date: Fri, 25 Jan 2013 04:24:38 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Last-Modified: Wed, 23 Jan 2013 14:58:51 GMT
Age: 134746
X-Cache: HIT from amssq43.esams.wikimedia.org
X-Cache-Lookup: HIT from amssq43.esams.wikimedia.org:3128
X-Cache: MISS from amssq44.esams.wikimedia.org
X-Cache-Lookup: HIT from amssq44.esams.wikimedia.org:80
Via: 1.0 amssq43.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq44.esams.wikimedia.org:80 (squid/2.7.STABLE9)
GET /w/index.php?title=MediaWiki:Gadget-ReferenceTooltips.js&action=raw&ctype=text/javascript&508635914 HTTP/1.1
Host: en.wikipedia.org
Connection: keep-alive
Cache-Control: max-age=0
Accept: */*
If-Modified-Since: Wed, 22 Aug 2012 16:12:35 GMT
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17
Referer: http://en.wikipedia.org/wiki/Main_Page
Accept-Encoding: gzip,deflate,sdch
Accept-Language: hu-HU,hu;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Cookie: centralnotice_bucket=1-4.2; clicktracking-session=HBszflapTPzHCS9W0J1TpTXaa5HZfSrvq; mediaWiki.user.bucket%3Aext.articleFeedback-tracking=10%3Atrack; mediaWiki.user.id=57FUr6tSm2LJWGc2cBerv7Qv2Qrl8UCD
HTTP/1.1 304 Not Modified
Server: nginx/1.1.19
Date: Fri, 25 Jan 2013 04:24:38 GMT
Content-Type: text/javascript; charset=UTF-8
Connection: keep-alive
Last-Modified: Wed, 22 Aug 2012 16:12:35 GMT
Age: 23
X-Cache: HIT from amssq37.esams.wikimedia.org
X-Cache-Lookup: HIT from amssq37.esams.wikimedia.org:3128
X-Cache: MISS from amssq40.esams.wikimedia.org
X-Cache-Lookup: HIT from amssq40.esams.wikimedia.org:80
Via: 1.0 amssq37.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq40.esams.wikimedia.org:80 (squid/2.7.STABLE9)
Edits in several articles show up in the edit history complete with renderred article underneath but not in the article under the article tab. This has happened in several articles and despite rebooting, refreshing my browser IE9, the edits refuse to show up. I attempted to do a minor edit to one that presented this problem and it appeared in the article but disapeared when I re-accessed the page, next time. One of the later special effects is the last edit line in the edit history has disappeared too. Good luck with this one. I believe this happenned last fall, also. Not in article talk page.[2], Not even in edit history page unless you slide to next [3]. 174.118.142.187 (talk) 22:35, 25 January 2013 (UTC)[reply]
its Due to a technical issue, some users are receiving outdated versions of pages, including the main page. Please see the village pump for details. i want to hide it i have read it alot today 65.175.255.73 (talk) 00:54, 26 January 2013 (UTC)[reply]
Remembering to hide the message presumably requires the browser to have JavaScript and cookie-saving enabled. So some users will see the message again each session (if they have only session. cookies enabled) or all the time (if they have cookies disabled). — Richardguk (talk) 01:06, 26 January 2013 (UTC)[reply]
To add to an existing section: Click the "edit" link to the right of the section heading, scroll to the bottom of the edit box, then add your comments at the end of the edit box. – PartTimeGnome(talk | contribs)21:51, 26 January 2013 (UTC)[reply]
Main Page updates
I'm still having problems with main page note showing correctly. In UK and it is 27th Jan but main page is from 26th. Using XP with Firefox. — Preceding unsigned comment added by 79.69.251.91 (talk) 18:16, 27 January 2013 (UTC)[reply]
Latest update from Operations
Hey all :). So, I've just been talking to Leslie Carr, one of our more awesome Ops engineers - and by 'awesome' I mean 'she spent 8 hours being batted around tech support and developers at the company that makes some of our hardware, and even more troubleshooting'. She's been working literally non-stop on this since Friday, and is incredibly sorry about both the problem and the fact that it's taking so long. Hopefully we'll have it resolved soon: in the meantime, thank you to all of you for your patience, and to Leslie for her hard work :). I'll let you know as soon as we have an update. Okeyes (WMF) (talk) 01:11, 28 January 2013 (UTC)[reply]
Thank you for the feedback, and thanks to you and awesome Leslie and everyone else for keeping the technology tamed and helping to turn our random edits into a world class resource! — Richardguk (talk) 02:01, 28 January 2013 (UTC)[reply]
Apparently the problem /should/ hopefully be fixed; try ?action=purge to clear old versions, and they should filter out over time naturally as the cache updates :). Let me know if it doesn't work. Okeyes (WMF) (talk) 04:43, 28 January 2013 (UTC)[reply]
I just checked another user's talk page where I had edited. Nothing yet. I made a minor edit and the combined edits result showed up on the talk page. After exiting and reloading the talk page it is gone again. hmmmmm... very strange. Actually this edit doesn't even show in the edit history page. Best and luck to you. 174.118.142.187 (talk) 16:13, 28 January 2013 (UTC)[reply]
"?action=purge" didn't do anything for me. Well first I had to know where to put the option text. LOL I have purged my caches a few times (shift <F5> and shift <browser refresh> on each page this has happenned to me. I cannot see your response, above on the page and I still do not see my minor indent edit to my own message, yet. I see them all in this edit text box and once I hit "Save Page" but when returning they do not exist again. 174.118.142.187 (talk) 18:19, 28 January 2013 (UTC)[reply]
Now this page seems to be fine and fully updated but the user's talk page this edit still does not appear from 4-5 edits back. When I added the purge to the URL it came back with a purge request confirmatiion box, both times (that did not occur ever on this WP:VPtech page) and yet still old news. I think there may be some selective eHarrassment from the system at selective places. :) 174.118.142.187 (talk) 18:42, 28 January 2013 (UTC)[reply]
I can see the latest edit in the revision history. But it doesn't change the way the page is rendered anyway. To purge edit histories, add "&action=purge", not "?". (The question mark is already there.) --Moscow Connection (talk) 21:54, 28 January 2013 (UTC)[reply]
It gets better with that one... "Search for "Wikipedia:Village pump (technical)&action=purge" in existing pages of namespace Wikipedia.". Looks like incorrect syntax using a string concatenation operator? The "?" works and is not already there in any page I have seen. Thanks 174.118.142.187 (talk) 22:12, 28 January 2013 (UTC)[reply]
Er... sorry to spoil your fun, but it isn't possible to purge edit histories separately from the article. The URL for a page history looks like this: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=history. If you add &action=purge to that, it will have two action= parts. MediaWiki resolves the duplication by ignoring all instances of action= except the last one. Hence the effect is the same as if you had just added ?action=purge to the URL of the article itself. (You might be right about purging an article also purging its history. I've never had to deal with an out-of-date edit history before.) – PartTimeGnome(talk | contribs)23:02, 28 January 2013 (UTC)[reply]
I thought that I maybe actually purged the article and the history simultaneously. That's why I added a note (two replies above, in brackets.) But anyway, the history was outdated and the purge worked. --Moscow Connection (talk) 23:17, 28 January 2013 (UTC)[reply]
I see now. There was one "action" already. So I purged the article and both the article and its history were updated. There was no fun involved, cause I updated all the other articles the usual way and noticed that their histories become updated too. --Moscow Connection (talk) 23:29, 28 January 2013 (UTC)[reply]
A purge takes more time to appear now. I purged a page and the page took over 30 seconds or so to actually update. I had already thought that the problem returned and was going to post here when I checked and the latest edit was there. --Moscow Connection (talk) 06:19, 29 January 2013 (UTC)[reply]
New feature announcement: New edits sometimes don't appear in the edit history until the page is purged. It was the case with articles, but now with edit histories too. I've just seen a fresh out-of-date revision history. An edit made on January 29 (after the purge problem was fixed) didn't appear neither in the article, nor in the revision history until I purged the page. Like PartTimeGnome, I had never seen an out-of-date edit history before January 22. Did outdated revision histories (like outdated articles that need purging) become a new feature of Wikipedia? But the way, I could see the edit in the user contributions.--Moscow Connection (talk) 06:19, 29 January 2013 (UTC)[reply]
This is still happening ocasionally for me. It was on a talk page with another person's edit. The purge command on the URL worked (I got confirmation boxes both timees) but it took about 15-20 minutes, and three or four browser refreshes to get my copy of the page to reflect the edit from hours back. 174.118.142.187 (talk) 15:06, 30 January 2013 (UTC)[reply]
Yep, happened today again - but only once, thanks to and for doubtlessly hard work done - on Meta, where I initially was forced to access Micru's replies via the history, best regards --Jan eissfeldt (talk) 22:10, 30 January 2013 (UTC)[reply]
Template error
Can someone check the template that generates the "we're currently having trouble with the main page" blurb? It appears to be causing the text on the page below where it is transcluded to be in small and centered text (in Chrome for Mac, at least), making the site effectively unreadable. Looks like an unclosed tag or two. Thank you. 94.192.225.169 (talk) 19:24, 30 January 2013 (UTC)[reply]
First time I'd ever visited the page in question, so nothing in the cache. Not using a proxy server either. Perhaps just one of those internetty things that happen and thus not my fault and not worth the slap down reply. Thanks. 94.192.225.169 (talk) 19:57, 30 January 2013 (UTC)[reply]
It's all still happening to new edits and events. Even the message appears and disappears randomly in the same pages. The message went from just the "main page" to "main page and others" and now back to "main page" again, when it appears. Tese are the same pages I have been to dozen times without a message. Still needs some unhacking, yet. 174.118.142.187 (talk) 20:57, 30 January 2013 (UTC)[reply]
Revision history is outdated while the article is up to date
Something strange is going on. This happens when I'm not logged in, I'm in Russia. This article この街 (森高千里の曲) in the Japanese Wikipedia is up to date, but its edit history is not showing the 3 latest edits, made on January 30 (UTC). The latest edit listed is from January 23. (History. These edits: [4][5][6] are not listed.) I didn't try to purge the page now cause I wanted to show the problem. When I log in, the problem disappears. --Moscow Connection (talk) 02:32, 31 January 2013 (UTC)[reply]
Another up-to-date article with out-of-date history in the Japanese Wikipedia: 湾岸ワンダーダーリン/ラズベリーラブ. When I'm not logged in, I can still see the latest revision of the article, but the article history doesn't show the latest edit, made on January 28 (UTC). (There were only 3 edits, on January 13, 25 and 28.) (When I log in, I can see the edit in the history.) I notice problems only in the Japanese Wikipedia simply because I don't edit much lately and don't have an opportunity to notice much. --Moscow Connection (talk) 08:06, 31 January 2013 (UTC)[reply]
No, for me it doesn't happen after a purge. Articles don't update immediately aftar I purge them, but eventually, in a few seconds or minutes, they do update. I didn't purge the last example intentionally, though. So anyone can check if they see more than two edits in the history here: [7]. --Moscow Connection (talk) 16:17, 1 February 2013 (UTC)[reply]
(For me it doesn't, but I haven't spent that much time in Wikipedia lately to be sure everything is fixed. People in the section "Template error" above say that for them the problem with pages that won't purge persists.) --Moscow Connection (talk) 16:17, 1 February 2013 (UTC)[reply]
Image revisions not appearing in articles
I have noticed several updated images I have uploaded recently, along with one uploaded by another user, that are still appearing in articles with the original revision. The original revision of File:P&O Cruises Australia.png was appearing in the article infobox in a stretched form but has now been replaced by a vector file. File:DVLA.svg is still appearing in the Driver and Vehicle Licensing Agency article as the old logo rather than the new version that was uploaded on 28 January. File:Edinburgh Airport logo.png was still appearing with the old logo so I replaced it with another upload under a different filename. File:Costa Cruises Logo.png still shows the original revision without transparency. The images I have uploaded all come up in my file list with the updated revisions. Cloudbound (talk) 14:04, 1 February 2013 (UTC)[reply]
The workaround (quoting bawolff from Bugzilla): If File:Example.svg was not updating for the 200px thumbnail size, you would do the following: 1. Go to
What's up with the extra space after external links?
Resolved
For several days at least I've been seeing an extra space after external links, and no icon for non-html doc links like pdfs, etc.. This results in commas and periods being misplaced, and the general look of amateur coding. Is this an ongoing problem that everyone but me is already aware of? I'm using Monobook, but I notice the issue when not logged in as well. — Sctechlaw (talk) 04:33, 30 January 2013 (UTC)[reply]
Yes and yes. Disabling this stylesheet resolves the space issue (but also disables most WP styles too), so I'm wondering if that stylesheet was recently changed? This occurs in Firefox 18.01 on Win7-64 for me, haven't looked recently on other boxes. — Sctechlaw (talk) 15:56, 30 January 2013 (UTC)[reply]
(edit conflict) the stylesheet you point to is basically an agglomeration of many individual stylesheets. the "resourceloader" will do that. if you want to investigate, you should probably add "?debug=1" (or "&debug=1", depending whether the address line already contains a "?") to the address line. this will cause each stylesheet (and btw, also each script) to be loaded separately, so you'll be able to disable them one by one to find out which of them causes the issue. peace - קיפודנחש (aka kipod) (talk) 16:46, 30 January 2013 (UTC)[reply]
Ok, thanks for that; more info now:
When I'm not logged in, I see no icons for external links that should have them, e.g., DOC, PDF, HTTPS (for a linked secure page), etc.. I also see an extra space after every external link.
When I am logged in, I see the icons on links that should have them, but on external links that should not have any icon (plain HTTP links to an html-type document), there remains an extra space. Disabling this stylesheet resolves the issue, but also disable most WP styles. I hope this information helps resolve the problem.
Only thing I see is the external-link icon missing. First thing to try is disable any user script and gadgets one-by-one to see if that fixes the problem. Most likely cause is that one of them may load conflicting CSS that causes the icon to diappear. — Edokter (talk) — 19:50, 30 January 2013 (UTC)[reply]
Here is a second screenshot (from Apple Inc. litigation footnote #52.) User scripts and gadgets are not "on" when one is not logged in, so that cannot be the issue. I did disable all Firefox add-ons in case that was the issue. but it had no effect. — Sctechlaw (talk) 20:23, 30 January 2013 (UTC)[reply]
Narrowing things down further, (1) there appears to be a stylesheet problem with the "Lock" icons for secure links when not logged in, and (2) same issue for non-secure external links whether logged in or not. In other words, when there is no lock icon to be used according the cascade, it leaves a space, and it shouldn't. — Sctechlaw (talk) 20:19, 30 January 2013 (UTC)[reply]
But, the cascade is still broken: when logged out there is no lock icon, just a space; and when logged in or out there is no external link icon showing up, just a space where it should be. It wouldn't be so annoying if it didn't make things look so bad, as in image 2. Anybody? — Sctechlaw (talk) 11:32, 1 February 2013 (UTC)[reply]
Try using differt skins. It looks like you are using Monobook so try Vector instead. This may be a problem with one of the servers returning a 401, 404, or other error so finding out what skin you are using and what server (do a host lookup) can help. – Allen4names (IPv6 contributions) 02:28, 2 February 2013 (UTC)[reply]
Allen, this occurs whether logged in or not, so I'm pretty sure it's not a matter of skin choice. The only difference I see when when I'm logged in is that the lock icons for secure links show up but the icon for standard external links does not. When I'm not logged in, neither of them show up. — Sctechlaw (talk) 18:15, 2 February 2013 (UTC)[reply]
→ Also, since I don't save my cookies or site preferences between browser sessions, when I'm not signed in, WP is not reading any preexisting cookie or preference, thus I believe it defaults to the vector skin. Surely I can't be the only one experiencing this issue. — Sctechlaw (talk) 21:02, 4 February 2013 (UTC)[reply]
Since it seems no one has asked this yet, do you have any content or ad blocker software? Also check any content blocking functions in your browser (even if you don't use them, in case they became set by accident). For example, in Firefox go to Preferences ▸ Content, and check that "Load images automatically" is checked. Then click "Exceptions" to the right of this, and make sure that no Wikipedia or Wikimedia sites are listed as exceptions. – PartTimeGnome(talk | contribs)22:34, 4 February 2013 (UTC)[reply]
I checked those in my initial survey of possible issues on my end. Nothing is different, no new add-ons, settings, etc.. To test further, I created a new naked profile, same result, and even temporarily loaded a backup profile from December to check, just to make sure, again with the same result, and this is what led me to think it was a CSS bug. However, as an additional test I did try to load some random WP pages in Iceweasel and Seamonkey, which work correctly, and also in IE, and the icons do appear normally there too. So, this makes me wonder whether the last Firefox update, which occurred recently, has anything to do with the disappeared icons. I haven't yet checked the Moz support forums to see if anyone there is also experiencing the same problem. — Sctechlaw (talk) 04:22, 5 February 2013 (UTC)[reply]
Found the answer finally. The latest update to Firefox includes a new config option:
security.mixed_content.block_display_content
which is supposed to default to false, but for me got set to true during the update, and, even with a new profile was set to true and would not 'hold' between browser sessions. I found some other issues too with this update, all appear to have been due to a corrupted update. Reinstalling Firefox resolved the issue. So this problem is solved, yay. Thanks all for your input. — Sctechlaw (talk) 05:29, 5 February 2013 (UTC)[reply]
New feature: guided tours
I've been writing a lot about this lately, so I am going to be brief, but I just wanted to give folks a heads up about the first, preliminary release of a new feature from the editor engagement experiments team: interactive guided tours. You can read more about this in the following places...
We're only using this feature in a couple experimental places right now, but it has a lot of potential to do good, if used carefully. Please let me know if you have any questions, especially about creating tours. Me and the developers on the team would be happy to walk you through the process. Steven Walling (WMF) • talk18:21, 1 February 2013 (UTC)[reply]
Your test tour goes off the edge of the screen when it points to the search box (Monobook, Firefox 18, 1920x1080). MER-C06:31, 4 February 2013 (UTC)[reply]
The feature is called "Post-edit feedback", and, once the target (e.g. Urdu) community had agreed upon its installation, take that request to //bugzilla.wikimedia.org . I'm sure it's not too difficult to configure, though localisation work might be required. - Jarry1250[Deliberationneeded]17:58, 2 February 2013 (UTC)[reply]
Raymarcbadz (talk·contribs) has a curious habit: if he creates a page and it comes up with an "help improve this page" box at the bottom, he requests its deletion and re-creates it so that a "rate this page" box will appear instead. See this dialogue headed "articles for deletion". We have told him that his behaviour is obsessive but for my own interest can someone please tell me what determines which box comes up. Is it possible to change the box or suppress it altogether? — RHaworth (talk·contribs) 22:21, 2 February 2013 (UTC)[reply]
Here is a copy of the regular (every fortnight) update for the VisualEditor project, so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement).
In the two-and-a-half weeks since 1.21wmf9, the team have continued planning for the next tranche of work, and working on the core changes that will be needed in preparation for this. For the end of 2012/13, in line with the strategic goals for the VisualEditor set out in the 2012/13 plan, we are looking to provide VE as the 'default' editor for all users, capable of letting them edit the majority of content without needing to use the wikitext editor. This means adding support for at least basic templates, references, categories and images, each of which is a very large piece of work.
The initial focus has included a major expansion in the capabilities of the 'document model' module that converts between the HTML+RDFa rendered by mw:Parsoid and an editable document. Other areas of work have covered editability of images in the "ContentEditable" editing surface, refactoring the keyboard short-cut command triggering system, and improving the documentation system used so that the code is easier to extend.
A small number of changes have made it into the codebase for this release, most notably adding support for Microsoft Internet Explorer v. 9 and above (42847), adding hints of what keyboard short-cuts are available to each button (42919), which can now vary more easily by platform (44012), and internationalisation support for toolbar icons (38551).
Earlier today I went to WP:Page Curation and Special:NewPagesFeed to learn what they were. I've noticed since then that when I visit a new page, there will be a gray bar floating along the right edge of the screen with buttons for things like "Show metadata for this page" and "Mark this page as reviewed." Even if the bar is closed, it will reappear whenever I next view a new page (including refreshing the page that I closed it on). I'm assuming that bar is related to Page Curation or the New Pages Feed. However, I never signed up for anything related to Page Curation and don't want to participate in patrolling new pages. My guess is that just visiting the New Pages Feed has made it show up. If that is the case, I think that functionality should be changed. You shouldn't start getting that bar just because you were curious what the New Pages Feed was, but should have to opt in to participating. Also, closing the bar should actually get rid of it, not just get rid of it until the next time you view a new page. Calathan (talk) 19:25, 4 February 2013 (UTC)[reply]
Thanks for referring me to that previous discussion, though it didn't seem like any solution to the problem was mentioned there. For me, and I assume also for the person who started the previous discussion, the toolbar does not stay closed after clicking the button to close it. My impression is that it works right for some people, but not for others (as some of the people responding seem to think that the x will keep it closed, so probably it does work for those people). Perhaps it doesn't work correctly in some browsers (I'm using IE9). If it could be fixed so that it works correctly for everyone (i.e. stays closed after you click the x, until you visit Special:NewPagesFeed again), I would really appreciate it. Calathan (talk) 21:06, 4 February 2013 (UTC)[reply]
This is a bug that has occurred because of a recent change to the API. A fix has been submitted and is waiting on deployment, which should be either tomorrow or next Monday.--Jorm (WMF) (talk) 21:24, 4 February 2013 (UTC)[reply]
I want to use this html code on wikipedia, however it doesn't seem to recognise even the most simple html. How to make wikipedia to interpretate it as html and not text ..?
<img> tags are not allowed. Use wikimarkup instead, and wrap the image markup in spans if necessary to apply positioning. Anomie⚔02:46, 5 February 2013 (UTC)[reply]
If you want to overlay a marker on a map (as indicated on your test page), there is probably already a template to do the job. For example:
3:[[File:Map of USA GA.svg|thumb|75|Map with Georgia highlighted]]
1
2
3
Atlanta
Atlanta (the United States)
Atlanta
Atlanta (Georgia)
Map with Georgia highlighted
See Help:Wiki markup for a general introduction to wikitext (most of which is not like HTML), or Help:HTML in wikitext for information about the permitted markup that is similar to HTML (including style="..." attributes which you can use to apply complex inline formatting to individual elements).
{{Attached KML}} and an appropriate KML file can be used to draw a path. For an example, look at M-553 (Michigan highway). That article has a KML file which plots the route of the highway on the WikiMiniAtlas that pops up from the globe in the upper right corner. That route can also be displayed on either Google or Bing Maps as well. Imzadi 1979→00:57, 7 February 2013 (UTC)[reply]
Detecting sysop bit; selective page content.
Over at WT:CSD, some editors are looking at a way of streamlining the SPEEDY process for attack pages. We obviously want to allow an editor to immediately hide that kind of content from the general public, but we also want admins to be able to evaluate the CSD tag efficiently and either delete the page or remove the tag. The way to do that would be to have the {{db-attack}} template hide page content for viewers unless they have the sysop bit. So my question is whether there is any way for content to be dependent on the viewer. Possibly a parser function so you could have code like {{#ifeq: {{UserRight}} | Sysop | Page content | --blank-- }}. One of the contributors seems to remember having seen an experiment on conditional content before, but doesn't remember where. Anybody have any leads on such a thing? VanIsaacWSVexcontribs04:20, 5 February 2013 (UTC)[reply]
You can't modify static page content based on viewer settings (other than language, but that is a whole different ball of wax). This would be broken by cache, as the last person to cause the article content to re-render would set it for everyone who saw the cached version afterwards. This could be done with CSS and/or JS, but I think that is frowned upon on the English Wikipedia. There has been admin-only css in the past, but I think that has all been removed for various reasons. Probably your best bet is a collapsed section or simply commenting it out or blanking it (the history and edit pages are readily available, and what you suggest can be bypassed by non-admins this way anyway). --Splarka (rant) 08:08, 5 February 2013 (UTC)[reply]
This was something I suggested, at template talk:db-meta. I posted a link to the page at WT:CSD, but wasn't aware that discussion was taking place there as well as that page isn't on my watchlist. I'll try to gather it all together rathether than have different forums taking place. Incidentally, it does seem technically possible to hide text from nonm-admins, as discussed recently on this VP, using <span class="sysop-show">. An optimist on the run!10:19, 5 February 2013 (UTC)[reply]
How can I easily find the editor who contributed a given sentence to some Wikipedia article? Can I do a search on all revisions of a given article at the same time?
Suppose I see a sentence in some article and suppose I'd like to find the editor who contributed it. Is there a way to easily find that editor? If you have trouble understanding what I mean, how about an itsy bitsy teenie weenie example? Take the article, hell, Itsy Bitsy Teenie Weenie Yellow Polka Dot Bikini. I read the article and I find in it the words "Bikini Amarillo" which is the name of a Mexican cover of the song. Say I'm keen to find the editor who contributed that crucial bit of information in order to show him Wikilove in the shape of an "itsy bitsy teenie weenie yellow polkadot... barnstar" (remember this is just a forinstance). Until now I've only known one very painful and lengthy process (which you can imagine) to obtain that information. Is there a way, in the current state of the software, to alleviate that pain and use a more efficient method? If this hypothetical efficient method (which I'd really love to hear about) involves locating the first revision containing a given phrase, it should also be the method one would use to identify the editor who removed a given phrase, by locating the last revision containing a given phrase. Long live WikiEfficiency! Signed: Basemetal (write to me here) 13:24, 5 February 2013 (UTC)[reply]
Are Commons files transcluded into File: namespace?
{{Rename media}} is used to request renames of image files, but it's only designed for renaming images actually stored in the File: namespace. If someone attempts to request a rename of a file stored on Wikimedia Commons, the template complies and puts the page in Category:Wikipedia files requiring renaming. I would like to add some intelligence to this template, which checks if the file is (transcluded?) from Commons, and if so, writes an appropriate error message. Is that possible? Is there a magic word that can be checked, or something like that? See this diff for an example. Thanks, Wbm1058 (talk) 15:27, 5 February 2013 (UTC)[reply]
There is not a way to fix the template to detect whether the image is originally on Commons or on Wikipedia, I believe. The "transclusion" of the image is not transclusion as you might speak of in a template but is more closely a mirror of the image and its description page. However, all images which are from Commons do have a standard boilerplate box which appears which identifies the image as being from Commons. Did you miss that? --Izno (talk) 15:52, 5 February 2013 (UTC)[reply]
No, I didn't miss the message, but I can see how others might. I found this because a less technically sophisticated editor made an error, which I found, and I also determined that what they wanted to do had not been done. So I am working through the process of figuring out how to help such editors help themselves to accomplish their desired changes, because often editors just revert their attempts, say something like, "no you can't do it this way," but then the change never happens. This is interesting. Someone tagged this page for rename back on 19 September 2011, and that request was reverted 21 September 2011. Then over a year later, another editor tries to rename it, but makes an obvious error. This is where I come in. Every now & then, I check for transclusions of {{subst:requested move}}, a template that must be substituted. I put myself in the novice editor's shoes, and walk through the process of following the error messages generated by "my" template (I wrote the edit checks that write these errors), and the trail leads to advice to use {{Rename media}}. So, curious to see what would happen, I tried this edit, and, a bit to my surprise, rather than tell me I have to do that at commons, a file mover complied with my request! So, now, I'm wondering if I can fix this by just "uploading" the file that is stored at commons under a different name? Wbm1058 (talk) 16:47, 5 February 2013 (UTC)[reply]
Somehow I don't think re-uploading a commons file is a good idea. Why did the "file mover" software let this move happen? Couldn't the "file mover" software see that the file was on Commons? Now, if someone who has been entrusted with the file mover bit can't get this right, how does the foundation expect any average Joe editor to understand this complex process? Help! please. Can someone who understands WMF files make this right?? Wbm1058 (talk) 17:14, 5 February 2013 (UTC)[reply]
Now wait a minute, there is a history here, which seem to actually be physically located on English Wikipedia, not commons, right? An there is a "file" here too, it's just a single line transcluding {{DYKfile}}. And this "file" is on English Wikipedia, and it needs to be moved too? So moving a Commons file on English Wikipedia is really a two-step process, and I have just successfully requested one of two steps, moving everything except the image file itself. Now I need to go over to Commons, and make my first-ever edit there, to request the second step, moving the image itself. Is that right? Wbm1058 (talk) 17:35, 5 February 2013 (UTC)[reply]
There is a red notice on webcitation.org today -- they too need donors.
WebCite will stop accepting new submissions end of 2013, unless we reach our fundraising goals to modernize and expand this service.
Please support our crowdfunding campaign. If you are interested in keeping this service alive, please give generously - or at least share our campaign on Facebook. Funders supporting us with $250 or more will be acknowledged by name on our redesigned website.
Archive sites like webcitation.org, that will archive web pages to protect us from those sites going dark, are an important resources. But, occasionally, when I have gone to the trouble of adding an archive link, I have wondered -- wouldn't it be a drag if the archive site itself went permanently dark?
Ideally, webcitation.org, archive.org (the wayback machine) and any other mirroring/archiving sites out there were either making sure they mirrored all the pages mirrored by their opposite numbers. Failing that, it would be wonderful if the other sites stepped in and started making copies of the pages archived by webcitation.org -- in case it went dark.
They seem to be indicating that even if they stopped accepting new links they would still serve copies of pages already in their archive. But the notice is a very broad hint that the whole site might go dark.
Is there any value in checking to see how many pages archived at webcitation.org we are using are also archived at archive.org?
FWIW I tried to use external links special pages to get an idea of how many links we have to http://webcitation.org. It only reported 808 links, while the Citizendium, a wiki site about one 10000ths the size of the wikipedia has 3200 links. I think I may have made 800 links to webcitation.org just by myself.
WMF projects may make so many links to webcitation.org that it should consider stepping in and adopting webcitation.org if the alternative were to be it going dark?
WebCite is really useful for news sites, as they often can become unavailable online and their robots.txt files prevent archive.org from crawling the page. Chris857 (talk) 18:49, 5 February 2013 (UTC)[reply]
Comment I have used WebCite numerous times for archiving Wikipedia citations and many citation links only exists there, since the original has died. I also think the WMF should consider a cooperation with WebCite and perhaps support them with part of their funds? If WebCite dies, this would definitely also hurt Wikipedia. Our content is only as good as the sources supporting it. -- ToshioYamaguchi18:54, 5 February 2013 (UTC)[reply]
Can someone give a clear indication that WebCite will be genuinely nonprofit? I'm looking at [8] and seeing "An increasing number of journal editors and publishers are currently joining the growing WebCite® Consortium. We are currently in the process of incorporating WebCite® as a distinct entity." This worries me because we don't want to be funding it if it turns out simply to be an Internet company. However, if it is nonprofit, then we should definitely find some way to help it continue to exist as a separate entity, because we wouldn't want to take all of its inevitable copyright squabbles with publishers and lump them together with our own Fair Use issues, infringing uploads, etc. Wnt (talk) 20:10, 5 February 2013 (UTC)[reply]
The last paragraph under Copyright and Long-Term Preservation Issues at http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1550686/ says "All WebCite code is Open Source, and all documentation is licensed under Creative Commons licenses. Secondly, through collaborations with libraries and consortia interested in preservation of digital material, who may act as a curator, custodian or trustee for the WebCite project. These long-term preservation partners may have agreed to hold backups of the service and to legally assume the domain name, all intellectual property such as trademarks, and the service itself, should for any reason the original WebCite service go out of business. " -- ToshioYamaguchi20:22, 5 February 2013 (UTC)[reply]
The information on Gunther Eysenbachs userpage (the initiator of the project, see this) says "WebCite is not a company, but a non-profit consortium of publishers (mostly open access publishers). WebCite in turn is member of an international community of archiving services, of which the Internet Archive, the Library of Congress and other institutions are a part of." -- ToshioYamaguchi20:29, 5 February 2013 (UTC)[reply]
The higher Webcitation.org citation counts linked above sound more realistic; good search-fu! Note that the number of WebCites is even higher than that, because not all webcitation.org URLs are inserted in refs yet. I'm a prolific WebCiter using the bookmarklet, though my insertion rate into refs is low (frequently deferring insertion until a URL dies). ;) It's odd that they don't actually link to their "Facebook campaign". FYI donation info is at http://www.webcitation.org/mailform . --Lexein (talk) 21:46, 5 February 2013 (UTC)[reply]
This is just a heads up to let you know that we have undeployed Moodbar and the Feedback Dashboard from the English Wikipedia. As an experiment, Moodbar was a fair success but we have come to the conclusion that it will require a fair chunk of development work (on the Feedback Dashboard side) to make it fully usable as a mechanism for new user engagement.
Additionally, we have new tools that we are planning to roll out and test that will operate in the same space and we want to avoid conflicts.
Hi bugzilla:15434 (Periodical run of currently disabled special pages) has had some activity lately, resulting in a once-off refresh of the special pages. e.g. Special:Wantedpages. It looks like periodical refreshes may be coming, so I expect that there are some on-wiki prep work to be done to ensure these tools are able to be useful once again.
For example, I noticed that wanted pages is less useful than it could be because it is full of items from /todo pages. e.g. Special:WhatLinksHere/The Sibley Guide to Bird Life and Behavior is high on the list because it is listed at Template:Birds tasks. The result is the ranking of wantedpages is caused by the number of pages claimed by a WikiProject, rather than the number of incoming links from content-space. We have two options here; either remove these 'wanted page listings' appearing on thousands of talk pages, or ask for a linked-from-namespace parameter on special:wantedpages.
I have manually generated this report at Wikipedia:Most_Wanted for the last few years. Eliminating common red links arising from other namespaces, in particular templates is a non-trivial task. The most useful single number for 'wantedness' of a red link seems to be the number of times the text of the red link appears as a wikilink in the raw source of all pages in namespace 0, or any page in namespace 10 that is transcluded into namespace 0 at least once. This is rather painful to calculate. A nearly-as-good approximation is for any red link that is not present in namespace 10, the number distinct namespace 0 articles that link to it. This is far easier to calculate and nobody's complained yet ;) - TB (talk) 10:06, 6 February 2013 (UTC)[reply]
I personally see no reason why we should ignore the inclusion of red links on talk pages via WikiProjects... I would personally be happy for a filter just to show redlinked namespace 0 articles; I don't particularly care which namespace the redlinks are in.... --Izno (talk) 15:09, 6 February 2013 (UTC)[reply]
The first 20,000 entries on a naive 'most linked to red links' arise from navigation templates like Template:Towns in West Gippsland and Template:Music of Asia. Such templates are typically included on many pages, making any red links they contain appear on each. The 'wantedness' of a title that has been linked manually from a handful of different articles is generally greater than one linked from a single but widely used template.
I am interested in your idea of incorporating red links arising in the Wikipedia_talk pages - can you point me towards some examples where interesting new titles are widely linked there please? - TB (talk) 09:42, 9 February 2013 (UTC)[reply]
Can a page notice undo a group notice?
We've got an RfC in the RfA namespace; is there any magicword I can put in a page notice that will keep the group notice for RfAs from showing up when people edit? - Dank (push to talk) 02:22, 6 February 2013 (UTC)[reply]
Yeah, try something like {{#ifeq: {{FULLPAGENAME}} | <name of the RFC page here> || <group editnotice here> }}. That should hide it on that page. jcgoble3 (talk) 02:47, 6 February 2013 (UTC)[reply]
I'm pulling what's left of my hair out. The two references in User talk:Kww/BillboardURL should be identical, but obviously they are not. I cannot figure out why getting the text string from {{BillboardURL}} breaks the reference. I can't use plain <ref></ref> markup inside of {{singlechart}}, so I have to get the tag ref version to work.—Kww(talk) 06:04, 6 February 2013 (UTC)[reply]
Not sure what you're aiming for or how all the templates are meant to interact. But if you edit User talk:Kww/BillboardURL to replace
[{{BillboardURL|artist=Gotye|chartnum=305}} Gotye Album & Song Chart History]
with
[{{trim|{{BillboardURL|artist=Gotye|chartnum=305}}}} Gotye Album & Song Chart History]
It wasn't a space (which in this case would have been harmless) but a line break, see here. It's sometimes forgotten that when a template is transcluded into another page, the whole template is transcluded - the <noinclude>...</noinclude> sections are not stripped until later. Therefore, if any spaces or line breaks occur between the "real" template code and the <noinclude>, those spaces or line breaks end up in the final wikicode:
Fact1:{{#tag:ref|[http://www.billboard.com/node/303039/chart?f=305
Gotye Album & Song Chart History]}}
A reader wrote in to Wikimedia Foundation to report a problem with pdf exports. I know there are some general problems, but this one is troubling, because it appears to work, yet will produce results which are off by a factor of ten.
I'll copy the person's own words:
I would like to report a problem concerning exporting articles from
Wikipedia to pdf. The problem lies with the following code:
Since confusion can arise from this situation I think that a fix of the
problem should be found as soon as possible.
I didn't find the example above in the link provided, but this line:
"the masses of elementary particles become visible at energies above 1.4 TeV" in Standard Model
So I like the Reference Tooltip gadget that is now a default feature. However, it would be pretty helpful if it was expanded to be active on the editing screen as well, not just while viewing the article; how feasible an update would this be? (and I have no clue where or who to ask) EVula// talk // ☯ //17:11, 6 February 2013 (UTC)[reply]
While that is certainly a fantastic feature (and I agree with the secrets comment), I'd still like for the default feature to be improved, if only because it would also work for logged-out editors as well. (I also think the default tool looks better, but that's just my personal taste) EVula// talk // ☯ //18:19, 6 February 2013 (UTC)[reply]
the cite-tooltip *is* available in edit mode, with some restrictions:
when pressing "preview" you can see the references tooltips, but only if the edit actually includes the "references" section. this means it would usually be available when editing the whole article, but not when editing a section. i believe this limitation can't be overcome without, practically, rewriting the whoel tool, so i doubt User:Yair rand (the author of cite tooltip) will implement it, but you can talk to him and see what *he* says about it...
without pressing "preview", cite tooltip is, of course, not available, but i can't imagine what the tool *would* do outside of "preview".
The Toolserver's copy of the English-language Wikipedia database is corrupted. Most of the errors surround edits from early December 2012. The Toolserver admins are aware of this, but have yet to give a date to fix it. = TB (talk) 11:30, 7 February 2013 (UTC)[reply]
(edit conflict) Scratch that. I now see that I was misled because I was looking at the assessment changes over the last five months - which have all been to the {{WikiProject Zoo}} banner, so Toolserver has not been updating the tables for any other project. Since 12 September 2012, the line
has not been altered at all, thus Toolserver does not know that its data should be updated. If you alter the |importance=low in {{WikiProject Indonesia}} to something else, and save it, and some time later alter it back, Toolserver should pick up the change. --Redrose64 (talk) 14:23, 7 February 2013 (UTC)[reply]
Doubt the Zoo project wants to add the parameter. Would removing "importance=low" from that template affect the Indonesia one? If so, why? — Crisco 1492 (talk) 14:17, 7 February 2013 (UTC)[reply]
Is the toolserver broken?
I just went there to try and find out how to register an account so I can try building something, but the front page isn't loading. — Hex(❝?!❞)13:07, 7 February 2013 (UTC)[reply]
as to the original message: it is my understanding that it's probably preferable to create an account on "wikimedia labs" server ([9]). supposedly it has similar capabilities to the TS, and, being a project of wikimedia foundation rather than dewiki, it's likely to be better resourced. it is my understanding that part of TS woes stem from the fact that the foundation, which funded significant portion of the TS operational costs, stopped doing so this year, with the rationale that this kind of stuff belongs on wikimedia labs, and dewiki is not sure it wants to pick the slack. projects should be migrating from TS to wikimedia labs, so building a new service/tool on TS seems like the wrong thing to do, IMO. peace - קיפודנחש (aka kipod) (talk) 18:45, 7 February 2013 (UTC)[reply]
Thanks, but... blurf. I've just spent a while reading around on Labs from your link; for what I want to do (a simplistic tool relating to presenting user contributions) it seems like using an atomic bomb to kill a fly. I guess I'll go to their IRC channel at some point and see if someone can explain it to me in terms that make sense to someone who only occasionally writes tiny Perl programs and bits of SQL. — Hex(❝?!❞)19:30, 7 February 2013 (UTC)[reply]
I've accounts on both systems. The toolserver is mature and convenient to use, but lacks capacity and has regular problems with database replication. Labs has lots of capacity, but is complex to get into and lacks precedent for almost all actions, limiting progress to the speed of discussion. - TB (talk) 09:47, 9 February 2013 (UTC)[reply]
Found A Bell Is a Cup in Category:All articles with dead external links sorted at A but I have checked the article itself and it has DEFAULTSORT:Bell is a Cup coded so I would expect to find it appearing at B. It appears to be correctly sorted in other categories in which is appears (for example Category:1988 albums so the problem appears to be with the category rather than the article itself...
I have been getting this a lot for at least 2–3 months now. Rarely does it happen when making an edit to an article, but quite often when creating one. Jared Preston (talk) 14:38, 7 February 2013 (UTC)[reply]
Cite toolbar not working: admin needed
Resolved
After this revision the cite toolbar hasn't been working because the user forgot to add a comma after the '. Could an admin please fix this? Please change
'cite-work-tooltip' : 'Name of journal, magazine, newspaper, periodical or website'
to
'cite-work-tooltip' : 'Name of journal, magazine, newspaper, periodical or website',
It still hides the Monobook tabs, and the text is still too small, as is the little "close" cross. It does stay up for three seconds though, AFAICT. --Redrose64 (talk) 22:50, 7 February 2013 (UTC)[reply]
If you have extra tabs like for TW, VisualEditor etc. that definitely means some would be covered. In any case, the vertical offset is better than it was at least. The text and icon size issue is in part a fault of the Monobook CSS text sizing, IIRC, but the expansion of the close region should mean that the icon size shouldn't matter as much. Thanks for testing it out. Steven Walling (WMF) • talk23:01, 7 February 2013 (UTC)[reply]
As an admin, I get a few extra tabs, yes. Immediately before I went for the "[edit]" link on this section, those tabs that were on this page were: project page; talk; edit this page; new section; history; delete; move; change protection; unwatch. The upper left corner of the "your edit was saved" box, when present, just obscures the right-hand end of the "history" tab. There is also one custom tab (enabled at Preferences → Gadgets → Add a "Purge" option to the top of the page, which purges the page's cache - which shows as a "*"); it occurs to me that since that tab can work out where it can be placed so that it doesn't obscure anything else (see MediaWiki:Gadget-purgetab.js), a popup message should be able to do that too. --Redrose64 (talk) 23:24, 7 February 2013 (UTC)[reply]
Grabbing the lede text?
I want to do some data mining on (en) wikipedia articles, with Python. I'm going to be using NLTK to infer a few basic facts from the lede of each article of interest. I'm using mwclient for the basic access, but all that gets me is a blob of text which I then have to parse to find the lede. I've come up with the heuristic that "the intro is everything before the first section break, and the lede is everything in the intro after the last template". In python:
host = 'en.wikipedia.org'
path = '/wiki/'
site = mwclient.Site(host, path = '/w/')
p = site.Pages['My Page Name']
text = p.edit(readonly=True)
# The intro is everything up to the first line that starts with "="
intro_text = text.split("\n=", 1)[0]
# Eliminate all the templates that might be at the beginning
lede = intro_text.rsplit('}}', 1)[-1]
Also, you can't ignore everything before the last closing template brackets in the intro, because many templates are used inline; for example: {{Lang}}, {{IPA}}, {{Convert}}, {{Citation needed}}. You would therefore lose foreign phrases, pronunciations and distances, as well as cleanup tags.
Could you parse the article in HTML form instead of the raw wikitext? That way, you could extract everything before the first <h#> heading that is not in a <div> (this could be refined to also exclude other block or floating elements). You would then be left with the paragraphs of text in the <p> elements of the intro.
If you still want to rely only on the raw wikitext, an improvement would be to strip only those templates which (after stripping whitespace) both begin and end at a linebreak. But putting block-level templates on separate lines is only a common practice, not a firm rule, as wikitext permits infoboxes in the same paragraphs as ordinary text. You would also have to take account of nested templates and consider how to treat tables and magic words.
This diff has a problem. After the part that says Line 29 it looks like a paragraph was deleted on the left, and a new paragraph added on the right. But it's the same paragraph, only a single line of whitespace was actually changed. This of course is confusing to the person viewing the diff. Silas Ropac (talk) 02:35, 8 February 2013 (UTC)[reply]
The diff is correct, even though misleading. There is no universally optimal way of computing diffs, the algorithm needs to rely on some heuristics as to which minimal set of changes to choose, and it is bound to get it wrong (from the human point of view) sometimes. You can try enabling the wikEdDiff gadget in your Preferences, which will give you access to an alternative diff algorithm.—EmilJ.17:53, 8 February 2013 (UTC)[reply]
Thanks wikEdDiff does it better in this case. I'm used to the side-by-side presentation more, but as a backup for the very few times the normal one "fails" it's great to have a 2nd option. Silas Ropac (talk) 18:28, 8 February 2013 (UTC)[reply]
Editor toolbar
Was there a change in the editor toolbar? There was a drop-down citation template with four options which I found very useful, which now seems to be absent? JMK (talk) 13:40, 8 February 2013 (UTC)[reply]
"An error occurred while changing your watchlist settings"
I tried adding User talk:Dhastingsabaarsotech to my watchlist. I got a popup saying that an error occurred. I supposed I should just wait and try again later, but this seems like a bug. I can add and remove other pages from my watchlist just fine. Any ideas? • Jesse V.(talk)18:18, 8 February 2013 (UTC)[reply]
In case anyone is interested, the following wording is that which has confused me. (pagetriage-del-talk-page-notify-summary: Parse error at position 44 in input: Notifying author of deletion nomination for $1) Thank you, dci | TALK 20:41, 8 February 2013 (UTC)[reply]
It says the Wikipedia:RefToolbar/2.0 page that the new Toolbar should be default for all English users(and I used to too) but for some reason I seem to have lost the "cite" option on my toolbar.
I don't seem to be using the "RefToolbar 2.0a" either because I have no {{}} icon featured. Could anyone tell me how I can get it back?! The cite tool is the only thing on there I actually need!!!
Many thanks! ----Brigade Piron (talk) 10:00, 9 February 2013 (UTC)
For future reference: at Musicology I clicked "Edit" at the top, then scrolled down to "View templates on this page" at the bottom, and that showed me which template had recently been edited. -- John of Reading (talk) 12:24, 9 February 2013 (UTC)[reply]
Just out of interest, how do you see from that which one of them had recently been edited? I see nothing indicating recent edits to one of them. -- ToshioYamaguchi12:29, 9 February 2013 (UTC)[reply]
wikimedia.org.
. -- Alan Liefting (talk - contribs) 20:44, 25 January 2013 (UTC)
Resolved
Have you tried the Computing section of Wikipedia's Reference Desk? They specialise in answering knowledge questions there; the page you are on is only for discussion of technical matters that relate to Wikipedia. I hope this helps. – PartTimeGnome (talk | contribs) 21:25, 4 February 2013 (UTC)
AtlantaAtlanta (the United States)
‑Scottywong| confess _ 17:44, 7 February 2013 (UTC)
Resolved
mea maxima culpa --— Gadget850 (Ed) talk 18:24, 7 February 2013 (UTC)
.jpg&diff=next&oldid=415764774){kind=link}
.jpg&diff=next&oldid=451236609){kind=link}
.jpg&diff=next&oldid=451689928){kind=link}
.jpg&diff=next&oldid=536696019){kind=link}
.jpg&action=history){kind=link}