This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Brief little template coding question regarding previous editor′s coding
Hi, brief little question,
given that {{Ja help icon}} takes no parameters,
really is there any difference between these:
{{Ja help icon|{{
#if:{{{help|}}}|{{{help}}}
}}
}}
{{Ja help icon|{{{help}}} }}
Forgive me if i'm missing something, about undefined values etc., but i thought i knew template coding just about enough for this. ——--macropneuma02:55, 2 January 2013 (UTC)
No, there is no difference because the parameter will be ignored. But why would you want to use either example when the {{{help}}} parameter gets ignored either way? Why not just type {{Ja help icon}} as intended?
Your first example sets parameter {{{1}}}} of {{Ja help icon}} to the value of {{{help}}} if the help parameter is neither missing nor blank, or sets it to blank if not. But then it gets ignored because {{{1}}} is not referred to in the template code for {{Ja help icon}}, so it is pointless!
Your second example sets parameter {{{1}}}} to the value of {{{help}}} regardless of whether it is blank or missing, which means that it will be set to the literal text {{{help}}} if the help parameter has not been defined (the equivalent of an error message). But then, as before, it gets ignored, so it is still pointless!
Indeed, thank you. I did not think i was missing something (also i didn't ask a leading question). Since i saw it i thought what's the point of that. Wanted to get a second opinion, in case i was stupid or missing something, thankyou. It'll be deleted for just {{Ja help icon}} or more perhaps {{{help}}}{{Ja help icon}}, if help= any values in any of the real uses in any article, of this template: {{Eigo}} which i'm fixing up. i'm learning more, and now beyond this one. --macropneuma03:50, 2 January 2013 (UTC)——
A simple history split should do it, unless I'm overlooking any reason why it wouldn't work with files (my experience as an admin on Wookieepedia leads me to believe that it should work, though I've never actually tried it on a file). jcgoble3 (talk) 19:30, 30 December 2012 (UTC)
IE, 244 people are listed to have competed at the 2012 Olympics in fencing, currently 215 have an article, making this category 88% complete. Is there a way to automatically calculate the percentage if you know how many articles should be in a specfic category? Thanks. LugnutsDick Laurent is dead20:19, 2 January 2013 (UTC)
(edit conflict) the gnome beat me to it. the only thing i wanted to add is that the "PAGESINCATEGORY" which is used for the calculation, and which you also use elsewhere in the table, is marked "expensive!", so you want to use it sparingly. using it once in a category seems reasonable, but it wouldn't be a good idea to use in in a template that's used widely.
(edit conflict) (edit conflict) (edit conflict) Something like this would do: "{{#expr: trunc ( {{PAGESINCATEGORY:Fencers at the 2012 Summer Olympics|R}} / 244 * 100 ) }}%", which produces: "100%" More complicated expressions could also handle special cases such as the number of pages being zero.
Use of "|R" to ensure that the number of pages does not contain commas if {{PAGESINCATEGORY}} exceeds 999 (punctuation might confuse the caluclator).
"Expensive" parser functions (such as {{PAGESINCATEGORY}}) cannot be used more than 500 times on a single page, to prevent excessive database load.
...is supposed to point or highlight to this one...
<ref name="Broderick">{{cite book |last1=Broderick |first1=James F.|last2=Miller |first2=Darren W. |title=Web of Conspiracy: A Guide to Conspiracy Theory Sites on the Internet |url=http://books.google.com/books?id=hOLDnJM91bkC&printsec=frontcover#v=onepage&q&f=false |year=2008 |publisher=Information Today, Inc./CyberAge Books |location=Medford, New Jersey |isbn=978-0-910965-81-1 |page=203 |chapter=Chapter 16: The JFK Assassination |chapterurl=http://books.google.com/books?id=hOLDnJM91bkC&lpg=PP1&pg=PA203#v=onepage&q&f=false |ref=harv}}</ref>
I've fixed it. When the book has last1=Broderick and last2=Miller, the {{sfn}} call must mention both: {{sfn|Broderick|Miller|2008|pp=206–207}} -- John of Reading (talk) 16:13, 3 January 2013 (UTC)
Two questions, the first I think I know the answer to, but the second is the main question.
I knew I had asked a question in this page, and wanted to link it on my to-do list, so I wouldn't forget about it. I checked my contributions, and saw I asked the question on 28 Dec. I looked at the TOC and didn't see it. I noticed that the oldest item dates back to 21 December, so I was initially puzzled, but I think I know the answer. I assume that the archiving process happens based upon the date of the last entry to the section, not the first, so the section created 21 December is not yet archived because it has 1 January responses.
However, when I did a search for the section heading, the first entry is the one I want. It has two links. The first link implies that it is not yet archived and is in the current page, but that isn't the case. The second is a specific link to the section, but when I click on it, I am brought to this page. I managed to find it by going to an archive Wikipedia:Village pump (technical)/Archive 106, but I am unclear why clicking on the link in the search failed to bring me there. Did I do something wrong?--SPhilbrick(Talk)16:46, 3 January 2013 (UTC)
Part one - yes, that's my understanding. Part two - the index used by Special:Search is updated at most once a day, and the thread was moved from this page to the archive earlier today. So the search is currently giving you out-of-date links. -- John of Reading (talk) 17:04, 3 January 2013 (UTC)
When checking the webpage of Wiki, found that we don't have the button or option "to the TOP/UP" that can convenient us quickly back to TOP, just a little advice for your amazing site.
Happy new year to you all!
Hello Paul. This has been brought up in the past, with many editors saying you should just use the "home" key on your keyboard or some other means. But it would actually be really good if we had a "back to top" link at the bottom of our pages. Many articles are very long, and scrolling back up to the top will seem frustrating for users who are accustomed to the "back to top" link seen on very many websites. Additionally, users of tablets have to "swipe" their way to the top of the page, which can be time-consuming. It would be ridiculously simple for us to implement a "back to top" link and it is something we should do. — This, that, and the other (talk)03:30, 3 January 2013 (UTC)
Probably a good question for mobile designers and how they circumvent this common problem - I don't support this for hardware with a classic keyboard, but it's an issue on devices without. --Malyacko (talk) 12:01, 4 January 2013 (UTC)
Yes, the tool is currently limited to enwiki. Adding the database option is a substantial amount of work, but it could happen if there was enough interest. However, for other tools that have the database option, they are very rarely used on any other wiki except enwiki. ‑Scottywong| spout _14:39, 4 January 2013 (UTC)
Today something has stopped the portion of {{rfd2}} that generates the links to stats.grok.se has stopped working correctly and it spits out an error (look at WP:RFD#Current list for examples). As this is happening to all uses of the substed template, I guess it must be an error in the transcluded {{stats.grok.se}}, but that template has not been touched since April. I've looked at the code of that template, but it just looks like a bunch of expressions to me but it's above my skill level to understand what has gone wrong. Thryduulf (talk) 12:30, 4 January 2013 (UTC)
The first template was badly-substed, but once that's fixed, it seems to be working okay - the templates currently visible link to 12/2012 data correctly. Andrew Gray (talk) 12:35, 4 January 2013 (UTC)
If you're suggesting to use <onlyinclude>__TOC__</onlyinclude>, that won't work... Transclusion happens before__TOC__ expands into the table of contents. You'd end up with the table of contents for the transcluding page, not the page being transcluded, just as if you'd typed __TOC__ directly. – PartTimeGnome(talk | contribs)01:45, 5 January 2013 (UTC)
Well, I suppose you could do something like this, to tell browsers to hide the transcluded content after it has loaded:
__TOC__
<divstyle="display:none;">
= Title of 1st page to transclude =
{{:Title of 1st page to transclude}}
= Title of 2nd page to transclude =
{{:Title of 2nd page to transclude}}
...etc...
</div>
(You wouldn't even need the headings if you are only transcluding one page.) But that's stretching wikitext beyond its intended use! The TOC would be the combined table of contents for the section headings of all the pages. An example of a page with a combined table of contents for multiple transcluded pages is Wikipedia:Village pump (all), though of course the transcluded content there is not hidden. — Richardguk (talk) 03:18, 5 January 2013 (UTC)
That's an interesting solution. One problem I can see, though, is that the links associated with the section/subsection entries in the transcluded TOC are all broken, since they are relative to the including page (rather than the original, included page). — Richwales(no relation to Jimbo)03:57, 5 January 2013 (UTC)
Good point. Well I did say it was stretching wikitext beyond its intended limits! Might be adequate if you only want a a userspace hack to gather the section titles together for glancing at or copypasting elsewhere (and if you are the only intended reader, you could combine it with a JavaScript hack to fix-up the links; or better still, use your personal JavaScript to create the list of section titles via the API instead – see below). Definitely not a suitable approach for a wider readership. The only respectable method for a public-facing list would be to create a bot to monitor the section titles and update your page whenever they change. Here's a sample API request that retrieves the section titles of this page in a computer-readable format: http://en.wikipedia.org/w/api.php?action=parse&prop=sections&text=%7B%7B:Village_pump_(technical)%7D%7D — Richardguk (talk) 04:57, 5 January 2013 (UTC)
advertisements on Wikipedia
Hello to anyone who may visit my post. I thought Wikipedia did not have adds.
I have no idea if this is the place for the following.
In some places I've visited, when I hover over certain words I get a pop up advertising about the word.. For instance http://en.wikipedia.org/wiki/%C3%86thelhelm
The word 'grant' brings up an add about the 2013 government grants. It's from Canada.
When I click on the add I get this site. http://grants-canada.org/apply1.php
This has happened on other articles but I didn't make a note of them.
I'm using Firefox.
Thanks
Elaine.
dorel341 — Preceding unsigned comment added by dorel341 (talk • contribs) 04:55, 4 January 2013 (UTC)
Hi Elaine, thanks for bringing this up. You are right that Wikipedia that never has advertising. Looking at the page you mentioned it does not appear that anyone has edited the page to add spam, which can happen occasionally (and when it does we of course remove it). I suspect that the advertisements might be from an add-in to your browser. Try loading the page with another browser, such as Internet Explorer and see if they go away. If so, you'll want to look for and remove the offending plugin from firefox. If not, or you cannot find a plugin, you likely have an adware infection on your computer, and will want to take action to remove that. Cheers! Prodegotalk05:09, 4 January 2013 (UTC)
This has been a recurring problem through 2012 - it seems there's quite a lot of malicious plugins like this around. There's some more details on the Wikimedia blog here. Andrew Gray (talk) 09:56, 4 January 2013 (UTC)
Thanks for the help. My husband did some cleaning and I haven't come across it since.
I'm lost on here. I don't know where to post a thank you. You were right it didn't happen on IE. It was something on Firefox.
I was surprised to get an answer. I didn't know what I was doing.
Thanks again for the links.
Elaine.
dorel341 — Preceding unsigned comment added by Dorel341 (talk • contribs) 06:47, 5 January 2013 (UTC)
Unfortunately, there is no indication of the duration of deferred link updates in the queue (Bugzilla:43287) and the Ganglia graphs of the queue size are not publicly available pending a bug fix. Nor is there an easy way to tell which template(s) caused the rise. But the most likely explanation is that a heavily-transcluded template was edited recently and that the backlog will therefore clear by itself over the next few days.
I have the same experience with "What links here" on template pages. That is: WLH lists and transclusion count are old (over days). Just a note, not an issue. Will be OK. -DePiep (talk) 19:45, 5 January 2013 (UTC)
Yes, I love this feature and it works great with foreign-language Wikipedias. But the problem isn't that it thinks some Montana community has an Indonesian-language name.
I noticed that there is an options button drop-down on the right side of the translate bar which has an option, Not in Indonesian? Report this error., so I'll let Google know about it. – Wbm1058 (talk) 02:17, 5 January 2013 (UTC)
I assume Google Chrome makes statistics about English looking and non-English looking words. Consider the English text displayed between the tagline "From Wikipedia, the free encyclopedia" and "Pages in category Unincorporated communities in Montana". Your links show that the Indonesian claim depends on how much text there is. Copying from your post with my addition in italics describing the text:
but the "current revision" from history does not! Red box saying "This is the current revision of ...", plus category lead
the original revisiondoes bring up the Indonesia translate prompt. Same red box but no category lead
this edit made the translate bar go away (at least in history view). A diff which duplicates English text in lead (both displayed in diff and the rendered page below diff)
while the next edit brought it back! A diff with much less text
It looks systematic to me. The whole page is apparently near a non-English tipping point and a brief English text can decide it. PrimeHunter (talk) 04:07, 5 January 2013 (UTC)
But what's tipping it to Indonesian? The English page doesn't even remotely look like this – and curiously, I think that page brought up the "translate from Indonesian to English" bar when I first looked at it, but now it's not showing it. id:Billings, Montana and id:Helena, Montana work fine. I think the answer's going to be something pretty obscure. Like some non-printing UTF-8 code for a spurious character or some glitch in html encoding somewhere – Wbm1058 (talk) 05:46, 5 January 2013 (UTC)
No, it's nothing like that. This is really a question for Wikipedia:Reference desk/Computing. I made some test html files on my own computer and opened them with Chrome. Not valid html files but just a few lines of plain text saved with html as file type, and making sure there were only normal ASCII characters. If the file contains 7 lines saying "Acton, Montana" and nothing else then Chrome says Indonesian. If it's 6 lines then Chrome doesn't. 7 lines of "Jackson, Montana" also says Indonesian, but for "Babb, Montana" it requires 8 lines. It appears "Montana" looks Indonesian to Chrome, and if it occurs enough times without a sufficient amount of non-Indonesian looking text to outweigh it, then Chrome guesses Indonesian. 6, 7 or 8 identical lines should give the same ratios, but maybe Chrome prefers more text before daring a guess. It doesn't look like Chrome uses large word databases. http://www.globalbydesign.com/2010/12/06/inside-googles-language-detection-tool/ says: "The tool works by scanning a chunk of text and then segmenting and analyzing four-character “tokens.” These tokens are compared against a very large table of reference tokens that have language properties associated with them." PrimeHunter (talk) 15:17, 5 January 2013 (UTC)
Thanks, your explanation makes sense, though playing with lots of "Montana" test edits in my sandbox, I couldn't duplicate your test results. I wasn't really aware of these types of questions being asked over at Wikipedia:Reference desk/Computing, I'll go there next time if I have more questions of this nature. Thanks, Wbm1058 (talk) 17:24, 5 January 2013 (UTC)
Hello everyone. I would like to know that is there any method of tracing this IPv4 address Special:Contributions/130.94.122.xxx and other types of similar IP addresses ? Since the last 3 digits do not exist, I have to presumably enter numbers ranging from 0-255 as is common for the IPv4 ranges and then search on the web for them. It also does not contain any WHOIS, Traceroute, Geolocate, etc. and many other links below which are found on all other IP addresses including all IPv6 addresses. Is there any way to know/find out what the actual IP address this is and how to properly track/trace it. Helpful suggestions most welcomed. Thank you. ~TheGeneralUser(talk)04:48, 5 January 2013 (UTC)
Also why don't the last three digits of the these types of IPv4 addresses show up ? Is it due to some software bug or glitch or is it some other kind if issue ? ~TheGeneralUser(talk)04:54, 5 January 2013 (UTC)
Very old IP contributions were anonymised by replacing the last number with "xxx" in Wikipedia databases. But since the block of addresses are usually closely connected, in practice it did not achieve much extra privacy, and so was abandoned about a decade ago. Note that all of the edits in your example pre-date 2003. With the many ISP and network changes likely to have occurred since then, I doubt that it's now worth worrying about. — Richardguk (talk) 05:10, 5 January 2013 (UTC)
I'm trying to hide the "Help:User contributions" link on the Special:Contributions page because it gets in the way when I'm using my tablet computer. I tried adding code to my common.css, but not being very versed in css, my guess didn't work. Any ideas? Thanks in advance. —DoRD (talk) 15:11, 5 January 2013 (UTC)
Change the .mw-sp-contributions-explain to #mw-sp-contributions-explain - that's because the HTML <p>...</p> element that you're trying to hide has id="mw-sp-contributions-explain" not class="mw-sp-contributions-explain" --Redrose64 (talk) 15:39, 5 January 2013 (UTC)
A Mouse-Over Abstract System Will Greatly Improve Wikipedia Use
I propose a change implementing mouse-overs to linked articles to greatly improve learning speed and retention.
I find that when studying an entirely new top level subject, the reader in barraged with a lot of concepts, jargon, and terms. The reader may already know some of these, and may want to verify their knowledge, or they may not know one or two missing terms.
When the reader encounters something they do not know, they are left with only two options: launch the link in a separate browser tab, or a separate tab instance. Both of these options will take the reader's eye and mind from the original concept they want to learn. Launching another tab or browser will take the reader's attention out from the Wikipedia webpage and back into the modality of using the browser's widgets and controls, thereby causing them to (more) easily lose the original concept.
I propose the following change: When the reader mouses over (hovers) a linked item/term, a child hint window appears displaying a short abstract of the term or page. Having an abstract will allow the reader to verify their knowledge of the term or concept, as well as possibly learning a new concept or term. Of course, if the reader selects the hint window, they will be taken to the appropriate linked Wikipedia page.
Computer artificial intelligences may also be helped by this change, as they will be able to find a short answer for questions.
An abstract system change will take time to implement properly, as Wikipedia pages should all have a concise opening paragraph, but they should a good opening paragraph already. The abstract part of the proposal may be difficult to implement as there should be a logical limit to the useful abstract length, such as: the mean average of all Wikipedia first paragraphs plus(+) some additional allowance.
Offering a mouse-over abstract system will be one of the best changes possible for this stage in Wikipedia's development. I implore Wikipedia greatly to implement it.
I just did, and already have the {{Navigation popups topicon}} on my user page, kudos to the developers! Any thought of having a template "use Navigation popups for a better view of this article's links" for display in the upper corner of selected overview articles like this? Wbm1058 (talk) 20:41, 5 January 2013 (UTC)
I have been making fairly time-consuming edits to Paris, but every time I click save page it thinks for a few minutes and then comes up with the Wikimedia error screen, saying this:
If you report this error to the Wikimedia System Administrators, please include the details below.
Request: POST http://en.wikipedia.org/w/index.php?title=Paris&action=submit, from REDACTED via knsq23.knams.wikimedia.org (squid/2.7.STABLE9) to 91.198.174.55 (91.198.174.55)
Error: ERR_READ_TIMEOUT, errno [No Error] at Fri, 04 Jan 2013 01:06:42 GMT
They all work for me. January 1 is the only day this month with stats yet, but if I click latest 30 then I see stats for December 4 to January 1. PrimeHunter (talk) 11:20, 3 January 2013 (UTC)
I noticed an absence of stats for 2/1 as well, checking a couple of hours ago. I vaguely remember it's taken a few hours to get daily stats up in the past on occasion, so it may not yet be a problem. Andrew Gray (talk) 11:39, 3 January 2013 (UTC)
I think I messed up on something, and I need to have it corrected. Talk:Laurence Harvey had no archive feature, so I set one up. However, I think I must have initially set it to start with Archive 2, because that's what happened. Archive 1 showed it was an uncreated blank page. The archive box would not show on the talk page. I moved Archive 2 to Archive 1. There still is no archive box on the talk page. Can anyone help correct my error?— Maile (talk) 14:00, 6 January 2013 (UTC)
Category flattening/spidering to build a specialized watchlist?
At one point I had every high school in three states on my watchlist. I would like to create a public watchlist with all high schools in the united states on it. I could probably go to Category:Lists of high schools in the United States by state or each of Category:Public high schools in Colorado and make it by hand, but surely there's an easier way to do this. As far as I can tell from the suggestions here there doesn't seem to be any way to do flattened category search on the English wikipedia. Is there some easy way to do this that I'm missing? If not, is it OK if I just do it by spidering with a perl script? Thanks, a13ean (talk) 21:21, 4 January 2013 (UTC)
you can use catscan (a toolserver tool - see WP:CatScan), and specifcially catscan rewrite ([5]). if you feed it Category:High schools in the United States by state, it returns a lits of some 16K articles within several seconds. granted, some of these are not really schools (the 1st that comes up is Andy Warhol: it seems that some "alumni of XXXX" categories belong to the "highschool of XXXX" category), but almost all the results seem to be legit. you could probably further refine the filter, eg. to articles containing {{infobox school}} or somesuch to get better list. peace - קיפודנחש (aka kipod) (talk) 22:45, 4 January 2013 (UTC)
I made a list of 7615 links for a public watchlist, and it was not of much use because there is too much noise in a big list. If you want to play with it, search this page for "main" (which finds two links). Spidering the html source is not a good idea—if catscan is not suitable for some reason (I haven't tried it), the approved spidering technique is to use the MediaWiki API (ask if info wanted). Johnuniq (talk) 00:09, 5 January 2013 (UTC)
Thanks to both of you! I'll take a look at both as soon as I have a chance, and if I get one I'm satisfied with I will post it here. If I do end up spidering for this or some other project I'll use the API via the WWW::Wikipedia CPAN module -- one of my new year's resolutions is to parse as little html as possible =) Cheers, a13ean (talk) 02:07, 5 January 2013 (UTC)
Hello people! I'm helping conduct a 3 day hackathon at IIT Madras, starting yesterday. We finished basic Gadgets training yesterday, and I have now a dozen enthusiastic volunteers looking for Gadgets to write. I've started collecting tasks at mw:User:Yuvipanda/Hackfest_ideas. Anyone adding anything more would be highly appreciated! Thanks! YuviPanda (talk) 03:00, 6 January 2013 (UTC)
For articles that have been certified as featured articles or good articles, will the entire discussion for the featured or good article nomination process be on the talk page? Or is there someplace they are archived to? I would assume the talk page would have a archival access point. Also, is there somewhere where all of the nomination dialogues (ie. reviewer editor's comments and author editors' feedback) for different articles are listed consolidated in one place? Best, Chantoketalk13:01, 7 January 2013 (UTC)
Generally speaking, the GA assessment is not held on the article's talk page but on a subpage, although that subpage is often transcluded to the main talk page while discussion is ongoing. The subpage is named Talk:article name/GA1 for the first GA assessment, with the final digit being suitably increased if the page has been sent to WP:GAN more than once.
The FA assessment is never held on the article's talk page, nor is the assessment page transcluded there during discussion. FA assessment pages are named Wikipedia:Featured article candidates/article name/archive1 for the first FA assessment, with the final digit being suitably increased if the page has been sent to WP:FAC more than once. Although named as "archives", they carry these names from the outset - for example, Wikipedia:Featured article candidates/United States v. Lara/archive1 was created yesterday.
In both cases, one or more of the boxes (other than WikiProject banners) at the top of the talk page will contain links to GA and FA discussions, both open and completed. Completed discussions are left where they were started. --Redrose64 (talk) 13:56, 7 January 2013 (UTC)
Mac calendar widget issue
It's probably been discussed before and an easy answer provided, but I can't find it. About a year ago, I subscribed to a link that downloads into my Mac calendar (iCal) the sunrise and sunset times for each day. I've since moved from the location I gave the service, but now can't figure out how to delete the link, or turn it off...and when I try, it refers me to "http://www.webcal.fi/goto.php?t=18", which takes me to Wikipedia's article on the "Sun". Can someone tell me where I can find the "turn off" button? — Preceding unsigned comment added by Reach01 (talk • contribs) 13:08, 7 January 2013 (UTC)
Normally these peaks are the result of a mistake in some code someone's made that ends up requesting the page over and over again. Given the subject matter I think that's likely in this case. Grandiose(me, talk, contribs) 14:55, 7 January 2013 (UTC)
Scripts don't work anymore
Okay so I was messing around with my scripts and I was trying to get this one script to work and I ended up removing all the scripts to see if re-adding them all would fix the problem. Well turns out it didn't it made the problem worse, I can't get any of the scripts to work. I have tried everything, cleared my cache several times, switched browsers, even restarted my computer and they still won't work!! What am I doing wrong!? JayJayWhat did I do?03:07, 8 January 2013 (UTC)
this may not be the source of the issues you see, but it hints that maybe you want to go over your vector.js page and make sure everything in there makes sense. peace - קיפודנחש (aka kipod) (talk) 05:09, 8 January 2013 (UTC) suspiciou
As a user of touch devices I have a great problem with collapsed navboxes. The [show] link appears for me in 8 point type. It is very small and difficult to touch accurately. In some cases the [show] link coincides with a natural "blind spot" of the touch screen, and I have to scroll the page before having another few stabs at the link. In the worst cases I have been forced to focus a nearby link and "tab" to the one I want (which is, of course, difficult on a tablet!).
Touch devices are becoming increasingly more common, and so I feel we need to solve this usability issue. Here are some ideas:
I love browsing Wiktionary on a touch device, because its collapsible boxes can be opened by clicking anywhere along them. See wikt:háček, for example. The problem with doing so here is our {{navbar}} (the V · T · E links); it needs some non-clickable space around it to give the user a margin of error.
A more reasonable improvement would be to increase the type size of [show] from 8 to 9 points (in terms of CSS, from 100% to 110%) and to include the square brackets as part of the clickable link.
We could even add a small arrow (again like Wiktionary) to give even more visual feedback and increase clickable area even further. However, this is certainly not at the heart of my request.
Making the title bar clickable sounds a good idea to me. Surely this can be done without interfering with the V·T·E area? (And, unlike the "[show]" link, those template links are used relatively rarely, so touch users could zoom in if they ever need to click the V·T·E links.)
The [show]/[hide] links are ugly, so it would be good to avoid increasing the text size if alternative approaches can be found.
A "▼" expansion symbol would be elegant, and seems to be provided in the most common browser fonts.
But I would like to make a broader proposal to obviate your dilemma:
Why not make all navboxes permanently visible?
In webbrowsers, vertical real-estate is free. And navboxes appear at the ends of articles, so they don't prevent readers from reading the article text. Stylesheets can be set up to hide navboxes when printing without hiding them from screen viewing (as is already the case for sidebars etc).
So the current policy of hiding the content of multiple navboxes seems ridiculous: having no effect on the reader who is uninterested in the content, and actively frustrating readers who do want to see what its hidden.
The obvious solution is to remove the [show]/[hide] functionality altogether from navboxes, and retain it only for hiding lengthy material that is not at the end of an article.
I most surely have not removed the last space in this edit. Not a big deal, but it is not reassuring having stuff to appear or disappear just because. A space, that space, is ok, but we can't have random characters vanishing - Nabla (talk) 10:29, 8 January 2013 (UTC)
Whitespace is automatically trimmed from the end of a page when you edit. You edited a section and a space was removed from the last line of that section. So, surmising: perhaps whitespace is also automatically trimmed from the end of a section if you section-edit. (As to how whitespace could appear there in the first place: it looks like the other editor's signature ends in a space, so perhaps the trimming is done before the ~~~~ is expanded; or perhaps the other editor commented by editing the entire page, so that the whitespace was not on the final line of the editbox when that edit was saved.) — Richardguk (talk) 11:43, 8 January 2013 (UTC)
That's pretty much it. When you edit a page or a section, all whitespace (whether blank lines or actual spaces) is automatically removed from the bottom of that item. This occurs twice: once when the edit window is loaded, once when it is saved. It is possible to add such whitespace to the bottom of any section (except the last) by editing the whole page and inserting such space before a section header. But the next edit to the section containing that whitespace will strip it again. --Redrose64 (talk) 13:16, 8 January 2013 (UTC)
The space at the end was actually made in a section edit [6] but I wouldn't worry about when ending whitespace is removed. It's not a sign that random characters may be vanishing. PrimeHunter (talk) 14:09, 8 January 2013 (UTC)
I was trying to recreate the hatnote at the top of Maritime_flag#Jacks using standard templates, but when I tried {{see also|{{Commons category-inline|Naval jacks}}}}, it produced an extra set of double-square brackets – [[ ]] – which I did not want. Is there any workaround? It Is Me Heret / c15:39, 8 January 2013 (UTC)
Is there any way to combine the two hatnotes at the top of Wedgwood? I've tried {{Redirect|Wedgewood||Wedgewood (disambiguation)||Wedgwood (disambiguation)}}, but that simply left out the second disambiguation link altogether. Any advice? It Is Me Heret / c16:20, 8 January 2013 (UTC)
I would personally combine the disambiguation pages. If that's not something you want to do, the template I would use would be about: {{About|the pottery company|other uses|Wedgwood (disambiguation)|and|Wedgewood (disambiguation)}}, which produces the below.
Have discovered that some of my recent edits do not appear in "My watchlist" (but some do). Since making this discovery I have ensured that each time I edit, the "watch" box is ticked. Still no joy. Have not changed preferences. Using Safari. Anyone else experiencing this? Moriori (talk) 22:30, 8 January 2013 (UTC)
At Preferences → Watchlist, make sure that "Expand watchlist to show all changes, not just the most recent" is switched on. If it's not, any edit (including minor and bot edits) subsequent to yours will prevent your edit from being shown. --Redrose64 (talk) 23:32, 8 January 2013 (UTC)
Also, most of your recent edits have been marked as minor ("m"), including your comment above. You can change your Watchlist preferences to show minor edits. But also, you should not select the "minor edit" box when you edit unless your edit really has only a minimal effect. Is something in your settings forcing the box to be ticked by default (indicating a technical problem), or have you misunderstood the purpose of the box and been ticking manually nearly every time you save? — Richardguk (talk) 03:10, 9 January 2013 (UTC)
Scripter left
I recently fixed an article which the operator of a script had clicked 'fix'(?) for a dash in an image file and broke the link to commons. Is the the correct forum to bring up an old bug in the script to have it skip changing dashes in file names? If it is not a big issue then just resolve this section. The bug is on the talk page starting here: User_talk:Cameltrader/Advisor#Two_bugs_and_four_requests and seems to be repeated a few times.--Canoe1967 (talk) 23:19, 8 January 2013 (UTC)
A number of things have just changed for me in the last few minutes, using Firefox/Monobook (but fine using Chrome). For example, the edit link in the lead has gone, when I hover over a footnote I no longer see the citation, and collapsed templates are showing uncollapsed. Has something changed centrally or is it just me? SlimVirgin(talk)02:18, 3 January 2013 (UTC)
I just tried that, and it looks even worse now. I can't describe what is happening now, but everything is different; Monobook not loading or something (if that makes sense). WP has been very slow for me today, with several images not loading. I wonder if that's connected. SlimVirgin(talk)02:30, 3 January 2013 (UTC)
I just changed my preferences to Vector, and the very strange appearance has disappeared, but the templates are still uncollapsed, etc (as described in my first post), so it's not only a Monobook issue. SlimVirgin(talk)02:34, 3 January 2013 (UTC)
The appearance changed again; it's neither Monobook nor Vector. Don't know what it is; it's not something I've seen before. I've moved to a different computer to see if I can see it here too, different operating system, still Firefox but different version, but it's the same. I'm surprised that I'm the only person who's reporting this. SlimVirgin(talk)03:41, 3 January 2013 (UTC)
I've tried that, thanks, and I've uninstalled and reinstalled various things that might be causing it, but with no resolution so far. If I really am the only person who's noticing this, it may be something to do with my internet connection. It slowed down yesterday and then suddenly I had these problems with Wikipedia's appearance. Many thanks to you and StuRat for the replies. SlimVirgin(talk)23:29, 3 January 2013 (UTC)
Assuming that you have definitely cleared your cache (which is the most common cause of sudden problems like this; not meaning to be patronising, but caches sometimes persist unexpectedly if the instructions aren't followed fully!):
The symptoms you describe all indicate that your JavaScript has stopped working. This is reinforced by the problem persisting when you change computers. (Can you see if it persists when you log in from a browser other than Firefox? It seems unlikely that Firefox itself would cause a sudden change, unless you had just installed an update or browser extension before things broke.)
Your monobook javascript is separate from your vector javascript. But most of your two scripts are identical, so the persistence when you change skins is consistent with an error in one of the common parts of the script.
You report that you have uninstalled various things, but you don't seem to have tried editing your script pages. So:
Start by blanking the script page of your current skin.
Is everything working as it should for a user with no JavaScript? In particular, you should find that you can now expand and collapse infoboxes in the normal way (though of course your custom helper tools will be missing).
Assuming that things are now working, then try adding in the scripts you want, block by block, until you find the block which stops everything from functioning. If it is a script imported from another user, you can then contact the script maintainer. You might even find that you no longer need that script (you have a lot of custom javascript and I'm guessing that some of it duplicates other parts, and that some of it was written several years ago and is effectively obsolete).
If blanking your script pages isn't the problem, then it is caused either by an unusual gadget or user preference (so disable all your gadgets, and re-enable one-by-one to find the cause), or else by an unusual Firefox setting (so uninstall any browser extensions and/or reinstall Firefox).
As an alternative to reinstating your javascript line-by-line, if you know enough about Firefox then you could see what error messages are reported on your browser's JavaScript console (adding ?debug=true to the end of the article URL will make it easier to track down the relevant component). But I'm guessing that you would have tried this already if you knew enough to be able to do so, so eliminating all your scripts and reinstating bit-by-bit is probably easier to try.
@User:SlimVirgin: More specifically, I've just noticed that there is a semicolon missing from your monobook and vector JavaScript pages, which could be causing a syntax error and stopping all the scripts from running. In both pages: importScript('User:Js/ajaxPreview.js') should be importScript('User:Js/ajaxPreview.js'); — Richardguk (talk) 17:47, 4 January 2013 (UTC)
SlimVirgin, it's not just you. I have Modern skin and have not been having this problem. But if I change to Monobook, I get the same results you do. Firefox 17.0.1, Windows XP. But if we both get this in Monobook, it's probably not your browser. Maybe something funky happened with Monobook skin. — Maile (talk) 01:48, 4 January 2013 (UTC)
@User:Maile66: There is an error in 2 of your custom CSS pages: a line of JavaScript, which is invalid for a stylesheet. Edit User:Maile66/modern.css and User:Maile66/monobook.css to remove the line importScriptURI('http://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:Haza-w/cactions.js');. Not sure whether that's the cause of your problem, but it can't be good to mix JS with your CSS! Guessing wildly, I suppose it's possible that this has coincidentally produced an error in your Monobook browsing at the same time as User:SlimVirgin suffered an unrelated error, though it might be that there is another underlying problem in one of the scripts used by both of you (you have custom scripts in User:Maile66/common.js and User:Maile66/modern.js, but you have indicated that you are not using Modern). — Richardguk (talk) 02:57, 4 January 2013 (UTC)
Richardguk, thank you for noticing the CSS page errors and telling me how to fix them. It did clear up the Monobook issues to remove the errors. I wasn't having problems with Modern, but removed the error on your advice. — Maile (talk) 15:52, 4 January 2013 (UTC)
Richard, thank you for all this information. I'll go through your suggestions and see if that helps. I've basically had to abandon using Firefox to edit WP with one computer; with the other computer (also Firefox but different version and different OS), I'm getting the problems sporadically but not always. SlimVirginTALK|CONTRIBS04:17, 10 January 2013 (UTC)
Problem using popups to mark pages as patrolled
When attempting to use popups to mark pages as patrolled from Special:NewPages, I have encountered a "Session failure" window continuously for the past several days, and logging out and re-logging back in serves no purpose. What is going on? GotRTalk22:16, 8 January 2013 (UTC)
Browser information could be welcome, plus wondering if anybody else also faces this - if yes, it might be worth to file a bug report in bugzilla.wikimedia.org to make developers aware of it. I tried to find a ticket but the only (not fully related) one was the old https://bugzilla.wikimedia.org/show_bug.cgi?id=38189 which is not exactly the same problem. --Malyacko (talk) 10:31, 9 January 2013 (UTC)
Can't bring up new Commons file version
Hello. I uploaded a file to Commons tonight, then reloaded to correct an error in the file. But on WP I can only see the original version before the reload. I did all the cache-clearing things, I still can see only the original. What am I missing? Thx. Ihardlythinkso (talk) 12:59, 9 January 2013 (UTC)
quote:
The Wikipedia page "Talk:Tau (2π)" has been changed on 5 December 2012 by
JohnBlackburne, with the edit summary: /* Ratio of a Circle's
Circumference to its Radius */ +reflist, so refs show up
The link works here as you can see by clicking it. Notification mails are sent in plain text. There are good reasons for that but it means url's are also mailed as plain text and not in link tags. It's up to the mail software of the recipient whether url's can be clicked, and which strings are interpreted as being url's. It sounds like your mail software doesn't think an underscore is part of a url, or maybe it's because the underscore is followed by text in parentheses. You can copy-paste the url to your browser address bar if your mail software misinterprets it. PrimeHunter (talk) 00:26, 10 January 2013 (UTC)
I added an explanatory note using EFN, and it worked on my sandbox (User:Ɱ/sandbox4), but for some reason, neither the article title nor the note at the bottom of the page displays on the actual page here- The Lego Group. Does anyone know why that happened? Thanks.--ɱ (talk) 23:10, 9 January 2013 (UTC)
Thanks. That's an error that I wouldn't expect to mess up the article title or note. Anyway, now it looks fine. Thank you!--ɱ (talk) 23:37, 9 January 2013 (UTC)
If such a slash is omitted, the tag is treated as a normal <ref> tag, so either of two things might happen to the text between that and the next </ref>: (i) all the "missing" text is actually placed inside the reference, which may give the impression that it's undisplayed; (ii) you get a big red error message. In this case, the next </ref> is just before the text "is a family-owned company based in", with the result that the text up to that point was undisplayed; there is also the error message at the bottom of the infobox:
::::<strong class=error>{{MediaWiki:Cite error included ref}}</strong>
The fact that the error message appears immediately after the "Employees" figure told me to look in the wikicode of the infobox for any ref associated with that figure. --Redrose64 (talk) 08:01, 10 January 2013 (UTC)
Case sensitivity
I'm sure it's been discussed, but did something change recently (last year) with the case sensitivity of page names and template names? I've searched for VP/T for the last few minutes and can't find any recent changes. Thanks, 715:46, 10 January 2013 (UTC)
As far as I am aware, the rule has been unchanged since I started in May 2009: the namespace prefix is case-insensitive, as is the first character after the colon. Everything else is case-sensitive. Where are you having problems? --Redrose64 (talk) 16:04, 10 January 2013 (UTC)
There was a change related to category sorting in MediaWiki 1.17, making the sort order case-insensitive, as well as allowing for improved international sorting according to custom locales (Bugzilla:164). The change was implemented around March 2011. — Richardguk (talk) 18:42, 10 January 2013 (UTC)
This is true: but 7 didn't mention category sorting, so I assumed that it was a q regarding wikilinks and template transclusion syntax. --Redrose64 (talk) 18:52, 10 January 2013 (UTC)
Based on [7] this may be relevant to you: Wikilinks have never been case insensitive after the first letter. The link WP:Irc only goes to WP:IRC if the former has a redirect. The "go feature" of the search box (jumping directly to a perfect title match) was once case sensitive but it became case insensitive around 2009, so entering "wp:irc" or other combinations in the search box would have worked with no redirect. PrimeHunter (talk) 18:58, 10 January 2013 (UTC)
Are suddenly returning "textmissing" instead of what typically what would typically be a formatted diff. This has broken my anti-vandal WP:STiki, and I have to imagine several others. What is going on here? Thanks, West.andrew.g (talk) 20:41, 10 January 2013 (UTC)
In copyediting articles, I often click-and-drag to highlight words and phrases. With annoying frequency, though, a very slight mouse drag highlights an entire section as if I'd keyed Ctrl+A; it just seems very touchy, especially if the text is layered over an image in the edit window. My browser is Firefox 17.0.1; is this a known issue? Thanks for any help and all the best, Miniapolis21:26, 10 January 2013 (UTC)
I don't have problems in Firefox 18.0 or earlier versions. A triple left-click will highlight an entire paragraph. Could there be a problem with your mouse so it registers three clicks instead of holding down the button? PrimeHunter (talk) 00:20, 11 January 2013 (UTC)
If you noticed the first announcement back in Mid-December, the our team has been working on an interface to help new editors without an idea of where to get started on Wikipedia find an easy first task. Called GettingStarted, right now it encourages people who've just signed up to work on easy articles from the copyediting backlog. We're adding more task types and ways to help educate these newbies soon, but since we launched on the 13th of last month, there has been a steady stream of these contributors every day.
To cut to the chase: we wanted to give the community a way to more easily find all the new people using this interface to make their first edits, so we have added a new tag you can see in the edit summary of such edits, via RecentChanges, page histories, or user contribs. This tag — it looks like "(Tag: new editor getting started)" — only appears for the edits to articles currently in the open task list that came via Special:GettingStarted.
The reason we want to point these edits out is because, giving everyone a view of the realtime stream of edits from this interface, not just folks with database access, is important. When the Foundation builds interfaces that encourage all new signups to edit something, it's only fair that the community should be able to inspect all those contributions easily. Also, while the small number of vandals (about 10-12%) are getting correctly reverted and warned, the newbies doing a good job copyediting are mostly getting ignored. Right now the best they get is one of the standard welcome templates, which doesn't really pertain to the edits they made or how they might be encouraged to help out more. It would be awesome if they could get some special attention from the Welcoming Committee or Teahouse folks.
I have a relative who uses Wikipedia. He lost his password, but he doesn't want to have to go through the trouble of creating a new account. The pages that help with lost passwords all say that either an email or username are needed. When we enter the username in, it doesn't work, and there's an error message 'There is no e-mail address recorded for user "X".'. When we try an email address, it says 'A reminder e-mail has been sent.', but as expected, an email never comes to any of the email addresses that I input.
Does Wikipedia really not have any way to reset a password without the usage of an email client? Sure, there's AutoWikiBrowser, which neither I nor my relative have ever used, just like the vast majority of registered users. The same goes for the 'committed identity' feature. Now fortunately, my relative's account has few edits, so a new account registration is far from a total loss; but I strongly feel that Wikipedia should have a function to reset a password without needing an email address, one potential being security questions. Every other site on the top ten websites list has some sort of functionality like the one I describe, so why not Wikipedia? Was there a discussion about this at some point? Even if there was, it's worth bringing up again, as it's a key functionality that every decent website should have as a given. My question is - can my relative recover his account? My request is that someone find a recorded discussion about this sort of password reset possibility and/or start a forum on creating a password reset based on security questions or other related techniques not having to do with email clients. Thank you.--ɱ (talk) 03:36, 11 January 2013 (UTC)
Requests for new features are filed at WP:BUGZILLA. If you tell me your relatives name (or email it to me), I can rename his old account out of the way so that he can re-register the same username. MBisanztalk03:42, 11 January 2013 (UTC)
Thanks for the reply. Luckily, after several days, he finally succeeded in logging in, yet my request for a new system still stands; thus I'll make sure to submit a request for a new feature. Thanks!--ɱ (talk) 03:51, 11 January 2013 (UTC)
Thanks. I don't use the script myself, I just came across it as an issue. If there are equivalent or better scripts, maybe it should be explicitly deprecated (or at least the hyphen replacement part). Rd232talk22:34, 8 January 2013 (UTC)
I can't actually verify that the Ohconfucius script completely accounts for the functionality of the Cameltrader script (in so far as the ability to change per MOS (or otherwise) items in the edit window). You will probably want to ask Ohconfucius himself. --Izno (talk) 01:06, 9 January 2013 (UTC)
AFAIK, my script only performs some of the functionality of Advisor. It was written for my own needs in accordance with my understanding of the MOS, without foreknowledge of the existence of Advisor. My script is regex-driven, and doesn't have any interactive capabilities or possibilties. I could look into all the features of Advisor and maybe incorporate more of them, but I fear my coding/programming skills are not up to the job of maintaining Advisor nor fully reproducing its functionalities. -- Ohconfucius ping / poke01:18, 12 January 2013 (UTC)
Template help needed
Hi en.wp people, this is really a Commons issue, but I thought there might be more people here who could help, and I assume the problem would transfer between wikis.
I would guess that the wikitext parses the gallery tags before transcluding the template, so it gets confused when your template tries to close and then open a gallery inside the outer gallery tags.
Why not simply have the opening and closing gallery tags within your template (and in that order), instead of having the outer gallery tags on the transcluding page?
Similar problems with nested extension tags are often fixed by using the {{#tag:...}}magic word, as that allows templates and tags to be nested without confusing the wikitext parser. But, from a quick look at your sample template, I think the simpler solution above might be sufficient for what you are seeking to do.
Sorry, I'm a bit confused, are you suggesting that I put the gallery tags on the page the template is transcluded onto? Yes, I could do that, but I wanted it to be simpler like this, and now I want to know why it won't work. I'm a mathematician - it's not enough that something doesn't work but a different way does, I want to know why the first way didn't. -mattbuck (Talk) 06:55, 10 January 2013 (UTC)
No, I'm suggesting that all the gallery tags be within the template (if possible); your example has some tags in the calling page and some within the template, which is likely to confuse the parser. In general, templates cannot straddle tag boundaries. So, in your example, they need to be either wholly within a single gallery (but a gallery will not parse section headings inside itself), or each gallery needs to be wholly within your template.
The more technical explanation is that templates are expanded recursively but so are tag elements. Tags parse expanded text, but the recursion nesting is broken if closing tags are at a different expansion level from opening tags. Hence a template that straddles tags will break. Hope that makes some kind of sense!
Also: placing header markup in a template is not a good practice. Do not use = wikimarkup to create section headers within a template which is intended for use in article space — this will create an [edit] link that when transcluded will confusingly open the template for editing. --— Gadget850 (Ed)talk17:51, 10 January 2013 (UTC)
If one simply must have a level 2 heading in a template, the <h2>...</h2> tag can be used - it won't display an editing link when rendered. — Hex(❝?!❞)17:57, 10 January 2013 (UTC)
Templates are markup procedures not text files: To answer the larger questions, it is important to realize that templates are processed as being sub-procedures when invoked, and parameters are only accessible when passed into a template. A template is not a simple embedded text file or segment. As a mathematical analogy, templates are not exactly "substitution by parts" but rather "transform functions" where function f(x,y,z) requires passing parameters {{{x}}}, {{{y}}} and {{{z}}}; otherwise, unless the parameter is passed into the template, then "{{{x}}}" becomes a 7-character literal string with 6 curly braces, similar to f(x,y) treating 'z' as a constant because it is not a variable unless passed into the function. Now, to make Wikipedia more powerful, as allowing substitution by parts, where "(x1+x2)-(y1+y2)" could become "xx-yy" then we would need separate "Text:" files, in the manner of separate Lua script modules:
Template:Aaa1 - contains a markup procedure with parameters
Text:Bbb1 - contains literal markup inserted as substituted text
Module:Ccc1 - contains Lua script to be "compiled" to run
When including a hypothetical file Text:X, then the contents would be rapidly substituted into the markup, and all parameters (or partial tags </gallery>) would be accessible because the contents of Text:X would be literally inserted, as inline text, while parsing the surrounding markup. Hence, that would be an extension to MediaWiki, just as a hypothetical parser function {{#set:x|4}} would reset parameter {{{x}}} to have value "4". Another extension might allow high-level language, such as #then, #else or #endif tokens to enforce the structure of a #ifeq. Similarly, the '#' prefix would allow short parameter syntax, as "#[x]" would mean "{{{x}}}" without all the braces "{{{_}}}" and templates could be coded with fewer squiggly "{{}}" to allow easier checking for syntax errors of template markup (by matching each #then with #endif). The major point is that, in the future, MediaWiki could be easily upgraded to allow much better functionality through a few simple changes, but currently the markup is too limited to allow full "substitution by parts" nor to reset the value of a variable parameter #[x] by {{#set:x|4}}. Such simple advancements are a path for the future. Anyway, thanks for requesting a math analogy for templates. -Wikid77 (talk) 11:33, 11 January 2013 (UTC)
How to mark edit as bot
According to the api, for action=edit, the bot flag must be set for it to marked as bot. When I do bot=true on a post, it doesn't seem to change anything. What does the bot flag do?Smallman12q (talk) 17:33, 10 January 2013 (UTC)
The bot flag, not to be confused with the bot userright, just hides an edit from RecentChanges and other similar pages such as your watchlist; it can be invoked by administrators on all edits by a specific user, as described at Help:Reverting# Bot rollback. The procedure described there still works for admins, because these edits do not appear in the relevant RecentChanges list unless you show bot edits (and even then my edit doesn't appear there for some reason). Graham87 08:36/10:07/10:28, 11 January 2013 (UTC)
Duh, that's because the rollback was marked as a minor edit and minor edits are hidden by default on RecentChanges. Graham8708:51, 11 January 2013 (UTC)
in my browser, the date span appears before the hebrew text for Nochum Shtif when I remove the "born" before the first date (see here). this has something to do with there not being any Latin characters between the {{lang-he}} and the year. is there an easy way to fix this? Frietjes (talk) 00:13, 11 January 2013 (UTC)
For me, in IE9, the image labelled "Modern hiragana n" at Hentaigana is somehow being forced below the image labelled "'Japanese alphabets', including Hiragana, Katakana ...", with the result that it appears in the wrong section ("Modern usage" rather than "Development of the hiragana syllabic 'n'"). When I remove the "Japanese alphabets" graphic, it moves to the correct section. I don't understand why this is happening -- why can't the two images sit level with each other on opposite sides of the page? Is it a glitch in IE? 86.176.208.123 (talk) 03:52, 11 January 2013 (UTC)
For once, IE is behaving correctly: see the rules for floating elements in the CSS specification, rule number 5. What's happening is that the {{Japanese writing}} box, which appears in the wikitext and HTML source before the Modern hiragana n image, is being pushed well down the page by the infobox and the Japanese alphabets image. Due to rule 5, the top edge of the Modern hiragana n image may not be above the top edge of the {{Japanese writing}} box, so it also gets pushed down.
Technically, is there expunge a block from someone's record when all agree that it was an error?
Technically, is there a way expunge a block from someone's record when all agree that it was an error? And if so, who technically has such capability in their toolbox? I've long wondered about this but now know of a case. The last part of the question will be the process for such, but I 'spose I'll need to ask that one elsewhere. North8000 (talk) 04:17, 11 January 2013 (UTC)
My preferred way of approaching this in the case of already-expired blocks would be to block and unblock so there is an explanation in the logs of what happened. It hasn't happened the few times I've suggested it, though. – PhilosopherLet us reason together.13:32, 11 January 2013 (UTC)
I viewed asking the "does it technically exist" question here as step 1. There seem to be conflicting answers, on that, but not on whether a process exists (it doesn't). So I have now proposed it at Village Pump (Policy) Sincerely, North8000 (talk) 13:40, 11 January 2013 (UTC)
Technically, it can be done by anybody with the admin right (as shown by Jcgoble3); but the permitted circumstances are so tight that morally, it shouldn't be done. --Redrose64 (talk) 14:30, 11 January 2013 (UTC)
An idea: can block mistakes be made invisible for the general public, but not for certain user groups? Then we wouldn't have to worry about morals. But I guess that would be the same thing in principle as revdel. HandsomeFella (talk) 17:11, 11 January 2013 (UTC)
I'm trying to hide the rollback links on my watchlist because they're too easy to hit by mistake when reading on my phone. With that in mind, I've tried this in my common.css:
Despite what W3C would like browser writers to do, some browsers are case-sensitive on class names (i.e. .mw-special-watchlist is not the same as .mw-special-Watchlist), although other browsers follow the standard and ignore case. When writing CSS code, it's best to code for maximum compatibility: (i) assume that the target browser is case-sensitive - i.e. having chosen .mw-special-Watchlist stick to that capitalisation); (ii) assume that the target browser is case-insensitive - i.e. having chosen .mw-special-Watchlist don't use .mw-special-watchlist for a different purpose. --Redrose64 (talk) 09:43, 7 January 2013 (UTC)
Yuck. I wasn't aware that some browsers (Chrome, I'm looking at you) contravene the spec. I've never used uppercase in my class names, so hadn't run into this particular issue before. How ridiculous; it reminds me of when I discovered a crash bug in Netscape Navigator 4.7 for Mac (really dating myself here) that was triggered by an uppercase tag attribute. Just say no to case-sensitivity! — Hex(❝?!❞)10:00, 7 January 2013 (UTC)
You misunderstand the spec. CSS says element names (e.g. table), attribute names (e.g. style), and properties (e.g. display) are case insensitive, but CSS declares they have no control over IDs and class names. I believe the HTML5 spec requires IDs and class names be case-sensitive, and that all modern browsers show that behavior. Dragons flight (talk) 16:45, 23 March 2013 (UTC)
Since you gave your use case, you might want to look at CSS media queries (tutorial). In this case, you could try:
@media only screen and (max-device-width: 480px) { .mw-special-Watchlist .mw-rollback-link { display: none; } }
You can tweak the width as needed. It should work if you have a recent phone, while still showing the links on your desktop. Superm401 - Talk00:19, 13 January 2013 (UTC)
Conversion function not simplifying the result for the lower end of a range
I believe the problem is in the rounding part - 3.95 meters is about 12 feet, 11.514 inches. Take these numbers as finl, then round the inches to the nearest whole number, and you land with 12 feet and 12 inches. עוד מישהוOd Mishehu09:52, 8 January 2013 (UTC)
That much was obvious. A similarly discernible bit is why it happens only at the bottom of a range. This single conversion is okay:
Use Convert/2 until fix for Template:Convert/Dual/prand2: I think a change inside the 2-unit-range rounding subtemplate Template:Convert/Dual/prand2 might fix the problem, and round inches from 11 to 0 while carrying 1 to add to feet. However, the wrapper template for 2-amount ranges, Template:Convert/2 (from 2011) can be used now for correct results:
{convert|3.95|to|5.5|m|ftin|0|abbr=on} → 3.95 to 5.5 m (13 ft 0 in to 18 ft 1 in)
I am thinking that {Convert/2} should be considered as a replacement in many other range-conversion articles. There are also {Convert/3} and {Convert/4}, to convert 4 amounts at once. I apologize that this was not a priority to note earlier, as the "12 in" error in ranges has been known for years, but thanks for the reminder. -Wikid77 (talk) 10:07, 11 January 2013 (UTC)
I've reverted. It will not be damaging to the article for the incorrect display while we wait for a fix in T:Convert. --Izno (talk) 16:27, 11 January 2013 (UTC)
Convert/2 is the general fix for T:Convert ranges: In general, Template:Convert/2 has fewer problems, and allows more options, than the basic ranges with Template:Convert. Also, corrections to the protected subtemplates of {Convert} have taken months or years due to "paralysis of analysis" where the impact of changes could only be "imagined" because of limited trial-and-error progress with protected, unchangeable subtemplates of subtemplates of subtemplates of subtemplates. Honestly, I have been trying all century to "fix" Convert, with limited slow success over the years, because Convert was a massive 12-year project, and it has only been 7 years so far. Meanwhile, Convert was restructured to support wp:Wrapper_templates, so thereby, complex interactions in the "creeping featurism" could be reduced by multi-level, higher template structures which combined simple functionality at higher levels of outer-nested wrapper templates, such as Template:Convert/4 to handle 4 conversions each with the accuracy of the single-amount form of Convert. Long story short, {Convert/2} is really "Convert" fixed to support all 2-number ranges, just as {Convert/3} is the way to handle 3-number ranges, or {Convert/spell} is used to spell-out numbers in English-language phrases for conversions. I hope that clarifies why {Convert/2} is the real deal for ranges. -Wikid77 (talk) 12:11, 12 January 2013 (UTC)
Is there a way to filter out old contributions when using special:contributions
Currently the contributions special page allows you to set a filter to see only contributions older then a certain month/year. Is there any way to do the opposite, and see only contributions newer then a month/year? When trying to check the recent activity of an IP range, the ability to do so would be very useful. Monty84504:42, 12 January 2013 (UTC)
Go to the contribs page for the user that you're interested in, and click on the "older 50" link, then the "newer 50" link - this might take you here. In the address bar of your browser, you should now see that the query string includes something like &offset=20130111171635 (n.b. some browsers hide this until you actually click inside the URL bar) - that is a date and time for the oldest edit that you're interested in, it's formatted CCYYMMDDhhmmss. Say you wanted the contribs of this user from 21 June 2010 on, beginning at 14:25 (UTC). You'd alter that portion of the query string to &offset=20100621142500 which gives this. Note the presence of &dir=prev - that indicates that &offset= refers to the earliest date/time (by default it's the latest). --Redrose64 (talk) 11:49, 12 January 2013 (UTC)
Upgraded Template:Inflation for commas and messages
As discussed since 9 November 2012, I have finally upgraded Template:Inflation to allow commas and show error messages (plus options "fmt=c" or "fmt=eq"), after a "few" 64 days of consideration (or distractions). Instantly, I had to remove validation of parameter 1, the nation country-code, because there are many and more can be created at any time. Discuss at:
I posted this notice here because this is the first major upgrade to {Inflation} since 2008, and might cause shock despite 64 days of planning. Also, sorry to delay a few days as 64 days, but many other templates have been improved or created. -Wikid77 (talk) 11:23, 12 January 2013 (UTC)
Yes I meant the equivalent of the orange bar - thanks for those details though. Checking the revision number would work fine of course. Looks like I'll have to use a more complex algorithm anyway, as I am developing a more fine-grained control system. RichFarmbrough, 00:25, 13 January 2013 (UTC).
In Star Trek, the the padlock for pending changes and the the speaker icon for a spoken version of the article overlap. Does anyone else see this, or know why they overlap? I'm using Vector. Chris857 (talk) 00:15, 13 January 2013 (UTC)
Confirmed in Iceweasel 11 and Vector. It looks like a CSS issue (right and margin-right are explicitly specified, and there's a collision). The fix isn't clear, since of course the exact set of icons varies and you don't want big gaps. Superm401 - Talk00:31, 13 January 2013 (UTC)
I'm using Firefox 18 under Windows XP, and in both Monobook and Vector I see the top icon for {{pp-pc1}} overlapped by File:Sound-icon.svg; to their right is the top icon for {{good article}}; to their left is the little "Accepted (latest)" pull-down menu box.
(edit conflict) Normally, when you view a redirect page, all you see is an arrow and a link to the redirect's target, plus any categories.
It used to be that when viewing the diff of a redirect, any templates got expanded and displayed - but this seems no longer to be the case. I suspect another unadvertised change in MediaWiki. --Redrose64 (talk) 23:23, 13 January 2013 (UTC)
At Wikipedia:Help_desk#clearing_cache_for_images, I was encouraged to post here. Older versions of images that I have cropped are appearing. In adddition to my primary machine, which may have cached images, I have logged onto wikipedia from two other machines that should not have cached images. I have also tried alternate browsers. Here are pages where old versions still appear on alternate machines:
Tim Hardaway, Jr. - all the images in the Junior year section. The 3rd image in the junior year section.
What baffled me over at the Help desk is that I am seeing the new versions of the images even though TonyTheTiger is seeing the old ones. Is there more than one image thumbnail server? -- John of Reading (talk) 21:29, 12 January 2013 (UTC)
I'm seeing the new image at Fast break, but the old ones at Tim Hardaway, Jr. and Layup. What's more, on Hardaway, I'm seeing the old version squeezed into the proportions of the new version. Having never viewed the articles or images before, and being on a brand new computer, there is no way I could have cached versions of the images. jcgoble3 (talk) 22:00, 12 January 2013 (UTC)
This happens it's a known bug, I have reported it to this pump before, but I can't remember if there is a bugzilla for it (or a workaround) - looks like PTG is correct though. RichFarmbrough, 00:51, 13 January 2013 (UTC).
Is there a way to use {{REVISIONTIMESTAMP}} or something similar but get the most recent revision of a different page. For example {{REVISIONTIMESTAMP|User:Patchy1}} would get the most recent revision of my userpage, but show it here? -- Patchy101:30, 13 January 2013 (UTC)
Just to double-check, are you trying to get the timestamp (an actual time), or the revision ID (an ID used for tracking versions, e.g. for diffs)? Superm401 - Talk20:34, 13 January 2013 (UTC)
It seems like more trouble than it's worth, and it's poorly documented.
Apologies if this is the wrong forum. I was really confused and annoyed by it, and the nice folks in IRC linked me here when I asked where to go to complain. The Editorial Voice (talk) 22:24, 13 January 2013 (UTC)
As you state that "it's poorly documented" (which might be true), could you describe better or provide links to the documentation that you found? Thanks in advance! --AKlapper (WMF) (talk) 13:58, 14 January 2013 (UTC)
Could someone please take a look at why there are a bunch of Failed to parse (lexing error) messages on that article? Thanks, It Is Me Heret / c16:39, 14 January 2013 (UTC)
I've found the MathJax option in Preferences, which side-steps the issue, but you need to be signed in to enable it. Cheers, Refried (talk) 20:00, 14 January 2013 (UTC)
Hello, I uploaded a PNG file File:Heartbeat timeline.png which is 742 × 1,286 pixels. When I click on the "Full resolution" link at File:Heartbeat timeline.png, IE9 initially displays a scaled-down image with a magnifying-glass icon when I hover over it. When I click again I get a scaled-up image which is larger than 742 × 1,286. There doesn't seem to be any way to get the image displayed at the actual correct size. Is this something I am doing wrong, or something Wikipedia is doing wrong, or something IE is doing wrong? (I know I can force a pixel size when I include it in an article, but in the article position I want, the full size would be too big. I want a thumbnail that users can then click on to view full size.) Another Matt (talk) 21:24, 12 January 2013 (UTC)
This seems to be a browser trick to re-render an image to fit the window, it happens to me with Palemoon (effectively Firefox), but once I click the magnifying glass I get an image with the properties "742px × 1,286px" (rt click, image properties).
Media:Heartbeat timeline.png is also 742px × 1286px for me. You didn't write a pixel size for the largest version. How exactly are you evaluating the size? If you visually compare it to your screen resolution then are you sure you know the right screen resolution? Note the image is higher than wide while screens are nearly always wider than high. My screen is 1024 × 768 and the full image displays at a little less than twice my screen height, but less than one screen width. PrimeHunter (talk) 00:41, 13 January 2013 (UTC)
Thanks for the replies. I know that the larger size displayed by IE is more than 742px × 1286px because I know what the image looks like on my screen when displayed at the correct "100%" size in other programs. I've just physically measured it against the screen and it's roughly 850px wide. I don't know where that enlargement factor is coming from. I have just realised, of course, that I can open the file direct from my hard disk in IE, and exactly the same thing happens. So that rules out it being anything to do with Wikipedia. If it is the right size in other browsers then maybe it is a random adjustment that IE is making? I also wondered about the "Metadata" at File:Heartbeat timeline.png saying "resolution 47.24 dpc", which I'm guessing is "dots per centimetre". I'm wondering if IE could be somehow trying to use that information, although the numbers do not seem to come out right (on my screen the "full size" width is considerably more than 742/47.24 cm). Another Matt (talk) 01:16, 13 January 2013 (UTC)
Do you have zoom enabled in IE? Zoom is reset to 100% with Ctrl+0. It can be changed up and down (sometimes accidentally) with Ctrl++ and Ctrl+-, or Ctrl and mouse wheel scroll. PrimeHunter (talk) 02:11, 13 January 2013 (UTC)
Oh, that's it. I feel like an idiot now. I always deliberately set it to a bit more than 100% because I find the type a bit hard to read these days. I completely forgot that would affect the displayed size of the image!! Thank you so much!! 86.129.18.113 (talk) 02:24, 13 January 2013 (UTC)
Change the font size in your browser instead of the zoom level. Then text will be more readable without causing discrepancy in how you expect images to look. ⇔ ChristTrekker14:27, 15 January 2013 (UTC)
You were probably using the mobile site; there should be a link to the desktop site, possibly from a "Wikipedia" menu. There may be other problems, depending on which browser is used - some browsers cut of the end of the page in the edit window or when saving, and others don't allow editing at all - I've occasionally used Opera Mobile to edit, so it is possible. I don't know if the model of phone would make a difference. Peter James (talk) 11:06, 15 January 2013 (UTC)
Every few months I edit a page using my HTC Evo V 4G. Must open the "Desktop view" at the bottom of the page, and the cramped four inch screen and keyboard do not make it easy. The Go Keyboard app helps a little. Your bigger screen will probably make it much easier once you become accustomed. Jim.henderson (talk) 13:19, 15 January 2013 (UTC)
I guess from your comment at Template talk:Sister project links#Link to Wikivoyage that by broken you mean that it had become opt-out instead of opt-in, and Aaron Swartz has no opt-out, like a lot of other articles where WikiVoyage lacks information so voy=no would have to be added. Making it opt-out was the whole point, but I don't know whether it's a good point when the majority of uses would probably require voy=no. PrimeHunter (talk) 22:46, 15 January 2013 (UTC)
Code help, please
I need to use ifeq and the NAMESPACE magic word in a template so that if the template is on an article, category A is applied; if a user page, category B, if a talk page or other namespace, nothing. How may I do that, please? I'd be happy to be pointed at a tutorial, but searching for one found nothing helpful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:18, 15 January 2013 (UTC)
I think it's from the {{S-rail}} template which seems to parse into calls to the X color, lines, stations and style templates. Unless the style templates got deleted, I think they just didn't get created. Maybe just let the WP:Trains project know about it as someone familiar with those templates needs to create the missing styles. Ravensfire (talk) 01:29, 16 January 2013 (UTC)
Why does the pending changes add-in display "Accepted (latest)" - this is just noise, if there are no pending changes, it's like a normal page. RichFarmbrough, 00:27, 13 January 2013 (UTC).
I'm not sure. Perhaps it is intended to explicitly tell readers (of course, editors are readers too), "Everything has been reviewed". However, I can see why you might think it's clutter. Superm401 - Talk00:38, 13 January 2013 (UTC)
Sometimes the "accepted" version is in fact a bad version; this provides the means to both view the review log, and to un-accept the change. --Redrose64 (talk) 10:07, 13 January 2013 (UTC)
On Lance Armstrong, whenever I click "show" or "hide" in either the "medal records" section of the infobox or on "voided results" under the "Palmares" section, I get kicked all the way back to the top of the page, and my address bar shows that a # has been appended to the URL. This does not happen when opening or closing navboxes at the bottom of the page. Firefox 18.0, Vector, and Windows 8. jcgoble3 (talk) 23:16, 15 January 2013 (UTC)
I have been having that problem with an outdated Firefox version (v11?) + Vector + Windows 7 on any show/hide link, and the same problem as Jcgoble3 for those specific show/hide links mentioned, in Firefox 18 + Vector + Windows 7. I don't expect a fix for the old version of Firefox, but it's probably the same problem. I can only assume this is related to the weekly rollout of a new version of software, but why were these affected? --Izno (talk) 01:21, 16 January 2013 (UTC)
The link is set by pagecategorieslink, which currently defaults to "Special:Categories". There used to be a customised enwiki link (deleted in 2008 with the log summary: "Now updated in MediaWiki defaults"). So the above proposal could easily be implemented on enwiki if editors support it. (Changing the link for all wikis would need a bugzilla request to edit the default value in languages/messages/MessagesEn.php.) — Richardguk (talk) 11:26, 16 January 2013 (UTC)
Shall we be bold and have it done or should it be discussed? I think we should go for it (but I have to say that ). It can alway be undone if there are objections but I would be surprised if there will be any. -- Alan Liefting (talk - contribs) 20:12, 16 January 2013 (UTC)
There have been several discussions recently about what exactly the 'autochecked' user rights group does. Special:ListGroupRights says Have one's own revisions automatically marked as "accepted" (autoreview), but it's unclear if this applies just to Pending Changes Level 1, or to Level 2 as well. In the previous discussions I was informed that its primary purpose was related to PC2, but I was a bit confused, namely by the fact that the [Accept: require "review" permission] phrasing would seem to imply that Autochecked wouldn't work on a PC2 article. And since I thought this could be relevant to the PC2 discussion over at AN, I thought it would be useful to figure out. So, I asked Prodego if he'd mind adding Autochecked to my alt account, User:FRC&AND. I made several test edits, two to Wikipedia:Pending changes/Testing/1 (PC1) and two to Wikipedia:Pending changes/Testing/4 (PC2). And, surprisingly, neither pair was automatically accepted (reviewing logs: [10][11]). So, umm, what's up with this? Is this some sort of bug, or does it have something to do with how we've configured PC, or did I just screw something up in testing this? — Francophonie&Androphilie(Je vous invite à me parler)08:30, 16 January 2013 (UTC)
Before it went live back in December, I made quite a few test edits (both with and w/o reviewer) on the test pages. None of them worked the way they should have. I think the test pages are just very very buggy for some reason. Theoretically, the software doesn't differentiate between the autoreview right a reviewer has, and one a "autochecked" user has. So it's kind of like giving them the ability to edit PC2 pages without being able to review other edits, i.e. it may be useful for someone who's working on a PC2 page a lot and doesn't wish to flood #wikipedia-en-pcconnect with their changes (or Special:PendingChanges). I think that it may help in the inevitable RfC on PC2 to get editors to agree with PC2, but not sure. Does that help a little bit? gwickwiretalkedits18:43, 16 January 2013 (UTC)
Hmmm. It also occurs to me that this could be because the account isn't autoconfirmed. Would an admin mind confirming it? This would also allow me to try making a dummy edit to one of the PC2-protected articles, if it really just is that the sandboxes are buggy. (Though I obviously will only do that as a last resort, and in a way with no visible effect on the article.) — Francophonie&Androphilie(Je vous invite à me parler)19:24, 16 January 2013 (UTC)
When I look at this in Microsoft Internet Explorer, the first and last of the four portal boxes on the right appear identical to me. Not so in Chrome – Wbm1058 (talk) 20:59, 16 January 2013 (UTC)
Absolute max-width and width properties are not supposed to be specified together, so there might be a better solution than supplying a width via |boxsize=.
I think the problem is with the way Chrome applies the "max-width:175px;" style which {{Portal}} applies to the table containing the portal links, because the table is surrounded a div element of unspecified size.
One solution might be to move the max-width property from the table styling to the div styling in the previous line of the template code.
Brief read-only test on English Wikipedia in 25 minutes
In preparation for the migration to the Virginia datacenter, we're performing a brief (less than 5 min) read-only test of English Wikipedia. This is in anticipation of what could be longer read-only time next week as we're migrating. Apologies in advance for the inconveniece. -- RobLa-WMF (talk) 20:36, 16 January 2013 (UTC)
Just to make sure this is clear, 25 minutes from now Wikipedia will go into read only mode for 5 minutes. Then next week the Wikimedia servers are being moved and Wikipedia will be in read only mode at random times on the 22nd, 23rd, and 24th? RyanVesey20:42, 16 January 2013 (UTC)
Yup, more or less. We're running a little bit behind for today's test (hence why I'm able to leave this comment). Next week, the migration starts in earnest at 9am PST on January 22nd. If we're extremely lucky, that goes smoothly and we're done in an hour (though we're planning on file storage work affecting images/media on January 23rd). This is a tough enough job that we're almost certainly not going to be lucky, though, so expect things to be bumpy. -- RobLa-WMF (talk) 21:07, 16 January 2013 (UTC)
might be a good idea to off (IOW, remove) the "edit" links on pages and sections, say, 10 minutes or so before the "read only" mode takes effect. this will reduce the number of people who will lose work because suddenly the "save" button does not work.
Yesterday was a bummer with incredible slowness and one brief outage. Today, it's not as slow as yesterday, but still slower than it should be on Saving. In checking the Signpost, this does not seem to be the target period for issues created by the primary data switchover. I'm thinking it's not just me. But is this going to improve soon? — Maile (talk) 16:22, 17 January 2013 (UTC)
Could this have anything to do with why two images I updated on Commons, said updates becoming visible in WP File space almost immediately, are not being updated in an article? ~ J. Johnson (JJ) (talk) 22:33, 17 January 2013 (UTC)
Many of the script-based formatting functions have suddenly stopped working for me. My watchlist looks as it does in a very old browser: all in plain text—sidebar & page-top links included—and multiple edits to the same page are all shown instead of being summarized with disclosure triangles as usual. My Preferences page doesn’t show the usual row of tabs at the top: everything appears in one long page. Collapsed content is displayed by default instead of being hidden. The widget that lets me preview pages by hovering over links (I forget its name) has also stopped working. I’ve tried quitting & relaunching my browser: no difference. The Edit page here looked normal when I started, but now that I’ve clicked “Show Preview” it also has lost the sidebar, backgrounds, and page-top links. Any suggestions as to what may have gone wrong?—Odysseus1479 (talk) 03:28, 18 January 2013 (UTC)
I thought you were arbcommed because somebody noticed that in two consecutive edits you made exactly the same spelling correction to two different articles, which they construed as "making automated edits". --Redrose64 (talk) 11:41, 18 January 2013 (UTC)
Is there a way to sort pages linked by "what links here" in the order of date-time when the link was last added (to cover the case of multiple links) ? Any external tools? Shyamal (talk) 03:59, 18 January 2013 (UTC)
This would be relatively resource intensive, so I think you would need to request something from a toolserver user. I am not aware that any such tool exists right now. RichFarmbrough, 10:26, 18 January 2013 (UTC).
I agree that it is resource intensive but it is more or less like the pagelinks table combined with a blame feature. Shyamal (talk) 14:10, 18 January 2013 (UTC)
Templates with “-“ in the name in diffs
The new diff web interface (since 1.20) works incorrectly with hyphens in the name of a template, as one can see at [12]. Namely, it generates wrong /wiki/Template:-link and title. For “{{Box-drawing sample}}”, I get an HTML code:
I assume you're talking about the WikiEd diff viewer (which links templates), not the standard MediaWiki one (which does not). If so, this isn't the kind of thing which should be posted to Bugzilla. Instead, follow the bug report guide at User talk:Cacycle/wikEd - Kingpin13 (talk) 11:12, 18 January 2013 (UTC)
You also forgot your manners. There's no need to use excessive letter-spacing. It makes you look like a jackass. Sometimes we mis-read or overlook parts of a post. It's part of being human. Repeating yourself with emphasis is fine, just try to be nice about it. :-) (And, for what's worth, the title and href attributes you pasted above look fine to me. I don't doubt that there's a bug, I just think you didn't report the bug very well. ;-) --MZMcBride (talk) 03:51, 19 January 2013 (UTC)
Green pop up from Commons
"Vote for your favorite picture in the Commons 2012 Picture of the Year contest" is a green banner pop up appear at the top of pages. Not good. It could so easily be taken as a virus. As you scroll down, that pop up stays and obscures text on the page. How do we disable that? — Maile (talk) 00:13, 19 January 2013 (UTC)
Yeah, and if you want to go to Preferences or something on that line, it totally obscures it so you can't access your own settings. — Maile (talk) 00:16, 19 January 2013 (UTC)
As part of the various statistics I run over Wikipedia page view data (e.g., WP:5000), I've observed that for every 10-day table I produce, I have 80 million rows, where rows are "viewed items". I only process en.wp and exclude any items that contain a semicolon (which should limit things to article namespace). English Wikipedia only has about 4.5 million articles. I know that titles before redirection are included in this raw data, but I don't feel it can possibly account for the massive jump up to 80 million items. Thoughts? Thanks, West.andrew.g (talk) 04:24, 19 January 2013 (UTC)
There are many articles that have a ":" in their titles. If you are using the same summary data I used then you have a sufficiency of page names, times 10 days. You will also have a serious number of double escaped wrongly escaped and other cruft in there (I cleaned most of this up but I wonder if that actually is good methodology). Not to mention any attempts to access deleted pages or deleted redirects, or otherwise non-existent pages (by URL of course). RichFarmbrough, 06:27, 19 January 2013 (UTC).
Over the last few weeks, I've had it happen to me a few times. Hasn't happened lately, until today. Keeps kicking me out off and on. — Maile (talk) 00:29, 20 January 2013 (UTC)
keeping all interwiki bots away from an article
Lads, quick question, is there any way to prevent all interwiki bots from touching an article? Is there any tag or template or something that you can put in an article so that interwiki bots will leave it alone? Thanks very much, Azylber (talk) 11:30, 18 January 2013 (UTC)
Hi Legoktm, thanks very much for your quick answer. I take it there's nothing specific for interwikis. But this will do! Cheers, Azylber (talk) 11:42, 18 January 2013 (UTC)
I think there is something specific for Pywikipediabots, which do most of the interwiki work. BUt it is useful to resolve the underlying issues with these cases. Last time I looked we had two or three articles where interwikis were a problem, prevented by {{Nobots}}, and they were all amenable to solution. RichFarmbrough, 12:03, 18 January 2013 (UTC).
Cool. And one more little (albeit perhaps silly) question: is that template with the new "interwiki" parameter supported across all of Wikipedia? (i.e. across all languages) Azylber (talk) 12:45, 18 January 2013 (UTC)
I've made some responses to other editor's comments on article talk pages in which I've attempted to cite sources the same way I would in the article itself. Unfortunately, upon saving those comments, the reflist template seems to appear and/or disappear in random locations, including in the middle of completely unrelated sections, which makes the talk page itself extremely confusing to view, which I assure you, is not my intent. Talk:Padmasambhava is probably the best example of this.
I know I must be doing something wrong here, but honestly have no idea what. I can't imagine there aren't already guidelines in place to handle source citations on article talk pages, but must admit: I haven't yet managed to find them. Any guidance would be very much appreciated. :^) :^)
I can't see what is going on either but multiple reference lists in any page need delicate handling. See Template:Reflist#Multiple_uses and Help:Footnotes#Multiple_reference_lists. Why not try avoiding using footnote style at all but simply have bare URLs or a list of formatted references truly in line and not as a footnote? If you use some gadget to format your references, simply remove the <ref> and </ref> from each one before saving. Thincat (talk) 12:06, 19 January 2013 (UTC)
After the error about missing reflist was added, the message started appearing on talk pages and a lot of editors got upset, so we now suppress it on talk pages. The downside is that you can't see that someone added footnotes elsewhere without a reflist. As Thincat referenced, using multiple reflists can be tricky. Basically, you need {{reflist-talk|close}} to close each reflist. {{reflist-talk}} is just a variant of {{reflist}} for talk pages that adds a box to offset the refs. If you want to see the error messages, on a talk page, see Template:Broken ref#Showing cite errors on other pages. I refactored the page in question to fix the issues. --— Gadget850 (Ed)talk13:15, 19 January 2013 (UTC)
Javascript redirects for Special:MyPage/skin.css or Special:MyPage/skin.js not working
I recently moved a big page with many revisions (2008 South Ossetia war → Russia-Georgia war, 11,833 revisions, plus its talk page with 13,592 revisions, plus multiple talk archive pages). In doing so, I got a "bigdelete" error message ("You do not have permission to move this page, for the following reason: This page's edit history exceeds 5,000 revisions. To prevent accidental disruption, its deletion is restricted to stewards"), although the message didn't say which of the pages in question it referred to. It must have referred to one of those pages itself, as I'm pretty certain there wasn't such a big history on any of the target locations that had to be technically deleted to make way. But whatever it was, despite the warning, all the pages were in fact moved normally.
Questions:
Is it true that the "bigdelete" restriction of 5,000 revisions is meant to apply not just to deletions but also to moves?
That's weird. For what it's worth, I just got a Wikimedia timeout error when I moved the same pages to the title "Russia–Georgia war" (with the correct dash). I don't think the Wikimedia sysadmins would want us doing too many more experiments of this nature. :-) Graham8713:16, 19 January 2013 (UTC)
As far as I know "bigdelete" applies only to deletions (and restorations), not to moves. The above page was moved successfully despite a timeout error. Ruslik_Zero18:25, 19 January 2013 (UTC)
Icon floats to the top of my talk page
The Guild of Copy Editors' newsletter notices (example here) include a Guild of Copy Editors icon, which is supposed to appear on the right side of the notice. But on my browser (Firefox 3.6.28), the icon appears in the upper right corner of the talk page.
I see this problem on every page that has a GOCE notice, whereas other users don't (discussion here). I've determined that the problem isn't my Wikipedia settings by logging in on a different computer, where the problem doesn't appear. But on my preferred computer and browser, the only way to keep an icon from floating to the top of the page is to have another GOCE notice above it, in which case the uppermost icon floats to the top and the others stay where they're supposed to be. The bug is minor, but a bit annoying. Does anyone know how to stop it? A. Parrot (talk) 21:52, 19 January 2013 (UTC)
You are long overdue for an upgrade to Firefox. The automatic updater in 3.6 and earlier only picked up minor updates and doesn't download or notify you of major updates, which you have to go to http://www.firefox.com to obtain manually. The current version (18.0.1) displays the icon correctly. jcgoble3 (talk) 22:25, 19 January 2013 (UTC)
Sigh. I can't update any farther because of a long string of backward compatibility issues. I suppose I'll just have to live with it. A. Parrot (talk) 00:23, 20 January 2013 (UTC)
Bar above edit box
Hi there all! Is there a way I can get rid of the bar that appears above the edit box? When loading a page for edit I start typing but after a second or two the bar appears and takes focus away from my edit box. I never really use it so is there a lovely bit of js or css I could use to remove it? Cheers. ·Add§hore·Talk To Me!22:37, 19 January 2013 (UTC)
Found it! Not under Advanced options but Usability features and unticking 'Enable enhanced editing toolbar' and 'Enable dialogs for inserting links, tables and more'. Cheers! ·Add§hore·Talk To Me!02:00, 20 January 2013 (UTC)
Are self-contained footnotes in template possible?
Resolved
I was trying to add footnotes to the Template:Kim Jong-il family chart. But I quickly discovered that having footnotes and a reflist tag in a Template throws an error on the article when the template is used. How can I achieve what I was trying to achieve? Jason Quinn (talk) 01:02, 20 January 2013 (UTC)
I see your Reflist was in <noinclude>...</noinclude>. If you only want the references to be displayed on the template page then place each <ref>...</ref> inside a <noinclude>...</noinclude>. Or do you also want the references to be displayed in articles using the template? PrimeHunter (talk) 01:20, 20 January 2013 (UTC)
I re-added the ref and placed it in <noinclude>...</noinclude> tags while PrimeHunter was responding. If that's what you were after, then it should be solved. jcgoble3 (talk) 01:28, 20 January 2013 (UTC)
I was hoping to have the references also show in the article too. At this point, I'm curious if it can be done. I've desired this ability in the past too. Your idea is an improvement, and if what I want isn't possible, I'll keep your idea. Jason Quinn (talk) 01:50, 20 January 2013 (UTC)
PS I also realized that I screwed up the nested of the noinclude tags. I didn't want the reflist tag inside the noinclude scope. I fixed that but the referneces still don't appear on the article. Actually, I think I'm okay with references only appearing when the template is viewed as per Jcgoble3's solution. But I am still curious if what I was asking can be done. Jason Quinn (talk) 01:57, 20 January 2013 (UTC)
PPS I figured it out. My problem was caused because I lost track of the noinclude. It's the simple solution: just add a ref and add a reflist and it works. My first reflist was noincluded so there were problems but I didn't noticed it wasn't included. Mea culpa. I'm tired. Thanks for the replies. Jason Quinn (talk) 02:02, 20 January 2013 (UTC)
Suppressing Article Feedback tool on dabs
Hi. I've been seeing the feedback tool (v4 mostly) on a lot of dab and set index pages, where they aren't really helping at all. Is there a magicword or something that can be used to suppress their appearance? Intelligentsium04:46, 20 January 2013 (UTC)
I believe applying Category:Article Feedback Blacklist should remove the feedback tool. You may want to check if there's a common template used by many or all of the pages in question, but no others (such as a specialized disambig or set index template), and add the category to that template instead. jcgoble3 (talk) 05:29, 20 January 2013 (UTC)
{{Disambiguation}} should be transcluded on most of them, so adding the template to the category should hide them all. (edit: actually, disambig already has the category. Do you have examples of disambig pages with AFT on them?) (X! · talk) · @294 · 06:03, 20 January 2013 (UTC)
Hm... the examples I've seen have all been set indices and disambiguations that are mistakenly marked as such. I'm going to add the {{surname}} template to that category also then. Intelligentsium06:10, 20 January 2013 (UTC)
The problem with adding the category to the surname template is that surname pages often have content alongside the disambiguation, which causes issues. (X! · talk) · @301 · 06:13, 20 January 2013 (UTC)
I see your point. However, I don't believe pages like Spiridonov which are essentially dabs and probably will never become anything more need the feedback tool (pages like Smith (surname) on the other hand, do). The vast majority of pages on which {{surname}} is transcluded seem to fit this latter description. Is there an alternative solution that doesn't involve large-scale changing of pages? Something based on the page's size perhaps? Intelligentsium06:23, 20 January 2013 (UTC)
I feel as if it's one of those things that should get its own parameter, and then added to the articles that need it. (X! · talk) · @310 · 06:26, 20 January 2013 (UTC)
Yes, that was my first thought too, but even if the default were set to no feedback, there may be hundreds of pages with content that it would have to be added to (a drop in the bucket compared to the 21000 or so that use the template, but still). The alternative of course, it to use feedback as the default and suppress feedback as needed when spotted (obviously I'm not going to bring ~20000 pages into compliance all at once) but sheer scale would be a constraint to how effective this could be. (The set indices also do not generally get a lot of hits, so some of them will inevitably be missed). Still, this isn't exactly a mission-critical feature and the wiki will not die if a page that should not have feedback has it enabled, or vice versa. Intelligentsium06:41, 20 January 2013 (UTC)
Crawler bots effect on page views
Following on from a query made to the cultural-partners mailing list, I'm curious about this, which no doubt has been discussed before. How best to estimate the number of page views that are actually bots? Is it a fixed number for all articles, or will it vary with the popularity of the article? User:Mike Peel pointed to this page, showing about 15% of ?all Wikimedia page requests are from bots, but what does this mean for the average en:WP article? Johnbod (talk) 16:25, 20 January 2013 (UTC)
Useful links disappeared from botton of Nostalgia skin
Ever since early December 2012, the English Wikipedia does not have the row of handy links at the bottom of pages any more. It looks like this only applies to the Nostalgia skin, which I use. It also only seems to have happened to a few wikis, (e.g. these links that use Nostalgia on English and German, but not on French or meta). I was wondering if anyone knows why it happened, and if there is any chance of some of the links being restored. The links I am talking about are the ones that look like
Edit this page | Watch this page | Discuss this page | Page history | What links here | Related changes
| Move this page
I use the Nostalgia skin because it seemed the simplest way to get rid of the left-hand margin and avoid overriding browser fonts. I most often used this row of links to see if a page was on my watch list, to change the watchlist status, and for the “What links here” function. Recently I have been resorting to typing in the URLs manually. Vadmium (talk, contribs) 04:21, 21 January 2013 (UTC).
Yes, they're (i) the first character and (ii) the first two characters of the image's hash code. Each character can be in the ranges 0-9a-f, so there are 16 possibilities for each, therefore the chance that these characters are the same for any two images is 1 in 256. I don't know which hashing algorithm is used: it might be MD5, SHA-2, or something else. --Redrose64 (talk) 17:36, 18 January 2013 (UTC)
In wikitext, the {{filepath:...}} parser function returns the URL for any specified file – but only if it has already been uploaded. For example: [{{filepath:SummitArenaAndConventionCenter.jpg}} this] produces this link.
But bypassing the file description page by linking to the file directly might breach the attribution requirements of the file authors, so a conventional File: link is usually appropriate.
Presumably the subdirectories are used so that multiple servers can store files instead of having them all in one location. For 1 in 256 files, the path will contain ".../a/ad/...", which has sometimes confused adblockers into not displaying those files. — Richardguk (talk) 18:36, 18 January 2013 (UTC)
Just to clarify: "the first two characters of the image's hash code" - the digits are the md5 sum of the image's file name (not the hash code of the image). 129.173.209.17 (talk) 15:57, 21 January 2013 (UTC)
Thank you. And how, then, on the English Wikipedia solve the problem of the dead links and move permanent links to external web sites? This is a common problem, and the archive manually all of the links for a very long time.
Oh, and is there a manual to bots, You indicated? If they can work in other wiki-projects? Thank you.--
I think is is a REALLY important issue to address. To prevent Link rot on so many pages, a bot is necessary to not waste human time on tedious manual web archiving. It would be great if somebody who knows how, puts a bot in place for this purpose. Regarding WebCite unresponsiveness, I believe they are going through some financial troubles. There was some talk about Wikipedia taking over WebCite to ensure its long-term sustainability and continued service. I came across this bot WebCiteBot, but seems to be inactive since 2009. The talk page has some discussion about it. (talk) user:Al83tito22:33, 4 April 2013 (UTC)
Pending Changes disagreeing with itself
Crosseyed?
Special:PendingChanges recently referred me to a pending change at Deaths in 2013 (edit | talk | history | protect | delete | links | watch | logs | views) (which I'd reviewed the previous edit to, but I don't think that has anything to do with what happened). However, when the diff loaded, it told me that it had already been accepted. Yet the history told me that the two edits (an addition by an IP and its subsequent reversion by Eyesnore (talk·contribs)) were still pending. I raised the issue on IRC, where several other editors saw the same issue; Legoktm (talk·contribs) deprecated the revisions and re-accepted them, and as far as I can tell, that fixed everything. Here's the problem, though: the review log shows that Eyesnore's revert was auto-accepted. But everything I can find on the subject says that the only edit auto-accepted following a still-pending edit is rollback executed by a reviewer. Eyesnore's a rollbacker, but not a reviewer. So am I mistaken, and are rollbackers' reverts in fact auto-accepted, or is there a bug in the system? — PinkAmpers&(Je vous invite à me parler)06:25, 21 January 2013 (UTC)
Is it possible to hide watchlist notices by type? I'm not interested in seeing notifications of upcoming meetups, which occur frequently. — Hex(❝?!❞)13:47, 21 January 2013 (UTC)
It is possible to hide individual geonotices (see MediaWiki:Geonotice.js), for example the current UK meetup one may be hidden by setting
#geonoticeUKFeb2013Meetups{display:none;}
in your Special:MyPage/common.css, but since that ID will probably change when the March meetups begin to be shown, it's easier to go for the [hide] link. Alternatively you can hide all geonotices on a permanent basis using
I've filed an edit request to incorporate {{Pp-pc1}} (though not {{Pp-pc2}}) into {{Pp-meta}}, in keeping with other protection templates. I believe it to be fairly non-controversial, as does Salvidrim, who's reviewing the request, but he's suggested that I seek comment from other editors before he carries out (or doesn't carry out) the changes. I agree that this is a good idea, and would be very grateful if some editors experienced in template markup could look over my work, both to make sure that I haven't screwed anything up and to comment on whether or not it's a good idea regardless. If necessary I can open an RfC, but it seems simpler to just fish for some feedback here. — PinkAmpers&(Je vous invite à me parler)06:37, 22 January 2013 (UTC)
parser function admin
Is there a parser function which could be used in a template to alter behavior if was posted on admin or non-admin's talk page? NE Ent19:28, 17 January 2013 (UTC)
{{#if:{{adminstats|{{{1}}}}}|{{{1}}} is an admin|{{{1}}} is not an admin}} would probably work, if placed on a userpage. (X! · talk) · @292 · 06:01, 18 January 2013 (UTC)
The second idea doesn't work for all users (whether admin or not), see User:Redrose64/Sandbox11. The problem is that it relies on the existence of a bot-generated template, and that template is only generated for admins who have asked for it. Further, it is not deleted if an admin is later de-sysopped. --Redrose64 (talk) 13:02, 18 January 2013 (UTC)
What you can do, is ADD information that is only visible to admins. You can use the css class sysop-show, which should make that CSS block only visible for sysops (but the content will always be in the HTML). Example: the answer of the question is 42, but hidden for most users. —TheDJ (talk • contribs) 22:05, 22 January 2013 (UTC)
Cyberbot will automatically create adminstats for administrators if it finds a link {{adminstats|adminname}}, as it did in your sandbox. Therefore in effect, you requested it yourself :-) An optimist on the run!22:42, 22 January 2013 (UTC)
Thanks, I just see that now. I'm going to change the dash to "no", to match the way the Sisterlinks template works, it seems more clear-cut that way. The dash is very vague to what it does. --Funandtrvl (talk) 17:38, 22 January 2013 (UTC)
The watchlist notice says "Wikimedia sites will be periodically in read-only mode early this week." So inbetween there will be periods where editing is possible? -- ToshioYamaguchi18:22, 22 January 2013 (UTC)
Well, starting at 1740 today, there was a span of about half an hour where no edits at all were possible (ending ten minutes ago or so), but we're making edits now, so I guess the answer to both your questions is "yes." :) Writ Keeper⚇♔18:25, 22 January 2013 (UTC)
All sites were in read-only mode for ~30 minutes, but the migration was completed successfully. We don't expect any further related editing interruptions. Asher Feldman00:36, 23 January 2013 (UTC)
No. Though if you give further details about what you're trying to accomplish, there may be another solution available. --MZMcBride (talk) 19:03, 22 January 2013 (UTC)
Ok, it's rather complicated, but here goes: I use a personalised {{information}} template on Commons, and want to put an anchor link in it to the licence section. This uses the header {{int:license}}. This gives a different title depending on a user's language preference. The obvious solution, which I've tried, is to link to [[#{{int:license}}]], which works for en-gb (my preference), but causes problems for the default en language. This is because {{int:license}} expands to [[Commons:Copyright tags|Licensing]] for en, containing a link. When this is transcluded into the anchor link, it produces nested square brackets, breaking the template. I want to strip the mark-up from {{int:license}}, so that it leaves [[#Licensing]] for English users. I can't just link to [[#Licensing]] directly, as it wouldn't work for users with other languages set. I could get around the problem by having a special case if {{int:lang}}=en, but there may be other languages that also have links in the header.
I'd thought of that, but hoped to avoid having to edit all my images (over 200), having only just gone through them all to add the header in the first place. Oh well, AWB makes it easier. Thanks for your help. An optimist on the run!21:00, 22 January 2013 (UTC)
Here's a proof-of-concept that it can be done, though the technique is probably too clunky for widespread adoption:
An undocumented quirk of the {{anchorencode:...}} magic word causes it to extract the dot-encoded displayed text from a wikilink, making it possible to link to the relevant section, so {{anchorencode:[[#Foo|Bar baz?]]}} will produce Bar_baz.3F
There doesn't seem to be a way to extract Foo or the unencoded Bar baz?.
Because the extracted display text is always dot-encoded, it needs piping to prevent non-ASCII text and punctuation from displaying oddly. Fortunately, in this case it's possible to cheat by piping int:version-license which happens to have the same intended meaning as int:license but uses only unlinked plain text – at present! (The display texts of the two messages are not identical in every language, so it is not possible to link with the simpler unpiped [[#{{int:version-license}}]].)
There's a working example at commons:User:Richardguk/int anchor test which you can test by appending the uselang parameter to the URL.[18][19][20][21][22] But the fact that it can be done by this obscure workaround doesn't mean that it ought to be done! In particular, links could break if there were changes to the internal workings of {{anchorencode:}} or to the format of int:version-license messages. But it is an interesting demonstration of wikitext's quirks.
(Apologies if this message isn't in your language.) Next week, the Wikimedia Foundation will transition its main technical operations to a new data center in Ashburn, Virginia, USA. This is intended to improve the technical performance and reliability of all Wikimedia sites, including this wiki. There will be some times when the site will be in read-only mode, and there may be full outages; the current target windows for the migration are January 22nd, 23rd and 24th, 2013, from 17:00 to 01:00 UTC (see other timezones on timeanddate.com). More information is available in the full announcement.
If you would like to stay informed of future technical upgrades, consider becoming a Tech ambassador and joining the ambassadors mailing list. You will be able to help your fellow Wikimedians have a voice in technical discussions and be notified of important decisions.
Hey, Yaris! You could try this script that I just wrote (not wholly by myself); I haven't tested it completely for cross-browser shenanigans, but I think it should work. Writ Keeper⚇♔19:34, 22 January 2013 (UTC)
This script from 2007 has been listed as obsolete by the user scripts project. However, I bumped into it and tried it out and it seems to work just fine in Firefox 18.0.1. Might this be erroneous? Can some other people with other configurations try out the script to see if it works? ResMar18:55, 22 January 2013 (UTC)
The script is no longer necessary. It was written at a time when there were no "edit" links for article sections in Wikipedia and the only way to edit a section was to open the entire article. — QuicksilverT@19:34, 22 January 2013 (UTC)
The listing specifically states that it has been "Broken by MediaWiki changes". While there is a live preview option under editing preferences, as well as an Ajax preview script, neither of them works inline in the same manner as this one - ae. they both take you to a new webpage. Maybe it's been rendered obsolete by something better, but I haven't found it yet... ResMar19:42, 22 January 2013 (UTC)
Hold up, that's not how it works. It changes the interface so that clicking on the edit button opens an inline editing interface, without switching to a §ion= editing page, and allows you to do all the usual stuff without changing web urls. ResMar19:46, 22 January 2013 (UTC)
Not sure if this is the right place - but once upon a time, a person creating an account saw the contents of the page MediaWiki:Fancycaptcha-createaccount. However I've seen an large increase of messages at OTRS from people who do not understand why they have been blocked because they have used a name of their business, etc. - they certainly have never heard of the user name policy. I did try the create account with another PC and found that the message is no longer displayed - all they get is a tiny link on the Username box that says "(help me choose)" - I can assume you that they do not click the link, they don't want help in choosing, they have already made up their decision. Is there some way we can get the little explanation box back? It would stop lots of new editors getting rather upset at being blocked for a reason that has never been explained to them. Ronhjones (Talk)02:17, 21 January 2013 (UTC)
Thanks John and Philosopher for the heads up. I really appreciate being invited to chime in on interface issues like these. I have a longer explanation about the message, why we removed it, and the testing data etc., but in the short term I just wanted to note that the current interface of the signup page won't display any contents of MediaWiki:Fancycaptcha-createaccount, except to users that have JavaScript disabled or who won't accept cookies, who get the old version for now. For now I wouldn't recommend trying to use new messages such as MediaWiki:Signupstart, as we haven't tested to see if overwriting defaults in that or other messages will break the styling of the new signup page. I do have some suggestions for how we might address the issue Ron brings up, and also wanted to say that Ron approaching the issue with the goal of lessening headaches for new people unfamiliar with our rules is admirable. Talk soon, Steven Walling (WMF) • talk06:09, 22 January 2013 (UTC)
Okay, following up, let me give you some bullet points on why we made the change we did, and why I don't recommend placing another list of "do not" items about usernames. Forgive me for being verbose...
First up: MediaWiki messages like Fancycaptcha-createaccount are meant to describe elements of the interface, and as you can tell by the title, the purpose of that message was to describe the CAPTCHA. Having it be used to provide warnings about username policy was technically a misuse of the message.
We get more than a hundred users signing up every hour, and thousands per day. When looking at from that high level view, you can tell that it is unlikely that all of these users need to see several paragraphs and five bullet points about username policy. The sheer number of registrations vs. username blocks every week makes this clear.
The current version of the page, which we ran as a side-by-side test to half of visitors to the signup page, produced a 4% increase in people successfully registering, and no statistically significant increase in the rate at which new accounts were blocked (for any reason). That sounds small, but at the seasonal rate of account creation for that week-long test, we netted more than 2,700 additional people. When comparing that gain to the potential for any confusion among people who are going to be blocked either way, the end decisionw was a clear one to us. Removing excess instruction and warnings is one important part of making the signup process easier on the majority of people.
The system for dealing with bad usernames ultimately needs to be redone. As tracked in bug 32330, our current thinking is that in the long run, we are going to let admins force a username reset which the user completes before they are allowed back in to their account. This is much more elegant than blocking and forcing users to create a new account.
The "help me choose" language in the link was suggested by an editor, over the version we originally had which as "username policy". I'm totally open to suggestions about changing the description of that link.
Anyway, the other reason I ask about actual stats on the increase in OTRS email is because we are coming out of the holiday season. As you can see from data like this, every year around Christmas and New Years, we see a very large dip in all account creations. The increase you may be feeling is almost certainly in part due to the fact that the overall number of registrations is increasing again, slowly but surely. Steven Walling (WMF) • talk20:01, 22 January 2013 (UTC)
Hi, I've probably done something completely wrong but my email notifications of changes to watched pages seemed to suddenly stop yesterday evening; it had been working correctly until then. I have checked everything is still all ticked in 'preferences' in case I'd inadvertently changed something. To check that the email address was working I even sent myself an email from my alternative email which came through. I also tried sending myself an email from Wikipedia using the email this user facility, which hasn't arrived either. I use a Mac (if that makes any difference). I hope I'm managing to explain this query correctly! SagaciousPhil - Chat15:03, 23 January 2013 (UTC)
Wow, thanks for such a speedy response! I'm still not getting anything through, I picked up your reply by constantly checking my watch list (I know - obsessive/compulsive springs to mind!). At least it's a relief to know it's unlikely to be something I've done and I'll just wait patiently as I'm not technical enough to know how to work the operations channels. SagaciousPhil - Chat15:31, 23 January 2013 (UTC)
By the way, notifications were delivered a few hours later, within the end of the day (at least for me). --Nemo13:40, 24 January 2013 (UTC)
Text and redirect in redirect page
In this article Fxall (or in this version of the article) and IP editor added some text without removing the redirect tag (go to edit mode to see)! Ignoring their formatting error, shouldn't the text in that page break the redirect? Or any changes recently? --Tito Dutta (talk) 16:29, 24 January 2013 (UTC)
To clarify, it does parse templates, and uses category and interwiki links appropriately. It just doesn't display any of the text after the redirect line, although it once did. — Carl (CBM · talk) 16:35, 24 January 2013 (UTC)
I think a more important issue is the added text is promotional and a blatant copyvio of www.fxall.com/about. I have removed it. Chris857 (talk) 20:31, 24 January 2013 (UTC)
The unhelpful error message is presumably for security and privacy protection; the server admins will probably have access to the full error message, which may include sensitive data. Ucucha (talk) 21:49, 24 January 2013 (UTC)
When it will start to work archivebot.py and weblinkchecker.py?
1) archivebot.py
I put in the parameters
|algo = old(1d)
Several days have passed, but still appears
Processing 10 threads
There are only 0 Threads. Skipped
When it will be back up?
2) weblinkchecker.py
I set the parameter-day:1 several days have Passed, but the bot is doing nothing.
And the errors are gone. I think that the problem is not only in my family file, because the same error occurs when I run the bot in Russian Wikipedia.
Looks like all text is centered, small, and the menu on the left is pushed below all content. Imagine it's something being looked into already but makes me scared of Wikipedia! Cheers. Andre666 (talk) 17:48, 25 January 2013 (UTC)
if you close the "notice" at the top of the page, then reload, the problem goes away. someone forgot to close a tag up there. see the threads above and below. Frietjes (talk) 17:50, 25 January 2013 (UTC)
Who ever put up that new banner on the Main page not updating has caused all text to appear small and centered! Please guys, a bit of professionalism. On a technical note, I'm using Chrome on Windows 7. 88.170.241.162 (talk) 17:49, 25 January 2013 (UTC)
Several Wikipedia articles are being presented in a centered text format (as if they were being edited to have a central alignment). When the history of the page is viewed, the articles return to normal formatting. Due to the widespread appearance of this effect, I doubt that it is intentional mal-editing. I have viewed Wikipedia on several browsers and two different laptops to rule out any system issues. It appears that this is a Wikipedia-related glitch and not a problem with my personal computers.
I don't know why or if anyone else is having this problem or not (I don't have time to read through everything people have said right now), but all of the content in every page on Wikipedia is showing up in smaller font than normal, and is centered in the middle of the page for some reason. Even the "Save page", "Show preview", and "Show changes" buttons are centered on my screen as I'm posting this. I've already checked some of the settings of my browser (including zoom, which is at 100%), and I don't think it's my fault. I'm pretty sure the sidebar and top bar are still their normal sizes, though. Alphius (talk) 17:51, 25 January 2013 (UTC)
For the "why" question, see discussion at WP:AN, section "Do we need a site notice regarding the main page update problem?". The centering was my fault; I forgot to close a <!-- comment -->. Someone else closed it a few minutes later, thus explaining the contributions looking normal. Nyttend (talk) 18:24, 25 January 2013 (UTC)
OH MY GOD GUYS WHAT DID YOU DO. it's updated for me but the font is tiiiny (8pt?) and there's ugly bullet points everywhere and pages are randomly center-aligned omg what happened god help us all Anyway, the navigation sidebar also got bumped to the bottom of the page for me, so there's like a big blank spot where the navigation bar is supposed to be. — NovaDog — (contribs) 17:52, 25 January 2013 (UTC)
I just came here to mention the center alignment as well, I found that the siteNotice div is not being closed until the very bottom of the page, so its "text-align: center" style is covering everything. There's a comment in the code with "/sitenotice" right after the mw-dismissable-notice div where I guess it should be closed, but isn't. Onlynone (talk) 17:56, 25 January 2013 (UTC)
Issues with the font size and alignment are all my fault. Someone requested an editnotice at WP:AN, so I created it, but I included a <!-- comment and forgot to close it with a -->, so the small size and centered text of the editnotice ended up applying to the entirety of every page. Nyttend (talk) 17:58, 25 January 2013 (UTC)
When English is selected from The Wikipedia landing page it generates an error stating "No site configured at this address". Its been doing this for a few days.
That's odd, http://en.wikipedia.org/ takes me to the main page whether I click the link on the landing page or enter it to the address bar (it automatically adds wiki/Main_Page as soon as the browser follows the link). The landing page works as I'd expect for me in Chrome and IE9. James086Talk20:59, 23 January 2013 (UTC)
That's interesting. I've tried it on 2 different computers with IE and Firefox and it doesn't work here. I also tried clicking the other links around the globe and they work, just not the english one. Kumioko (talk) 21:27, 23 January 2013 (UTC)
As I mentioned above it leads me to http://en.wikipedia.org/ and then generates a blank white page with "No site configured at this address". Its no big deal if no one else is having the problem. I've also already cleared my cache and my recent history. I even tried to restart my computer. I just thought it was something to do with the Server move from Fl to Va. Kumioko (talk) 21:34, 23 January 2013 (UTC)
Redirect OK here, US user, Firefox 18.0.1, Windows 7 Ultimate N x64, no extensions installed that are affecting Wikipedia (I even disabled AdBlock for Wikipedia, even though Wikipedia has no ads). 50.46.184.47 (talk) 23:38, 25 January 2013 (UTC)
For people who registered before September 2005, the Registration time was populated from the first edit at the time it was populated. There are other ways to determine the registration date for such affected people. MBisanztalk17:57, 24 January 2013 (UTC)
You probably moved a page over a redirect when the bug described in the second-last paragraph of the section about moving over a redirect was in force. The edit may have since been nuked because somebody moved the page back over it (i.e. changing the title back to what it was before your page move). The errant edit is probably somewhere in the old dumps. Graham8713:03, 25 January 2013 (UTC)
Sorry to add a "me too", but this is still not resolved. Is there a publicly available link that shows what is going on, and that someone is actually working on this? 46.115.53.225 (talk) 14:15, 26 January 2013 (UTC)
Is there a way to detect which articles (in a category) have interwiki links on them? I'd like to generate a "priority list" for translation of the articles in a certain category to other Wikipedias, and "have they already been translated somewhere" would be a very useful thing to know. – PhilosopherLet us reason together.17:06, 25 January 2013 (UTC)
You can also get this information (probably with more options) from querying the toolserver database. I can run queries for you if you want. Legoktm (talk) 17:55, 25 January 2013 (UTC)
That'd be great! What I want for this project is a list of the members of Category:Iowa_(government)_articles that do and that don't have a version in another Wikipedia. If it's not too much more work, a list sorted by how many interwiki links are on them would be better, but the set's small enough that that probably doesn't matter. – PhilosopherLet us reason together.01:36, 26 January 2013 (UTC)
I've just started getting a new toolbar popping up at the right margin of some pages - "Show metadata", "Send appreciation...", etc. I can dismiss it, but it still shows up on other pages. How can I make it go away and never reappear? -- Boing! said Zebedee (talk) 13:41, 26 January 2013 (UTC)
Oh, I did recently view the new "New pages patrol" thing, and I see one of the tools in the new toolbar is "Go to the next page in the queue". Has viewing the new patrol thing left me with this toolbar? -- Boing! said Zebedee (talk) 13:42, 26 January 2013 (UTC)
At some point (circa July 2012 ?) a number of files began showing up with the Permission field for their {{Information}} templates filled with "Evidence: Will be provided on request.". See e.g. File:Acumen International.png. Does anyone know why that started showing up with those files? VernoWhitney (talk) 20:45, 16 January 2013 (UTC)
Why is that even an option? If the copyright owner has given appropriate permission, it should be provided to OTRS without being requested and if it isn't the image should be deleted; and they certainly should not be tagged for moving to Commons. Otherwise we will have even more images with unconfirmed copyright status and that is not a good thing.--ukexpat (talk) 20:58, 16 January 2013 (UTC)
Yep, I'm the culprit here; I put these options into the upload form when I wrote it last year. My thoughts were these:
In my understanding, this was the previous policy status quo: we don't force people to provide evidence the moment they do their uploads; they just need to make a plausible assertion of licensing and we tell them their images might get deleted if they can't provide evidence if and when challenged. When I wrote the form, I didn't want to create the impression it was sneakily introducing new, stricter policies.
While most such images certainly should be challenged (and I as well as others actually tag most of them with "no-permission" routinely), I believe there are situations where a reviewer might legitimately take an uploader's word for it and accept an assertion of licensing without evidence, on assumption of good faith. I, for instance, occasionally do that with COI editors, when it is obvious from an uploader's editing profile that they are acting as the article subject's representative.
Most importantly, I believe this option is useful because it gives problematic uploaders a relatively simple way of admitting a file isn't their own. If we didn't have this option, many of these uploaders would choose to lie instead and tag the files as "own work", which would make copyvios much more difficult to detect.
By the way, I would guess most of the ones that have turned up on Commons with the "will be provided" option were not moved there, but uploaded directly to Commons from our WP:FUW form. That option was disabled some time in July, I think.
A quick look at the files in Category:Files licensed by third parties that have the "on request" annotation shows that there are probably hundreds that should be challenged. I tagged a few yesterday but ran out of steam. If we are so tough on potential copyvios elsewhere, why are we not showing the same rigour here? Personally, I think that option should be rewritten to immediately tag the image with {{di-no permission}} so that the uploader is put on immediate notice that permission must be provided. As for COI editors, why should they be exempt? If they have have appropriate permission they should have to provide it or face deletion just like everyone else.--ukexpat (talk) 17:32, 17 January 2013 (UTC)
I often see people uploading images as "own work" although the images obviously aren't own works. If this feature in the upload wizard makes copyright violations easier to discover, then I think that it is a good thing. However, maybe this option could tag the files with {{subst:npd}} automatically? There are other "bad" templates such as {{permission from license selector}}, but files with that template automatically get {{db-f3}} and don't require someone else to go through the files and tag it manually.
I don't like the idea of assuming good faith for file copyrights. While it is unlikely that a contributor with a good standing would try to violate copyright, it is possible that other people might not know this and then tag the file with "no permission" in 5 or 10 years. If the contributor no longer is around, the file would then be lost. It is better to sort out the OTRS part now while the contributor still is around. --Stefan2 (talk) 11:26, 19 January 2013 (UTC)
I like the idea of making it auto-tag it for speedy deletion just like the permission-for-Wikipedia-only option (although I didn't see that option at all just now while glancing through the FileUploadWizard.js). F11 deletion requires notification of the uploader, though. Would that be satisfied just by an explanatory template on the file page itself like the template you pointed out, or would we need to get a bot involved if we change to that option? VernoWhitney (talk) 16:24, 21 January 2013 (UTC)
Well, if the file is going to be tagged as {{subst:npd}}, the uploader needs to be notified about this, but not necessarily on his talk page. He will most likely look at the file information page after uploading the file, and there it will say that permission needs to be sent to OTRS. Wouldn't that be enough? The upload wizard could also be designed to automatically put a notice on the uploader's talk page using the uploader's own account. --Stefan2 (talk) 22:16, 21 January 2013 (UTC)
I came here following Stafan2's note at WT:CSD, having not previously been aware of this discussion. Personally, I think that if a user has state that they will provide evidence "on request", we must assume good faith that they will provide it when requested. As an absolute minimum, we must therefore explicitly request that permission before or at the same time as tagging for speedy deletion - in other words the speedy deletion clock must not start until the permission has been requested. This brings up the second question about what constitutes adequate notice, and for me the minimum must be notices on the file page and the user talk page. I say this because any user familiar with Wikimedia wikis, and likely other people too, will have an expectation that any requests specifically for them to be made on their user talk page. Thryduulf (talk) 03:07, 24 January 2013 (UTC)
Okay, since you're the only feedback from my cross-post to CSD, I'd like to forge ahead with that. Going with that expectation and requiring a post to the uploader's talk page, is there a way to add that to the upload wizard without requiring the editor to push through more buttons? I assume so, but that's getting beyond my immediate experience with automated tools here. VernoWhitney (talk) 01:59, 28 January 2013 (UTC)
Curiosity concerning stats.grok.se
As some of you may or may not know, I previously went by the Wikipedia alias of Backtable. My former userpage was deleted on January 4, 2013, as per my own request. Ever since then, stats.grok.se has reported a sharp increase in views of my deleted userpace, starting when the page got deleted. Stats.grok.se reports hundreds of post-deletion views per day, even though not getting 10 pre-deletion views per day was nothing unusual. Is this an error on behalf of the viewcounter, or is there an otherwise reasonable explanation for the uncanny increase in views? I know I haven't been viewing it that much.
Also, I did send an e-mail to Henrik about this, as was recommended here, but that user has not been very active on Wikipedia as of recent. I also e-mailed another administrator about the viewcount anomaly, and the administrator referred me here. Mungo Kitsch (talk) 22:14, 21 January 2013 (UTC)
Purely a guess, but could it be bots external to Wiki, e.g. Googlebots, trying to spider your page repeatedly when they can't find it? An optimist on the run!14:57, 23 January 2013 (UTC)
I'm unfamiliar with bot practices, but I would venture to consider your guess possible. I found this page, and I may instill some of its suggestions to hopefully reduce viewcount. Mungo Kitsch (talk) 03:12, 24 January 2013 (UTC)
Elements of this situation appear to be looking upward. Despite me not doing anything yet to curb the views, 27 January 2013 registered only 88 views, down from 563 on 26 January. I'm meaning to attend to the situation further, but I'm glad that views have started going back to double digits at least for the time being. Mungo Kitsch (talk) 05:20, 28 January 2013 (UTC)
Oh ok thanks. I am aware that editcountitis is not a good thing, but wished to record my 10,000th edit. I had thought I remembered from somewhere that the My Preferences is more accurate, have you heard this (or contrary) as well? --GilderienChat|List of good deeds20:12, 26 January 2013 (UTC)
Yes, the list of Wikipedians by number of edits does count deleted edits. However, it does not count page moves, which are counted by X!'s edit counter. Graham8708:05, 27 January 2013 (UTC)
Old version of template appears in articles
The version of Template:Indianapolis_Museum_of_Art_artworks displayed in article space is a couple of months out-of-date, with the result that articles which exist are displayed as red links because an old version of the link is displayed.
Examples:
In the article Peasant with a Wheelbarrow, the links "Broek in Waterland" and "Charing Cross Bridge" appear red. Those links were changed as far back as November 24, but the version of the template on the article page does not show the updates.
When you look at the template itself the updated links are displayed.
Now that the article has been patrolled it is no longer listed as an orphan. But I promise you, before it had been patrolled, there were two links to it and yet it would show as an orphan. I still would like to understand why, just for technical understanding's sake. Thanks. Of course the question has now to be rephrased in more general terms, since the specific situation has changed: "How can an article that has got links pointing to it, nonetheless be listed as an orphan?". Again, thanks for any technical insight. Signed: Basemetal (write to me here) 22:15, 27 January 2013 (UTC)
Admin can't see revdel'd revisions
I seem to be unable to check out the revdel'd revisions at Derby sex gang. I don't even get to check the box for selecting a revision. I'm an admin; I was logged in; it usually works. What happen? Bishonen | talk21:00, 24 January 2013 (UTC).
Don't be an asshole, please. Suppression (available to admins) and super-suppression (available to oversighters) both have pretty dreadfully confusing user interfaces. --MZMcBride (talk) 18:23, 28 January 2013 (UTC)
this may be so, but it still does not justify the language. it is absolutely 100% OK for you to think it, or even say it aloud, but please do not type it here (or, if it helps, do what i sometimes do: type it, hit "preview" and view it to your satisfaction, just do not hit "save").
I wouldn't worry too much about it. It's a variant on an old wiki principle (m:Don't be a dick). Making a snarky comment (e.g., "My Wikipedia confidence meter just went up!") is fine, but users do so with the knowledge that they'll likely only receive a snarky comment in return. You get back what you put out. :-) --MZMcBride (talk) 07:55, 29 January 2013 (UTC)
What's changed about images placed on the left?
In the past couple of days I've noticed that images placed on the left are no longer rendered where they should be. I haven't completely parsed the problem yet, but it appears that if a left-hand image is listed before any right-hand image it will be properly placed, but if it's coded after a right hand image, it gets pushed down to below that image, even if the right-hand image is pushed down by, for instance, an infobox. This is totally new. The left hand image used to render where it came in the coding, even if the right-hand image had to shift down because some other item was in its way.
I've put an example of the problem in my userspace, at User:Beyond My Ken/temp, taken from the Yonkers article. Note that there are three right-hand images which begin just before the "Northwest Yonkers" section. Then there are two left-hand images which should appear at the beginning of the "Southeast Yonkers" section, because that is where they are place in the coding. Instead, those images don't start until the top of the third right-hand image, so they are pushed down the page out of the section they're intended to be connected to. If the left-hand images were coded before the right-hand images, they would appear where they were placed, and the right-hand images would appear in the correct place also. (Feel free to play around with the page to verify this for yourself.) This is different from how image placement used to work, and it's not an improvement. Beyond My Ken (talk) 13:32, 25 January 2013 (UTC)
This has been normal behaviour for a very long time. Images are always rendered in the same order that they appear in the wikicode. --Redrose64 (talk) 13:33, 25 January 2013 (UTC)
I'm sorry, but that is not the case. A large proportion of the work I do is in page layout, and the images have never rendered in this fashion until recently, nor should they. Images used to (and should) render where they are put in the code, with the right and left images not interlinked in any way, which appears to be the case now. There's no reason that an image on one side of the page should be dependent on the position on an image on the other side of the page, and once they were not, but now they are in some fashion.
BTW, I've checked this under Firefox, Chrome, IE, Safari and Opera, both logged in and logged out, so this is not a browser-dependent problem, not is it anything to do with my settings. Beyond My Ken (talk) 13:44, 25 January 2013 (UTC)
Could this be caused by your browser switching to CSS or HTML5 standard layout rules? "The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document." (CSS2, emphasis added.) Wikipedia switched to HTML5 last year, but I think Internet Explorer initially included Wikipedia on a transitional list of websites to render in quirks mode, and the layout mode can also be affected by user preferences. So different browsers will have applied different layout rules at different times. — Richardguk (talk) 15:18, 25 January 2013 (UTC)
This seems very likely. FWIW, I looked at User:Beyond My Ken/temp and confirmed that the "pushed down" rendering being complained about here is the correct rendering according to the CSS standard. Anomie⚔00:15, 27 January 2013 (UTC)
if the OP is using IE (specifically IE9 - i don't have access ATM to earlier versions), please note that there is a difference in rendering between "compatibility mode" and "normal mode". if the OP switched off "compatibility mode" recently without even noticing it ("compatibility mode" switch is the small, bizarre icon to the left of the "refresh" icon on the address line of IE - it looks something like a broken brick, or a white bird crashing into a blue window, or maybe like square jaws), he/she might experience this as a "surprising change that happened recently", while, as you said, it is something that happened a while ago. peace - קיפודנחש (aka kipod) (talk) 23:36, 28 January 2013 (UTC)
The "Number of watchers" link on article history pages now leads to a page without that information. I hope that this is temporary. For pages I care about, it is comforting to know that lots of other people are concerned with its accuracy. When I edit such a page, I am more willing to be bold if I know that there are a substantial number of editors around to make sure that I don't mess up. Will we get this function back? Peter Brown (talk) 23:20, 27 January 2013 (UTC)
The "info" page which this page's history took me to does include the number of watchers. I'm not sure if it handles <30 watchers the same way as before, though. Grandiose(me, talk, contribs) 23:24, 27 January 2013 (UTC)
(edit conflict) Compare [23] (this page) with [24] (my user page). The former shows the number of watchers, the latter doesn't even have a row in the table for that. I assume that's because I don't have enough watchers for it to show that information (indeed the old watcher tool said the same), but I don't know what the cutoff is.
I think there is a lower limit, and although I don't know what the limit is, I haven't seen a number below 30, so I think the limit might be the same it's always been. Azylber (talk) 23:43, 27 January 2013 (UTC)
I think they have written it so admins can see it below a lower limit, checked that same link logged out and it doesn't have the number. GBfan23:50, 27 January 2013 (UTC)
Actually, Ryan, what you suggest adding to the end of the URL is already a part of the URL. At least, it shows up as part of the URL on my browser. But like the rest, I don't see the number of watchers unless it's over a certain limit. I'm assuming that limit is 30. — Maile (talk) 00:03, 28 January 2013 (UTC)
I'm assuming you are looking at the URL of the information page. Adding ?action=info while you are on the article will take you to the information page. RyanVesey00:05, 28 January 2013 (UTC)
I added a link to the bugzilla bug which is about adding in a line if the number of watchers is below the threshold, rather than just not including it. Legoktm (talk) 00:00, 28 January 2013 (UTC)
There is (in theory at least) a heightened risk that vandalism at unwatched pages will not be noticed or reverted. Therefore, if we give that information out to everyone (potentially including malicious people), there is a risk the data could be abused for vandalism.
I'm not sure that's really a significant risk. Many pages that are watched may be watched by accounts that are long dormant; people using tools like Huggle will revert even on pages that aren't watched by anyone; and you can probably guess what pages are obscure enough to be watched by very few people without an explicit list. Ucucha (talk) 00:18, 28 January 2013 (UTC)
And it's still possible to create multiple accounts, and add the same pages to each watchlist. There's a risk that all of the accounts would be blocked, but a vandal would just evade the blocks, possibly making it easier for a vandal than for most editors. Peter James (talk) 00:35, 28 January 2013 (UTC)
(edit conflict) Some people fear that little-watched pages would be vulnerable to vandalism if a list were published. But watchlists are not the only defence against vandalism. On the other hand, many watchers might have added the page years ago and since stopped checking their watchlists regularly. So the benefits of having a threshold are plausible but open to debate.
For non-admins, the number of watchers is hidden on the Info page if it is less than 30 ($wgUnwatchedPageThreshold default set in InitialiseSettings.php, utilised in InfoAction.php). This reflects the threshold for which pages were previously excluded from the Toolserver query that the Info page superseded. See also Bugzilla:39957 for some related background information.
Does anyone know what the code is for the exact shade of grey which is the background-color of the Table of Contents that sits at the top of pages with more than 3 sections, e.g. this very page?
Eyeballing it, thru trial and error, I approached it to something like 0xF9F9FA (the border is just plain old 0x000000):
This is 0xF9F9FA
But I'd like the exact code. Do you know it off the top of your head? If not, how do I find that out? And while we're at it, what is the code for the shade of grey of the border of the Table of Contents? Signed: Basemetal (write to me here) 07:21, 28 January 2013 (UTC)
(If you use Chrome, you can right-click on an element and open "Inspect element" to find out the effective styles. Similar tools exist for other browsers.) --Yair rand (talk) 08:17, 28 January 2013 (UTC)
Never mind; I didn't realize we were talking about the TOC. I thought we were asking for the background color for the discussion section. --Trovatore (talk) 08:26, 28 January 2013 (UTC) It looks like that one is 0xF8FCFF, which at least someone out there refers to as "ghost white". Is that right? --Trovatore (talk) 08:35, 28 January 2013 (UTC)
The pale blue background for this page is rgb(248, 252, 255) (or #F8FCFF in the old money). GhostWhite has slightly less green - #F8F8FF or rgb(248, 248, 255). --Redrose64 (talk) 11:58, 28 January 2013 (UTC)
Thank you MZMcBride. ColorPix works on any part of the display whereas Yair rand's advice only works in a Chrome window, right? Incidentally I tried to use Yair rand's method but it only works in some areas of a Chrome window. I click the right button of the mouse, I get a pop-up and I choose "Inspect element". I get the HTML windows. I open the "Styles" window. For some areas of a Chrome window
element.style {
}
contains the data I want, background color, etc., but in most of the cases (and in particular in the case of the TOC)
element.style {
}
is just an empty structure. Only once, I don't know what I did, the pop-up I got (the HTML window was already open so I had already done "Inspect element" once) had only two choices (one of them being "Inspect element" again) and when I chose that again I got an
element.style {
}
with the data I wanted in the "Styles" window. But that happened only once and I could never reproduce the sequence of actions I took to get to that point. So what am I doing wrong? How do I get the background color for any part of a Chrome window with "Inspect element"? How come for now it works only for some parts of the window? Signed: Basemetal (write to me here) 07:55, 29 January 2013 (UTC)
In this case, the relevant style is applied to the <table> element. Once you click on the element, you should see a section below the element.style section titled "Matched CSS rules", which will include styles other than those directly applied using the style attribute. Alternatively, you could expand the "Computed style" section. --Yair rand (talk) 08:07, 29 January 2013 (UTC)
Actually, it's the talk page appearing on google, not the article page. Adding noindex on the talk page should resolve the problem. — Edokter (talk) — 15:03, 28 January 2013 (UTC)
Using Italic or Bold in your section title seems impossible if you create the new section by choosing "New section" at the top of the page
Have you noticed that if you want to add a section to a talk page and you do it by choosing the "New section" button at the top of the page, it is impossible to use Italic or Bold in the title of the section. Whereas it is perfectly possible to do if you create the new section "manually" by simply editing the whole file and inserting a line ==<new section name here>== like I just did here and in the title of another new section above. So, bug or feature? Signed: Basemetal (write to me here) 01:03, 29 January 2013 (UTC)
Italics are sometimes appropriate in section headings. You see this a lot in articles about authors, where specific works may be considered watersheds or otherwise appropriate for a section heading (for example, this). Regards, Orange Suede Sofa (talk) 01:19, 29 January 2013 (UTC)
Yeah, the premise of the question is just false. It's perfectly possible to type apostrophes/inverted commas/single quotation marks into the section header field. I guess you can't actually click the Bold text or Italic text buttons, but does anyone actually use those? Evanh2008(talk|contribs)01:24, 29 January 2013 (UTC)
I do. But you're right I did not realize it was only the shortcut buttons that didn't work. Of course I did not say that you couldn't have bold and italic in the section header (my own section header had them, didn't you notice?) but only that you could not get them by using the "New section" button, and I did not try to insert myself the '' and ''' markers by hand. Signed: Basemetal (write to me here) 04:54, 29 January 2013 (UTC)
Basemetal, see the section below. When I saw your post, my tablet did not render italics (I use Puffin), so I had to fire up my PC to make sure the italics were rendered for Wikipedians in general. --Ancheta Wis (talk | contribs)03:24, 29 January 2013 (UTC)
Basemetal, thank you for adhering to the expectation that one does not delete the posts of another editor. We could just wait for the bot to archive quiescent sections. Would that be OK with you? --Ancheta Wis (talk | contribs)12:20, 29 January 2013 (UTC)
Is it possible that some browsers don't render bold and italic formatting within header tags? It seems clear that MediaWiki handles them fine. Ucucha (talk) 03:43, 29 January 2013 (UTC)
Ucacha, I think it is the Puffin browser that does not render italics, in general, and not just within section headers. I live with it because my device is "instant-on" and generally more convenient for me to read Wikipedia. That said, I have to be very careful with my touches. --Ancheta Wis (talk | contribs)12:29, 29 January 2013 (UTC)
Congratulations. Is it ok now to ask you to delete your test section? Or I can do it for you if you prefer. Signed: Basemetal (write to me here) 04:44, 29 January 2013 (UTC)
Who sez "new section" cannot be italicised or bolded?
I created this as a new section to test the assertion immediately above.
In successfully doing so, I have demonstrated that it is indeed possible to italicise and bold text in headings. However, if Basemetal is seeking to use the shortcuts immediately above the edit window to perform a one-click insertion, it's true they don't work. But how is that really a problem? -- Ohconfucius ping / poke02:00, 29 January 2013 (UTC)
The assertion was not of course that you can't have bold or italics in a section header (my own section had bold and italics in it!) but only that you can't have it if you create the new section with the "New section" button and you are perfectly right I only tested the shorcut buttons I did not try to insert the markers '' and ''' myself by hand. Is this really a problem? What is really a problem, except death and taxes? It would be nice if they did. Do those shortcuts have a good reason not to work? Signed: Basemetal (write to me here) 04:40, 29 January 2013 (UTC)
I just converted a bunch of the successful test sections into level 3 headers in order to keep the page organized. Legoktm (talk) 09:16, 29 January 2013 (UTC)
Does anyone know if a script exists where I could add an article to a to do list of sorts? When I come across an article I want to improve, I tend to add it to my watchlist, but pages that aren't actively edited don't show up. What I'd like is if there was a script so I could click a button and it would add it to some sort of articles to improve page in my userspace. I know I could manually create that, but it would be a lot easier with some type of script. RyanVesey21:51, 29 January 2013 (UTC)
Does this tool exist already?
From a comment on WT:MED, is there such a a thing to auto generate a list of article rating by date. E.g., start class articles rated between Jan 1st 2010 and Jun 31st 2010...ty for advice. Lesion (talk) 22:23, 29 January 2013 (UTC)
The article Heritage Auctions' talk page is at Talk:Heritage Auction Galleries. The article and talk page were moved in 2009, and for some reason Cluebot reverted the move of the talk page. I haven't been able to figure out how to move articles over redirects, and I'm not sure what to do since the talk page doesn't match the article. Can someone fix this? RyanVesey13:45, 30 January 2013 (UTC)
If the table were not sortable, it might be straightforward, though tedious, to include headers in several places, but that won't work well with a sortable table. Many spreadsheets have the ability to freeze the top row, so they remain on screen while you scroll down, but I'm not aware that Wikipedia's table rendering can do that.
For some long tables such as List of Manchester United F.C. players, this feature might not be needed, because after looking at the headers once, you can understand the meaning of each rows' entries even after the header is scrolled off the screen. However, in the case of Comparison of e-book readers, that isn't as easy to do, so it would be nice if there were some way to repeat the header or freeze it.
Does anyone have any thought on how to improve these tables?
Hi Sphilbrick, I'd be curious if something is available technically, but that wouldn't be the way I'd go with that particular table. I'd probably instead break up that one huge table into several smaller sub-tables, each with their own header. Find some logical thing to use to partition that big table off into smaller tables.... would a reader really need to compare all of those rows together like that? Zad6819:38, 30 January 2013 (UTC)
It does not look like collapsible things are currently collapsible (i.e. in the sidebar and for subcategories) and the suggested edit summaries have disappeared. AutomaticStrikeout (T • C) 03:25, 29 January 2013 (UTC)
My watchlist is now indented funny. The collapsible items with arrows are indented further than those without, so it looks like this:
19:12 Over the Hedge (film) (diff | hist) . . (+4) . . 174.94.50.250 (talk) (→Plot: ) [rollback]
Where it used to be the case that all of the timestamps would line up in the same column, making it much easier to read the list quickly. Now it is much harder. Why the change? Elizium23 (talk) 03:39, 29 January 2013 (UTC)
We've been discussing how to better communicate to users about reporting usernames at WT:UAA. It has come up that the new users log page is one of the places where the message does not quite jive with best practices. How does one edit a page like that? Beeblebrox (talk) 23:31, 30 January 2013 (UTC)
Awesome, thank you. For future reference, how is it that you even figured that out? There's no clue when viewing the page. Beeblebrox (talk) 23:50, 30 January 2013 (UTC)
[27]. The third gadget under the "Advanced" header in your preferences' Gadgets tab gives you a link to do this automatically. Ucucha (talk) 00:07, 31 January 2013 (UTC)
This has been happening for a while now, Wikipedia:Purge has some instructions that may solve the problem, these may fix but but don't expect the results to be quick as I noticed a similar problem with File:Moorhouse in Cumbria - geograph.org.uk .jpg in the Moorhouse, Cumbria article a few days ago and the thumbnail wouldn't display at the correct size in the article until several hours later (adding the "?1" to the url would work for the image, but the syntax used in articles doesn't allow that. The full size images of your uploads are appearing correctly. Peter James (talk) 01:37, 23 January 2013 (UTC)
In general we face some on-and-off thumbnail issues, see the list under "Depends on:" bugzilla:41371. Bug 41130 (server caches) comes to my mind but mostly people from North America are affected, while I can reproduce the problem here and am based in Europe. As recommended by Peter I'd wait a few hours, and if the issue still happens I'd file a bug report in the bugtracker (I'll happily do that). --AKlapper (WMF) (talk) 11:40, 23 January 2013 (UTC)
It looks like something broke on the wiki side from 19:14, 22 January 2013 to 19:17, 22 January 2013. All of the files in between don't render. It's only a few minutes, but the bot does 10-15 files/minute. See listfiles on commons for the bot for the empty rendering spaces.Smallman12q (talk) 23:47, 23 January 2013 (UTC)
On the other hand, I also see very similar issues with thumbnails that were not created around that time. I'll try to find a developer to discuss with. --AKlapper (WMF) (talk) 12:58, 24 January 2013 (UTC)
-Speaking of thumbnails: I updated two images on the Commons, which were updated on WP the next day, but not in the article (Puget Sound faults); purging my cache did not help. I now see that it is the thumbnail version that is not updating. Changing the "upright" parameter to a different size appears to force a new rendering. But invoking the image at the old size gets the old version of the image. I suspect that each size of an image in use is stored as a separate file, and these are not being updated when the source image is changed. ~ J. Johnson (JJ) (talk) 23:19, 24 January 2013 (UTC)
Your bug is a bit different in that you have stale thumbnails, whereas my bug had no thumbnail. Thumbnails are cached. The server cache for your images could be stale. Did you try Wikipedia:Purge? (Go the image file on commons, add ?action=purge to the url and hit enter).Smallman12q (talk) 03:14, 25 January 2013 (UTC)
Yes, that worked. Even though the latest image had been promoted to WP, I gather that some derivative process (for the thumbnails?) did not complete, and re-promoting it from Commons restarted all that. I wonder if this should done with all recently uploaded images. ~ J. Johnson (JJ) (talk) 23:53, 25 January 2013 (UTC)
There is a similar problem with File:The_cave_video_game_cover.png, a new version has been uploaded but the old image is displayed with the new image's dimensions. Purge has no effect. Reverting, and then restoring the image has no effect. Adding the purge command to the image url will display the correct version of the image, but it has no long lasting effect. It may be worth investigating if there is a chance that this could be affecting all images uploaded during the fault period. - X201 (talk) 11:34, 25 January 2013 (UTC)
No it isn't. Just follow the link to The Cave image above, scroll down to the File History and look at what should be shown as the Current Image. It's still broken. - X201 (talk) 15:24, 26 January 2013 (UTC)
They always call soccer football, we had great disc jockeys that are never on here, and American kids are not learning how to spell the words properly. — Preceding unsigned comment added by 75.18.161.228 (talk) 09:21, 31 January 2013 (UTC)
About the iconic {{Periodic table}}. A reader noted in feedback that the element names should be there, and rightly so. I've come up with {{Periodic table/sandbox}}. Now width (horizontal px) is the issue. I squeezed out a lot. Still, when on screen 1024x768 (like old tubes), it is too wide. Column 18 ends up next to the page ("canvas"?). My question is: what to do? Is that wide overflow acceptable? Use {{wide template}}? Any other tricks re width? Project discussion at here. -DePiep (talk) 18:48, 28 January 2013 (UTC)
The names are there; they show up as tooltips. You version also looses the borders that denote some key properties. I'm sure the width was a consideration for the current design. None of the tables in print I have ever seen have the full element names. — Edokter (talk) — 20:04, 28 January 2013 (UTC)
Tooltips (aka mousehover): WP:ACCESS#Text says: Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text..
Borders that denote some key properties: the border I removed only signs one property (natural occurrence). Compared to the name, such a "key property" is way less relevant, and I deliberately offered it. Really, if one can't find an element (but for hovering over 100), such a property is completely useless (and of course: that might be re-added somehow by using vertical space; is what I have been trying).
"I'm sure the width was a consideration for the current design." - How to reason with that? I have considerations too.
"None of the tables ... in print ... have names" - not convincing they should be left out. Maybe internet offers new possibilities.
(edit conflict) The element names are already present; hover your mouse over a symbol like H and it shows as a tooltip (at least, it does in Firefox; IE might have its own ideas). --Redrose64 (talk) 20:06, 28 January 2013 (UTC)
Mousehover: see above me re Edokter. It is a secondary way of providing info. Hope you are not looking for Tungsten. -DePiep (talk) 21:59, 28 January 2013 (UTC)
Yes, that is what I wrote: it became too wide. But at least my sandbox version only has one column (18) spoiling in a specific situation (lowres screen). A sort of tradeoff on what is acceptable is what I am looking for. Having to click into the blind to get primary information is not WP:ACCESS. -DePiep (talk) 21:59, 28 January 2013 (UTC)
@Edokter, Redrose64, PrimeHunter. I think the element name should be in the table at first sight. It is primary information. Not every reader knows what the symbols are for gold, silver, mercury, phosphorus -- not the most obscure elements. Mousehover and click-more is a secondary way for readers, they don't find what they look for (sure "but somewhere else the information is"). Apart from Edokter's "I have never seen it" I have read no argument against adding names for information reasons. My question was "how could it be done", not "why not". -DePiep (talk) 21:59, 28 January 2013 (UTC)
It can't be done; there simply isn't enough space, as you can see in all the other versions. Your version has the names printed so small they are almost illegible, which is an accessibility issue in its own. — Edokter (talk) — 22:39, 28 January 2013 (UTC)
These other (wider) versions clearly were not designed to match the width constriction, and they do not suggest so. And so they do not prove it is impossible (anyway they do not try {{shy}}). Seems like PrimeHunter improved the sandbox [28], even when I set the font-size from 80% to 85% for legibility. Apart from darmstadtium (110), I see this issue gone in 1024x768 screen. -DePiep (talk) 10:30, 29 January 2013 (UTC)
Yes, but still no borders. And what about 800x600 screens? And mobile devices? There will always be limitations. Just because it now fits on 1024x768 does not mean the problem no longer exists. — Edokter (talk) — 10:47, 29 January 2013 (UTC)
About using the the border: above I explained that their informative value is less than the element name, so I choose accordingly in the trade-off. That property is descriptive, not identifying. Adding your argument (not mine): that information is in the tooltip text. Next: 1024x768 is the smallest screen size to be checked as per WP:ACCESS. As for mobile devices: I found no mobile-specific guidelines for wiki pages. Maybe you can point to them. As I understand it, well crafted CSS and tags should cover that. -DePiep (talk) 11:10, 29 January 2013 (UTC)
Trading one piece of information for another is not a solution. The occurence info is just as vital. And as PrimeHunter has pointed out: the other periodic table templates do contain the full names, which is linked to where ever the basic template is used. The table as it is does conform to WP:ACCESS; abbrivations (which is what the symbols are) are exempt from the 'hovering' rule. — Edokter (talk) — 15:16, 29 January 2013 (UTC)
I traded (the presentation of) information with different qualities. I never claimed the current version is not WP:ACCESS. They are not abbreviations they are symbols (Au for gold), and I am not dropping or disputing them. Now that you state that these other (way wide) templates do correctly show the names, why would you not let the basic one get wide too (like saying "hey you can't go wide, and by the way these other wide templates are fine")? My point of question was and is to combine the goodies of these two. I was just asking for some thinking along, just about a sandbox. In general, can you tell me what went wrong here? Why do you think of new objections by the hour, without paying attention to my earlier responses? Can you please step over some kind of 'I don't like' treshold, and point to possible improvements. That would be helpful. -DePiep (talk) 16:34, 29 January 2013 (UTC)
I can't see any possible improvement here without sacrificing other information. What you want is basically have one of the wide templates (with names) fit into the 1024 boundary. Making the basic template go wider is simply redundant to the ohter existing templates. — Edokter (talk) — 17:10, 29 January 2013 (UTC)
OK, so you could not see it happening, but that is not a reason to conclude and argue it should not be tried. Just a note saying so would have done then, leaving it to others to search further. And actually it did happen. Shortcutting all argumentation, I can say the need for some compromise solution, I was looking for here, is gone: the current sandbox version combines all requirements. That is: the infomation fits within the 1024 screen. Looks like problem is solved. -DePiep (talk) 16:45, 30 January 2013 (UTC)
Can't say I like that solution either; now the table is in danger of not fitting the 768-pixel vertical boundary. Just what is wrong with the current template? — Edokter (talk) — 19:56, 30 January 2013 (UTC)
Look, it's just not going to work. {{Periodic table}} is built to fit comfortably on any page at the cost of element names, while the wide tables provide all information, including the element names, but those require more space, which means they do not fit 1024. There is simply no 'one size fits all' solution here. — Edokter (talk) — 23:24, 30 January 2013 (UTC)
Edokter, it already is working and showing for a few days. I do not understand why you keep repeating that it won't fly while it is already sitting there in a tree. And my original question here is resolved. Even better: it didn't need a compromise (wrt contradicting requirements). So we might as well close it as resolved here. -DePiep (talk) 15:56, 31 January 2013 (UTC)
Have you noticed that it is impossible to Compare selected revisions if the two revisions you wanna compare reside on two different pages of the list of revisions? For instance if you chose to display 20 revisions per page then it is impossible to compare the latest revision and the 21st latest revision (or even the 20th latest revision and the 21th latest revision because the 20th latest and the 21st latest are displayed on different pages). Of course you can always change the number of revisions displayed on each page to get around that but that's very inconvenient and time consuming. And my point remains that this is not how things should behave in my opinion. Is this behaviour intentional or is is a bug? Signed: Basemetal (write to me here) 00:54, 29 January 2013 (UTC)
Hi. You know you can click the "(cur)" link next to any revision to see the diff between that revision and the current version of the page, right? So it doesn't matter what your pagination is set to if the goal is only to diff to the current revision.
Pagination is better than the alternative: attempting to display every revision in the same browser window. That would be pretty awful for any large page history.
What I think would be more convenient is that the two top "bullets" (what do you call them actually?) to the right of "(cur | prev)" are not automatically selected and do not automatically turn blue when you click for a new page of results. This way you could pick say the 5th most recent on the first page of results. The "bullet" turns blue indicating that this is the more recent version you want to compare. Then you click for new results, 1, 5 or 10 results pages later (depending on the length of the revision history of course) and you choose, say the 125th most recent version. Then you click the "Compare selected versions" button and you get the diffs between the 5th most recent and the 125th most recent version. Why you would want that is your problem. If people start arguing on the basis of "Who would ever want that?" there's no point. The question is, is there any downside to things working that way? I don't see any. Anyway, the way it works now is that you type for a new result page and the selection on your previous page is forgotten: the two most recent revisions in that page get selected and their "bullets" turn blue automatically. I hope what I am trying to describe here is clear. At least it could be an option in your "Preferences" if you would like those things to get reset any time you click for a new result page or instead work the way I am trying to describe here. Signed: Basemetal (write to me here) 05:44, 29 January 2013 (UTC)
A better question is, why should a developer spend time on such a feature? Unless you are planning to do the work yourself, "Who would ever want that?" is one question to answer if you want to convince a developer to make changes for you. Using someone's time to make the changes is a downside. Also, the additional complexity introduced by software changes should be considered. Preferences is already a mess with lots of options, I'd prefer to avoid adding more if it can be avoided... – PartTimeGnome(talk | contribs)22:04, 31 January 2013 (UTC)
Getting rid of pagination is of course not a method I'd consider sensible of giving people the option of comparing any revision to any other. That goes without saying. Signed: Basemetal (write to me here) 05:59, 29 January 2013 (UTC)
No, it seems perfectly normal and acceptable for 99.5 percent of uses. It would seem odd to need to perform this whether systematically (or often enough) to warrant such a feature for everyday use. If you want to find the difference between two versions separated by a relatively long period of time, you can also do so by selecting a larger number of versions – you can do any of 20, 50, 100, 250, 500 in the history by simple click (or almost an infinite number if you change it from within the url bar of the browser) and then diff your two versions. -- Ohconfucius ping / poke02:11, 29 January 2013 (UTC)
Well yes, you can do that say in the URL bar of the browser, but first you would have to get the 9 digit revision id for the two revisions you want to compare. I don't see it in my results page when I click "View history". And even if there is a way to conveniently get those ids (is there?) I find it more convenient to not have to mess with the URL, you can always make mistakes while typing. The click of a mouse is always the more convenient option. Most of all, I don't see why the behavior I am suggesting for those "bullets" would not be as natural and intuitive and more convenient than the present one (and it could of course be provided as an option only in your "Preferences"). Incidentally why was it considered necessary that the two "bullets" once you have selected them and made them turn blue need to not be on a line with each other, that is why does the more recent revision have to be offset to a location that is on a line to the right of the line of the older revision? Why was that considered useful? To rephrase this: why does the x-coordinate of the bullet of the newer revision need to be to the right of the x-coordinate of the bullet of the older revision? Whew. Is what I am trying to say here clear? Signed: Basemetal (write to me here) 05:44, 29 January 2013 (UTC)
The simplest way I know of getting a revision number is to look at the oldid parameter in the URL of the linked timestamps in the history list. Sometimes I wonder if it would be nice to have them more visible, but maybe that would just confuse or alienate people. Also, check out the User:DerHexer/revisionjumper gadget; you can enable it in the Special:Preferences#mw-prefsection-gadgets. I recently used it to track down and compare revisions over hundreds of edits.
Also, I think I understand what you mean about the positioning of the old and new revisions. I believe the left-hand column is meant for selecting the old revision, and the right-hand column is for the new revision. If you manage to swap these around (maybe if inhibit Java Script?) you’re going to be comparing the old revision as if it were newer than the new revision, and the differences will be the opposite of normal (removing text that was actually added, etc). Vadmium (talk, contribs) 06:25, 29 January 2013 (UTC).
Yes, but why do those "bullets" need to be in two columns? Of any two revisions only one can be the older and the other the newer. I don't see how there could be any confusion there. A revision is newer than another one simply by virtue of it being later. Couldn't the "bullets" all be in one column? (Is no one gonna tell me what those things are really called?) Signed: Basemetal (write to me here) 07:13, 29 January 2013 (UTC)
They are indeed radio buttons: and one of the features of the radio button is that in any given group, only one may be selected - all the others of the group must be deselected. Therefore, to have two buttons selected at the same time requires them to be in different groups - hence the two columns, one for each group.
When Ohconfucius put "you can do any of 20, 50, 100, 250, 500 in the history by simple click (or almost an infinite number if you change it from within the url bar of the browser) and then diff your two versions", this didn't refer to the revision numbers of a page diff (as used in the &diff= and &oldid= fields), but to the &limit= field of the revision history itself. Let's say you are viewing http://en.wikipedia.org/w/index.php?title=Radio_button&action=history - by default, this shows 50 entries. You can change it to 20 by clicking 20 - or you can do exactly the same by appending &limit=20 to the URL. This works for any positive integer up to 5000. --Redrose64 (talk) 10:00, 29 January 2013 (UTC)
I mentioned this further up the page, but since the Solved tag was put on the general problem this related, but specific, one hasn't received any attention. So I'm relisting here as the problem persists.
There is a problem with File:The_cave_video_game_cover.png(hovering over this link shows the correct image, clicking it or going to the article doesn't), a new version has been uploaded but the old image is displayed with the new image's dimensions. Purge has no effect. Reverting, and then restoring the image has no effect. Adding the purge command to the image url will display the correct version of the image, but it has no long lasting effect. Re-uploading the image has no effect either. Could someone fix this please? - X201 (talk) 11:21, 29 January 2013 (UTC)
Well in my case a couple of days... obviously I can't be certain that something more complicated is not happening in your case. I wonder if anyone else has any ideas. Grandiose(me, talk, contribs) 15:23, 29 January 2013 (UTC)
Depending on the issue, this can actually last indefinitely, at least until WMF Ops completes a difficult image handling change. Of course, it might also go very shortly (I think it's gone now? for me at least). See bugzilla:41130#c18 for a workaround if it doesn't. - Jarry1250[Deliberationneeded]15:30, 29 January 2013 (UTC)
Fixed: Thanks. Just in case anyone else is having the same problem, I followed comment 24 in the link that Jarry provided above, and that fixed it. - X201 (talk) 10:56, 31 January 2013 (UTC)
As I understand it, MediaWiki only auto-accepts a revision if the revision immediately before it was accepted. The edit you reverted was not accepted, hence neither was yours. I think there is an exception if you use the rollback feature to revert to an accepted revision, in which case your edit would be auto-accepted (I'm not certain on this). Since you don't have rollback rights, I'm guessing this was a standard revert. – PartTimeGnome(talk | contribs)22:22, 31 January 2013 (UTC)
I've created a doc page, with a blank template. It's a nasty infobox; none of the parameters are optional. For future ref, requests like this are best sent to WT:Infobox. --Redrose64 (talk) 09:59, 31 January 2013 (UTC)
Last night the birthdays in infoboxes on my phone started to be messed up. For example Al Gore shows:
(1948-03-31) March 31,1948 (age 64)
which is really annoying to have the numbers as well as the date. When I view a mobile page on my computer though there is no problem. How do I fix it? CTF83!23:57, 30 January 2013 (UTC)
{{birth date and age|mf=yes|1948|3|31}} generates this in order to be sortable by birth date when it's used in a table column:
Text in <span style="display:none">...</span> is not supposed to be displayed but apparently your phone doesn't know this. I don't know how to fix it on your phone. It has been used in the template since 2007.[29] Did you change something in the phone software recently? I suppose we could add an optional template parameter to say "Don't generate a hidden sortable date", but I'm not sure we should cater to issues like this if it isn't widespread. PrimeHunter (talk) 02:00, 31 January 2013 (UTC)
If the text is not needed, the template should not generate it. Throwing in extra text, even if it's marked display:none, will slow down page load and confuse search engines, Dillo users, and anyone when the site CSS fails to load. The real solution here would be to turn the extra content generation off by default and add a parameter to {{birth date and age}} to re-enable it. —Remember the dot(talk)02:09, 31 January 2013 (UTC)
That won't work either. The MobileFrontEnd extension strips all inline CSS, so any mechanism for hiding/unhiding certain parts will fail on mobile. This affects nearly every template, and IMO was a bad design decision for MobileFrontEnd. — Edokter (talk) — 09:55, 31 January 2013 (UTC)
Someday I hope we won't have to manually include the references/notes section(s) at the bottom of articles, and that sfn will look like: {{sfn|isbn=|p=|some text}} or {{sfn|doi=|p=|some text}} that will produce what the harvnb/citation combo does today.
While I'm wishing, it would be cool for wp to put the refs/notes/see/external stuff on a separate tab automatically, and move cites out of the notes and not require editors to deal with organizing any of that nor ordinary readers to have it lard up their articles with it.
Obviously, if this conversation belongs elsewhere, I'd appreciate a tip!
Include (default not checked) case-sensitive option when WP:SALTing pages
Include a checkbox to have a SALT article creation protection be case sensitive or not. The option would say "Case-sensitive" and it would not be checked by default. This is useful in situations where multiple users may create differently capitalized article names to get around the protection. However, a SALT might need to be case-sensitive in some situations as well, so that's why it's an option. I believe this would be relatively easy to implement; simply adding a .lowercase() on both the filters and the article name being checked, and then comparing them, would do the trick. Vacation904:07, 1 February 2013 (UTC)
Why is it impossible to do? If the change is made to MediaWiki it isn't. This is a feature that with no doubt would be extremely useful across all wikis. The majority of salted pages should be not case sensitive anyway. Vacation904:13, 1 February 2013 (UTC)
Page protection is a per page setting, and a property of the page. There is no more relation between Example and ExAmple, then between any other page. You would have to check the database for every page with every case permutation individually (perhaps there is some way to do case insensitive LIKE in SQL, in which case it isn't too bad), and then query the properties of completely different pages to see if any are protected, and if this option is set. That's no good, especially to duplicate existing functionality. Prodegotalk04:23, 1 February 2013 (UTC)
Maybe it would be a difficult, but I don't think it's duplicate functionality persay; we're talking about thousands of pages that people who might not be familiar with Regexes would need to add to the title blacklist. I see your point though. Vacation904:31, 1 February 2013 (UTC)
Wikilink parsing isn't easy. There are a lot of edge cases. Probably best to use MediaWiki's built-in parser for this. --MZMcBride (talk) 18:30, 28 January 2013 (UTC)
Today, I encounter a new bug in Wikipedia when I develop a category. With Safari Mac. I go at en.wikipedia.org/wiki/Category:Films_set_in_Poland. I click on the + to develop the category History of Poland on film. And I get this insult message :
“categorytree-collapse-bullet: Parse error at position 0 in input:”
I still get [+] on all category pages. The bug affects all such categories (i.e. with three layers - the + is to expand a subcategory). I do not get it when logged out because then I get served triangles as suggested. Grandiose(me, talk, contribs) 12:27, 31 January 2013 (UTC)
How much does Pending Changes slow down load-times?
The load times on Deaths in 2013 are excessively long, and editors have even converted all of the references to the basic <ref> </ref> format, to avoid the delays from using citation templates, but this has not sped things up very much. How much of this extreme slowness is down to the use of Wikipedia:Pending changes, rather than semi-protection? Arjayay (talk) 18:56, 30 January 2013 (UTC)
You can also try adding ?forceprofile=true to URLs (not POST requests though) and clicking "view source" to look for any intersting profiling data. Aaron Schulz23:35, 1 February 2013 (UTC)
Can bots do asynchronous requests to the wikipedia api? For example several uploads simultaneously through the commons api or is this frowned upon? Would there be a performance benefit? I have a 100 Mbit/s line and so I'd like to know if doing simultaneous uploads would be worthwhile. Smallman12q (talk) 22:04, 31 January 2013 (UTC)
Yes, it should be fine if you don't use too many threads (I'd stop at three). Are you able to saturate the connection with only one thread? MER-C08:30, 1 February 2013 (UTC)
Huh? That page doesn't look like a policy -- the sole author does not seem to be listed here (in fact, the author is banned on en.wp). Almost nothinglinks to that page; if it is policy you really should publicise it more. I searched wikitech, and CPUs have come a long way since this was posted nearly six years ago. MER-C14:00, 1 February 2013 (UTC)
I've filed bugzilla:44584 for guidance...there should an official policy. @MER-C, I'm not able to saturate the line with only one thread. (The line is part of a wider shared line, but I'm guaranteed that minimum).Smallman12q (talk) 15:09, 1 February 2013 (UTC)
The development for TAFI has progressed significantly over the last few weeks, and we are preparing to launch the new feature on the main page when it can be properly implemented (target date Feb 9th at 0:00 UTC, but subject to change). Concensus was established that the TAFI content should be placed below the DYK content. A key part of this is the concensus to display one of a group of several articles (7 at this time), shown randomly. One implementation of this can be seen on the example page. It requires the user manually click the purge button, and I do not know if there is another way to do this sort of thing.
As far executing this implementation on the Main Page, one editor suggested that "the simplest approach is to use a new set of seven dated subpages each week (which can be created and prepared as far in advance as desired). When the date arrives, the update will occur automatically." Being more accustomed to my work in the textile industry, I have no clue when it comes to these matters. From what I gather, items to appear on the Main Page first go through Wikipedia:Main Page/Tomorrow, and this can be used to transclude the relevant article blurbs to the page. I am looking for assistance from technically minded individuals that can help in implementing this on the Main Page. --NickPenguin(contribs)01:58, 1 February 2013 (UTC)
There is no way that consensus is sufficient to modify the main page. Without feedback from hundreds of editors, the main page should not be touched. There needs to be a discussion linked form the watchlist notice, in addition to CENT and the other usual pages, before you can do this. Prodegotalk04:19, 1 February 2013 (UTC)
I believe we did go an RfC, which was also at CENT and other places, though I am not sure anybody mentioned going through the Watchlist notice. The proposal was passed by consensus at the Village Pump(Proposals), which I believe is the page where any such proposal is to be passed.
In any case, is there something else that we ought to be doing before TAFI can make it to the Main Page? If so, what? [Just a casual count revealed 50+ editors voting on the original proposal] TheOriginalSoni (talk) 07:27, 1 February 2013 (UTC)
What page do I edit to update this template's documentation?
I'm looking at the documentation for Template:Uw-unsourced3. At the bottom there's a little table that shows the different warning levels available. For Template:Uw-unsourcedn where n in [1, 2, 3] it says incorrectly that Template:Uw-unsourced4 is N/A. There actually is a Template:Uw-unsourced4. I want to update the documentation to fix this, but I cannot figure out what page I need to edit to do it! Note Please, I'm looking for someone to tell me how to figure it out so I can learn, I'm not asking to have it done for me! Help appreciated, cheers... Zad6816:21, 1 February 2013 (UTC)
(edit conflict) I’m not going to do it myself since you asked. If you view the source of the template, you’ll see that the documentation comes from {{Templatesnotice|series = uw-unsourced|max = 3|s1 = uw-unsor3}}. A bit of common sense confirmed by experiment shows that raising the max parameter to 4 does the job.—EmilJ.16:58, 1 February 2013 (UTC)
PDF rendering problem - same as another report, or different?
An email received by Wikimedia noted a problem rendering an article as PDF. The article is House of Medici
I tried it myself, and thought it was successful, but when I open the file, it reads:
WARNING: Article could not be rendered - outputting plain text.
Potential causes of the problem are: (a) a bug in the pdf-writer software (b) problematic Mediawiki markup (c) table is too wide
I do see bug in rendering page as PDF. That note a bug identified, and marked as fixed, although when I go to the bug report, it appears to be fixed, but not yet deployed.
I would like to point the reader to this discussion.
I hope someone can identify whether:
The problem with House of Medici is the same as in the bug_in_rendering_page_as_PDF, and is not yet fixed (from the stand-point of the reader) but is expected to be deployed at some time in the future, or
The problem with this file is known, and there is a work-around, or
Seeing that User:Darkness Shines has retired, I was curious to see when he started editing, so I went to Special:Contributions/Darkness Shines and told it to show his earliest contributions. To my surprise, the block log changed: instead of displaying his current one-week block, it displayed the following block message:
02:23, 5 January 2012 Magog the Ogre (talk | contribs | block) blocked Darkness Shines (talk | contribs) (account creation blocked) with an expiry time of 24 hours (Edit warring: Taliban)
What's going on with the log? And is it something that needs work, or should it be forgotten? This reminds me of seeing reports in the past of people who were recorded as being blocked even though their blocks had expired. IE8/Windows 7/Monobook, though that's probably irrelevant. Nyttend (talk) 00:54, 2 February 2013 (UTC)
Everything seems to be functioning fine for me except for one of the blocks I made today (The system thinks that Saturday is a specific date on 1970 but when changing the block, the expiry was correct). @Gilderien, if you remove the underscore, the block is displayed. Elockid(Talk)01:07, 2 February 2013 (UTC)
It's exactly what you pointed out: when you click to show the earliest contributions, it also changes the block log extract to display the earliest block instead of the most recent. I'm sick of seeing this bug, why hasn't anyone fixed it already? Anomie⚔02:28, 2 February 2013 (UTC)
Logs
I know this makes it easier for newbies to understand log entries, but how can I revert the new log format to the old one:
New format:
[Edit=Block new and unregistered users] (expires 07:31, 30 January 2013 (UTC)) [Move=Block all non-admin users]
Old format:
[edit=autoconfirmed] (expires 01:29, 27 January 2013 (UTC)) [move=sysop] (indefinite)
What they did was upgrade enwiki from 1.21wmf7 to 1.21wmf8. The particular change being complained about appears to be this one, FYI. I don't think it was done for newbies so much as other languages, so that for example arwiki could see something like "[تعديل=امنع المستخدمين الجدد وغير المسجلين]" in their logs instead of "[edit=autoconfirmed]". Note that won't go live on arwiki until tomorrow, but you can see it now on non-Wikipedia projects such as de:wikt:Special:Log/protect. Anomie⚔21:35, 29 January 2013 (UTC)
I think this is actually less useful phrasing, because "new" is undefined while "autoconfirmed" has a definition. If there was a way to wikilink the "autoconfirmed" and "admin" (instead of sysop) text, that'd be best. Is this a change directly to the MediaWiki software or is there a MediaWiki: namespace file that can be changed? – PhilosopherLet us reason together.19:56, 30 January 2013 (UTC)
Additionally, I don't think it's beyond the realm of possibility that some (perhaps those less than proficient in English) could interpret it as "if you try to edit the page, you will be blocked". But hold on... if it's localized now, does that mean that we can change what it says? Because then we could compromise on something like [edit=Autoconfirmed users only] - new users would understand what it means, but we wouldn't feel like MediaWiki is treating us like toddlers. — PinkAmpers&(Je vous invite à me parler)16:08, 2 February 2013 (UTC)
Well, sort of. The messages are MediaWiki:protect-level-autoconfirmed and MediaWiki:protect-level-sysop. But there are two potential issues: 1, the messages are resolved when the page is protected, so it could be changed going forward but existing logs will still have the old text. And 2, these messages are the same ones used in the protection form itself, so whatever changes are made will be reflected there too. Anomie⚔21:09, 2 February 2013 (UTC)
problem opening wikipedia
my browser (explorer 8) on my pc (windows XP SP2) makes me see every site normally,except wikipedia. The issue occurred yesterday and it seems not solved yet. your site appears to be running,but is extremely slow and often can't load photos or heavy pages. it seems strange,as a few days ago it was going wonderfully. — Preceding unsigned comment added by 87.21.32.151 (talk) 17:49, 1 February 2013 (UTC)
thanks a lot for answering. not fixed yet,and it seems getting worse. could it depend on the new signal enhancer I bought to improve the wi-fi signal? I thought about it as the sole action I made in these days,but wikipedia is the only site affected. other sites are ok. if it helps the problem occurred in Italy.
Help creating template for fractions
Hello CSS/Wikimarkup experts,
I would like to create a general template to display inline calculations or simple formulas, e.g. 9 \times 103 \times 4. Template:frac and Template:fraction don't put the numerator above the denominator. I know I can use the LaTeX math feature, such as used in Template:DentalFormula here, but
The font does not match the normal text font face and size.
It doesn't resize correctly when I resize the text.
I've experimented with some CSS to produce this:
9 × 10
3 × 4
(although I wrote the raw HTML here, it will be transcluded from a template). This works on my Firefox 18 browser, as long as I wrap the entire paragraph in a div (as is done here).
If not, the p tag closes, the table is displayed as a separate block:
9 × 10
3 × 4
, then the rest of the text appears in a separate p tag.
Is there a way to avoid that? Or is there another way to inline such fractions?
The simple answer is: use the math/LaTeX markup. It is rubbish right now as you rightly point out, but if you use some crazy HTML/CSS-based solution for some formulas but not others, then fixes made to the math/LaTeX extension in future (e.g. install MathJax, anyone?) won’t apply to your fancy template. — Timwi (talk) 20:50, 1 February 2013 (UTC)
Aha! Turns out MathJax is actually supported, but you have to rummage through the preferences first and find a well-hidden option. Go to Preferences, Appearance, and then at the bottom choose MathJax. — Timwi (talk)
These templates do not display correctly in pdf files because apparently our pdf creator knows nothing about 'inline-block' display option. Ruslik_Zero16:28, 2 February 2013 (UTC)
There are many templates that have this problem. That doesn't mean they should be excluded from use. These templates use ordinairy HTML/CSS, which any PDF converter should be able to handle. — Edokter (talk) — 18:34, 2 February 2013 (UTC)
I've accessed it on my Windows Phone 7.5, and it redirects me twice, to some sites that on first look seem to be either sex/dating/pornography sites. Based on this, and the comments above, I've removed the link. Even though it's the only reference, I'm sure someone can find a more reliable source. Thank you for bringing this to our attention. gwickwiretalkedits23:48, 1 February 2013 (UTC)
Doing some investigation I discovered that http://resources.infolinks.com/js/infolinks_main.js is an included javascript and that it is the source of the hijacking. Werieth (talk) 03:09, 2 February 2013 (UTC)
I know this has been discussed before, (here), but I'm getting sick to death of the ambiguous "contributions" link in my sidebar in classic skin. I repeatedly find myself clicking it when I want to check another user's contributions, and seeing my own instead. I thought I'd get used to it in time, but it's not happening. I never used to do this when it was "my contributions", so it's just the ambiguity that's throwing me. When this was raised before, someone came up with a css tweak, which I've tried in my common.css page, but it doesn't work in classic skin. Any suggestions? An optimist on the run!07:46, 2 February 2013 (UTC)
The following CSS should work for the Classic skin:
Worked in vector and monobook classic for me. (I think the CSS property "content" can only be used with a :before or :after selector.) Writ Keeper⚇♔15:51, 2 February 2013 (UTC)
My code works in Opera 12, but it is possible that Writ Keeper is right with regards to using content: in other browsers. (Edit: Writ Keeper updated his comment before I saved, so the following mention of #pt-mycontris makes no sense now.) #pt-mycontris is specific to Vector though, so won't work with Classic. Below is a combination of both of our CSS that might work:
It's also possible that your browser doesn't like the title= selector I am using (I know it doesn't work in IE6; it should work in later versions of IE). If that is the case, I can't think of anything else to try, since Classic is rather lacking in the IDs and classes I would use in other skins. – PartTimeGnome(talk | contribs)16:01, 2 February 2013 (UTC)
The previous/next version links go to the revision of the article with the previous/next revision ID number, not the previous/next revision by timestamp. Because I imported that July 2001 revision into the Wikipedia database from the Nostalgia Wikipedia in May 2010, the July 2001 edit has a revision ID number typical of edits from May 2010. This problem is tracked in Bugzilla as bug 2930. Graham8710:53, 2 February 2013 (UTC)
"RFC" autolinks
Has something changed recently such that the letters "RFC" followed by a number will automatically link to ietf RFCs? For example, here under the Computing section. I hadn't noticed this behavior before. older ≠ wiser17:50, 2 February 2013 (UTC)
It's been set up this way for a while, in the same way as ISBN autolinking. I'm not sure how long it's been enabled, but I believe several years. Andrew Gray (talk) 18:10, 2 February 2013 (UTC)
Hi, the {{Coastal settlements}} template was modified in early December and the link to the category appears not to be working. I cannot see what the problem is, may be you cannot substitute in the parameter as it is trying to do. Can anyone fix-it? Keith D (talk) 18:13, 2 February 2013 (UTC)
(edit conflict) As presently coded, {{Coastal settlements}} expects |place= to contain plain text without wikimarkup, because it applies wikimarkup to that text. At Tunstall, East Riding of Yorkshire, there is |place=the [[East Riding of Yorkshire]] - you are getting a page link inside a category link, which is forbidden - the only links which may contain other links are file links, where the caption text may be wikilinked. --Redrose64 (talk) 20:29, 2 February 2013 (UTC)
Are there any plans to enable noreferrer on Wikipedia since there are browsers that support it? (There are also non-standard, browser specific methods to hide referrers).
For non-tech folks, when you are on the insecure wiki (http not https), and you click on an external link on the wiki, the external site you visit gets a copy of the wiki url you came from. For example, if you click on an external link in the reference section of any page, such as Banana, the site you go to will know you came from the url http://en.wikipedia.org/wiki/Banana .
Several privacy issues arise with allowing referers:
If a low-traffic page is viewed, and an external link followed, if the person comments about a recent development on the page, it may be possible to link the ip to the editor.
If a person visits the domain name or service repeatedly from the wiki, it may be possible to profile the individual.
This "referrer" feature, on any site, in any circumstance, is a disgraceful breach of privacy. I was appalled when I first learned of it. I think most people don't even know it exists. 86.176.208.123 (talk) 23:57, 11 January 2013 (UTC)
(edit conflict) To play devil's advocate for a second, HTTP referrers are useful to website operators to discover who links to them (search engine link searches might not find Wikipedia because our external links are marked "nofollow"). Website operators are often knowledgeable on the subject of the linking article (that's why we linked to the site), and seeing Wikipedia linking to their site would probably inspire them to check out the article. Some proportion of these, being knowledgeable on the subject, would go on to improve the article or suggest improvements on the talk page.
On the other hand, link spammers could use referrers from Wikipedia to gauge the success of a link-spamming campaign. (However, there are other techniques to do this without using referrers.)
IMO, one set of pages that absolutely needs "noreferrer" would be deleted pages viewed by administrators (ditto for oversighted pages viewed by oversighters). If an administrator clicked an external link, the referrer would leak information about the deleted page (e.g. the page title, the timestamp of the revision, and that it linked to that site). This would be particularly harmful for pages where even the page's title has been oversighted (e.g. as a BLP violation).
Also, if you are concerned about your own privacy, it is possible to turn off referrers globally (not just from Wikipedia), using a browser setting or add-on (how depends on your browser). Note that some websites won't work without referrers (e.g. this link requires a referrer to work). – PartTimeGnome(talk | contribs)00:46, 12 January 2013 (UTC)
Such an interesting dilemma! I'm a federal employee (and of average tech abilities), and as we boot up our computers we get a message about "no expectation of privacy" on our workstations. After seeing this for 15 years I've internalized the message, and assume that everything I do on the internet is public. And forgive me, I'm beginning to think that none of us should assume any level of privacy on the internet. That actually seems the safest, really. This leads me to understand that the internet is a giant advertising machine, and because I want to track where webusers come from to get to my educational site (so I can serve them better) I also know that someone is tracking me, as I buy dog beds for the local no-kill shelter on Groupon. And I'm ok with that, because I can't have it both ways.
Again, as someone creating an educational website I want to know when/if Wikipedia and the sister projects are sending me webusers - I can then strengthen my relationships with the referring websites (like we are doing here), and learn which uploaded files get used, and which don't, so I can be nimble and respond accordingly. Bdcousineau (talk) 01:08, 12 January 2013 (UTC)
No opinon on the current subject, but the fact that privacy on the web is very low, does not mean nothing should be done to improve it (that's a general rule, and one of the poorest common arguments I usually see: "given X is already bad, there is no problem in making it worse") - Nabla (talk) 01:18, 12 January 2013 (UTC)
I've rephrased the request on WP:CENT to emphasise that this is a request to disable something used by Wikipediaweb browsers as part of a common standard, rather than starting from a status quo of its absence. I can understand that in some circumstances there are limited privacy implications, but these circumstances seem fairly limited and unusual. Andrew Gray (talk) 17:14, 12 January 2013 (UTC)
Your formulation "disable something used by Wikipedia as part of a common standard" makes it sound like Wikipedia is actively doing something now to pass referrer information. I'm not sure how it works but isn't the standard that a website does nothing at all and the browser by itself passes referrer information? And then a website can choose to add code to request browsers to not pass the referrer? PrimeHunter (talk) 00:56, 13 January 2013 (UTC)
Comment. Aren't these descriptions the wrong way round? How can support for "noreferrer" mean that "Wikipedia should have referers"? Ditto the one below. — Preceding unsigned comment added by 86.129.18.113 (talk) 18:35, 12 January 2013 (UTC)
Per the above two comments (moved from the support section), I've swapped support and oppose and updated the description at the top of each section to be a little more verbose. Hopefully things are a bit clearer now. (I also updated James086's !vote to reflect support and oppose have swapped meanings.) – PartTimeGnome(talk | contribs)00:55, 13 January 2013 (UTC)
Smallman, perhaps you can write up the code that allows an editor to opt in to a noreferrer feature and we can iVote whether to place that option in Special:Preferences. The noreferrer feature could work both in logging into Wikipedia (erase the URL from where you came into Wikipedia) and in clicking on external links in Wikipedia (prevent the target site from learning the Wikipedia URL source that referred to the target site.) -- Uzma Gamal (talk) 09:19, 13 January 2013 (UTC)
Regarding Uzma's bit about erasing the URL from which a user enters Wikipedia, I don't think the WMF record this in a way that threatens privacy. Looking at the requests by origin report, it seems they only keep the domain name of the referer (not the full URL), and do not associate this with an IP address or username. Looking at the CheckUser documentation, CheckUsers cannot see referers either. It is possible that server logs accessible to developers might have them. If this were the case, it would be a topic for a separate discussion; this RFC is about referers sent to external sites, not those received by Wikipedia. – PartTimeGnome(talk | contribs)15:04, 13 January 2013 (UTC)
Someone below mentioned that there are reasons why referers exist, so I decided to look them up. I've taken the below snippets from the HTTP 1.0 specification, to better inform this discussion.
This allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance.
...
Note: Because the source of a link may be private information or may reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.
The toggle switch was proposed in the HTTP/1.1 Protocol:
The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.
...
We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.
For those folks who believe HTTPS is the panacea, referers are sent on https -> https connections but not on https->http connections.
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.terface be provided for the user to enable or disable the sending of From and Referer information.
That means that when you click on a secure site from the secure wiki, you will send a referer. HTTPS will only prevent sending a referer to http sites.Smallman12q (talk) 16:54, 25 January 2013 (UTC)
Wikipedia should enable noreferrer, so that referers are not sent to external sites:
Support - Changes should be made in the best interests of readers and editors, not external sites. I think our users are more important than the owners of sites we link to. James086Talk15:21, 12 January 2013 (UTC)
Wikipedia sends referers to external sites now. The proposal is to stop doing this, not to add it. (James' comment previously referred to adding referers to Wikipedia, but he has since corrected this.) – PartTimeGnome(talk | contribs)00:55, 13 January 2013 (UTC)
Support - Wikipedia should take every reasonable step to ensure that it doesn't violate the privacy of any person. Telling other sites that the use rhad previously visited Wikipedia, let alone a specific Wikipedia page, is clearly such a violation. עוד מישהוOd Mishehu14:18, 13 January 2013 (UTC)
There has been some confusion here about how referrer works but Wikipedia doesn't tell anything to other sites now. It's browsers which usually by themselves tell a site where the browser came from. The proposal is to make Wikipedia ask browsers to not tell they came from Wikipedia. I think few sites do that currently so when you surf, a website usually knows where you came from. PrimeHunter (talk) 19:56, 13 January 2013 (UTC)
Whether it's Wikipedia, or the user's own browser doing stuff behind the user's back, is irrelevent. If Wikipedia can prevent such action from being taken behind the user's back, it should. עוד מישהוOd Mishehu13:00, 15 January 2013 (UTC)
Support seems like since we do nofollow this would be logical too. That said, I don't think we should get all paranoid about the reasoning: the sky isn't going to fall because website A knows it's been linked to from website B, and any site likely to do something sinister with that info probably shouldn't be linked to on WP anyway. Andrew Lenahan - Starblind22:24, 13 January 2013 (UTC)
Nofollow serves an actual purpose: it takes away the SEO incentive for people to spam their links here. Noreferrer does not have any such purpose. Anomie⚔22:31, 13 January 2013 (UTC)
From what I understand, for the people that care, this is a positive. For the people that don't care, there's no effect at all. Therefore, I support. Sven ManguardWha?01:27, 15 January 2013 (UTC)
Support. If Wikipedia can ask browsers to not reveal that our users have visited a page on Wikipedia, we should do so, for the same reasons we use nofollow on links. Some external sites will use this information for "wikipedia optimization" to the detriment of our attempts to reduce COI problems. --Guy Macon (talk) 20:10, 16 January 2013 (UTC)
Support and completely disagree with opposes I have read. We cannot control other sites or individual browsers, but we can do this. --Nouniquenames04:25, 17 January 2013 (UTC)
Support per Od Mishehu and Guy Macon. The web was a much smaller and saner place when this sort of tracing capability was introduced. The time to opt out is past due. ~ Ningauble (talk) 16:21, 18 January 2013 (UTC)
Support Referers might have been an ok idea in the CERN era of an academic-operated, research-oriented web. In today's advertiser and user-profiling web, they are evil and should be suppressed whenever possible. 67.117.146.66 (talk) 08:43, 25 January 2013 (UTC)
Support since as Sven said "for the people that care, this is a positive. For the people that don't care, there's no effect at all". Helder11:15, 25 January 2013 (UTC)
Support This should be an explicit Opt-In, not Opt-Out, choice. Unless readers are aware that the site can see their URL, this is not an acceptable practice. RolandR (talk)21:22, 30 January 2013 (UTC)
Support, Wikipedia should send no referers to any external site, as that enables external sites in theory to keep statistics of Wikipedia page readers' IP addresses: a no-go. --Chris Howard (talk) 09:37, 3 February 2013 (UTC)
Clarification: External sites can see readers' IP addresses and gather statistics about pages the reader views on the external site even without the referer. Blocking the referer would stop the external site gathering statistics about which the page the reader viewed on Wikipedia to get to the external site, however. – PartTimeGnome(talk | contribs)15:04, 3 February 2013 (UTC)
noreferrer - Oppose
Wikipedia should continue to allow referers to be sent to external sites:
This is pointless paranoia. The few people who are concerned should either avoid clicking external links, install a browser extension to block/falsify the referrer, or use the Javascript snippet WOSlinker posted above. Anomie⚔15:45, 13 January 2013 (UTC)
Agree with Anomie above. Anyone who is worried about a site knowing they got there by following a link in Wikipedia should be even more worried about links on other sites and install or activate referrer blocking in their browser. Kiore (talk) 08:50, 14 January 2013 (UTC)
Referrer isn't as big of a privacy breach as people think. It's also useful for certain sites, such as when I was working on my edit counter. I'll bring up an anecdotal example of why referrer was helpful: The tool was getting hit hard in basically a DOS attack. It was causing my email to get spammed, the tool was getting throttled, and by looking at the referrer, I found which page the attack was coming from, and was able to solve it. It's near impossible to get anything bad out of the referrer, and when a site really needs it, like I did, it's useful to have. (X! · talk) · @957 · 21:57, 14 January 2013 (UTC)
Let's not mess up the way the Internet was designed to work. There are reasons the referrer exists, and there is no reason to remove that en masse. Prodegotalk07:52, 15 January 2013 (UTC)
This is stupid. It gives people a false sense of privacy while breaking an important part of the HTTP protocol. --Chris11:58, 15 January 2013 (UTC)
The Referer header is optional; omitting it does not break the protocol. The proposed technique for disabling it is part of HTML5, not some hack. However, I do think it would be an abuse of rel="noreferrer" to turn it on globally. The use intended by the HTML5 authors was to block referers from private pages, to avoid leaking private information. – PartTimeGnome(talk | contribs)22:47, 15 January 2013 (UTC)
I agree with what all the "opposers" before me have said. The only "sure" way to do this, would be for the user to do it in his UA settings, not trying to enforce a one-size-fits-all "solution" by mucking about with Wikipedia (which probably wouldn't work anyway). ⇔ ChristTrekker14:22, 15 January 2013 (UTC)
So, if you visit a website, your IP is transmitted to them anyway. All that putting noreferrer on it does is deny the site owner useful information about who is linking to their site. So, oppose. —Tom Morris (talk) 20:48, 15 January 2013 (UTC)
Oppose, It is in the HTTP protocol for a reason, it is useful, people can block this on a case by case basis using scripts so removing noreferrer for the whole site seems pointless and wrong. ·Add§hore·Talk To Me!21:20, 15 January 2013 (UTC)
Oppose, it's standard, useful for web analytics, and if the user doesn't want to people to know where they've been, they can disable it themselves/use the secure server. --SarekOfVulcan (talk)11:50, 16 January 2013 (UTC)
Oppose 1) Referrers are part of the structure of the Web. Wikipedia should work with the web protocols, not against them. 2) One way to measure the success of partnerships with GLAMs and other organisations is for them to see how many referrals they get via Wikipedia. This is important: one of the drivers of the growing academic respectability of Wikipedia is that people who run scholarly journals or online archives are seeing how much Wikipedia is driving their traffic. MartinPoulter (talk) 19:23, 19 January 2013 (UTC)
Oppose - Sarek sums it up beautifully. As we are the Worlds fifth largest (and by far the most visible) website out there, it's up to us to lead the way in standards. There is a simple solution to this: Edit the Special:LoginUser page to briefly mention noreferrer in the explanation field. -T.I.M(Contact)01:19, 24 January 2013 (UTC)
Oppose; there are no genuine privacy benefits, and there are a number of entirely legitimate technical reasons why that header is useful. Users genuinely concerned about following links should use the privacy extension of their browsers or retype URLs, not rely on specific sites using noreferrers. — Coren(talk)03:33, 25 January 2013 (UTC)
Oppose per Anomie, Sarek, Martin, Tom. If we are really concerned about users privacy under the belief they cannot take care of it themselves, we should enable HTTPS by default as MZMcBride and Edoktor have suggested. Nil Einne (talk) 07:03, 25 January 2013 (UTC)
Comment Referers are still sent when the url is https. Also, https doesn't help much with privacy of page views if someone can snoop the TCP traffic (since the lengths of the pages are still observable through the encryption, and that goes a long way towards identifying the pages). Https is useful for protecting passwords but that's about it. It has nothing to do with this referer issue and is a red herring. And the idea of asking users to log in and set a profile option to turn off referers is unhelpful: logging in correlates all of the person's pageviews together (a privacy problem in its own right), and anyway the vast majority of visitors never log in or edit (that's that #5 website in the world thing: non-logged-in read-only users). It would be ok to have a login option to turn the referers on for users who want to send them. 67.117.146.66 (talk) 08:54, 25 January 2013 (UTC)
Clarification: Referers are sent when following a link from one HTTPS site to another, but are not sent when following a link from an HTTPS site to a plain HTTP one. (I think this is what you meant; I'm just making it a bit clearer.)
As well as passwords, HTTPS is useful to protect login cookies (which can be used to impersonate a logged-in user if discovered). HTTPS can also effectively protect non-public content, such as deleted pages being viewed by administrators. – PartTimeGnome(talk | contribs)23:34, 25 January 2013 (UTC)
Oppose -- This putative "improvement" to privacy is many orders of magnitude smaller than the privacy failure we create in making permanent, publicly-available records of all contributions by IP address for most editors, that is to say, IP editors. Convince the community that not requiring account creation isn't a serious privacy concern, and do something about *that*, and then we can deal with the at best marginally-useful improvements like this. --j⚛e deckertalk23:49, 3 February 2013 (UTC)
This issue seems slightly paranoia. Anyway, it will also be moot once Wikipedia switches to https-only, as clicks from secure sites never send referrers. — Edokter (talk) — 09:34, 13 January 2013 (UTC)
Normally I'd favor any efforts by a site to protect its users' privacy. In this case, since concerned users already have ways to strip or forge referrers on their own (several methods are mentioned here), I don't see a compelling need for any action on Wikipedia's end. Kilopi (talk) 05:30, 15 January 2013 (UTC)
I'm leaning towards oppose. Referers provide useful information for webmasters, which most sites do not use in a way that threatens privacy. Users should decide for themselves whether or not they want to provide referers to websites and use their browser settings (or add-ons) to control this. (I acknowledge that browser makers could do more to make privacy options clear to users.) I also regard the proposal as abusing the "noreferrer" feature, as the HTML5 authors did not intend it to be used across a whole site.
However, I'm putting myself down as neutral because I think the noreferrer feature should be used in limited circumstances. When someone with permission to view an oversighted (or deleted) page clicks an external link, a referer should not be sent. Some websites make referer logs public, and hence could expose article titles that have been suppressed on Wikipedia. Given that a common reason for suppression of a title is a BLP problem, we should do everything we can to prevent such titles being sent to other sites. Protecting non-public information such as this is the intended use of noreferrer. – PartTimeGnome(talk | contribs)23:30, 15 January 2013 (UTC)
Question: http://wiki.whatwg.org/wiki/Meta_referrer gives four possible values for using referrer in a meta tag (never, always, origin, default). Are we talking about adding a meta tag to our HTML or adding something to the HTTP headers? If the latter, are those four values available in the HTTP header? --Guy Macon (talk) 20:34, 16 January 2013 (UTC)
Thus far, this proposal has discussed adding the HTML5 rel="noreferrer" to every link. Using the meta tag would be another way to achieve the same end. I am unaware of an HTTP header that would have the same effect. If we were to go ahead with this, it might be worth investigating which method has the best support amongst browsers (or just use both to be extra certain). – PartTimeGnome(talk | contribs)22:47, 16 January 2013 (UTC)
If we can make it work, the "origin" option has a lot going for it. It tells the linked-to page that the link came from en.wikipedia.org without saying what page on Wikipedia. --Guy Macon (talk) 06:58, 17 January 2013 (UTC)
I have always used double click to edit, but it has stopped working (XP, IE8, Vector). I first noticed it a couple of days ago and assumed it was a temporary glitch, but it is still not working. Yes I have purged, and rebooted, and I haven't touched my JavaScript, whilst other things relying on Java - such as the edit toolbar - are still working. Arjayay (talk) 18:44, 30 January 2013 (UTC)
It was working a few minutes ago - came to this page to report this, double click and.... It's not working again. - Arjayay (talk) 09:13, 31 January 2013 (UTC)
Still not working, but have noticed that double click works on the first use, having opened Wikipedia, but odesn't work thereafter until re-booted - seems to be some soort of "hang-up" _ Arjayay (talk) 19:38, 3 February 2013 (UTC)
In my case it’s the right-click on section titles that isn’t working; I’ve resorted to turning the “[edit]” links back on in Preferences.—Odysseus1479 (talk) 03:59, 31 January 2013 (UTC)
I think it's because you created the redirect on Wikipedia. If the image is on Commons, I believe that the redirect must be on Commons too. --Redrose64 (talk) 19:15, 1 February 2013 (UTC)
I guess ImageRemovalBot got the same false message as us that the file doesn't exist, and the bot reacted like it's supposed to react for files that don't exist: Remove them. PrimeHunter (talk) 02:34, 2 February 2013 (UTC)
CommonsDelinker replaced Flag of the United States Army.gif above with the new name as well. This caused the image to display correctly. I've undone the bot here, since that is supposed to be an example of using the redirect, not using the new name directly. – PartTimeGnome(talk | contribs)15:31, 2 February 2013 (UTC)
This is strange... After undoing the bot, the image redirect displays correctly now, even though it used to be a red link for me. Even if I look at an older version of this thread that didn't work before, I see the image correctly. It might have been a caching issue of some sort. – PartTimeGnome(talk | contribs)15:39, 2 February 2013 (UTC)
It appears to vary which of the file redirects are working. Flag of the United States Army.gif also works for me now, both here and at commons:User:PrimeHunter/sandbox, but the three other examples still don't work. I tried to track down when the problem started by previewing Commons files moved at different times yesterday, but I couldn't come to a conclusion because it sometimes varied between previews whether a given redirect worked. PrimeHunter (talk) 16:12, 2 February 2013 (UTC)
Cool. The redirect now works, so the un-edited articles should work.
Do we know what went wrong here?
If it was user error (in the way the file was moved), has it been documented so the wiki software might be able to warn users in the future if it sees the same actions?
If it was a wiki software error, has it been documented and fixed? Did other similar renames fail in the same way and have they been fixed?
Is there an explanation somewhere of how redirects work with these kinds of files (that are apparently on Commons, but still referred to as though they were in the enwiki File namespace I think)? There doesn't appear to be an actual redirect on enwiki – links to the old filename just go to the new filename when followed.
When a file is moved (whether on Wikipedia or on Commons), a redirect is normally left behind, unless the moving admin deselects "Leave a redirect behind". This redirect should work for all normal usage of the file (but won't work if the file is accessed directly through the Media: namespace). When the file is on commons, a redirect on commons should be sufficient for all Wikipedias: the Wikipedias should not need to create their own local redirects. Unfortunately some commons admins are in the habit of deselecting "Leave a redirect behind", or of deleting file redirects that they encounter, without first ensuring that all file usage is for the new name. --Redrose64 (talk) 11:55, 3 February 2013 (UTC)
Most of these issues, when a properly redirected image does not show, are technical/software (database, caching) issues. It was working fine over a long period but one of the constantly applied mediawiki updates may have missed proper testing and broke something. In the past we had problems with improper deletions due to database quirks (page deleted but image stayed visible and was not deletable) so this may be related somehow. --Denniss (talk) 16:29, 3 February 2013 (UTC)
Billboard ID
Due to a site revamp, I'm having to rework {{singlechart}} and {{albumchart}}. The core of the problem is that to reference a Billboard chart for an individual artist, you need to know a six digit magic number. Billboard just changed them all, and I'm having to figure out how to update thousands of hardcoded magic numbers. I've done the search, and now know that there are approximately 14,000 artists that have both a Wikipedia article and a Billboard chart. More like 1000 actually have an existing call to singlechart or albumchart.
The brute force way to fix things is just take my updated list of 14,000 artists and throw it into {{BillboardID}}. That way, I can ignore the artistids being passed in to the templates, look up the magic number based solely on artist name, and only have one place to update when the numbers get changed. I suspect that something, somewhere, something is going to break if I do that.
My first thought is to break it into submacros based on the first two characters of the artist name, so that BillboardID is just a big switch statement that calls BillboardIDAA, BillboardIDAE, BillboardIDAQ .... BillboardIDZZ. What I don't know is the way the templates actually get processed internally. If I did that, would I still wind up loading all 14,000 artists every time as the template expanded?
My second alternative is to set up a special website that redirects you to the appropriate chart based on a database lookup. I'm not eager to pay money to do it, and feel queasy about setting up a universal redirection service to someone else's website. That's why I'd really like to figure out a decent way to do it inside a template.—Kww(talk) 04:48, 3 February 2013 (UTC)
I'm not sure whether #switch would expand all of the templates, but I'd do it like this instead: {{ BillBoardID/{{ uc:{{ padleft:|2|{{{artist}}} }} }} }}. Hence, if {{{artist}}} begins "Ab", this should transclude {{BillboardID/AB}}. This would only expand the one template. If the template might not exist and you want to avoid showing a redlink, you can combine this with #ifexist to check for its existence before trying to expand it.
As for your idea of setting up a special website, the Toolserver can provide free hosting for tools that are useful to Wikimedia wikis. Wikimedia Tool Labs will replace Toolserver at some (uncertain) point in the nearish future, so bear in mind your site's URL is likely to change if you go down this route. – PartTimeGnome(talk | contribs)15:34, 3 February 2013 (UTC)
External links should nearly always go directly to the target and not via a redirect service, not even one we set up and control. If {{BillboardID}} gets thousands of artist-ID combinations in one big template then it becomes expensive to use. Subtemplates could help but the proper solution is to add the ID in the calling article. Consider Wikipedia:Bot requests for this. Bot requests have been used many times to update links to moved or revamped websites (my own experience with this was very poor but hopefully it normally runs better). PrimeHunter (talk) 15:47, 3 February 2013 (UTC)
Which of the files MonobookStylesheet, MediaWiki:Common.css, commonPrint.css do I need to make another wiki have the same look as wp when class="wikitable" is used? and where should it go? in particular the less gray background in the table header seems not to materialize? Electron9 (talk) 16:54, 3 February 2013 (UTC)
How do you deal with two changes in a row on pending changes? at Super Bowl, I would like to accept a change by Mjrmtg (grammar fix) and reject the change by the IP before him. In addition, why wasn't my change reviewed? RyanVesey15:12, 3 February 2013 (UTC)
Even more weird, while Mjrmtg's edit doesn't show up as accepted, it appears in the article. It also doesn't show my most recent review in the log [33]RyanVesey15:22, 3 February 2013 (UTC)
Not that I claim to be an expert on pending changes, which I'm not, but my understanding is that you can only accept the latest revision, not individual diffs. So to accept some changes and not others, you have to revert the unwanted changes and then simply accept the resulting revision "authored" by you. The valid changes then do not appear in the page history to be accepted, but still show up because a later revision was accepted without those changes being reverted and MediaWiki simply shows the latest accepted revision. jcgoble3 (talk) 19:38, 3 February 2013 (UTC)
Let me see if I can answer all questions:
Ryan: If you make an edit to a page with pending changes without reviewing those changes first, it treats your edit as if you didn't look at the pending changes. It therefore adds your edit to the queue of changes pending. This is so that vandalism isn't accepted when a reviewer makes an edit (or an autoconfirmed) when it shouldn't be.
Unaccepted edits appear to all logged in users. There is a preference that can be changed to deal with this.
Jcgoble is correct that you can only accept a 'version', and only the latest one. That prevents you from accepting your edit, but not the old one. Darn technical difficulties...
The English Wikipedia introduced restrictions on page creation on 5 December 2005 in response to the Seigenthaler incident. Though this was originally intended as an experiment on ways to reduce hoax and attack articles, the restrictions have since become permanent. Read the Signpost article written at the time for more detail.
Targets from a Google search are actually URLs to Google itself, which then redirects to the actual target. That's fine for HTML and text targets: after a moment the browser is refreshed to the intended URL. But for certain filetypes (most notably PDF and I think MS Word and Office files), you never get the final URL, you only get the Google redirection URL. The Google redirection URL is spam-blocked, because it could be used to avoid other spamblocks. That's reasonable, but it's so difficult to discern the actual target you want for a PDF. All you have is the Google redirection URL, which is full of extraneous data and which encodes many the slashes, percent signs, and others. Is there a tool into which you can paste a Google redirection URL and get back the target?
For example, I'd like to dump in:
http://www.g00gle.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&cad=rja&ved=0CFQQFjAF&url=http%3A%2F%2Fjfk.hood.edu%2FCollection%2FWeisberg%2520Subject%2520Index%2520Files%2FO%2520Disk%2FOlney%2520Warren%2FItem%252009.pdf&ei=HI4OUYX9Hs_EiwK4uIG4Dw&usg=AFQjCNHwjHRIhEWarlEQ6M-5Xk8TAusKYQ&sig2=QCGZzGelt140atGm6bfW8Q&bvm=bv.41867550,d.cGE (URL munged to "g00gle" to avoid spam-blocker)
In Google, click the long-form link; when you are on the target page, go to your browser's address bar and copy that. --Redrose64 (talk) 17:32, 3 February 2013 (UTC)
What browser? In Firefox (multiple releases) for me, the target page is not updated for PDFs; that's the issue I'm describing above. Hmm... I should probably note that I view PDFs with Acrobat, not internally in the browser; that may make a difference. TJRC (talk) 18:08, 3 February 2013 (UTC)
I think it's because of my configuration to use an external viewer. Anyway, the question remains: is does anyone know of a tool into which you can paste a Google redirection URL and get back the target? TJRC (talk) 19:43, 3 February 2013 (UTC)
This should work:
In the Google URL, copy the text between "&url=" and the next "&". That gives you the (double) percent-encoded URL: "http%3A%2F%2Fjfk.hood.edu%2FCollection%2FWeisberg%2520Subject%2520Index%2520Files%2FO%2520Disk%2FOlney%2520Warren%2FItem%252009.pdf"
To convert that back to the original URL, you can paste the above encoded text into the box labelled "Percent encoding for URIs" on this handy webpage: http://rishida.net/tools/conversion/
You can also use a redirect checker to examine where Google actually redirects it. With a Google search on "redirect checker" I found http://www.seologic.com/webmaster-tools/url-redirect. The response field for your url says URL='http://jfk.hood.edu/Collection/Weisberg%20Subject%20Index%20Files/O%20Disk/Olney%20Warren/Item%2009.pdf'. PrimeHunter (talk) 22:57, 3 February 2013 (UTC)
I process the raw page view statistics provided by the WMF (to make things like WP:5000). Prior to February 1, this file was always in a 4-column space-delimited format. However, beginning on that date, page titles started to appear which had spaces instead of underscores in them -- although this is not always the case (only a couple thousand in a file with several million lines). My processor started throwing errors and I've since fixed it -- but I could imagine this being a potential problem for those who haven't noticed the change or are not actively maintained (e.g., Henrik's tool). Is there any explanation why this occurred? Thanks, West.andrew.g (talk) 18:05, 3 February 2013 (UTC)
They changed the format of the source log files to be tab-delimited instead of space-delimited, to make processing easier when the field values contain spaces. They intended to not change the format of pagecounts-raw,[34] but apparently something earlier in the process used to convert spaces in the page names to underscores but doesn't anymore. Hopefully that can be fixed quickly. Anomie⚔20:44, 3 February 2013 (UTC)
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)
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)
(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)
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)
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)
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)
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)
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)
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)
→ 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)
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)
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)
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)
Rate vs. Help
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)
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)
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)
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)
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)
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)
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)
I don't think this is possible, but the group notice could add code to examine the pagename and display blank on the given page. PrimeHunter (talk) 02:42, 6 February 2013 (UTC)
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)
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)
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)
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)
This is a confirmed problem related to the eqiad migration, and operations is working on it now. Hopefully should be resolved shortly. ^demon[omg plz]14:43, 23 January 2013 (UTC)
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)
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)
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)
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)
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)
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)
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)
Still an issue UK 11:46gmt 24JAN2013, main page shows 23JAN data, tried all the purges etc, viewing vis USA proxy shows correct date data. — Preceding unsigned comment added by 213.104.131.116 (talk) 11:47, 24 January 2013 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
I reported a related squid issue in August 2011[35]. 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)
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)
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)
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)
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.
I tried purging [[Template:ITN-Update]] and Template:DYK-Refresh but it still shows the time as 01:42 UTC even though I live at UTC+4 and the time here is nearly 10:00am, so therefore the clock should be about 6:00am. It's not a huge problem (at least it shows the correct date!) but the clock still seems to be a few hours behind here. - a boatthat can float!(watch me float)06:02, 26 January 2013 (UTC)
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)
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)
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)
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)
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)
I just want to let everyone know that we've poked all the right people, hopefully they can keep tracking down the issue :-/ Jalexander--WMF15:37, 26 January 2013 (UTC)
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)
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)
Thanks Yoda1893 -- It looks like the multicast bug has bitten us again - i will be spending some time on the routers today to try and fix this — Preceding unsigned comment added by LeslieCarr (talk • contribs) 19:45, 26 January 2013 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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.[36], Not even in edit history page unless you slide to next [37]. 174.118.142.187 (talk) 22:35, 25 January 2013 (UTC)
And now the problem is back on another machine! Spoke too soon! Thanks. I read that and figured that problem was a fixed one from the past. LOL 174.118.142.187 (talk) 23:54, 25 January 2013 (UTC)
why can i not hide this
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)
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)
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)
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)
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)
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)
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)
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)
"?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)
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)
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)
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)
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)
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)
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)
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)
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)
Oooh :(. This is weird; I'll talk to Leslie again (tomorrow. She's taking today off due to the working-for-8-days-in-a-row thing) Okeyes (WMF) (talk) 17:01, 29 January 2013 (UTC)
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)
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)
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)
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)
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)
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: [38][39][40] 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)
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)
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: [41]. --Moscow Connection (talk) 16:17, 1 February 2013 (UTC)
(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)
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)
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
Resolved
Resolved
it's a known bug, I have reported it to this pump before, but I can't remember if there is a bugzilla for it (or a workaround) - looks like PTG is correct though. Rich Farmbrough, 00:51, 13 January 2013 (UTC).
Done Will do. -- Alan Liefting (talk - contribs) 01:35, 16 January 2013 (UTC)
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
-1.jpg){kind=link}
-1.jpg){kind=link}
. -- Alan Liefting (talk - contribs) 20:44, 25 January 2013 (UTC)
