Wikipedia:Village pump (technical) - Wikipedia


37 people in discussion

Article Images

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security@wikimedia.org.

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

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

TL;DR: this is to announce a small new addition to the editing experience, based on previous testing.

What it is, and when it's going live:

 
The post-edit confirmation message on the Sandbox. View full resolution to get a sense of the right scale.

This is a confirmation message that will tell all editors, anonymous or registered, that "Your edit was saved". It only appears for two seconds and then fades out, and is also dismissable via close button.

It looks like the screenshot to the right, and will work in most skins and browsers. Since it is supposed to consistently tell editors that their contribution was saved, it will appear on all edits, except page creations (since the message refers to an edit, which could be confusing use of the term when referring to page creation).

We're going to deploy this on Thursday, pending any last minute bug fixes, and it should go live shortly after.

Why we're launching it:

Confirming to someone that the contribution they just made was successful is a very common usability enhancement. It is used by most major Google products (Gmail, Maps, YouTube, etc.), Twitter, and innumerable other sites, like Dropbox. It is not used by sites like Facebook or Google Docs, where contributing is visually obvious 100% of the time, though clearly that's not the case when editing Wikipedia.

As part of editor engagement experiments, we tested this change with several thousand new registered editors, and comparing them to a control group, we found a significant increase in the volume of their edits — 23% in the short term — without an associated increase in how often they were reverted or deleted. (There's more about the results in our recent blog post.)

This data backs up the experience you see if you teach someone to edit. I've personally heard first time editors ask things like, "So what happens now?" and "When does it go live?" after saving. This message answers that question.

Please give it a try:

I realize that this may seem unnecessary for everyone is a very active editor already, and has thus learned that a successful save just means the page reloads in read mode. But since we've designed this feature to have as minimal an impact as possible, and because it has made a very measurable difference for people who are less experienced, I am asking everyone to give it a try for a week or two before making a final judgement about it. It's pretty easy to have a small, fast notification like this disappear from your attention after going about normal editing for a bit.

We've not immediately added a preference or gadget to remove this, for three reasons:

  1. No other website allows you to permanently disable small notifications that confirm a contribution. This includes existing Wikipedia notifications like the watch/unwatch bubble message. They only exist on screen for a few seconds, and are dismissable in case they obscure any content. We're not making this dissappear after something like 100 edits, because once you start to expect it, not seeing it might look like the system is broken. For new people especially, who will be expecting to see this from their first edit on, consistency is extremely important.
  2. The preferences tabs are totally bloated with checkboxes for single features, and there is already discussion about how to remove cruft. If in a while, the feature continues to be extremely distracting, then we can talk about adding a preference to opt out.
  3. Personal CSS or JS can't hide this, because of the speed at which it appears and the order in which personal styles are loaded compared to the rest of the site. Update: It looks like we missed this, because the test environment we use didn't have personal styles enabled. Thanks to Yair rand below, the following CSS might work to hide the feature...
.postedit {
   display: none;
}

Thanks for reading all that, and of course please speak if you have questions/comments. Steven Walling (WMF) • talk 09:55, 17 October 2012 (UTC)Reply

Good feature! I'm the sort of experienced user who will not benefit, but I'm glad that the inexperienced user is being considered. Binksternet (talk) 19:46, 17 October 2012 (UTC)Reply
I second that. This will (probably) not bother me too much (I'll just have to remember that the box fades out in a few seconds), and I think it's going to be a very effective feature to tell first-time/new editors in a quick and clear way that they have actually edited a page. I know how lots of people wonder: so did it save my changes or not? Jsayre64 (talk) 22:48, 17 October 2012 (UTC)Reply
Please give it a try: Interesting wording. Unless I'm misunderstanding something, since we can't turn it off, if we still want to edit we will be forced to try it. So why say please? I'm not saying the "feature" is bad, I'm just saying you probably could have chose better wording.--Rockfang (talk) 20:12, 17 October 2012 (UTC)Reply
I used that language in the context of Jimbo's request at Wikimania in 2011 [1] to give the WMF some more room to deploy things, give them a try, and then give us feedback. The assumption is that this will be permanent because we previously tested it, but that definitely doesn't mean we're not open to feedback and changes in the future, including an opt-out. I just didn't want to start the conversation with an assumption that we don't want to ever change things for existing community members, and instead want to request an open mind about it. I realize that's not as simple as it sounds, but I watch VPT and other forums pretty closely, so we're not just going to dump new software on the site and run. Steven Walling (WMF) • talk 20:54, 17 October 2012 (UTC)Reply
"...so we're not just going to dump new software on the site and run". From my observations, from big projects to small things, decisions made top-down by WMF fiat seem to be get implemented, "discussed" for a while until opposing users lose interest, and then forgotten about. Jason Quinn (talk) 00:17, 18 October 2012 (UTC)Reply
  • nagware I kind of like keeping browser scripting turned on, on sites like this, where presumably the scripting is non-harmful (actually, it's not, every year or so I have to create a new browser profile to fix various "bugs" that seem to come from "somewhere"). While I can't think of the wikipedia name offhand, the editor which color codes the editing window separating text from code is kind of nice to use, but I guess I can turn it off, it just is slightly more tiring to use, and takes a little longer to make edits. That's the side effect of stopping these popups. Maybe someday the foundation will decide that encyclopedia content shouldn't be visible unless scripting is turned on, like some sites do now. It's almost humorous, follow a link to read something and find a Blank Page unless scripting is allowed. Can't serve a page until ID is shown. Show us your papers! Gzuufy (talk) 15:28, 18 October 2012 (UTC)Reply
    • "Maybe someday the foundation will decide that encyclopedia content shouldn't be visible unless scripting is turned on, like some sites do now." Doubtful. Unlike some participatory sites, many of which require login and other stupid requirements to just read content, job number one for us is to give away the encyclopedia to as many people as possible. For readers, we are actually are moving in the opposite route of what you describe, enabling features such as optionally disabling images on the mobile site to speed up page load times for those on slow connections. Reading != editing when it comes to browser requirements. Steven Walling (WMF) • talk 17:48, 18 October 2012 (UTC)Reply
Thanks Steven. Gzuufy (talk) 19:27, 18 October 2012 (UTC)Reply
So, if I have Javascript disabled in my browser, can I still edit? And will I see this message? InedibleHulk (talk) 19:13, 18 October 2012 (UTC)Reply
InedibleHulk, I just submitted this message with scripting off. I don't know if it is limited to disabling only javascript, I'm using Noscript. The editor appears slightly different. It opens quicker, probably due to the limited speed of my connection. I haven't seen those messages yet, once they appear, we'll know what, if anything, works to block them. Gzuufy (talk) 19:27, 18 October 2012 (UTC)Reply
Yes, you can edit without JS. And no, you won't see this message if you have JS disabled. Steven Walling (WMF) • talk 19:40, 18 October 2012 (UTC)Reply
Cool, thanks. No objections here, then. InedibleHulk (talk) 20:09, 18 October 2012 (UTC)Reply
  • If the purpose of this is to let users know when their edits were saved, shouldn't userrights (with the exception of, say, "confirmed") disable this? I can't imagine this affecting users who already have rollback, etc. on their accounts. That said, this is only minimally intrusive. Several userrights have their own .css Special: pages, so perhaps the disabling script mentioned above could just be added to those pages? --Philosopher Let us reason together. 05:08, 19 October 2012 (UTC)Reply
    • That would make perfect sense if you consider everyone who already has these userrights, but think about it from the perspective a brand new person. Say you start editing today, make a few thousand edits. You've learned that a successful edit = seeing that two second flash. You get rollback, and suddenly you don't see the confirmation anymore, on your edits or on rollback. That would probably seem like an error, if you've grown accustomed to it. The feature is configured like it is not because we really want you to read the message every time, but because a consistent display like this, with the green checkmark you can easily scan, is an extra assurance. Steven Walling (WMF) • talk 05:15, 19 October 2012 (UTC)Reply
      • That's a fair point. What page does the code come from, btw? Given your point about the accustomed user being surprised, perhaps it'd be better to just put the "disable" code on the talk page of whatever MediaWiki: page the code comes in from (for easy reference) but leave it active for everyone? I'll admit I was surprised at how minimal the intrusiveness was, but I'm going to turn it off for myself anyway. --Philosopher Let us reason together. 05:48, 19 October 2012 (UTC)Reply

Has the change been deployed yet? On the older rig I use (IE7, Windows XP but with JS enabled) I'm not seeing the change enabled yet or on Safari on iPhone. Haven't checked on anything else. if it has been deployed can the wtachnotice be removed. NtheP (talk) 08:06, 19 October 2012 (UTC)Reply

  • I have a concern that will come into effect with the reintroduction of pending changes this December. Suppose a new editor makes a change to a page, gets this message telling them their edit was saved. Yet, it hasn't appeared until a reviewer has checked the edit and passed it. This will cause confusion with all the newbies wondering why their edit hasn't showed up. I am opposed to pending changes anyway. Rcsprinter (post) @ 16:37, 19 October 2012 (UTC)Reply
    • The use of Pending Changes or Flagged Revisions is part of why we went with the very specific language of "Your edit was saved", as opposed to "Your edit is live" or similar. (This feature is also deployed on German Wikipedia currently as well, btw.) Even if PC or FR is used at 100% it is accurate to say that the edit was saved. Remember that new editors don't all have a mental model of editing like we do, where saved == visible. Steven Walling (WMF) • talk 22:59, 21 October 2012 (UTC)Reply
  • I like this a lot. However two seconds seems a bit fast; you could easily miss it, especially if you were looking at somewhere else on the screen (where the save button was?) and then looked up. Not everybody is super quick off the mark. I'd suggest extending the duration to four seconds. I also think a slightly slower fadeout would look nicer, but that might just be me; the visible duration is more important. — Hex (❝?!❞) 19:01, 19 October 2012 (UTC)Reply
  • Not to second-guess those working on technical improvements for the encyclopedia—but I generally feel that we should avoid most bells & whistles unless there's a really good reason to add them. Creeping complication, load times, clutter, etc. ... groupuscule (talk) 22:28, 19 October 2012 (UTC)Reply
    • I agree 100%. It's one of the maxims of good design that more features all the time generally don't always help, and in fact often hurt usability. That's why the team explicitly takes an experimental approach to new things, where we test them out before committing to enabling them forever/for everyone. For this feature, the demonstrated positive impact it had for new editors, plus the fact that this design pattern is very common on the modern Web, is why we decided to add it. Steven Walling (WMF) • talk 22:37, 19 October 2012 (UTC)Reply
  • Can't say I have read everything above but I'm guessing some of our long-term users are complaining about it in there somewhere, so for the record this long term user thinks it is just fine and can easily see that new users would find this helpful and reassuring. FYI it works fine on my iPad (not everything here does) and does not seem to be affecting page reload times at all. Beeblebrox (talk) 23:09, 19 October 2012 (UTC)Reply

This shows just long enough to be annoying (like something flickering in your peripheral vision annoying), and barely long enough to be useful. Bonus: can transient JavaScript dialogs be trusted? Why no, no they can't. :p ¦ Reisio (talk) 17:38, 20 October 2012 (UTC)Reply

  • I'm getting the same bug as some others here. Telling editors their edit was saved when no edit was saved is very misleading. If it can't be fixed it should be turned off. Ryan Vesey 20:07, 20 October 2012 (UTC)Reply
Me too. Right now I am getting the message every time I use the browser Back function to return to a page I saved 15 minutes ago. (IE8 on XP). Nurg (talk) 20:38, 20 October 2012 (UTC)Reply
That's a bug we're going to deploy a fix for in the coming week. Sorry for the annoyance. Steven Walling (WMF) • talk 23:35, 21 October 2012 (UTC)Reply
Should be   Fixed now. Steven Walling (WMF) • talk 17:15, 23 October 2012 (UTC)Reply

I am still seeing this in Chrome (Mac OS) every time I go to to a new page without editing, even if I am logged out. Firefox and Safari seem fine. Jokestress (talk) 13:08, 27 October 2012 (UTC)Reply

Did you try clearing your cookies and cache? The issue appears to be fixed for me. Steven Walling (WMF) • talk 01:45, 29 October 2012 (UTC)Reply
The issue still happens in Chrome. I have some additional details. I cleared cache and cookies, logged back in and visited several pages. Everything was fine - no notification. Then I did a small edit to a bio, and the notice came up. After that, every new page I visited had the notice come up. Even when I opened this page to add this comment, it said "your edit was saved" after it loaded, before I even made a change. Hope this helps. Jokestress (talk) 17:36, 29 October 2012 (UTC)Reply
I get this same issue on FF 16.0.2 on Mac. Every link I click.. "Your edit has been saved" 24.123.186.227 (talk) —Preceding undated comment added 14:26, 9 November 2012 (UTC)Reply
Please allow a preference to disable this
  • No matter how much one editor thinks this is a really good idea, there will ALWAYS be a whole bunch of people who do not. Imposing preferences on everyone is like the Henry Ford style operating philosophy: you can have any car you like so long as it's black. That's a really outdated way of thinking, and it's a real pity people think that's acceptable now. Wikidea 10:02, 21 October 2012 (UTC)Reply
Sorry, I see there's some discussion above about how to switch it off, but can you explain the steps for people like me who aren't developers? I'd be grateful. Wikidea 10:09, 21 October 2012 (UTC)Reply
You add ".postedit { display: none; }" (without the quotes) to Special:MyPage/skin.css :) - Jarry1250 [Deliberation needed] 11:34, 21 October 2012 (UTC)Reply
Many thanks for your help. Wikidea 17:31, 21 October 2012 (UTC)Reply
I do think it's a good idea for newcomers, as I've seen questions asked on the Help Desk many times relating to this issue, but I can't add the above text to anything because "Wikipedia does not have a user page with this exact name."— Vchimpanzee · talk · contributions · 19:56, 26 October 2012 (UTC)Reply
No, you don't; but that's not a problem. You merely need to create it: go to Special:MyPage/common.css (which should give you a heading "Creating User:Vchimpanzee/common.css" and an edit box; paste the single line
.postedit { display: none; }
into that edit box; and click Save page. --Redrose64 (talk) 20:18, 26 October 2012 (UTC)Reply

Thanks. — Vchimpanzee · talk · contributions · 20:34, 26 October 2012 (UTC)Reply

Another bug?

In Firefox (16.0.2), while editing a section in a long page, after the edit is saved I'm not redirected to the relevant section. Repeating the same process with JavaScript disabled works. ¦ Reisio (talk) 16:12, 3 November 2012 (UTC)Reply

Is it only long pages, or any pages with sections? Steven Walling (WMF) • talk 22:38, 5 November 2012 (UTC)Reply

I can't reproduce it on the long page I was noticing it on now, so perhaps it's a bug on Firefox's end (in fact I noticed an entirely different strange bug only in Firefox 16.0.2 [on another OS, on sites not to do with Wikipedia] which only lasted until restarting the browser... which also makes it more suspect :p). Sorry for the bother, I will of course give a yell again if I can reproduce it reliably. ¦ Reisio (talk) 03:36, 6 November 2012 (UTC)Reply

No worries. I'll keep an eye for it. Steven Walling (WMF) • talk 08:02, 6 November 2012 (UTC)Reply
Are you sure it wasn't just because there were two identically named sections on the same page? That confused me the first time I encountered it. (After editing any such section, you will always be returned to the first one on the page [unless this issue has been fixed, but I don't think it has].) If so, this wouldn't have anything to do with the pop-up — and maybe someone renamed one of the sections before you got back to the page to try to reproduce the bug. Alternatively, it could be because there's a "collapsed" table (or other content) on the page. Collapsed tables seem to be rendered fully before they collapse, which sometimes causes one's browser to become confused as to what portion of the page to display (in my experience). - dcljr (talk) 23:22, 6 November 2012 (UTC)Reply
Not the former, but I suppose it could potentially be the latter... although I've been editing such pages (both long and with collapsed content) for a long time, and don't recall this happening before. If it is due to the other content on the page, you could check [2] if you're really interested. I won't get back to it myself for a while. ¦ Reisio (talk) 23:37, 6 November 2012 (UTC)Reply
It does seem to be due to JS collapsed sections (and therefore not likely related to this popup), although I suspect something has changed in Firefox 16 to make me notice it. ¦ Reisio (talk) 23:47, 6 November 2012 (UTC)Reply

Location of message

I wonder if the message could be made to appear slightly lower on the page. It's not a huge bother since it disappears quickly, but it does temporarily obscure the history tab, which I often reach for after saving an edit (especially after reverting vandalism). A minor annoyance. Rivertorch (talk) 19:49, 7 November 2012 (UTC)Reply

Is this in Monobook or Vector? We're considering alternate ways to position the message offset from the top, but haven't deployed any changes yet. Steven Walling (WMF) • talk 20:01, 9 November 2012 (UTC)Reply
Monobook. Rivertorch (talk) 16:32, 10 November 2012 (UTC)Reply
And it occurs to me that a good place for the message might be at the extreme top left, where all it would obscure would be the WP logo. Just a thought. Rivertorch (talk) 07:01, 12 November 2012 (UTC)Reply

On Tommy, when clicking on the watchlist star, it starts turning round on an on, for minutes... and hours and this problem has been starting exactly 24 hours ago (no problems at all regarding other articles). I gave up trying to get this article in my watchlist, but it would be better if u could settle it up... thanks ;-) --Bibliorock (talk) 04:29, 3 November 2012 (UTC)Reply

I'm seeing this too, using Firefox 13. I have no idea how to debug this, but a workaround is to add "?action=watch" to the URL. -- John of Reading (talk) 07:08, 3 November 2012 (UTC)Reply
Seems we have another JS bug in MediaWiki. —TheDJ (talk • contribs) 12:04, 3 November 2012 (UTC)Reply
It happens if I preview any page with an ogg file, for example File:Alessandro Moreschi.ogg in Tommy. If I view (not preview) an existing article with an ogg file then sometimes it only happens after I purge the article. This is for example what happened for me at Castrato. PrimeHunter (talk) 16:46, 3 November 2012 (UTC)Reply
Confirmed using Firefox 16.0.2 and Monobook. Perhaps it's something to do with the new Timed Text feature? See Wikipedia:Wikipedia Signpost/2012-10-29/Technology report --Redrose64 (talk) 16:53, 3 November 2012 (UTC)Reply
Both problems are now solved, but one of the fixes is not yet deployed. —TheDJ (talk • contribs) 09:31, 5 November 2012 (UTC)Reply
Thanks.--Craigboy (talk) 00:22, 6 November 2012 (UTC)Reply

Thanks a lot... from Paris w/love ;-)--Bibliorock (talk) 17:22, 11 November 2012 (UTC)Reply

I am trying to clear the backlog at Category:Articles with missing files. Some of the articles listed in the category (generally album articles) don't actually have a missing file and don't have the missing files category listed (it is a hidden file but my prefs are set to view them). Doing an edit to the articles clears it from the maint category. The problem seems to occur when album cover art is added to the infobox. Seems to be an infobox problem? Here are some examples:

Doing an edit clears out of missing files category. In recent days an editor has been adding lots of images to the album articles bumping up the article count in the maint category. I had virtually cleared all the articles up to those starting with the letter H. And look at it now! Help!!! -- Alan Liefting (talk - contribs) 05:06, 5 November 2012 (UTC)Reply

From the category page: "If there is no hidden category listed in the article [...] or it is a glitch where a previously redlinked image has been created (?). Doing an edit to the article clears this glitch." One look at Special:Contributions/J04n shows that this editor is adding a redlink image to the article, then using said redlink to upload the file, thereby triggering this glitch. I think we can probably safely kill the question mark in that quote. As for a solution that doesn't require tons of manual null edits, it's possible that the job queue could take care of these eventually, but being that it's a conditional inclusion, we may need Joe's Null Bot (BRFA · contribs · actions log · block log · flag log · user rights) to expand its scope a bit. jcgoble3 (talk) 05:46, 5 November 2012 (UTC)Reply
I just used the API to clear all the 0–9 articles out of the category except for two that actually have missing files. I'd do more but I need to go to bed. If you want to give it a shot yourself (it's a bit quicker than manual null edits), use the URL http://en.wikipedia.org/w/api.php?action=purge&forcelinkupdate&titles=XXXXX where XXXXX is the titles of all articles you want to purge at once separated by pipes ("|"), up to fifty at a time. I just copied and pasted six to eight titles at once from the category list directly into the address bar, inserted the pipes, and hit enter. jcgoble3 (talk) 06:03, 5 November 2012 (UTC)Reply
Thanks for that. I saw a bunch of stuff disappear out of the category. You go off to bed. I am just starting my shift! -- Alan Liefting (talk - contribs) 06:15, 5 November 2012 (UTC)Reply
If you want, I can set up a bot to do that (I think with a bot flag I can do up to 500 at once) daily/weekly. I'm already doing it for another category, so it would be extremely easy. Legoktm (talk) 06:22, 5 November 2012 (UTC)Reply
Yes please! That would save a lot of hassle. -- Alan Liefting (talk - contribs) 06:45, 5 November 2012 (UTC)Reply
So it's running right now but a bit slowly as to not overload the server. Once it finishes a full run through I'll take a look and figure out whether it should be running daily or weekly. Legoktm (talk) 14:06, 8 November 2012 (UTC)Reply
Well the bot finished running through the entire category and I'm not seeing much of a dent made... Legoktm (talk) 18:51, 8 November 2012 (UTC)Reply
Hmmm. Can you try again? There are lot of articles that have now cropped up in the "B" section and two in the "2" section that may need a bit of a tickle by the bot. Cheers. -- Alan Liefting (talk - contribs) 01:11, 12 November 2012 (UTC)Reply

While reverting an -ize- mispelling back to the -ise- demanded on an european-english article and quickly putting back the -u- into habour- two thoughts came to mind- one is unprintable but the other has probably already been considered. But Here goes:

I want a template {{tr-en-us}} which will be used {{tr-en-us|habour}} or {{tr-en-us|parlour|parlor}}/{{tr-en-us|parlour|best sitting room}}. This template will examine the readers keyboard or OS dialogue settings to see whether they use UK, AUS, or US international settings, and print out either the original or the US translation. Common problems could use one parameter, while the user could give a suggested translation.I would see this working by the server including a little javascript in the page head, and a tagged dictionary array in-line, which would render only the desired word. This should be extended to ==H0== to ==h6== tags, to embrace the problem word fibre. Any takers?

Go-on the first idea is to write a bot that searches each page written in am-en and changes the number four to for to achieve logical consistency. --ClemRutter (talk) 11:30, 5 November 2012 (UTC)Reply

Is this whole proposal a joke, or just your final sentence? Nyttend (talk) 11:39, 5 November 2012 (UTC)Reply
Have you any thoughts on the rest? We do have a big problem with articles such Fibreglass etc, and headings in multiple articles on seaports. Then there are the plethora of -ise-/-ize- reversions that probably don't appear to be vandalism to the ip-editor. So is there a technical solution? --ClemRutter (talk) 12:47, 5 November 2012 (UTC)Reply
the media wiki parser can't take user preferences or settings into account when expanding templates. doing so will practically mean no cache can be used, which will mean, in turn, that the current servers will sufice to serve the population of Lichtenstein. קיפודנחש (talk) 13:29, 5 November 2012 (UTC)Reply
See that- it can't be done server-side. Is it possible client side, or easy to implement!, string of javascript; onRefresh= (if language.thisbrowser=="en-US ( write ("harbor")) else (( write ("harbour")) ) which the browser will render. (pseudocode JS not my forté).A page like that should not blow the server cache. It is up to the user to refresh the page its browser has cache. As I say, just a wild thought but BE BOLD. If it is feasible- then could we politely ask Wikimedia to give us a Christmas present. --ClemRutter (talk) 15:08, 5 November 2012 (UTC)Reply
For pages which are frequent targets for good-faith but improper spelling "corrections" we have editnotices, such as Template:Editnotices/Page/Harry Potter and the Philosopher's Stone (film). --Redrose64 (talk) 17:47, 5 November 2012 (UTC)Reply
I'm pretty sure this is possible; I think the relevant JS variable is "window.navigator.language". But is this a good idea? First of all, I don't know how efficiently it can be done, and second of all, it would require changes to people's edits as well as the text they read. I personally wouldn't be super-comfortable with a script that changes my edits surreptitiously as I submit them. (Is there any precedent for something like that?) If we don't change edits as well as reading text, then our articles will become a confusing hodgepodge of different spellings that might not be visible to readers, but still there in the raw article. Am I not reading this correctly or something? Writ Keeper ⚇♔ 18:09, 5 November 2012 (UTC)Reply
This is a perennial proposal. Never gets anywhere; most people are willing to accept that some articles are written in British English and some in American English. (And just a few in some other varieties, usually barely distinguishable from British English, except for Canadian which is a mix.) See WP:ENGVAR for the accepted compromise — it isn't perfect but it mostly works, and to my mind it's better than insulting our readers by implying they can't handle an extra (or missing) u or two. --Trovatore (talk) 09:13, 6 November 2012 (UTC)Reply
Perennial- OK, I thought it would be. I do think you underestimate its importance in attracting a wider readership and institutional acceptance. For example, in a college setting a lecturer in the US could not quote or use most of the textile articles I write- due to the use of the term fibre. Spelling has to be perfect if you are be hassled by management. UK educational agencies decry WP for it lack of academic rigour and the number of errors it contains. (POV:These consultants all share the same single brain cell). They are not looking to a clever compromise. I don't think it insults our editors to use a little bit of markup. In the commercial world- you give the customer what he wants not what you think is good for him.
Alternatively, the lecture notes of the college lecturers would often make good WP articles- so getting them on board would initiate a two way traffic in steadily improving articles.
Next we have the problem of continually reverting ip-editors who -ize- a -ise-. Every time I do it, I feel guilty as it could be their first good-faith edit. I strongly believe that valuable editor start with a little bit of trial vandalism, then a few good faith edits then get a user name and start being productive. Reverting a couple of their first edits will just turn them away. A facility to copyedit it into a tr-template where it does no damage gives them a strong welcome message.
Yes, I can see that you could be uncomfortable in having articles with hidden content- I don't see this as an absolute problem. I am happy that anything I have created is 'loaded with translations' and editor so minded could place the page in a hidden category, or dissenting article creators could place theirs in a opposing category. I already switch between 4 keyboard settings while editing- could this be used to check 4 different renderings of the same markup.
If it is technical feasible could someone code it up so we could do a limited trial. I am just asking. WP needs to continually improve, this may be a useful way forward or not. Be BOLD and see it has any mileage. Any takers? — Preceding unsigned comment added by ClemRutter (talk • contribs) 12:28, 6 November 2012 (UTC)Reply

Any RFC to implement something of this sort would fail for the same reason that automatic date formatting was turned off on WP. See Wikipedia:Date formatting and linking poll. --Izno (talk) 13:46, 6 November 2012 (UTC)Reply

Yes, I agree the date autoformatting is good precedent here - much the same arguments apply. Very limited benefits (there is almost no EN-GB/EN-US difference that isn't easily readable and understandable) as a reward for an increased level of complexity.
The costs are nontrivial. I can't speak to the technical side (though that does feel costly), but it would instantly mean that the edit window was substantially more complex to use, through lots of templates being implanted into the text. I suspect this mess would scare off more new contributors than the alternative of a few reverted spelling "corrections"!
It would also impose a large burden on the community; we can't simply automatically tag words, as we don't want to change titles, direct quotes, etc. Articles would have to be marked up semi-automatedly or by hand, consuming a lot of volunteer time. It would also simply shift a lot of the ongoing disputes about article style to different venues, rather than stopping them - which words should be tagged, which are the "correct" forms for each variant, etc. (I would object to the assumption above that -ize is always wrong in EN-GB, for example). Again, I believe these costs substantially outweigh the benefits.
As to educational agencies challenging Wikipedia over quality, I spend a substantial proportion of my working time talking to these organisations about Wikipedia (they're surprisingly positive). While I usually mention the language variation issue as part of my general introduction, I don't think anyone's ever found it disconcerting or problematic. They tend to focus on the bigger issues ;-) Andrew Gray (talk) 13:58, 10 November 2012 (UTC)Reply
This is one point on a wider spectrum, with totally non-mutually-comprehensible languages on the other end, where we face a choice of whether it's better to handle the translation manually, eg. http://fr.wikipedia.org , not at all, eg. current EN-GB/EN-US ize/ise treatment, or some automated/semi-automated way (client-side, server-side, etc.). These imply some sort of trade-off among end-reader readability (writ large enough to include educational agencies' quality needs), ease of editing (and trust that the template and edit behavior will perform as desired), and server efficiency. MHO is that current edit/revert technology makes the optimum choice for the ize/ise issue the current scheme: the variants in spelling aren't a problem for most readers and I doubt many editors are put off by reversion of a single ize/ise change. That opinion is, however, pretty narrow to this context and the current edit/revert scheme. I would like to see some kind of projection editor that would allow editing at the template-expanded level, then save the server-side version. I think that would ease the burden on inexperienced editors to understand how templates work and hence allow greater use of templates in contexts where the burden would be too great under the current edit-server-side scheme. Wcoole (talk) 19:32, 14 November 2012 (UTC)Reply

Today, I noticed that the user creation log ([3]) now shows the "contribs" link for newly created users in blue. It used to remain red until the editor had actually edited. I find this really disruptive in terms of vandal fighting as you can no longer instantly see which new accounts have actually edited. Is there someway to undo this change on an account level? Does anyone know why this change was done? Or, is it a bug? If it's not a bug, I sure wish the developers would discuss upcoming changes here before fielding the software. --Hammersoft (talk) 19:23, 5 November 2012 (UTC)Reply

Looking at Special:ListUsers, it looks like this changed everywhere. Legoktm (talk) 19:35, 5 November 2012 (UTC)Reply
It's not a change to thoses lists, but a change to how Special:Contributions works - see for example Special:Contributions/Totallymadeupuser_whichIdontthink_existsatall, which is presently a bluelink. --Redrose64 (talk) 20:24, 5 November 2012 (UTC)Reply

At this point, bugzilla:41793 has been fixed. Thanks to User:Hoo man for writing the patch. It hasn't been pushed to enwp yet, hopefully that will happen soon. Legoktm (talk) 02:09, 14 November 2012 (UTC)Reply

  Michaelzeng7 likes this. Michaelzeng7 (talk) 21:48, 14 November 2012 (UTC)Reply

The new interwiki prefixes 'y:' for Wikivoyage and 'd:' for Wikidata will soon be enabled. All articles and redirects with titles starting with "Y:" and "D:" will have to be moved or deleted, ideally before the interwiki prefix becomes enabled. See:

— This, that, and the other (talk) 01:22, 6 November 2012 (UTC)Reply

Not sure what we can do with the redirects (I guess we'll just lose them?), but I've moved the D: articles, and I'm about to start with the Y: articles. Nyttend (talk) 03:37, 6 November 2012 (UTC)Reply
Should someone make a bot to update all of the wikilinks that will soon cease to function? Someguy1221 (talk) 04:21, 6 November 2012 (UTC)Reply
This is a reminder that there has not been similar accommodation for a namespace prefix "U:" representing "User:". The June 2012 discussion is archived at Wikipedia:Village pump (miscellaneous)/Archive 38#U:.
—Wavelength (talk) 04:10, 6 November 2012 (UTC)Reply
I might point out that your proposal has nothing to do with this discussion, which is about interwiki links. — This, that, and the other (talk) 09:02, 6 November 2012 (UTC)Reply
Good point. We didn't delete Project:Mersh just because it's in WP: space; we keep it as a redirect to the article. The thing is that we can easily navigate around from WP: space to mainspace, but we can't easily navigate around from en:wp to Wikidata and back. Nyttend (talk) 12:23, 6 November 2012 (UTC)Reply
When species: became an interwiki prefix for Wikispecies, the article "Species: The Awakening" first disappeared completely and was then moved around and ended at Species – The Awakening. A link at Species: The Awakening has been deleted twice.[4] The link was apparently not explained so the Wikispecies editors may not have known the purpose. I have recreated it with an explanation. We could try the same for the few D: and Y: titles when those wikis open. PrimeHunter (talk) 15:02, 6 November 2012 (UTC)Reply
Perhaps soft redirect? ---— Gadget850 (Ed) talk 15:12, 6 November 2012 (UTC)Reply
Wonder what will happen to this diff? Saving here so that I'll perhaps remember to check it. I'd agree with the idea of soft redirects. Nyttend (talk) 20:18, 6 November 2012 (UTC)Reply
Eventually, someone might wish to update these.
—Wavelength (talk) 01:49, 7 November 2012 (UTC)Reply
True, but the new interwiki prefixes are not enabled just yet... — This, that, and the other (talk) 07:00, 7 November 2012 (UTC)Reply

Turns out that, for unknown reasons, the interwiki prefix for Wikivoyage is actually voy: not "y:". This was changed after I made the request. So in that respect it was a false alarm. However, d: is now working. — This, that, and the other (talk) 06:38, 13 November 2012 (UTC)Reply

Now that the d: prefix is live, I've been trying to work out how to clear up the incoming links to Wikipedia pages that formerly started with D:. I've worked it out and will fix these links over the next few days. If anyone wants to help, here's how:
  • Start at Special:PrefixIndex/w:D:, which lists the redirects that used to be valid before the new prefix went live. (The w: stops the D: being treated as an interwiki prefix.)
  • For each redirect listed, go to Special:WhatLinksHere/w: followed by the redirect title. E.g. Special:WhatLinksHere/w:D:tour 1997 Live at Southampton.
  • For each page listed, edit the page and change any links using the D: prefix.
  • If you are unsure to what the link should now point, the move log should give you a hint. Go to Special:Log/move and type w: followed by the redirect name in the Target box.
  • I have not been able to find a way to view the redirects themselves or their history. Attempts to use the w: trick here give me the "Bad title" error. It may be possible to view the latest revision of the redirect if you know its revision ID, but I don't know how to find that without the history of the redirects. – PartTimeGnome (talk | contribs) 00:50, 18 November 2012 (UTC)Reply

Anyone else loose popups within the last hour or so? Or am I the only unfortunate one? --Jezebel'sPonyobons mots 21:08, 8 November 2012 (UTC)Reply

Are you using the preferences version? If so, try turning that off and adding the following to Special:MyPage/common.js Ryan Vesey 21:12, 8 November 2012 (UTC)Reply
importScript('User:Lupin/popups.js');
The preferences version works just fine for me. Clear your cache? Legoktm (talk) 21:13, 8 November 2012 (UTC)Reply
Hmmmm, and My Preferences are no longer tabbed - they just show as one long page (editing in Monobook). --Jezebel'sPonyobons mots 21:14, 8 November 2012 (UTC)Reply
And just like that <snaps fingers> all is good again! --Jezebel'sPonyobons mots 21:15, 8 November 2012 (UTC)Reply

Oh no it's not. Popups have disappeared, as has clock/purge in top RH corner and all the editing toolbars above the edit box.

I tried turning popups off and adding the script, but no change - and yes I have purged, I've even rebooted. - Arjayay (talk) 11:07, 9 November 2012 (UTC)Reply

Which browser (and version) is this about, and what are steps to reproduce this? --Malyacko (talk) 11:51, 9 November 2012 (UTC)Reply
XP IE8 Vector skin - I don't understand the question about steps to reproduce it, I'm not trying to reproduce it, it just happened. As explained above I have tried code on js page, cleared cache and rebooted but still no pop-ups, no clock, no editing toolbars. It seems to be ignoring most of the "my preferences" settings. Have tried changing skin, which does work, but doesn't solve the other problems. Arjayay (talk) 15:16, 9 November 2012 (UTC)Reply
Not working for me with XP Pro/IE7/Vector. Went so far as a complete reboot, but no dice. Will experiment on Safari and see if that's any different. Who is supporting popups these days, post-Lupin? LeadSongDog come howl! 21:25, 9 November 2012 (UTC)Reply
Pop-ups are ok for me, but I can't get the cite tool in the editing toolbar to work. IE9 on Win7, monobook. DuncanHill (talk) 21:30, 9 November 2012 (UTC)Reply
to experience the problem on IE9 (or 8), switch to compatibility mode. peace - קיפודנחש (talk) 23:19, 9 November 2012 (UTC)Reply

I'm still "experiencing" the problems without any such switching. Is there an option for not experiencing the problems?

Over 48 hours after my original complaint and Wikipedia is still almost impossible to use - to repeat the known problems:-

There may well be more problems, but as editing is very difficult I haven't come across these

I appreciate that most people on Wikipedia are volunteers, and designing new gadgets, and so called "improvements", is far more interesting than resolving old problems. However, most of my previous problems, such as loosing "My preferences" (and, I suspect, the current problems) have arisen because of so called "improvements".

Clearly, such "improvements" are being introduced without full and proper testing, and are subsequently being allowed to remain, despite the problems they have created.

  • Where can I report these in detail?
  • Where can I object to the introduction of, and require the removal of, poorly tested "improvements" which prevent me, and numerous other Wikipedia editors, contributing to Wikipedia?

Arjayay (talk) 16:37, 11 November 2012 (UTC)Reply

To add to the list of known problems, the script causing minor edit to be checked by default has defaulted. Arjayay (talk) 17:49, 11 November 2012 (UTC)Reply
you reported using IE-8. are you 100% sure you are not in "compatibility mode"? this is the little icon that looks like a broken Matzah in the address line of the browser. if it has a bluish tint, you *are* in compatibility mode. try to press it and see if it solves the problem.
your complaint is understandable, but demanding that all software will only be deployed when it has 0 bugs is not realistic, and will probably never be realized. the best we can do is to report problems - in this case, the report is here: BugZilla:41937. i can't give you timetable for the deployment of the fix, but it seems that the bug was found, identified, fixed, and the patch was (at least prartially) reviewed, so one can hope that the fix will be deployed in the near future.
peace - קיפודנחש (talk) 18:29, 11 November 2012 (UTC)Reply
I've eaten matzos, but never seen one in an address line - nor is my address line blue, bluish or any colour other than black/grey - I tried pressing it anyway, but it made no difference.
Unfortunately, a lot of editors seem to think that submitting a bugzilla report "solves" a problem - e.g. how is the one relating to "my preferences" progressing? Arjayay (talk) 18:54, 11 November 2012 (UTC)Reply
do not be confused. reporting the problem to bugzilla does not "solves the problem". reporting is "the first step to the solution". i did describe exactly what status this problem is at present:
  • problem reported
  • actual bug found
  • patch to solve the bug written
  • patch partially reviewed.
  • no deployment date yet.
as to the broken matzah: i hope the next two pictures will help some:
 
 
if you do not see these icons, try to play with the "Compatibility" entries under the tools menu.
peace - קיפודנחש (talk) 19:36, 11 November 2012 (UTC)Reply

@Arjayjay: If the above compatibility-mode suggestion does not work, try removing the line @import url('http://en.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=User:Lupin/navpopdev.css'); from your custom CSS at User:Arjayay/common.css. Just a wild guess, but possibly the import is confusing IE into thinking there's a cross-site resource request that it needs to block. Also, have you tried disabling any ad-blockers and checked for malware that could interfere with your javascript functionality? As I say, just throwing out some wild guesses. — Richardguk (talk) 02:00, 12 November 2012 (UTC)Reply

Thanks for the suggestions - No, compatability mode does nothing on XP IE8, but my understanding of this mode is that it is designed to help newer browsers deal with older web-formats, not older browsers deal with newer.
However, when tried on a friends machine running W7 IE9, compatability view reproduces the problems exactly:-
  • No popups
  • No clock/purge in top RH corner
  • No editing toolbars whatsoever
  • "My preferences" tabs not working
  • Failure of script causing minor edit to be checked by default
So, as it appears very easy to reproduce, it should be easy to work out when it is resolved, and should have been checked for before implementing whatever change brought this about.
Removing the line of code from User:Arjayay/common.css doesn't work either, but thanks for the suggestion.
Unlike the editor below, I do have a tilde, but fully understand his frustration. My editing has also slowed to a snails pace, as I can't check diffs without loading them, and can't do any complex editing without any toolbars Arjayay (talk) 11:57, 12 November 2012 (UTC)Reply
And to add another problem to the list:-
  • Double click to edit doesn't work
Arjayay (talk) 13:41, 12 November 2012 (UTC)Reply
If one thing breaks in IE, almost everything breaks indeed, you don't need to report each case :) The change will be deployed as soon as can be, which at no time was gonna be any sooner than monday morning San Francisco time. (There are only deploys in weekends if there are issues that very critical, this is a clear annoyance, but basic functionality [read,edit] is still working). —TheDJ (talk • contribs) 14:27, 12 November 2012 (UTC)Reply

I'm old, fa Chrissake, into Shakespeare's lean and slippered pantaloon stage, not mentally but in terms of flexibility to take on board technical digital discussions. Do the people who tinker ever think that there are probably a lot of editors who (a) cannot follow a technical discussion and (b) find from day to day their pop-ups, tilde, markups disappearing so that any edit now has to be done mechanically, and (b) when reading technical advice are hopelessly lost. Since these innovations came in, I never know what options, if any, will meet me on a page I wish to edit, which means I am doing about 5% of the edits I formally did, and probably, since manual copying of brackets etc triples the time consumed, will have to leave the project, unless something like the superbly simple regimen that existed before is restored? Nishidani (no tilde on my keyboard, and no way of signing)

Of course they know this, and that this is not acceptable. Soon there will be new technology in the infrastructure to detect these problems more easily before deploy. It's a huge problem that things like this break all the time, but unfortunately writing this kind of software is very susceptible to making these kinds of mistakes (because there is not enough consistency between the browsers). This new test framework is currently in development. —TheDJ (talk • contribs) 14:27, 12 November 2012 (UTC)Reply

Hurrah - I hesitate to say this, as it usually goes wrong, but currently all the above problems have disappeared (except the tabs in My preferences, which goes back to July) - Thanks Arjayay (talk) 15:09, 12 November 2012 (UTC)Reply

Thank you, it seems to be working even on IE7/XP Pro now (just started this hour).LeadSongDog come howl! 18:33, 13 November 2012 (UTC)Reply
Well it was for a few minutes. Now stopped again. ARGHH!!

LeadSongDog come howl! 19:06, 13 November 2012 (UTC)Reply

And it's back. Is this some kind of peekaboo show, or are we supposed to simply hope that things will work? How about a little communication when changing these things?LeadSongDog come howl! 19:12, 13 November 2012 (UTC)Reply
How about a lot of communication, and testing, before changing these things? - Arjayay (talk) 15:34, 16 November 2012 (UTC)Reply
you are correct about testing. "communication" in this case is irrelevant: developers should not communicate "next release has a new bug" - they should never release a version with known regression, and, ttbomk, they do not. the key word here is "known"" it is pretty common that a new release comes with some regressions, but none of them is known at the time of release, and hence nothing to communicate.
as to testing: you are 100% correct here. part of the problem is that many (most?) of the developers do not use windows as their OS, and this causes inadequate testing with IE. i guess one can volunteer to help with testing - look in mw:Volunteer coordination and outreach for details.
peace - קיפודנחש (talk) 19:05, 16 November 2012 (UTC)Reply

Has anything changed centrally that would have caused fixed image sizes to appear reduced? Several images in articles I've worked on look quite a bit smaller today. SlimVirgin (talk) 21:12, 8 November 2012 (UTC)Reply

Yes, something has changed, and not only with images. I fixed the Bradley Manning infobox at a width of 260px, which was a good width. But today this is what it looked like -- too thin with all the words squished together. I removed the fixed size and it went back to normal. It's the same on multiple articles I've looked at - tiny images, shrunken boxes. Does anyone know what has happened? SlimVirgin (talk) 21:18, 8 November 2012 (UTC)Reply
Correction, it's only with Firefox. I've just tried another browser and they look the same as before. Something has changed about the way Firefox (at least for me) is interpreting the fixed image sizes. SlimVirgin (talk) 21:26, 8 November 2012 (UTC)Reply
Ff is displaying OK for me.--ukexpat (talk) 21:29, 8 November 2012 (UTC)Reply
Did you accidentally change the zoom level of your browser perhaps ? —TheDJ (talk • contribs) 21:31, 8 November 2012 (UTC)Reply
No, that would change the text too. This is just image and infobox sizes, where they are fixed. SlimVirgin (talk) 21:40, 8 November 2012 (UTC)Reply
Is this still an issue SV? - Jarry1250 [Deliberation needed] 15:59, 12 November 2012 (UTC)Reply
Yes, it is, Harry, thanks for asking. I've been fiddling around with my fonts -- in browser preferences and in WP preferences -- trying various combinations, but nothing makes a difference. I can't see how fonts would be related to image sizes anyway. The things that are affected are where sizes are fixed, so images and infobox width. I am seeing tiny images and very thin infoboxes. And it's happening only in Firefox. I recently updated it, so it may have started then, but I don't recall whether it started directly after that. SlimVirgin (talk) 16:17, 12 November 2012 (UTC)Reply
 
Mockup of the new personal tools links (sandbox link will be added when enabled in preferences)

Hi everyone, I wanted to let people know about a small design change.

What is changing and when

The "personal tools" links in the upper right corner will drop the possessive voice for logged in users. This means a switch from "My preferences", "My watchlist", and "My contributions" to "Preferences", "Watchlist", and "Contributions". You can see what it looks like in Vector in the screenshot to the right.

For Vector users only, there will also be a change from (what would have become) "Username Talk" to "Username (talk)" to match the default signature. For other skins (such as Monobook), it will simply be "Username Talk" because advanced users who specify skins other than the default skin likely won't confuse the personal tools' "Talk" link (that takes you to your personal talk page) with the Talk namespace tab (that takes you to the current page's talk page).

This should go live on Monday, November 19 (PST), after the weekly deployment of the latest version of MediaWiki, unless there are delays.

Why

This change has been waiting in the wings for a long time, actually since Vector was created, but it was recently brought up again by MZMcBride, Isarra and our team (Ori in particular) proposed it. After discussion with designers and developers, see bug 41672 and the Wikitech-l thread, there was agreement that MediaWiki should not use possessive language to refer to these links. If you like I can give a list of bullet points from the discussion, but this is pretty small, and I just wanted to post some explanation here, in case anyone notices and was wondering.

Thanks, Steven Walling (WMF) • talk 17:52, 9 November 2012 (UTC)Reply

Discussion

I'm not sure why you believe this change will only affect the Vector skin. --MZMcBride (talk) 18:46, 9 November 2012 (UTC)Reply
I'm also not sure your screenshot is accurate. Was the "(talk)" code ever reviewed and merged? Looking at https://translatewiki.net/?useskin=monobook while logged in seems to indicate that it was not. --MZMcBride (talk) 19:03, 9 November 2012 (UTC)Reply
re: the Vector issue, I might have gotten confused (I was writing two announcements at the same time), but let me double check. The (talk) change was merged this morning. Steven Walling (WMF) • talk 19:34, 9 November 2012 (UTC)Reply
The "(talk)" code is Vector-only, for now. The rationale was this: having two dangling "Talk" links on each page would only be confusing for n00bs, and n00bs don't use Monobook. Generating the personal tools section is currently handled by each skin, so there was no particularly easy way to make this change globally. But no reason it couldn't be backported to older skins if the teeming millions^H^H^H^Hdozens want it. --ori (talk) 19:45, 9 November 2012 (UTC)Reply
Okay, so dropping the "my" will apply to all skins, as I thought. The "Username (talk)" change will only affect users of the Vector skin. Got it.
And over two million users use Monobook, by my count. --MZMcBride (talk) 21:51, 9 November 2012 (UTC)Reply
P.S. It seems some extensions and user scripts will need adjustment as well. Commons adds a "My uploads" link and the LiquidThreads extension adds "My new messages".
Announcement edited accordingly. Also, My sandbox is another that we will need to edit to match the new copy. Steven Walling (WMF) • talk 22:14, 9 November 2012 (UTC)Reply
scripts should not use the link text, but rather the element ID ('pt-userpage', 'pt-watchlist' etc.), which should not change. any script that uses the link text should probably be eliminated on the ground of poor design. as to "My Sandbox": IMO, this one should not be changed, to distinguish personal sandbox from WP:SB and reduce confusion. the sandbox link is mainly for noobs, and many experienced editors uncheck this gadget in their preferences anyway. noobs can easily get confused between WP:SB and their personal sandbox, so it's best, IMO, to keep it in possessive form (i.e., leave the "My" in place). peace - קיפודנחש (talk) 00:02, 10 November 2012 (UTC)Reply
The reasoning behind the change was that the "my" is redundant for all links, because it is either apparent from the appearance or the destination that all links are personal rather than generic. In addition, inconsistency is a very bad for usability. It needs to be all or nothing. Steven Walling (WMF) • talk 00:24, 10 November 2012 (UTC)Reply
Were I a newbie seeing the new layout for the first time, I might deduce that, because of the spacing and proximity, the "user" icon only applied to the username and talk page link. I might believe (wrongly, of course) that "contributions" and "watchlist" were not specific to me, but rather "global". I think it would be much clearer if the personal toolbar was visually "quarantined" (different background colour, border, shadow, etc.) to make it super-obvious that these links are all personal in nature. — This, that, and the other (talk) 00:40, 10 November 2012 (UTC)Reply
I share that concern. I agree with the general premise of dropping My, but I think the problem is that there is not enough. 'coherence' in the usertools as they are now, to properly communicate that the contributions link belongs to your account. In a dropdown menu or something similar you would easily convey this context, but not it's missing a bit. —TheDJ (talk • contribs) 10:28, 12 November 2012 (UTC)Reply
This is something of a solved problem already: new users do not expect that items which pertain to them are marked with possessive copy. I would definitely read the related links in mw:Personal tools for lots of discussion. Also, note examples such as the top toolbar on Google products ("Search", "Mail", "Images", "Drive", "Calendar"), Facebook, and more. Steven Walling (WMF) • talk 22:43, 12 November 2012 (UTC)Reply
I don't see how any of that addresses the concern. Google doesn't have: "Search", "Mail", "Images", "Drive", "Calendar", "account", "privacy", "profile", "logout" all next together on the same UI level. You have to click "account" to drilldown and find the level of "privacy", "profile", "logout" etc. This is about logical grouping implying coherence between the elements. Using My consistently there, while not anywhere else also creates a strong 'grouping', but if you remove it, for my mother there will be little difference between that link and any other on the page. —TheDJ (talk • contribs) 10:00, 14 November 2012 (UTC)Reply
Let me be more direct about what I was trying to say above: it's not a concern because users generally don't expect that possessive language is used, based on their experience with the naming schemes of other popular products where they spend most of their time other than Wikipedia. Steven Walling (WMF) • talk 21:32, 14 November 2012 (UTC)Reply

Update: Because today was a holiday for WMF (Veteran's Day) this deployment got pushed back. It will change on Monday the 19th (PST) with the 1.21wmf4 deployment. Steven Walling (WMF) • talk 04:56, 13 November 2012 (UTC)Reply

Hello.

When I access some pages, including the main page, the ActiveX control is activated, but the "Control name is unavailable". I refuse accepting ActiveX control that I can't identify. Can anyone see to it that it is identifiable?

Thanks

HandsomeFella (talk) 21:40, 9 November 2012 (UTC)Reply

Can't help with your question, but does Wikipedia really use ActiveX controls? What for? 81.159.105.214 (talk) 03:20, 10 November 2012 (UTC)Reply
It doesn't. HandsomeFella, it might be a good idea to check for spyware on your computer. Graham87 09:29, 10 November 2012 (UTC)Reply
Does this happen on pages that contain videos? This might be IE's attempt to locate a compatible control for the new Media Handler. — Edokter (talk) — 10:44, 10 November 2012 (UTC)Reply
It was indeed on a day when there was a link to a video on the main page. HandsomeFella (talk) 18:40, 11 November 2012 (UTC)Reply

For some time now, the trend in Navbars has been toward using either listclass=hlist or bodyclass=hlist. This hasn't presented a problem to me until now. I have no idea what has caused this, but the bullets are missing from these new and improved Navbars. When the transfer to hlist began, there was no loss of bullets. One expects to see the bullets between linked items. If the bullets are missing, then all the links run together, and this makes the Navbar much harder to read. Here are examples that I recently found:

I normally use Internet Explorer v.9 browser and Win 7 Ultimate os. I note that the bullets are not missing in Firefox 16. – Paine (Climax!)  00:28, 10 November 2012 (UTC)Reply

It's because you've accidentally enabled "compatibility" mode (the torn page icon to the right of the address bar). Turn it off and you should be right. — This, that, and the other (talk) 00:43, 10 November 2012 (UTC)Reply
Thank you very much! That fixed a few other problems I've been having as well. See Bug 41792 – Paine (Climax!)  17:51, 11 November 2012 (UTC)Reply

Recently Wikipedia has been painfully slow for me when saving pages, especially longer ones. Is it just me? Are there any known problems? 81.159.105.214 (talk) 03:13, 10 November 2012 (UTC)Reply

I think this is a known issue if a page contains many templates. --Malyacko (talk) 13:06, 12 November 2012 (UTC)Reply

Look at the following sentence: The quick brown fox jumps over a lazy dog. The formatting uses single quotes, precisely as you'd expect.

Now look at: The quick brown 'fox jumps' over a lazy dog. This is identical, except that a new line has replaced the space after fox, which would ordinarily be ignored (treated as a space). A bug? Or, should I say: A bug!

Another question: How to format "('⁠Hello⁠')" without the Unicode U+2060 WORD JOINER character? — Quondum 11:30, 10 November 2012 (UTC)Reply

As to the second, use <nowiki /> instead; see WP:NOWIKI. ---— Gadget850 (Ed) talk 11:35, 10 November 2012 (UTC)Reply
Thanks for this answer on the second, clumsy but I guess there aint no better way... — Quondum 11:43, 10 November 2012 (UTC)Reply
Regarding the first, it's because the single-quote markup only works within a single line of wikitext.
Regarding the second, you can also use {{'}}, or use &#39; directly. Anomie⚔ 15:18, 10 November 2012 (UTC)Reply
I have not been able to find what you mention where the single-quote markup is described in Help:Wiki_markup#Text_formatting. Have I missed something, or is this an omission in the documentation? — Quondum 16:37, 10 November 2012 (UTC)Reply
I added a note about it to the help page you linked. jcgoble3 (talk) 17:04, 10 November 2012 (UTC)Reply
Cool. The world is perceptually in balance once more. — Quondum 18:50, 12 November 2012 (UTC)Reply

Today, when I went to delete a page, I noticed that something is different on the deletion page. The main effect is that I am unable to select a "blank" reason from the top dropdown box. So even though I entered a descriptive reason in the "other reason" box, it still used the reason in the top box, and I didn't see any way to get that to select a blank reason. Does anyone else have this problem? — Carl (CBM · talk) 18:17, 10 November 2012 (UTC)Reply

I worked around it by just deleting the entire dropdown from the delete form with javascript. Everything seems to work properly without it. — Carl (CBM · talk) 18:31, 10 November 2012 (UTC)Reply
Did you try selecting "Other reason", the top option? --Philosopher Let us reason together. 21:59, 10 November 2012 (UTC)Reply
In the latest Chrome for Mac (23.0.1271.64), it is not possible to select anything above the G1 line. Perhaps that is what has changed. — Carl (CBM · talk) 22:50, 10 November 2012 (UTC)Reply
Weird, it still works fine for me (Chrome 22.0.1229.94 m 23.0.1271.64 m just updated on Windows 7). At any rate, what you're seeing comes from MediaWiki:Deletereason-dropdown, I don't know where the "other reason" option that I see comes from, but we could always create a temporary "patch" by adding "Other reason" to that page. Have you tested this with your user scripts disabled in case one of them was updated recently? --Philosopher Let us reason together. 18:12, 11 November 2012 (UTC)Reply
I've added an "other reason" option to the General section, per Philosopher's suggestion. I doubt we'll use it much, but better to have it in the way often than to force someone to pick an inapplicable reason. Nyttend (talk) 02:07, 16 November 2012 (UTC)Reply

Hi All, I'm looking for a way to see recent changes on articles part of a WikiProject. The most close I found is using Recentchangeslinked for example for WikiProject Engineering: Special:Recentchangeslinked/Category:WikiProject Engineering articles. But this list only the recent changes of talk pages, because WikiProjects typical group articles based on project templates placed in the talk page of the article.

If there is no other way to get this result, is it possible to expand this special page "Recentchangeslinked" when using a (WikiProject) category as parameter, to include the associated article namespace? This would be a great way to create a kind of "my watchlist" linked to a specific WikiProject. Thanks, SchreyP (messages) 21:19, 10 November 2012 (UTC)Reply

You want Tim1357's WikiProject watchlist tool: tools:~legoktm/cgi-bin/wikiproject_watchlist.py. Legoktm (talk) 21:45, 10 November 2012 (UTC)Reply
Cool! This is indeed what I was looking for :) Thanks Legoktm, SchreyP (messages) 21:58, 10 November 2012 (UTC)Reply
How many pages are in that wikiproject? We could have a list of them on the wiki if it is only a couple thousand. But if it is more than that, the page will be too big. — Carl (CBM · talk) 22:45, 10 November 2012 (UTC)Reply
Hi CBM, for WP:WikiProject Engineering this is close to 2900, for WP:WikiProject Electrical engineering this is 260. Is this within specs to have it "on the wiki"? SchreyP (messages) 22:23, 11 November 2012 (UTC)Reply
I think that about 3,500 articles is probably about the page limit, but you can translude the pages together to cover larger projects. I have a project with about 13,000 tagged pages (so 26,000 pages, article + talk) in it with an on-wiki list transluded from 7 pages that can be used with Special:RecentChangesLinked. Keith D (talk) 00:39, 12 November 2012 (UTC)Reply
@CBM, how can this be done "on the wiki"? Or is first some development needed?
@Keith D, can you specify in which WikiProject you have used this technique, so we can learn for it? Thanks, SchreyP (messages) 19:47, 12 November 2012 (UTC)Reply
The big one is WP:YORKS with the transluded page at Wikipedia:WikiProject Yorkshire/WatchAll. Keith D (talk) 20:14, 12 November 2012 (UTC)Reply

For some reason my edit count has just been been reduced by about 40 or 50 to where it is now at [27,009+]. Last time I peeked at the count it was over 27,030 and I've since made many more edits. We just got over a back-log problem with X's edit counter so I'm wondering if this has anything to do with it. There is no back-log now, at the time of this entry, yet the count is still low. My main concern is that this may happen again if not looked into. Any and all help greatly appreciated. -- Gwillhickers (talk) 21:43, 10 November 2012 (UTC)Reply

I did a separate query on the toolserver and I got the same figure as the edit counter. There is some ongoing maintenance of the toolserver database replica, which had been corrupted. So after that is over, please remind me in a week or so and I will check again. What does the edit count on your user preferences look like? — Carl (CBM · talk) 22:44, 10 November 2012 (UTC)Reply
Insert : Thanks, Carl. I forgot to mention also that my contributions and edit history seem to be complete so evidently there is a problem in the 'counting' process. -- i.e. Currently X!'s edit counter is including/counting my latest edits but for some reason has overlooked my edits from early yesterday which I estimate to be around 40-50. Again, this began to happen when the edit-counter was back-logged yesterday. Also, the edit count on 'My preferences' reads '26,957', while X!'s edit-counter currently reads '27,015' -- which are both low readings.Gwillhickers (talk) 17:33, 11 November 2012 (UTC)Reply

What is the proper/best way to detect the localized name of Special:Contributions from within an user script?

Specifically, this concerns User:SoledadKabocha/markBlockedPlus.js which is a modification of the original mark-blocked script.

I ended up doing this for the name of the Special namespace. (Is it possible for the special namespace to have multiple aliases, that is, "Special" as well as a word in another language?) That doesn't check for the word "Contributions" though.

It looks like the original script used to have this feature, but it was dropped in favor of hardcoding the English and Russian names. Can someone literate in Russian explain why? I'm not very literate in any language other than English (which is also why I haven't tested my script on a WMF project of another language). --SoledadKabocha (talk) 04:37, 11 November 2012 (UTC)Reply

Hold: After some investigation, it looks like I might be able to query the API for this information (specifically, specialpagealiases). I will work on this myself, and I will post back here if I need any further help. --SoledadKabocha (talk) 04:54, 11 November 2012 (UTC)Reply
Alex Smotrov seems to have made the change you asked about. You might leave a question for him at his Russian talk page. He has been recently active on the Russian wiki and he knows English. EdJohnston (talk) 05:05, 11 November 2012 (UTC)Reply
Ok... I had been contacting him on his enwiki talk page before (about other scripts); I should have realized earlier to go to ruwiki. Anyway, I think I'll wait to contact him until after I've made my attempt at implementing this. --SoledadKabocha (talk) 05:30, 11 November 2012 (UTC)Reply

If you use the english alias, it will work on every MediaWiki ever. ^demon[omg plz] 23:23, 11 November 2012 (UTC) 23:23, 11 November 2012 (UTC)Reply

Yeah. You don't need to jump through hoops. Compare ru:Служебная:Вклад/Redrose64, ru:Служебная:Contributions/Redrose64 and ru:Special:Contributions/Redrose64 - they should all behave the same. --Redrose64 (talk) 23:50, 11 November 2012 (UTC)Reply

I was looking at Category:Canadian disbarred lawyers which I thought was emptied recently, and to my surprise I saw that a recently deleted article shows up as an entry. When I click on the entry it leads to a page that tells me that the article has been deleted. Thanks for any clues on how this can happen (especially to those who can explain without using wiki/techie jargon :-) Ottawahitech (talk) 15:49, 11 November 2012 (UTC)Reply

When a page is deleted, the link tables (which are what the list in the category page is based upon) are not necessarily updated immediately. --Redrose64 (talk) 16:38, 11 November 2012 (UTC)Reply
That I couldn't say. Three days is a bit long though. What I do know would have fixed this (although it's too late now) goes something like this. Immediately prior to deleting a page, the deleting admin blanks out the whole of the page, saves, and then goes for the "delete" button. Saving a page which contains no outward links (whether these be wikilinks, categories or templates) forces all the outward links to be removed from the link tables. Then, the action of deleting does not have to worry about outward links - only inward links (which get changed from blue to red). --Redrose64 (talk) 17:08, 12 November 2012 (UTC)Reply
Caching issue? The linked category is showing empty when I check it, as it did for me yesterday. Anomie⚔ 20:36, 12 November 2012 (UTC)Reply

For the last couple of days, I've noticed that the toolbar above the edit box has disappeared. Is anyone else having the same problem or know what's wrong? The C of E. God Save The Queen! (talk) 17:35, 11 November 2012 (UTC)Reply

Lots of us are experiencing this, and other problems as well - please see Wikipedia:Village pump (technical)#No popups above Arjayay (talk) 17:44, 11 November 2012 (UTC)Reply

Lately I am encountering a lot of occasions where all of a sudden, when I click on a wikilink or try to access my watchlist I get logged out. Has anyone else experienced this or knows, why this is happening? -- Toshio Yamaguchi (tlk−ctb) 20:33, 11 November 2012 (UTC)Reply

Well, just happened again, even from another location. -- Toshio Yamaguchi (tlk−ctb) 13:13, 13 November 2012 (UTC)Reply
I have the impression that this especially happens when I use the back button in my browser. -- Toshio Yamaguchi (tlk−ctb) 13:18, 13 November 2012 (UTC)Reply
I'm presently using Safari, instead of Firefox, because it's the only way to get any javascript (see below); and this has logged me out once already. It happened just after returning to the watchlist after viewing a diff, when an error box popped up with a message about an error in the application which needed to terminate, and did I want to tell Microsoft about this problem? Clicking Send error report didn't close Safari as I expected, but returned me to Special:Watchlist - which showed the message "You are not logged in". --Redrose64 (talk) 12:09, 16 November 2012 (UTC)Reply

The code #expr does not round properly: if the final digit is a zero, it is dropped. For example,

5940/6615 rounded to two digits ({{#expr: 5940/6615 round 2}}) gives 0.9 rather than 0.90.

— kwami (talk) 20:38, 11 November 2012 (UTC)Reply

Yes. Try {{rnd}} (a complex template used by {{convert}}): {{rnd|{{#expr: 5940/6615}}|2}} → 0.90. I believe it uses {{rnd/-}} to zero-pad the fraction. Johnuniq (talk) 03:03, 12 November 2012 (UTC)Reply
That's pretty inefficient. Shouldn't we just fix #expr ? — kwami (talk) 07:20, 12 November 2012 (UTC)Reply
Is tracked. -DePiep (talk) 07:51, 12 November 2012 (UTC)Reply
  • Precise rounding is likely to become a Lua module: After the successful preliminary tests with Lua script on test2.wiki, it seems reasonable to write a precise rounding module, to allow trailing zeroes, and support the minus-sign with &minus ("−"). Such a lightning-fast template interface could also support special options, such as "near" to round "3.874" to 4 as near-enough, or option "up/down 50%" to randomly round "2.5" as up/down to 2 or 3, for use in calculations with numerous values which might suffer round-upward bias. Although Lua coding is tedious, running similar to "compiled source code" rather than interactive edit-previewed markup, we should be able to explain tactics to add "debug switches" to allow users to create interactive debugging sessions (with dynamic input/output values) to write complex Lua modules faster. There are some editors who have far more computer expertise than the people who designed the MediaWiki software, such as for numerical analysis or A.I., so I think the Lua modules will enable having improvements, sooner, for complex operations. This ain't bug-report and wait a few years... Meanwhile, use the slow {rnd} or {rndpad} templates as an interim fix. -Wikid77 (talk) 14:22, 12 November 2012 (UTC)Reply
Who rounds upward? Isn't it conventional to round xx.5 to an even number? — kwami (talk) 20:23, 12 November 2012 (UTC)Reply
According to Rounding#Tie-breaking, "round half up", "round half away from zero", and "round half to even" are all common. It probably depends on what field you're in, and where/when you learned basic mathematics in school. Anomie⚔ 20:45, 12 November 2012 (UTC)Reply
My father (with his BSc (Hons) in Metallurgy from Manchester Univ.) taught me to round exact halves away from zero; and my schoolteachers (most of which also had university degrees) were of the same opinion. --Redrose64 (talk) 21:01, 12 November 2012 (UTC)Reply
Here in the Midwestern US, I was taught to "round half up" and never heard of these other ways. Interesting. --Philosopher Let us reason together. 22:45, 12 November 2012 (UTC)Reply
The rule: "round 2.5 upward and 3.5 downward because 2=even and 3=uneven": that is a bankers rule, for when dealing with descrete numbers (i.e. cents). (It assures that say over 1000 money numbers in cents, the "x.50"'s doesn't move the total&average upwards). However, when non descrete numbers (e.g. with logarithmic outcomes; R numbers), this is not needed. And even wrong: one may not state that a logarithmic outcome is exactly/descrete "x.5". So, only bankers may round that way. And we know where the bankers have brought us. Concluding: There is no single rule for rounding. Any "round" operator is a choice, or must give an option wrt floor/ceiling &tc situations. Now back to the topic: when rounding to "2 numbers", zeros must stay because of precision claims. Glad to make things clear. -DePiep (talk) 22:13, 13 November 2012 (UTC)Reply

Hi-

I'm trying to link to South Pacific (musical), and the link works fine in a .doc file, but when I convert to .pdf, I get South_Pacific_, not accepting the opening paren or what follows, so I'm taken just to the disambig page. Is this a known problem, or is there a workaround? Thanks for any help. Milkunderwood (talk) 04:43, 12 November 2012 (UTC)Reply

Now I have exactly the same problem with http://en.wikipedia.org/wiki/Iroquois_(horse). In a .doc file it takes me to the horse, but in .pdf it takes me to the Native American peoples - not even a disambig, which is worse than useless. Milkunderwood (talk) 06:22, 12 November 2012 (UTC)Reply

And here's a third one, but this time with a section hatch mark #. My link is http://en.wikipedia.org/wiki/Gershwin_Publishing_Corp._v._Columbia_Artists_Management #CAMI.27s_.22Community_Concert_Associations.22, but .pdf cuts off the "#CAMI...[etc]". Sheesh. All of these work perfectly in .doc format. Milkunderwood (talk) 07:05, 12 November 2012 (UTC)Reply

And the same thing again, with Seven Sisters (colleges). Milkunderwood (talk) 09:52, 12 November 2012 (UTC)Reply

Try rewriting the links using percent-encoding. In my experience that fixes virtually every problem. Someguy1221 (talk) 10:15, 12 November 2012 (UTC)Reply
If I understand correctly: You are creating a Microsoft Word document on your PC that contains links to Wikipedia articles that work properly. You then convert the DOC file to PDF (with what application?), then the links are truncated at a parenthesis or hash. ---— Gadget850 (Ed) talk 10:22, 12 November 2012 (UTC)Reply
Yes, I am using MS Word with XP, and converting to .pdf with a freebie download from Cnet called PDFCreator. The hyperlinks convert in full from .doc to .pdf, in blue and underlined, but hovering the pointer in .pdf shows truncation at either the "(" or the "#". And clicking takes me to the truncated name in Wikipedia.
Perhaps also in response to Someguy1221, what I don't understand (besides the "percent-encoding" discussion you pointed me to) is that I have a link to Max Delbrück copied as http://en.wikipedia.org/wiki/Max_Delbr%C3%BCck into my .doc file, and identically with these percent signs converted into .pdf - but not only does the link work correctly from .doc but also from the .pdf file. I didn't insert the %'s - they translated automatically. Milkunderwood (talk) 11:51, 12 November 2012 (UTC)Reply
Have you tried http://en.wikipedia.org/wiki/South_Pacific_%28musical%29? It has percent-encoding of '(' and ')'. PrimeHunter (talk) 12:03, 12 November 2012 (UTC)Reply
Yes, that does work - thank you very much!!! Now I see the distinction between reserved and unreserved characters. I was looking at the "ü" with "%C3%BC", and assumed you needed a second code to return to normal. Milkunderwood (talk) 12:16, 12 November 2012 (UTC)Reply
Interestingly, %28 and %29 do work for open and close parens, but I can't get %23 to interpret as a # hatch mark; the link still truncates at that point. I can live without this one, but it's a little frustrating. This was the Gershwin v Columbia #CAMI problem, shown above in full. Again, either the # or %23 work perfectly in a .doc file, just not in .pdf. Milkunderwood (talk) 19:39, 12 November 2012 (UTC)Reply

You have a space before # in the above example. Without the space it is http://en.wikipedia.org/wiki/Gershwin_Publishing_Corp._v._Columbia_Artists_Management#CAMI.27s_.22Community_Concert_Associations.22. This works for me when I save as a pdf file with Word 2010. I don't have the pdf converter you use but maybe it has a limitation. PrimeHunter (talk) 22:53, 12 November 2012 (UTC)Reply

Thanks for trying that. I checked for a space and there isn't one in mine; the line just wraps at the #. The bolded copy I put in my initial posts was nowiki'd. So I guess it must be my freebie converter. Milkunderwood (talk) 00:43, 13 November 2012 (UTC)Reply

According to {{Lang-x/doc}}, which is transcluded as documentation in many {{lang-*}} templates, the parameter links=no can be used to prevent linking of the language. However, this is not implemented in many of the templates (e.g. {{lang-ka}}, {{lang-pt}}, {{lang-ur}}, etc.). The templates are fully protected and I cannot edit them. See {{lang-ru}} for an example of correct implementation. —[AlanM1(talk)]— 10:20, 12 November 2012 (UTC)Reply

Trying to edit the lead sentence of Sheikh Anwarul Haq to insert the dates of birth and death results in the date getting mixed in with the name in Arabic script. The lead contains the text:

([[Urdu]]: '''{{Nastaliq|شیخ انوار الحق}}''')

If you place the cursor to the left of the closing parenthesis and then attempt to insert:

;11 May 1917 – 3 March 1995

the whole thing gets jumbled:

([[Urdu]]: '''{{Nastaliq|شیخ انوار الحق}}'''11 May 1917 – 3 March 1995)

Note that it only happens when the first non-punctuation character being inserted is a digit; inserting ";May 11, 1917 – March 3, 1995" works fine.

I've tried this with Firefox 7 on WinXP as well as Firefox 15 on Win7-x64, with the same results. I've had the problem in other articles and it seems like I must have found a way around it, though I can't this time. —[AlanM1(talk)]— 10:46, 12 November 2012 (UTC)Reply

It also happens for me when the text is copied to Notepad (software). It's a problem with Help:Arabic#Text bidirectionality. Numerals are the same in Arabic and Latin so if numerals come right after Arabic text then software doesn't know whether the numerals are part of the Arabic text and should be displayed where they would be in right-to-left Arabic. As you note, a solution is to place something containing a Latin letter so software knows the Arabic has stopped. Here you can for example use &lrm; (left-to-right mark). PrimeHunter (talk) 11:47, 12 November 2012 (UTC)Reply
Excellent! That solves the problem. There's some inconsistency in the way the editor works, though – inserting ";&lrm;11 May..." works correctly, even though the ';' comes before the "&lrm;" (I'd expect it to either move the ';' to the left of the first Arabic character or for it to be sufficient to switch back to LTR mode, neither of which it does). I'll add a usage note about this issue to the relevant template docs for the next guy that stumbles on it. Thanks.   —[AlanM1(talk)]— 23:29, 12 November 2012 (UTC)Reply

FYI: In recent days, the copy/paste characters have been disappearing from Monobook skin during edit-preview of pages. I have created essay "WP:Copy and paste" (WP:Paste) which shows the old typical copy/paste for markup and symbols. The essay preserves the old, familiar table:


Copy and paste: – — ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § Sign your posts on talk pages: ~~~~

{{}}    {{{}}}    |    []    [[]]    [[Category:]]    #REDIRECT    [[]]    &nbsp;    <s></s>    <sup></sup>    <sub></sub>    <code></code>    <pre></pre>    <blockquote></blockquote>    <ref></ref>   <ref name=""/>    {{Reflist}}    <references/>    <includeonly></includeonly>    <noinclude></noinclude>    {{DEFAULTSORT:}}    <nowiki></nowiki>    <!-- -->    <span class="plainlinks"></span>

Symbols: ~ | ¡ ¿ † ‡ ↔ ↑ ↓ • ¶ # ∞ ‘ ’ “ ” «» ¤ ₳ ฿ ₵ ¢ ₡ ₢ $ ₫ ₯ € ₠ ₣ ƒ ₴ ₭ ₤ ℳ ₥ ₦ № ₧ ₰ £ ៛ ₨ ₪ ৳ ₮ ₩ ¥ ♠ ♣ ♥ ♦ ♭ ♯ ♮ © ® ™
Latin: A a Á á À à Â â Ä ä Ǎ ǎ Ă ă Ā ā Ã ã Å å Ą ą Æ æ Ǣ ǣ B b

( ...and all the other characters...)

By remembering to use WP:PASTE, then there will be less fear of all the radical changes to the edit-interface for pages. We want the edit-interface to be improved when possible, so WP:Paste provides access, forever, to the old style of copy/paste symbols. -Wikid77 (talk) 14:40, 12 November 2012 (UTC)Reply

Ever since I got my new Windows 8 computer, bold links (as on the Main Page) look the same as normal links, and bold titles (on normal articles like Ustya River) look the same as the rest of the text. Is it just me, or is it everyone with Windows 8? It happens on both Firefox 16.0.2 and Explorer 10. Art LaPella (talk) 15:07, 12 November 2012 (UTC)Reply

I fixed it by changing my default Ariel font. Of course most Windows 8 users won't bother or won't know. Art LaPella (talk) 21:47, 14 November 2012 (UTC)Reply
Can you be more specific? Is the default font in your browser (which?) different in Windows 8 and does it not support bold (pretty rare)? —[AlanM1(talk)]— 22:45, 14 November 2012 (UTC)Reply
Bolding didn't work on my Windows 8 computer. I clicked "Firefox", then "Options", then "Advanced" in the "Fonts & Colors" section. It said "Proportional Serif", "Serif Times New Roman", "Sans-serif Arial", "Monospace Courier New". I changed the "Sans-serif" to "Times New Roman", and Wikipedia changed its appearance, including bolding, which started working. On each of two old Windows XP machines (not my own old one, which would crash repeatedly if I tried to start it now) I found the same four choices, including "Sans-serif Arial", but Wikipedia bolding worked there. So the default "Sans-serif" font, Arial, does not support bolding on my Windows 8 machine. If that is rare, no biggie. If that happens to everyone who gets Windows 8, that is a biggie. Art LaPella (talk) 02:27, 15 November 2012 (UTC)Reply
I just found out that I can also make bolding work with Explorer, by checking the "Accessibility" box labeled "Ignore font styles specified on webpages", so it changes to Times New Roman. Art LaPella (talk) 21:33, 15 November 2012 (UTC)Reply

Per discussion here and here

Using a percent mode in a table makes the table looks less than ideal on a wide monitor:20 inch monitor view

But making it fixed width makes it problematic on a mobile device.

Is there a way to have the best of both worlds? So the table would act as if it had a percent width below some threshold, but revert to a fixed size when viewed on a larger resolution?--SPhilbrick(Talk) 15:18, 12 November 2012 (UTC)Reply

This isn't supported in all browsers (these days it should be enough to not be an issue), but one can set a min- or max-width in the css along with a width percent. So setting max-width: whatever; should solve that problem. -— Isarra ༆ 15:41, 12 November 2012 (UTC)Reply

Dennis Brown had reported that he tried that and it failed, but it now seems to be working. Thanks.--SPhilbrick(Talk) 17:49, 12 November 2012 (UTC)Reply

Oops, maybe agreed too quickly. The max-width seems to be ignored in Chrome. Any thoughts?--SPhilbrick(Talk) 14:58, 13 November 2012 (UTC)Reply

Yep, needs to be a "display:block" in there; max-width only works for blocks. Writ Keeper ⚇♔ 15:07, 13 November 2012 (UTC)Reply
Heh, I just tried that, and it worked. Thanks.--SPhilbrick(Talk) 15:10, 13 November 2012 (UTC)Reply
Well, that does break some features of a table though. Table captions for instance will then be inside the table, instead of on top and border collapse will stop working. —TheDJ (talk • contribs) 16:23, 13 November 2012 (UTC)Reply
MF came up with a better solution of removing the margins that I somehow didn't notice, so it worked out. Writ Keeper ⚇♔ 16:51, 13 November 2012 (UTC)Reply
It does, but so does making the table sortable, which breaks "rowspan" and "colspan". The caption issue is easily dealt with by setting the table border to the background colour, as in class = "wikitable sortable" ... style="border:1px solid #ffffff;". Malleus Fatuorum 20:03, 13 November 2012 (UTC)Reply

The two images in the blurbs displayed at Wikipedia:Today's featured list are massively oversized, as noted at Wikipedia talk:Today's featured list#Images. However, the blurbs (which are at Wikipedia:Today's featured list/November 12, 2012 and Wikipedia:Today's featured list/November 19, 2012) do not have problematic image sizes there or at other places where they are transcluded, such as Wikipedia:Today's featured list/November 2012. I can't see any edits in the page history of Wikipedia:Today's featured list or {{TFLcontent}} that might account for this. Can anyone find and fix the problem? Thanks, BencherliteTalk 15:51, 12 November 2012 (UTC)Reply

I've determined the critical factor: simply, it's whether it's inside a table or not. Compare this
with this
I collapsed them both so that they're not in-your-face. The same thing happens with the Nov 19 one. --Redrose64 (talk) 16:46, 12 November 2012 (UTC)Reply
OK, i'm baffled ... —TheDJ (talk • contribs) 19:44, 12 November 2012 (UTC)Reply
I've examined the emitted HTML. The main (the only?) differences are in the attributes to the <a><img /></a> elements:
<a href="/wiki/File:Bostonstraight.jpg" class="image" title="Skyline of Boston's Back Bay neighborhood"><img alt="Skyline of a city on a river. Two buildings are much taller and more prominent than the rest; one of the large buildings is a skyscraper with a blue-tinted, all-glass facade, and the second is a large rectangular tower with a steel latticework facade and a tall antenna mast on its roof." src="//upload.wikimedia.org/wikipedia/commons/thumb/8/86/Bostonstraight.jpg/125px-Bostonstraight.jpg" width="125" height="80" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/8/86/Bostonstraight.jpg/188px-Bostonstraight.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/8/86/Bostonstraight.jpg/250px-Bostonstraight.jpg 2x" /></a>
<a href="/wiki/File:Bostonstraight.jpg" class="image" title="125x125px Skyline of Boston's Back Bay neighborhood"><img alt="125x125px Skyline of Boston's Back Bay neighborhood" src="//upload.wikimedia.org/wikipedia/commons/8/86/Bostonstraight.jpg" width="2904" height="1848" /></a>
Significantly different, as you will agree. The crucial thing to spot is that the width= and height= attributes differ, and that the desired size 125x125px has somehow ended up in the title of the <a> and also in the alt= of the <img />. We need to identify what is processing the image size. --Redrose64 (talk) 20:16, 12 November 2012 (UTC)Reply
Baffled as well... Why does it not happen on the main page, where it uses the exact same table structure? (Becuase it uses raw HTML.) Looking at the served HTML, I do suspect a parser problem, dropping a pipe in the {{TFLcontent}} logic, making it ignore or misinterpret the size parameter. — Edokter (talk) — 20:22, 12 November 2012 (UTC)Reply
A pipe is certainly a factor. Compare this:
with this
Both are in tables. The only difference in the wikimarkup is the number of pipes immediately before the alt=. --Redrose64 (talk) 20:33, 12 November 2012 (UTC)Reply
Well surely this tag meta-soup at Wikipedia:Today's featured list is asking for trouble:
|-
| style="color:#000;"><div id="mp-tfl" style="padding:2px 5px;" | ...
(Previewing this VPT reply, <source>...</source> and <pre>...</pre> don't seem to be nesting multiline raw text within indents as normal right now. Maybe there's a bigger parser bug. Hmmm. Is Tidy working as normal?)
— Richardguk (talk) 20:39, 12 November 2012 (UTC)Reply
That was just bad wikitable coding (on my part BTW, though fixing that does not seem to solve the problem). Wikitables and parser code don't mix well anyway. Using HTML did fix the problem, so I do not see any reason to investigate this further. — Edokter (talk) — 20:51, 12 November 2012 (UTC)Reply
The extra pipe creates an empty parameter that probably cuases the image size to be reset. Will investigate the TFL logic more closely. In the mean time, I fixed Wikipedia:Today's featured list by using HTML tables. — Edokter (talk) — 20:42, 12 November 2012 (UTC)Reply
The problem was that this edit to {{TFLcontent}} caused the output to contain "||" immediately after the size specification (unless |border=yes was given), which was somehow or other interacting with the interpretation of "||" in table markup and causing the size specification to not be recognized as valid. This edit appears to have fixed it. Anomie⚔ 21:20, 12 November 2012 (UTC)Reply
Good catch! Now it's fixed on two levels, it should never happen again. I should have paid more attention to edits made to {TFLcontent}... that was a poor edit which I should have caught. — Edokter (talk) — 21:34, 12 November 2012 (UTC)Reply

Well, I didn't understand a bloody word of that conversation, but it's fixed now! Thanks to everyone for your input. BencherliteTalk 20:52, 12 November 2012 (UTC)Reply

Glad to be of help. — Edokter (talk) — 21:34, 12 November 2012 (UTC)Reply

I'd like to complete commons:Commons:Batch_uploading/ECGPedia. Is there a way to import/export files and their history from one mediawiki to the wiki?Smallman12q (talk) 23:25, 12 November 2012 (UTC)Reply

Thank you for your interest - did you know there is also a commons:Commons:Village pump? You should probably ask there to see if there's a simpler way that what I'm thinking of. As far as I know, the answer is a definite "maybe". First, I don't know if this right copies the file as well or if it just copies the page and page history, but you could ask to become an "Importer" on Commons and then use ECGPedia's Special:Export in conjunction with Commons' Special:Import. See meta:Help:Importers. Getting such a userright would require a community discussion at commons:Commons:Requests and votes; the right itself would be granted by a Steward if the discussion approved the right. The bad news is that that userright hasn't been used on Commons since January 2011, so I don't know how willing the community would be to give it out. (Note: The "Importer" userright is different than the "Transwiki importer" userright.) --Philosopher Let us reason together. 17:03, 13 November 2012 (UTC)Reply

Hello. Template:Coord/dec2dms/dms1 displays an (old) error when I click on it.

Text on wiki:fr is 

<includeonly>{{#expr:{{{1}}} mod 360}}° {{padleft:{{#expr:{{{1}}} * 60 mod 60}}|2|0}}′ {{padleft:{{#expr:({{{1}}} * 36000 round 0) mod 600 / 10}}|2|0}}″ </includeonly><noinclude>Modèle utilisé par {{m|Coord}}, voir cette page.

[[Catégorie:Modèle de coordonnées|Coord/dec2dms/dms1]]
[[en:Template:Coord/dec2dms/dms1]]
</noinclude>

(Another error, more insidious, occurs on wiki:fr : there is a round-up error at some values, giving wrong minutes value - see fr:Discussion modèle:Coord#Bug format dms1. We're trying to correct it on wiki:fr). Regards, Jack ma (talk) 07:34, 13 November 2012 (UTC)Reply

It's not an error as such - the template is expecting a numeric value, but when you view the template directly, this number hasn't been supplied. So, the calculation isn't being performed on a number like 51.6063 but on the wiki markup {{{1}}} - this is the place where the first positional parameter will be inserted when the template is used. So, if I put {{Coord/dec2dms/dms1}} without parameters, which is not the intended use, I get the error condition Template:Coord/dec2dms/dms1, but if I supply a value {{Coord/dec2dms/dms1|51.6063}} I get Template:Coord/dec2dms/dms1 which is working as designed. --Redrose64 (talk) 11:10, 13 November 2012 (UTC)Reply
The French version uses the <noinclude> tag to suppress the template on the template page. ---— Gadget850 (Ed) talk 12:21, 13 November 2012 (UTC)Reply
actually it's "<includeonly>". i've edit en:Template:Coord/dec2dms/dms1 a bit to display more polite message when viewing the temaplate page itself. קיפודנחש (talk) 15:29, 13 November 2012 (UTC)Reply
  Facepalm ---— Gadget850 (Ed) talk 16:28, 13 November 2012 (UTC)Reply

Originally asked at the WP:HD#Search and replace function in edit window.


I am pretty sure in edit mode there used to be a function called something like Search and replace where you could search for a specific string of characters and replace them with something else. Where exactly in the edit window is this again, somehow I can't find it anymore. I could swear it was located in the top right corner of the edit window. However it's gone now, at least for me, I have no idea why though.... -- Toshio Yamaguchi (tlk−ctb) 07:41, 13 November 2012 (UTC)Reply

It is under the "Advanced" section. —TheDJ (talk • contribs) 08:04, 13 November 2012 (UTC)Reply
  Facepalm Thank you =P -- Toshio Yamaguchi (tlk−ctb) 08:16, 13 November 2012 (UTC)Reply

But it isn't working properly, when using the "Replace all" button - It inserts the "replace" word in front of the "search" word, without removing the "search" word. It sometimes over-writes the text in front of the "search" word and sometimes opens up a gap. (XP IE8 Vector)
Arjayay (talk) 17:20, 13 November 2012 (UTC)Reply

Yikes, another IE bug. If only we had IE developers ;( Well you know where to file them: bugzilla:. —TheDJ (talk • contribs) 18:28, 13 November 2012 (UTC)Reply
(added after collision) good news/bad news department: you are absolutely correct that the Search/replace tool is broken in latest version. the "good news" is that it's only broken in IE.... reported it here: bugzilla:42073.
peace - קיפודנחש (talk) 18:35, 13 November 2012 (UTC)Reply

Hi all, first off really appreciate the help, I am attempting to allow a mouseover display of this: $7¤ to include the base dollar amount being adjusted (converted) to show on mouseover (not just the adjusted for inflation wikilink which redirects), so a functional redirect link to the wiki article on "adjusted for inflation" that has such a display as this on mouseover: $7¤. Thanks again! Marketdiamond (talk) 08:26, 13 November 2012 (UTC)Reply

  • Simulate FYI-link text as #section: A link to show FYI-text can be simulated as a #section header link, such as "[[Adjusted_for_inflation# originally 2.00 US dollars|¤]]" which will appear as: ¤, where the phrase "originally 2.00 US dollars" will be shown but ignored by the "bug/feature" which simply ignores an invalid #section name and links to the top of the article (if clicked). Your use of wikilinks as mouse-over FYI-links seems to be way ahead of the state of the art, and so perhaps we should propose a standard for using wikilinks with FYI-text appended. Ideally, the wiki world would rise to have a high-level feature to show an FYI-mouseover with a non-url-encoded "originally $2" rather than encode "$2" as ".242", but others here might have some more suggestions. -Wikid77 (talk) 12:01, 13 November 2012 (UTC)Reply
Thanks for the insight Wikid77, although impractical and even undesirable for most of wikipedia my use for this will be a subsection inside a portal where for spacing concerns brevity would be desirable and linking to more expansive wikipedia articles would be encouraged by the use of somewhat truncated descriptions. No portal would hope to be definitive on all the various and diverse topics it hits so why not be brief is my thinking.
I have noticed though the article title is shown and then below it the article URL, and I do see such a suggestion would fix the URL portion, but anyway to replace both with a simple one line of what you wish to display on rollover? I will keep your suggestion in mind as a fallback and appreciation for the insight! Marketdiamond (talk) 12:15, 13 November 2012 (UTC)Reply
I don't quite understand what you are trying to do, but check out {{abbr}}. ---— Gadget850 (Ed) talk 12:19, 13 November 2012 (UTC)Reply
Thank You Gadget850! You may not understand my reasons but you got the question right and that ABBR seems to really solve it. Thanks again all! Marketdiamond (talk) 12:28, 13 November 2012 (UTC)Reply

Would it possible (presumably by use of the Toolserver or similar) to find how many times a certain deletion summary has been used in the past, say, three months (I'm felxible on time length, though, if another – either longer or shorter – is easier)? The summary in question is "G6: Talk page is a redirect created by move of associated article". Cheers, Jenks24 (talk) 09:58, 13 November 2012 (UTC)Reply

According to Wikipedia IRC channel a query to do this is under development. Sfan00 IMG (talk) 12:55, 13 November 2012 (UTC)Reply
Per IRC - there are 16186 results that mention G6 Sfan00 IMG (talk) 19:35, 13 November 2012 (UTC)Reply
{cite_web} 35% faster w/o COinS; see below. -Wikid77 17:41, 16 November 2012

WMF/System administrators/developers, specifically Tim Starling, have cut down the citation template by removing COinS from the citation templates, due to continued performance problems with pages. Apparently this was the point where Don't worry about performance, kicks in, specifically If the sysadmins identify a performance problem, they will fix it. For more information see Template_talk:Citation/core#Removing_COINS_metadata. Hopefully soon we will have Scribunto to tackle this problem in a better way. —TheDJ (talk • contribs) 16:19, 13 November 2012 (UTC)Reply

I disagree with their removal, at least in the short term, but see Proposal: citation microformat for an alternative, with no such overhead. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 13 November 2012 (UTC)Reply
Actually when Tim does such things, we usually have reached the point where we are no longer really 'allowed' to disagree anymore. —TheDJ (talk • contribs) 16:29, 13 November 2012 (UTC)Reply
Well editors' right to disagree is inviolate, but their ability to take action on the basis of that disagreement is what's severely curtailed. Scribunto/Lua is indeed the upcoming solution to this issue, and others. Happy‑melon 19:44, 13 November 2012 (UTC)Reply
Good point :D —TheDJ (talk • contribs) 08:59, 14 November 2012 (UTC)Reply

Cite_web/sandbox4 has been the proposed next step

Created as {Cite_web/smart}, but renamed (after 3 weeks of pending-TfD deletion), Template:Cite_web/sandbox4 is proposed as the next step to streamline {cite_web} to run 4x times faster, with a lower post-expand include size (reduced by using fewer subtemplates). Meanwhile, {cite_quick}, which runs 8x-10x times faster, has been used as a safer alternative to only affect a specified article page, rather than all 1.2 million pages using {cite_web} of the 1.6 million using {Citation/core}, and then it was beset with a pending-TfD deletion, which was stopped after only 10 days. Meanwhile meanwhile, {cite_web/sandbox4} can be updated from lessons learned when improving {cite_quick}, such as to support Harvard referencing, all because {cite_web/sandbox4} is a hybrid which combines {cite_web} with {cite_quick}. Meanwhile at test2.wiki, I modified the Lua script version, Module:Citation, to closely mimic the {cite_web} format (and {cite_journal}, etc.). However, because those templates have over 230 parameters, then complete testing is mathematically impossible (as a combinatorics problem, from 230!), and so people should accept a certain level of slightly different formatting, because it is basically impossible to exactly mirror the 24-25 {cite_*} forks' template logic with the one Lua module. Hence, as a caution, I have advised to change the "big 4 cites" (cite_web, cite_news, cite_book, cite_journal) to Lua, at first, and then later upgrade the other 20-21 forks ({cite_video}, {cite_press_release}, etc.). Meanwhile, {cite_web/sandbox4} is still the markup-based path to better performance, to not rely on using Lua quite yet to reformat 1.2 million pages currently using {cite_web}. Hence, there are still 2 better futures: with streamlined markup or with Lua. -Wikid77 (talk) 22:28, 13 November 2012 (UTC)Reply

  • Cite_web or Cite_journal 35% faster without COinS: I forgot to note, earlier, that the removal of the COinS metadata also increases the citation speed by not re-checking the parameter values to format the metadata, beyond also using a smaller post-expand include size which benefits by omitting the metadata (formerly passed between subtemplates). In a recent test of 432 full citations for {cite_book} and {cite_journal}, those 432 entries were processed within 23 seconds, or 19 per second, when formerly, some similar full citations (with publisher, URL and Harvard referencing) would run at slower than 12 per second (now 50% 35% faster). So now, {cite_web} or {cite_news} or {cite_book} (etc.) can format 100 citations in 5.3 seconds, or almost 3 seconds faster (per 100) than before. A major pop-culture article with 200 citations would reformat (or preview) now 6 seconds faster, such as 24 seconds reduced to 18-second edit-preview. -Wikid77 (talk) 17:41/23:33, 16 November 2012 (UTC), 16 November 2012 (UTC)Reply
    Revised: I had inverted the ratio of new/old reformat times, where omitting the COinS data is about 35% faster, but re-adding the COinS would be over 50% slower for {cite_web}. -Wikid77 23:33, 16 November 2012 (UTC)Reply

While delivering a training sesison today, I was caught up in an IP address block. I undertsnad that it's possible for established accounts in good standing to be exempted from such blocks. Is that so, and if it is, how do I go about requesting such a flag, please? I deliver a lot of training, on large networks (universities, councils, libraries, etc.). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:20, 13 November 2012 (UTC)Reply

Wikipedia:IP block exemption —TheDJ (talk • contribs) 16:26, 13 November 2012 (UTC)Reply
Thank you, but that seems to apply to IP blocks affecting an editor's usual IP, rather than a case like mine, where I regularly work, on a one-off basis, on other people's sites. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 13 November 2012 (UTC)Reply
If editing from various blocked locations is your usual situation, then it applies to you as well. Never hurts to apply, I'm sure someone will grant you exemption. — Edokter (talk) — 19:33, 13 November 2012 (UTC)Reply
Not to be nosy, and with the knowledge that you may very well decline but I am curious as to the geography on this, might we know what city or political subdivision (state, province etc.) this occurred in? Just curious no extrapolations will be made against that locale. Thanks! Marketdiamond (talk) 20:24, 13 November 2012 (UTC)Reply
This happened in Staffordshire, England, but I've delivered training all over the United Kingdom and in Germany. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 13 November 2012 (UTC)Reply
Thank you; I'll try WP:ANI. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 13 November 2012 (UTC)Reply

Does any one know why {{Str sub long|Fusão/Central de fusões/Anexo:Página a ser fundida 2; Anexo:Página a ser fundida|24|29}} don't return "Anexo:Página a ser fundida 2" and ommits ":" ? Thank you very much!OTAVIO1981 (talk) 17:37, 13 November 2012 (UTC)Reply

I think it's because the colon in "Anexo:Página" and the semicolon after "fundida 2" are being taken as Wiki markup. --Redrose64 (talk) 18:05, 13 November 2012 (UTC)Reply
Yes. What's happening is that {{Str sub long}} puts the string through {{str index any}} 29 times, to extract one character at a time beginning at position 24; it then joins the characters together - but in the meantime, Wiki markup processing occurs, and that colon is processed exactly as if it were the colon at the start of this reply. Here are characters 28-32:
--Redrose64 (talk) 21:33, 13 November 2012 (UTC)Reply
  • Could change Str_sub_long to insert &#58/&#59 for colon/semicolon: The markup in Template:Str_sub_long invokes Template:Str_index/getchar to extract each character by using a {#switch} parser function, which treats semicolons as bold-headers and colon ":" as colon-indent. Note in the following example, how a #switch function already warps the colon character, before any other processing can occur, and so the #switch totally hoses the colon ":" to become a newline-indent, in the middle of string "xx:zz" as follows:
  • xx{{#switch:colon| colon = : }}zz
  • Result: xx
zz
However, {Str_index/getchar} could be changed to return the 5-character encoded form "&#58;" for a colon (":") and similar &#59 for a semicolon (";"). However, the resultant substring would be further expanded in length to fit the 5-long "&#58;" where each colon would have been. Does that seem acceptable? -Wikid77 (talk) 23:48, 13 November 2012 (UTC)Reply
  • New Str_sub/any to handle colons/semicolons: I have created an entirely new substring template, as Template:Str_sub/any, to handle any character in the string by encoding/decoding special characters. It has the same format as {Str_sub_long} but also handles colons, semicolons, asterisks ('*') and hashmarks ('#'). For the above example:
  • Markup: "{{Str sub/any|Fusão/Central de fusões/Anexo:Página a ser fundida 2; Anexo:Página a ser fundida|24|29}}"
  • Result:  "Anexo:Página a ser fundida 2;"
The template handles the colons/semicolons and other special characters with a null-nowiki tag (such as "<nowiki/>:") because it is impossible to treat a leading colon as literal text when every template is forced to process markup for newline tokens. However, when the result is formatted into a page, then all the characters will appear in the exact locations, as expected. Long term, I am also thinking of a method to retain the pure character sequences by parsing the text with a one-character look-ahead algorithm, likely 10x times more difficult, so I hope the null-nowiki tags will work for now. I am sorry that I did not write the new Template:Str_sub/any years ago, when I first suspected the need to encode/decode the special characters. I guess many of us thought that the parser functions would be improved to provide simple substrings, or that a literal colon ":" could be inserted one day without embedding nowiki tags inside strings. -Wikid77 (talk) 04:58, 14 November 2012 (UTC)Reply
Wow! Thank you all for helping. I really appreciate. OTAVIO1981 (talk) 12:51, 14 November 2012 (UTC)Reply

Sister projects When one searches for a redlink term (e.g. ldskjfoi4j0239fj), there is a box of sister projects that comes up, suggesting you search Wiktionary, Wikiquote, etc. It's in a div id'ed "mw-content-text", a table id'ed "noarticletext", a td id'ed "mbox-text", and a further div id'ed "sisterproject". I figured that one of those HTML tags would translate into a MediaWiki interface named something like MediaWiki:Sisterproject or somesuch, but I was completely wrong. Anyway, where in the interface is this sisterprojects box located? I want to post an {{protected edit}} to add Wikivoyage when it's out of beta. —Justin (koavf)❤T☮C☺M☯ 19:41, 13 November 2012 (UTC)Reply

Hey, Koavf! This is actually in template space, found at Template:No article text. Writ Keeper ⚇♔ 19:50, 13 November 2012 (UTC)Reply
In fact I suspect it may be MediaWiki:Nocreatetext that produces this. This is what is shown to logged out users. — Martin (MSGJ · talk) 19:58, 13 November 2012 (UTC)Reply
Ah, probably. I stand corrected! Writ Keeper ⚇♔ 20:08, 13 November 2012 (UTC)Reply
Are you sure? With the uselang=qqx interface-debugging parameter, http://en.wikipedia.org/wiki/Ldskjfoi4j0239fj?uselang=qqx shows (when not logged in) that it is using MediaWiki:noarticletext-nopermission, which in turn does indeed contain "{{No article text|nopermission=yes}}", as indicated by Writ Keeper. (Logged in readers get MediaWiki:noarticletext.) — Richardguk (talk) 22:01, 13 November 2012 (UTC)Reply
Thanks all! —Justin (koavf)❤T☮C☺M☯ 09:17, 14 November 2012 (UTC)Reply

This question was not signed, but the bot came along and signed it later. I thought questions were in order according to when they were asked, but even the time of the bot signature is inconsistent with the questions above and below.— Vchimpanzee · talk · contributions · 21:45, 13 November 2012 (UTC)Reply

*sigh* this again. It's really just like any other Wikipedia page: the sections are in whatever order they're put in. Our JS gadget puts questions at the top, rather than the bottom as usual, but not everyone uses that gadget; sometimes questions go to the bottom, which causes things to be out of order. We try to shift 'em around to be in the correct place, but sometimes things slip through the cracks. It's not automatically sorted by date or anything like that, so that might just be a question out of order, rather than something malfunctioning. and yeah, i know that bottom-posting is standard for wikipedia. don't ask me; i just work here. Writ Keeper ⚇♔ 21:52, 13 November 2012 (UTC)Reply
Okay, thanks.— Vchimpanzee · talk · contributions · 22:00, 13 November 2012 (UTC)Reply
The post was placed at the bottom. Since there is no heading, and the edit summary is blank, the "New section" tab was not used: the poster most probably edited the whole page. They might have edited the last section, if so they also blanked the edit summary. We often get both of those right here on WP:VPT even from logged-in users with years of experience. --Redrose64 (talk) 22:27, 13 November 2012 (UTC)Reply

I can't compile this module. It says, "Line 26, col 9 [CS1501] InitialiseLogListener ...". What's wrong with it? --MakecatTalk 09:52, 14 November 2012 (UTC)Reply

This page's history shows an edit at 09.59 "Search list not updating", which I can read using the diff, and wished to add to.
However, this thread does not appear on the page, nor if I try to edit the page. The most up to date entry on the page and the edit screen is 09.52 Customizing general fixes
I have purged, but still can't get the page to catch up to the history
This comment looks fine on the preview screen but I don't know if it will appear on the actual page, or when ? - Arjayay (talk) 10:21, 14 November 2012 (UTC)Reply

Wierd - this diff [5] at 09.59 has still not appeared although I started this thread at 10.21 - Arjayay (talk) 10:26, 14 November 2012 (UTC)Reply
And it won't appear because it has inadvertently been removed in the next edit. Looks like an edit conflict resolution gone wrong. Lupo 11:04, 14 November 2012 (UTC)Reply

Hi, I created a new article Wikipedia

http://en.wikipedia.org/wiki/Colloidal_probe_technique

but its content does not show up in the search bar. No idea how to fix this. Bubblerock2 (talk) 09:59, 14 November 2012 (UTC)Reply

I have reinstated this thread, accidentally removed by either another editor, or an edit conflict
I initially wondered if Bubblerock2 was just being impatient, as many editors do not realise the search is only normally updated every 24 hours. However, I see that spelling corrections I made on 10 Nov are still appearing in a search for the misspelled word, so the search hasn't been updated since at least then. The search results are also changing sequence, which makes checking a search difficult and is usually indicative of "stale slices" (whatever they are) Arjayay (talk) 11:21, 14 November 2012 (UTC)Reply
  • Created redirect but Google Search also out-of-date: To help users find the new article from 11 November 2012, I created a redirect as the popular scientific term "colloidal probe" to transfer to "Colloidal probe technique" (Google hits=22,700 for "colloidal probe" in many science websites). Fortunately, the wikisearch will match those 2 exact titles, until re-indexed to search inside the article text. However, Google Search is also out-of-date as indexing the userfied version under User:Bubblerock2/~, but that Google-index delay could be an attempt to slow the use of new-article spamming. I will update the article, in case Google checks the number of various editors to determine the speed of re-indexing. -Wikid77 (talk) 15:30, 14 November 2012 (UTC)Reply
We're looking into this.--Eloquence* 07:06, 15 November 2012 (UTC)Reply
It seems to have re-started, but still lists things which were removed on 12 November, so has a lot of catching up to do. Arjayay (talk) 11:45, 16 November 2012 (UTC)Reply
Thanks for your feedback, this page is now indexed in Wikipedia search as well as by Google correctly. Bubblerock2 (talk) 16:26, 17 November 2012 (UTC)Reply

Is there a way to alphabetize Special:ListGroupRights by the "plain English" names of the rights instead of by their "group"? As an example, "Administrator" is alphabetized by its group name, "sysop", which puts it in a quite unexpected place - and buried - on the list, especially since almost no one calls an admin a "sysop". --Philosopher Let us reason together. 19:01, 14 November 2012 (UTC)Reply

Only by changing the code; right now it explicitly sorts by the group name. Anomie⚔ 04:12, 15 November 2012 (UTC)Reply
Where is this code? Do you know why it explicitly sorts by group name? --Philosopher Let us reason together. 01:36, 16 November 2012 (UTC)Reply
The code is in includes/specials/SpecialListgrouprights.php. Presumably it sorts by the group name so that the order of things on the page doesn't change depending on the order things are set up in the configuration files. Anomie⚔ 04:51, 16 November 2012 (UTC)Reply

Hey all,

Below are copies of the regular (every fortnight) updates for the past two periods on the VisualEditor project and its cousin the Parsoid 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). (Sorry these are late; I forgot to send them as they coincided with the monthly reports.)

VisualEditor

The VisualEditor was updated as part of the wider MediaWiki 1.21wmf3 branch deployment on Monday 29 October.

In two weeks since 1.21wmf2, the team have continued to devote most of their time working on re-designing how the code integrates together and providing clean interfaces between them so new developers can re-use and extend VisualEditor in the future.

Beyond the API work, we have worked to fix a number of serious bugs in the new code from the last release such as not being able to enter text in blank paragraphs in Firefox 41120, as well as copy-and-paste (41055) and cutting (41092) both breaking, a JavaScript error being caused when editing a blank page (37843), and not being able to change the formatting on two lists at once (41434).

A complete list of individual code commits is available in the 1.21/wmf3 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

The VisualEditor was updated as part of the wider MediaWiki 1.21wmf4 branch deployment on Monday 12 November.

In two weeks since 1.21wmf3, the team have spent their time mostly working on finalising the code in preparation for its deployment in December as a test for users. One of the major changes to the integration code is how the VisualEditor can be used; it now can work on other pages than just those in the VisualEditor: namespace. (This is configurable on a per-wiki basis, rather than defined in the code itself.) Amongst other things, this now means that editing the wikitext of VisualEditor: namespace pages can be done by anyone, and is no longer restricted to just sysops (as will be needed for the December deployment). The related bugs surrounding permission checks, filter checks, conflicts, etc. remain, and will be fixed in the next release.

Part of the preparations involved entirely re-writing the user interface code including the way in which commands operate (40896). Another aspect was the addition of "Change Markers" to the data sent to the mw:Parsoid system to reduce any accidental changes that should not happen when users save. Finally, a bug with how the "save page" button worked on old revisions was fixed (41865).

A complete list of individual code commits is available in the 1.21/wmf4 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

Parsoid

The mw:Parsoid team focused on testing the JavaScript prototype parser against a corpus of 100,000 randomly-selected articles from the English Wikipedia. A distributed MapReduce-like system, which uses several virtual machines on mw:Wikimedia Labs, constantly converts articles to HTML DOM and back again to wikitext using the latest version of the Parsoid. For a little over 75% of these articles, this results in exactly the same wikitext, as we intend. For another 18% of these articles, there are some differences in the wikitext, but these are so minor that they don't result in any differences in the produced HTML structure when it is re-parsed. In the production version of Parsoid which will attempt to retain original wikitext as far as possible, these minor differences will only show up, if at all, around content that the user edited. Finally, just under 7% of articles still contain errors that change the produced HTML structure. These issues are the focus of the current work in preparation for the December release.

Most of the work has been on the JavaScript implementation, in preparation for the December release. The automated testing of wikitext->HTML->wikitext now has 75.81% of articles returning exactly the same, and 94.26% with changes that do not change the nature of the page (but still makes changes to the wikitext).

The full list of Parsoid commits is available in Gerrit.

Hope this is helpful! As always, feedback gratefully received, either here or on the centralised feedback page.

Jdforrester (WMF) (talk) 19:47, 14 November 2012 (UTC)Reply

The new video player (for example visible at Dr. No (film)#The introduction of James Bond) contains a small "Kaltura" logo, visible in full screen after the movie stop playing or after clicking the "Menu" button. This logo links to http://corp.kaltura.com/, which rather prominently displays a "Sales" link. This link should either be removed or at least be pointed to the more reasonable http://www.kaltura.org/. —Ruud 21:02, 14 November 2012 (UTC)Reply

It's Bug 23965. --Yair rand (talk) 22:28, 14 November 2012 (UTC)Reply

I'm used to watching links on Special:SpecialPages, especially Special:BrokenRedirects, where I tag or repair. These normally update every three of four days. I've noticed that none of the working updates seem to have updated since 11/4. I'd post this at WT:Maintenance, but thought I'd get more eyes here (nobody has edited there since mid-year). Mistakenly put this on AN. Is this a bot function, or is there human activity required? BusterD (talk) 23:47, 14 November 2012 (UTC)Reply

For the time being, you might want to use the reports on WP:DBR. I'm not sure why they aren't updating though. I though they were just cronjobs that ran every so often. Legoktm (talk) 23:49, 14 November 2012 (UTC)Reply
Will do. Many of the links at SpecialPages never update anymore, but I often use the ones that do. BusterD (talk) 04:40, 15 November 2012 (UTC)Reply
If this doesn't improve please consider filing a new bug report in bugzilla.wikimedia.org under product "Wikimedia" and component "Site requests", and mark it as blocking bug 29782 if possible. Thanks! --Malyacko (talk) 09:36, 15 November 2012 (UTC)Reply
Apparently this was happening across the platform in multiple language wikis. Has been repaired. Thanks for the help! BusterD (talk) 04:19, 17 November 2012 (UTC)Reply

I don't know where else I'd ask this, but does anyone know what happened to Tedder? He seems to have just disappeared. I don't know what WP circles he edits in, so I'm at a loss. Nothing on his talk page indicates he was not coming back. I have emailed him, but have no idea if he's checking his email. — Maile (talk) 02:19, 15 November 2012 (UTC)Reply

Which specific tasks do you want restarted? It looks like the code was all open source, so if you try posting at WP:BON you might be able to find a maintainer. Legoktm (talk) 04:41, 15 November 2012 (UTC)Reply
Check his talk page. Looks like he's on vacation. It's only been 3 weeks or so. —[AlanM1(talk)]— 11:18, 15 November 2012 (UTC)Reply
Oh, my. I had read his talk page and totally missed where he'd said he was headed on vacation. Disregard this post. Everything will resume normally when he returns. — Maile (talk) 13:37, 15 November 2012 (UTC)Reply

Wikipedia is looking weird in in Firefox Mozilla — Preceding unsigned comment added by 59.183.15.122 (talk) 11:00, 15 November 2012 (UTC)Reply

It looks normal to me in Firefox. Try to clear your entire cache and if it still looks weird then please describe what you see at which page. PrimeHunter (talk) 11:11, 15 November 2012 (UTC)Reply
What, specifically, seems out of the ordinary? TortoiseWrath (talk) 04:46, 17 November 2012 (UTC)Reply

  Resolved

 – Know what to do now technically, thank you. PrimeHunter, Redrose64, Doctree are all righteous.

So a couple users and I are trying to breathe life into the Wikipedia:Africa-related regional notice board/Peer review space. Energy is so far going good, but there is a problem with the template in terms of recommending articles. It says: add peer-review=yes to the Africa noticeboard template, but doing that does nothing. Any help on a workaround, a redesign, or anything that can get that working easily. I looked at other peer review pages but didn't find any help. Thank you in advance for your time! AbstractIllusions (talk) 01:10, 15 November 2012 (UTC)Reply

The instruction "Add peer-review=yes to the {{Africa noticeboard}} banner" was written before {{Africa noticeboard}} was redirected to {{AfricaProject}} in [6] (and later moved to {{WikiProject Africa}}). See the previous code in the diff for how the parameter worked. The parameter is not present in the current template code so it's completely ignored when the template is called. PrimeHunter (talk) 16:29, 15 November 2012 (UTC)Reply
So, if I understand correctly (alas, code is not something I'm good at), I need an Admin to reenter that code at [7], is that the right solution? AbstractIllusions (talk) 16:41, 15 November 2012 (UTC)Reply
You need an admin to edit that template, but the code is different now when {{WikiProject Africa}} uses {{WPBannerMeta}}. Template:WPBannerMeta/hooks/peerreview may help to achieve similar functionality. If you restrict Special:WhatLinksHere/Template:WPBannerMeta/hooks/peerreview to the Template namespace then you can see what other WikiProjects do. Tests can be made at {{WikiProject Africa/sandbox}}. PrimeHunter (talk) 16:54, 15 November 2012 (UTC)Reply
I'm pretty sure I got this, could you check Template:WikiProject Africa/sandbox just to make sure that is what I want to suggest at the template page for addition. Borrowed from the films template and novels template, but just want to make sure that this works. Let me know if I am missing anything important. Thanks for all the help. AbstractIllusions (talk) 17:28, 15 November 2012 (UTC)Reply
The normal method is to put your proposed version at the template's sandbox page, which as noted above is {{WikiProject Africa/sandbox}}. This allows direct comparisons to be made using the links which are created automatically. See WP:TESTCASES. --Redrose64 (talk) 17:54, 15 November 2012 (UTC)Reply
Cool, fixed above and Template:WikiProject Africa/sandbox here. AbstractIllusions (talk) 18:50, 15 November 2012 (UTC)Reply
The idea of using a template sandbox is to test the code before it goes live. My test [8] failed. If you want to keep the peer review at Wikipedia:Africa-related regional notice board/Peer review#Company rule in Rhodesia then you must change the sandbox parameters. PrimeHunter (talk) 22:00, 15 November 2012 (UTC)Reply

Looks like it works if you change the link back to Wikipedia:Africa-related regional notice board/Peer review. Creates a subpage for the review. Try it now in a test page. DocTree (ʞlɐʇ·cont) Join WER 00:53, 16 November 2012 (UTC)Reply

We need to add "archive1" and so on to the links, but other than that this looks like it works now. —Cliftonian (talk) 04:51, 16 November 2012 (UTC)Reply

Hola,

How come the "Upload file" link in the toolbox still points to Wikipedia:Upload, which is a redirect to Wikipedia:File Upload Wizard? Kinda messy. Can we get $wgUploadNavigationUrl changed, or is there something holding us back from that?

Thanks, — Hex (❝?!❞) 14:57, 15 November 2012 (UTC).Reply

As reported on Talk:Shellsort#Graph of number of operations, thumbnails generated for File:Shell sort average number of comparisons (English).svg suffer from a weird error: the label in the upper left corner, which reads “log2N!” in the original svg, is rendered as “log!2N”.—Emil J. 16:18, 15 November 2012 (UTC)Reply

Somebody's altering the style sheet for diffs in Monobook. The font has got larger, and previously-centred text is now left-justified. --Redrose64 (talk) 20:17, 15 November 2012 (UTC)Reply

MediaWiki:Monobook.css hasn't been touched in a while. Neither has MediaWiki:Common.css. And I'm on monobook, and I don't see anything different... Legoktm (talk) 20:21, 15 November 2012 (UTC)Reply

Well unread pages on my watchlist suddenly went bold. (I was clicking it a couple times in a row). So someone changed something... - jc37 20:26, 15 November 2012 (UTC)Reply

Beginning at 20:16 the style has been variable. Font is now normal again but the shape and size of the boxes is varying. At one point the two main areas weren't equal-width but as wide as necessary; this meant that if a short line had been significantly extended, the right-hand "half" would be much wider than the left. --Redrose64 (talk) 20:27, 15 November 2012 (UTC)Reply
Have you tried viewing a diff between page versions? Completely useless at the moment. Working fine in Vector, but broken in Monobook. Not browser-specific -- tried in both Firefox (16.0.2) and IE (8.0). WikiDan61ChatMe!ReadMe!! 20:28, 15 November 2012 (UTC)Reply
Yes, it had zero formatting. It started (at least) several minutes before the watchlist bolding. - jc37 20:31, 15 November 2012 (UTC)Reply
(EC) Something is wrong. My diffs are definitely screwed up in Monobook, and I had to reload my watchlist three times before the css kicked in. Rivertorch (talk) 20:30, 15 November 2012 (UTC)Reply
Yup I'm having errors too now. Legoktm (talk) 20:32, 15 November 2012 (UTC)Reply

oooooo I just edited User talk:Jimbo Wales and after hitting suubmit, the page has no formatting. And same with the edit page/screen when I try to edit this page. apparently not all formatting is gone, since the save page etc buttons, and the scrollbar along the edit window both are still there. - jc37 20:41, 15 November 2012 (UTC)Reply

Ok when I hit save page, the formatting came back, and when I clicked edit to note that here, I'm now looking at no formatting again... - jc37 20:42, 15 November 2012 (UTC)Reply
Different bits of formatting are randomly appearing and disappearing in monobook with every refresh of a page. For example all collapsed sections are now expanded with no option to hide them and hatnotes have no formatting, previously hatnotes and indentation were the only bits of formatting working. Thryduulf (talk) 20:51, 15 November 2012 (UTC)Reply
  • Just came here to add that something strange is happening with Monobook. It started at exactly 20:10 UTC for me if that helps. First, the watchlist appearance changed; then it went back to normal except that changes are now in bold; now I'm seeing infoboxes on the left of articles instead of the right, and they look different. SlimVirgin (talk) 20:57, 15 November 2012 (UTC)Reply

Useless diffs

Am I the only one who is getting unintelligible diffs? Toccata quarta (talk) 20:28, 15 November 2012 (UTC)Reply

See above. Legoktm (talk) 20:32, 15 November 2012 (UTC)Reply

I just had a diff in Vector show up without CSS; bypassing my cache brought it up properly. Windows Vista/Firefox 16.0.2. jcgoble3 (talk) 20:36, 15 November 2012 (UTC)Reply

Other pages are changing their styling too. Infoboxes are randomly losing their borders and going hard left; and the watchlist has lost all styling. --Redrose64 (talk) 20:37, 15 November 2012 (UTC)Reply
Previously-collapsed tables and boxes and whatever are now defaulting to uncollapsed, making pages like AIV a bit harder to navigate. Who do we tar and feather for this? Writ Keeper ⚇♔ 20:41, 15 November 2012 (UTC)Reply
Seems to be fine now. Writ Keeper ⚇♔ 20:44, 15 November 2012 (UTC)Reply
It's not fixed for me. --Anthonyhcole (talk) 20:48, 15 November 2012 (UTC)Reply
Me either. I've temporarily gone over to the Dark Side. It's clearly a plot to assimilate us Monobook holdouts! Rivertorch (talk) 20:53, 15 November 2012 (UTC)Reply
Yeah, I think I jinxed it. Writ Keeper ⚇♔ 20:56, 15 November 2012 (UTC)Reply
My diffs are OK now in Vector and Monobook. --Anthonyhcole (talk) 20:57, 15 November 2012 (UTC) Spoke too soon. 20:59, 15 November 2012 (UTC)Reply
Oh, this is fun. The edit conflict screen now has large-type before-and-after diffs, but all diffs are indeed completely useless—no highlighting or anything. Thank goodness for pop-ups. (I dread the day that an interface "improvement" renders pop-ups permanently unusable, since evidently no one is maintaining them.) Rivertorch (talk) 20:44, 15 November 2012 (UTC)Reply
And I spoke too soon. Now pop-ups aren't working, and my watchlist items are bolded. Yuck. Rivertorch (talk) 21:02, 15 November 2012 (UTC)Reply
Vector; and the diffs are screwed for me too. 20 minutes ago my toolbar went missing, then came back. Now it's gone again, and presented with the gibberish diff appearance. Jared Preston (talk) 21:05, 15 November 2012 (UTC)Reply
To heck with this. I'm off to watch TV, then I might go to bed. See you all tomorrow. --Redrose64 (talk) 21:08, 15 November 2012 (UTC)Reply
Same problem here: No highlighting or formatting on diffs. It's like playing "find the differences between these two pictures". I think Redrose has the right idea. Kafziel Complaint Department: Please take a number 22:28, 15 November 2012 (UTC)Reply
Yes, diffs don't show up properly in Google Chrome either. Δρ.Κ. λόγοςπράξις 01:10, 17 November 2012 (UTC)Reply
Also the bars on the page view stats have become invisible. Δρ.Κ. λόγοςπράξις 01:12, 17 November 2012 (UTC)Reply

Scripts not functioning

Not sure if this is related to the above, but all of my user scripts have stopped functioning. I'm using Vector, not Monobook. --auburnpilot talk 21:02, 15 November 2012 (UTC)Reply

Same here; pretty sure it is related. Writ Keeper ⚇♔ 21:03, 15 November 2012 (UTC)Reply
Mine stopped working 5 minutes, (including collapse), but it's all back to normal now. Edgepedia (talk) 21:05, 15 November 2012 (UTC)Reply
I also noticed that when clicking on "show preview" takes you back to the top of the page in the edit box, even if you were editing half-way down the article. Never experienced this before. Jared Preston (talk) 21:08, 15 November 2012 (UTC)Reply

Define the problem

It affects (intermittently):

  • English Wikipedia
  • Vector and Monobook, and Modern and all skins
  • diffs
  • article space, Wikipedia: space
  • watchlists
  • scripts
  • Editing interface
  • Gadgets

Please add to or edit this list. --Anthonyhcole (talk) 21:13, 15 November 2012 (UTC)Reply

Added a couple. Thryduulf (talk) 21:19, 15 November 2012 (UTC)Reply
Added more. It's only English Wikipedia, as far as I can tell. But all skins are whacked. Commons is fine. Wikisource is fine. German Wikipedia is fine. Just the English Wikipedia. — Maile (talk) 21:23, 15 November 2012 (UTC)Reply
Mine corrected. I'm in Modern skin, and everything else seems to be OK. — Maile (talk) 21:37, 15 November 2012 (UTC)Reply
Seems OK now. This is usually some sort of connection issue where the site CSS is not served. ---— Gadget850 (Ed) talk 21:40, 15 November 2012 (UTC)Reply
I'm currently getting a problem with diffs (no markup) using chrome, but not Explorer 9. Edgepedia (talk) 21:56, 15 November 2012 (UTC)Reply
Purged the cache on chrome and it's now working fine. Edgepedia (talk) 22:11, 15 November 2012 (UTC)Reply
I'm getting it still on Chrome, but not Firefox. Purging the cache doesn't seem to help. Adding here in case it helps, since doing anything about the problem is totally beyond my skills. --Moonriddengirl (talk) 12:01, 16 November 2012 (UTC)Reply
Same as Moonriddengirl, problem still exists on Chrome, but not firefox. CMD (talk) 16:24, 16 November 2012 (UTC)Reply
I had this problem with Chrome yesterday. I had to close all pages, clear the entire cache (from the "beginning of time"), then close the browser and restart it before loading any Wikipedia pages. --R'n'B (call me Russ) 18:21, 16 November 2012 (UTC)Reply
I cleared my cache for the past week, which is from before the problem, and it fixed it. CMD (talk) 23:35, 16 November 2012 (UTC)Reply
I had this problem two days ago (using Safari 5 point something) and Monobook - that was the only skin affected. I had to clear my cache, then do a complete shut-down (not a reboot). After that it was fine. Truthkeeper (talk) 00:32, 17 November 2012 (UTC)Reply
I cleared the Chrome cache as suggested by R'n'B and CMD and now it's working. Δρ.Κ. λόγοςπράξις 20:56, 17 November 2012 (UTC)Reply

Identify the problem

Seems there have been a lot of people going "me too", and not many people looking at what is causing the problem. I looked into this a few hours ago when I first saw it happening. Since diff colours seemed to be the worst affected, I checked the HTML source to find the CSS for diff colours. For me, they come from bits.wikimedia.org. I loaded that page in my browser, and found it contained errors like "Can't connect to local MySQL server" followed by PHP stack traces, but no CSS. The error message was repeated several times, with a slightly different stack trace each time. Unfortunately, I didn't make a note of the exact error text at the time and I can't get the problem to happen again now... I'll post back if it happens again. – PartTimeGnome (talk | contribs) 23:34, 15 November 2012 (UTC)Reply

Propose a solution

Hopefully this is the best place to ask this question. I have a citation to an article originally in Newsweek from 1996. I found all the details for the article at a pay site, and added them to the reference. However, I've also found a link to the full article that is free, but has none of the original publication details like author, date, etc. Is there a way to link more than one url to provide the full set of information? My current solution was to include the second url with details as a hidden comment in the citation. —Torchiest talkedits 20:42, 15 November 2012 (UTC)Reply

The publication details of the article do not include a URL (the document was originally published in print). The fact that you happened to find the publication details online is somewhat irrelevant. I would simply list the URL of the full text that is freely available. WikiDan61ChatMe!ReadMe!! 20:52, 15 November 2012 (UTC)Reply
Or, if you really need to give two URLs, give two references. --Redrose64 (talk) 20:57, 15 November 2012 (UTC)Reply
WP:Citing sources is the proper venue for this, but as long as we're here: If the print and on-line versions differ then they should have separate citations. If they are essentially the same I generally use |url= for the free or more convenient link, relying on |doi= (if there is one) to indicate the authoritative source. If a secondary url (or isbn or a comment) is needed it can be added following the template. E.g.: {{cite ... }} ([http:... free copy]). Which is pretty much like the following example. ~ J. Johnson (JJ) (talk) 22:38, 15 November 2012 (UTC)Reply

I've been using something like

on a number of articles recently. Edgepedia (talk) 22:06, 15 November 2012 (UTC)Reply

Thanks to everyone for all the good ideas and suggestions. I'd been thinking about trying something like J. Johnson or Edgepedia's ideas, just having an extra link at the end. —Torchiest talkedits 23:14, 15 November 2012 (UTC)Reply
There's no apparent reason why Edgepedia's example can't be given as
this links the title to the URL. --Redrose64 (talk) 07:37, 16 November 2012 (UTC)Reply

None of the gadgets I had enable (wikEd, TW, etc.) are working right now and in My preferences I no longer have a Gadgets tab. Is anyone else experiencing this? --Odie5533 (talk) 02:35, 16 November 2012 (UTC)Reply

I'm experiencing this as well. --Webclient101talk 02:40, 16 November 2012 (UTC)Reply
I came here to report the same thing. IE 8.0.7601.17154/Monobook/Windows 7. Nyttend (talk) 02:42, 16 November 2012 (UTC)Reply
Me too. The gadgets panel in "my preferences" is also missing. Windows 7/Chrome 22.0.1229.94.--MakecatTalk 02:44, 16 November 2012 (UTC)Reply
Same here. I noticed earlier that one of the gadgets wasn't working but I thought it was an isolated case; nothing I've added is working right now and the tab is missing for me too. GRAPPLE X 02:46, 16 November 2012 (UTC)Reply
Same here. The stuff in my vector.js file is working, though, so it's a gadget issue. Almost like someone accidentally disabled the gadget extension. Windows Vista/Firefox 16.0.2/Vector. jcgoble3 (talk) 02:49, 16 November 2012 (UTC)Reply
Actually, Special:Version still lists the Gadgets extension. So it's not disabled, just not working. jcgoble3 (talk) 02:54, 16 November 2012 (UTC)Reply
<me too>Me too. I assume it was a gadget was the keeping the old green diffs, and they are gone. </me too>♫ Melodia Chaconne ♫ (talk) 02:49, 16 November 2012 (UTC)Reply
I am also missing the gadgets tab with Safari 6.0.2 on OS X 10.8.2. I believe I noticed something weird going on earlier today, maybe 8-10 hours ago (17-19 UTC). For now, we will have to manually install the gadgets in our skin.js file as Legoktm said. The Anonymouse (talk • contribs) 03:01, 16 November 2012 (UTC)Reply
I'm having this problem as well. Twinkle, HotCat, WikEd, Popups, and other more minor gadgets are all gone. I've asked this question at the hep desk as well. BTW, about the Europe comment below, I'm having problems in the U.S. as well. I have the newest version of Chrome. StringTheory11 (t • c) 03:03, 16 November 2012 (UTC)Reply

I've asked in #wikimedia-tech with no response. For the time being, if you install them manually into your skin.js they will work. Legoktm (talk) 02:52, 16 November 2012 (UTC)Reply

Based on a discussion with another user earlier, servers in Europe (or maybe users in Europe) experienced this starting about 2-3 hours ago. Don't know what this means. gwickwire | Leave a message 02:55, 16 November 2012 (UTC)Reply

Firefox 16.0.2/Vector/Gentoo here, Gadgets not showing up for me from Canada. ⁓ Hello71 02:57, 16 November 2012 (UTC)Reply

Same here. TBrandley 03:01, 16 November 2012 (UTC)Reply
Same issue for me here in Australia - using Firefox 16.0.2 - Hotcat and gadgets have all stopped working in the last hour.--Chaleyer61 (talk) 03:04, 16 November 2012 (UTC)Reply
The only gadget that's working for me is popups. Otherwise, I'm on the same boat as everyone. Elockid (Talk) 03:05, 16 November 2012 (UTC)Reply
The reason that one is working is because your browser still has it cached. It you hit CTRL R it will no longer work either. --Odie5533 (talk) 03:06, 16 November 2012 (UTC)Reply
Making a null edit to the MediaWiki:Gadgets-definition file might cause Gadgets extension to reload. I'm not sure though. I did find this bug, which might be related: [9] --Odie5533 (talk) 03:09, 16 November 2012 (UTC)Reply
I'm having the same problem on my iPad, there's not even a Gadgets bar in my preferences.--Astros4477 (talk) 03:10, 16 November 2012 (UTC)Reply
i need my Reference Tooltips! Gadgets Tab where are you going!--Qa003qa003 (talk) 03:12, 16 November 2012 (UTC)Reply

And it's fixed. Special:Gadgets now has all the gadgets available. --Odie5533 (talk) 03:11, 16 November 2012 (UTC)Reply

Tim Starling deleted a corrupt memcached value which has fixed it. Legoktm (talk) 03:13, 16 November 2012 (UTC)Reply

The only gadgets enabled for me are the default ones. All of the ones I had explicitly turned on are now off. jcgoble3 (talk) 03:14, 16 November 2012 (UTC)Reply

  Orz...yes i see .....--Qa003qa003 (talk) 03:16, 16 November 2012 (UTC)Reply

Same for me. --Lexein (talk) 03:17, 16 November 2012 (UTC)Reply
I am not having that problem. All the gadgets I had enabled previously are still enabled. --Odie5533 (talk) 03:24, 16 November 2012 (UTC)Reply
Gadgets tab, and in-browser gadgets are working. All the Gadgets prefs fine. --Lexein (talk) 03:29, 16 November 2012 (UTC)Reply
Did you save your preferences while Gadgets were missing? That might have reset your gadget preferences to defaults. – PartTimeGnome (talk | contribs) 00:26, 17 November 2012 (UTC)Reply
Not that I remember. jcgoble3 (talk) 01:46, 17 November 2012 (UTC)Reply
I've tried five browsers, and found that it varies. Firefox 16, IE 7, Chrome - no javascript. Opera - limited javascript (the MediaWiki:Geonotice.js displays correctly, but the search box does not offer suggestions; there are no gadgets, nothing from Special:MyPage/common.js; and MediaWiki:Edittools shows the "Copy and paste" version). Safari seems to be OK. --Redrose64 (talk) 11:53, 16 November 2012 (UTC)Reply
I sometimes can reproduce this, too. May be related to or caused by bugzilla:42192. I notice that when I get that error on a page and then click on "my preferences", there will be no tabs on the preference page. Lupo 12:47, 16 November 2012 (UTC)Reply

Has someone asked the foundation for help? What about Bugzilla? I don't know who to ask at the foundation, or how report a problem to Bugzilla. --Anthonyhcole (talk) 13:35, 16 November 2012 (UTC)Reply

It is mentioned in https://bugzilla.wikimedia.org/show_bug.cgi?id=42192 , however above comment by Legoktm states that "Tim Starling deleted a corrupt memcached value which has fixed it". --Malyacko (talk) 14:52, 16 November 2012 (UTC)Reply

Working for me on Firefox, still out on Chrome. Or maybe it is working on Chrome, and I just have no idea which boxes I used to have checked on my settings. This is super awesome. Kafziel Complaint Department: Please take a number 15:09, 16 November 2012 (UTC)Reply

Not working again for me. One of my tools are missing some features as well. Elockid (Talk) 15:13, 16 November 2012 (UTC)Reply

Hmm. It doesn't work on Monobook but works on Vector. Sigh. Elockid (Talk) 15:16, 16 November 2012 (UTC)Reply
Everything seems normal for me now. Monobook, Firefox, Vista. --Anthonyhcole (talk) 15:53, 16 November 2012 (UTC)Reply
Pleased to report that, with XP, IE8, Vector, there is a Gadgets tab.
It doesn't work of course, because it hasn't worked since 21 July, as reported in this diff [http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28technical%29&diff=503442043&oldid=503440558} but at least I can admire the, totally useless, tab. - Arjayay (talk) 16:10, 16 November 2012 (UTC)Reply
Arjayay, i succeeded in reproducing, but only in "compatibility mode". there is a bug report about this problem (bugzilla:41792) that was erroneously closed. i reopened it, and linked to your report from July. there is no excuse for this, and the problem *should* be fixed, but for your own use, you can overcome the issue by switching your browser out of compatibility mode. peace - קיפודנחש (talk) 19:55, 16 November 2012 (UTC)Reply
One of us misunderstands compatability mode. As explained under #No popups above, my understanding is that it is allows newer browsers deal with older web-formats, not older browsers deal with newer. On a machine running W7 IE9 I can reproduce the problem by turning on compatability mode, as it back-grades the machine, and overcome the problem by coming out of compatability mode. However, there is no change whatsoever, whether using, or not using, compatability on XP IE8. - Arjayay (talk) 13:24, 17 November 2012 (UTC)Reply

how open Reference Tooltips?--Qa003qa003 (talk) 03:02, 16 November 2012 (UTC)Reply

Special:Preferences - Gadgets. If missing, see the discussion above. --MakecatTalk 03:07, 16 November 2012 (UTC)Reply
消失了怎么回事。。。--Qa003qa003 (talk) 03:10, 16 November 2012 (UTC)Reply

Following the discussion at VP (proposals) I have globally enabled the HotCat gadget for all logged-in users. See also the request at the gadget's talk page.

If this causes any serious problems, feel free to roll back this edit of mine. If you notice non-critical problems, please report them at Wikipedia talk:HotCat. Lupo 09:01, 16 November 2012 (UTC)Reply

I predict a lot of categories deleted unintentionally by logged-in users who think the functions might be some sort of expand/collapse function, not an editing function. I've just done it and so did someone else on the same article. Hopefully users will realise their mistake and undo it, as the two of us did. Nurg (talk) 10:35, 16 November 2012 (UTC)Reply
It used to be off by default, and I was glad of it. When I felt like wading into category setting, I turned it on. I sorta think it should be off by default. I'm thinking of minimum surprise and minimum unintended side effects, I guess. --Lexein (talk) 10:49, 16 November 2012 (UTC)Reply
I see no "+" or "-" next to categories, so I guess that it's still off for me. I expect that's because I have lost all javascript, as noted above. --Redrose64 (talk) 11:15, 16 November 2012 (UTC)Reply
It should be off by default, and a banner should be provided informing all users of the change. GiantSnowman 13:18, 16 November 2012 (UTC)Reply
I noticed that this morning when I logged in. Not a great idea to have it switched on by default IMO. I wondered what it did, so I clicked a minus on a category on this very page, only to find it removed it. If it's not broke, it doesn't need fixing... Lugnuts Dick Laurent is dead 14:25, 16 November 2012 (UTC)Reply
Having HotCat enabled by default can only cause detriment to Wikipedia. It is a great gadget, but leave it to people who know how it works to turn it on. Like Lexein above, I too turn it on from time-to-time – but leaving it off would be a whole deal better to prevent accidents from happening by unexperienced editors. Jared Preston (talk) 15:39, 16 November 2012 (UTC)Reply
  • I'm against this. It appears that there's not even a confirmation button; it just automatically saves your edit when you click on the minus sign. Too easy to do by accident — don't throw it at users who don't know it's there (like I didn't). --Trovatore (talk) 05:48, 17 November 2012 (UTC)Reply
    Yeah, that was a problem. It's been fixed, though the fix may be active right now only if you reload your browser's cache. (If you don't, it may take some time. The next time your browser decides to refresh on its own, you'll get the fix anyway.) Lupo 14:41, 17 November 2012 (UTC)Reply
    If one knows what it does, though, not having a confirmation can be fine. It's more when the thing is thrown at everyone that that becomes an issue... -— Isarra ༆ 16:04, 17 November 2012 (UTC)Reply
turning it on by default for all registered users seems to me like an exceptionally bad idea. doing so based on 4 (!) "support" votes in the proposal page seems excessive - one does not do something so radical (adding a single-click editing option that does not go through the editing screen and does not require a "save" button to every registered user, without so much as some "what does it mean" message to first-time users *is* radical) based on 4 "support" votes in a not-extremely-visible page.
however, the reason i write here is because i noticed that the proposal, that was approved by these 4 "support" votes, claimed that this gadget is enabled by default on pl wiki. i peeked in pl wiki, both with my account and as anon, as well as looked in the history or pl:mediawiki:gadgets-definition, and as far as i can tell, this claim is 100% false. this is not, and never was, enabled on pl wiki by default. i have no idea whether or not having a false claim part of the proposal has any implication on the validity of the "vote", but i wanted to note the fact that this false claim was there. peace - קיפודנחש (talk) 16:57, 17 November 2012 (UTC)Reply
"HotCat [ResourceLoader] | HotCat.js" is clearly present there. --Piotr Konieczny aka Prokonsul Piotrus| reply here 17:13, 17 November 2012 (UTC)Reply
But the [default] keyword is not, meaning it is not enabled by default for all editors. — Edokter (talk) — 17:19, 17 November 2012 (UTC)Reply
Ah, I see. My bad then, apologies for jumping to conclusion about the use there. I was sure I read that it was default there before, but I must have been wrong. Anyway, it was just something I mentioned in one of my vote comments, not the proposal itself. --Piotr Konieczny aka Prokonsul Piotrus| reply here 17:22, 17 November 2012 (UTC)Reply
then i am probably a complete idiot. i absolutely see it mentioned in the proposal itself. peace - קיפודנחש (talk) 03:54, 18 November 2012 (UTC)Reply
Mhm. Ok, I am blind those days. I guess I did. --Piotr Konieczny aka Prokonsul Piotrus| reply here 06:39, 18 November 2012 (UTC)Reply

To all people who complain about the woe of people using it - the discussion was announced in numerous places; IIRC it was an RfC and was mentioned in the Signpost report for ongoing discussions. Few people participated. But the few who cared voted to try it out. So unless you have data to show mass abuse have begun, the Cassandra option was not the one predicted nor chosen by the community. --Piotr Konieczny aka Prokonsul Piotrus| reply here 17:13, 17 November 2012 (UTC)Reply

Announcing my POV, I am a registered editor who suddenly discovered I had this tool and wondered where it came from. I am definitely a content person, not a technical person, when it comes to Wikipedia. Lately, I have been doing quite a bit of editing of pages with various categories associated with US military aviation.

I find the tool very handy (better for removing than adding categories). I would hate to lose it now that I've got it. Since I'm not technical, I wouldn't have gone looking for this tool. On that basis alone I Disagree with those who suggest that the addition be reversed.
As to the complaints that not enough editors commented to reach a consensus, It seems to me that the proposal was posted at the most appropriate place (although it might have been posted elsewhere and linked here -- I didn't even know there was a Village Pump (Technical) until a couple of weeks ago. There was an opportunity to comment.
I Agree that the early version made available, which made the edits automatically, was problematical. I was surprised that the result (deleting a category) occurred immediately when I first used it. The fact that this gave no opportunity to not add a page to my watchlist, mark the edit as minor, or enter a reason for the edit (for example deleting because WP:CAT More specific category in article). This no longer occurs, so I Disagree that it remains a reason to reverse the decision.
I did not have a problem with mistakenly deleting categories, although I Ageee this was a problem initially. When I saw the new little plusses and minuses appearing, I hovered over them, so I had an idea what would happen when I clicked on them, so things worked for me. Now that the bot takes you to an edit page, there is an opportunity to cancel, so I Disagree that it remains a problem.
I Agree that adding the bot with an inadequate announcement was not the best way to implement it. Is it possible to put an announcement concerning what is done on each Wikipedia Project's Talk Page? That would reduce the surprise and possibly attract more comments to determine what the consensus really is.
Apologies to all for bloviating.--Lineagegeek (talk) 18:03, 17 November 2012 (UTC)Reply
Re your comment "I would hate to lose it now that I've got it" - if the addition were reversed, HotCat would still be available to you, at Preferences → Gadgets (it's under "Editing", described as "(S) HotCat: easily add, remove, and change categories on a page, with name suggestions (example)") - it's been there since 21 March 2008. --Redrose64 (talk) 19:43, 17 November 2012 (UTC)Reply

As a user who is not constantly editing categories and does not want to see the ugliness of a bunch of +/-s all over the category line when reading articles, is there a way to turn this off at least on a user-level? —Mr. Matté (Talk/Contrib) 19:23, 17 November 2012 (UTC)Reply

Yes, at Preferences → Gadgets, deselect "(S) HotCat: easily add, remove, and change categories on a page, with name suggestions (example)" and click Save. Sorry, I should have responded to this post when I responded to the one immediately above. --Redrose64 (talk) 20:48, 17 November 2012 (UTC)Reply

During a typical edit-preview, the preview-notice has become so wordy that it can wrap and look sloppy, or unprofessional, for a typeset encyclopedia. I am thinking the preview-notice should be shortened, but do any automated programs or bots depend on the current wording? I propose the following change to a shorter message:

  • Currently:
    Remember that this is only a preview; your changes have not yet been saved! → Go to editing area
  • Proposed:
    Note this is only a preview; your changes have not been saved! → Go to editing area

The shorter form drops 3 words (omits: Remember, that, yet), but I am unsure if some automated software looks for those words when parsing an edit-preview HTML page. Anyway, whenever the preview-notice wraps onto 2 lines, it looks very sloppy (or unkempt) within the clean boxlines of the Monobook or Vector skins. The wrapping might be related to a user's window being set a few pixels more narrow than usual, so the wrap margin should also be set to align under the first word of the preview-notice message. Any thoughts? -Wikid77 (talk) 15:55, 16 November 2012 (UTC)Reply

Looks good to me, and if anyone is screen-scraping the preview message instead of the API, they should have their software broken. Legoktm (talk) 16:39, 16 November 2012 (UTC)Reply

"Yet" does mean something, whereas "Note" is unnecessary. I'd go for:

This is only a preview; your changes have not yet been saved! → Go to editing area - Nurg (talk) 21:00, 16 November 2012 (UTC)Reply

This is a preview. Your changes have not yet been saved! → Go to editing area
I might even suggest:
This is a preview.
Your changes have not yet been saved! → Go to editing area
—Trappist the monk (talk) 13:52, 17 November 2012 (UTC)Reply

I created new essay WP:PASTE to preserve the Monobook copy/paste symbols, but now I am concerned that removing those from the Monobook skin and using the drop-down Insert menu (with Javascript?) might be very disruptive to users who depend on the current format of the edit-mode screen. For instance, when the check-box "minor edit" was removed from the create-screen, then the tabbing between buttons changed from 5 to an annoying 4. Also, someone else complained that the "minor-edit" checkbox was being correctly used to create minor redirect titles, not possible to mark as "minor" any longer. Any thoughts about restoring the "minor-edit" checkbox to Monobook skin? Or stop other proposed changes? -Wikid77 (talk) 15:55, 16 November 2012 (UTC)Reply

Sorry what? The minor checkbox works fine for me in monobook. In fact, I'm marking this edit as minor. Legoktm (talk) 16:31, 16 November 2012 (UTC)Reply
And of course I would forget to actually check the box. Worked fine on the Sandbox (diff) Legoktm (talk) —Preceding undated comment added 16:35, 16 November 2012 (UTC)Reply
He means the checkbox is gone when a new page is created. It is still available when editing existing pages.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 16, 2012; 16:52 (UTC)
That was removed from all skins in MW1.19. If you disagree with that change, you can search bugzilla for anything relevant or perhaps add a new bug.
And nobody should be depending on a current format; if you are using some sort of automation, that is what the API is for. -— Isarra ༆ 17:10, 16 November 2012 (UTC)Reply
Two thoughts.
  1. Gnome and KDE went off the rails when they put a pretty UI ahead of utility- can we remember that the editor is primarily there to generate and edit content- the ribbons and bows and tight CSS are secondary to that.
  2. Editors who have poor eyesight do use the keyboard and rely on muscle memory; a change in tabbing order slows destroys an otherwise perfect edit
My personal bugbear is that over on Commons I have a totally different set of edit tools and tabs in Vector and Monobook- and for different tasks I have to change skin to get relevant work done. Can we please go back to good programming practice- soak test the changes and repair everything that has been freshly broken before doing a release. --ClemRutter (talk) 17:37, 16 November 2012 (UTC)Reply
creating a new page should never be considered a "minor edit". leaving the checkbox there allows people to do the wrong thing, so removing it can't be *all* bad.
you are correct that every change to the UI such as tabbing order can be disruptive, but if the corollary is that nothing can ever change in the UI, the end result is complete stagnation, which is (IMO) inferior to progress with occasional disruption.
of course, it is also very easy to go in the other direction and in the name of progress remove all stability and change the !@#$% thing so frequently, that users will never be able to rely on anything to be where they expect it to be.
so there is a balancing act here, between stability and progress. within this balancing act, my personal opinion is that eliminating the ability to mark as "minor" an edit that creates a new page is reasonable.
peace - קיפודנחש (talk) 19:21, 16 November 2012 (UTC)Reply

It appears that {{Divhide}} has stopped working (at least for me in Monobook). It used to generate a show/hide tag for collapsible boxes, but doesn't do that any longer. I'm not seeing any changes to the template, could changes elsewhere be impacting it? --- Barek (talk • contribs) - 17:39, 16 November 2012 (UTC)Reply

Note: I went to Special:Preferences to try other skins. In Monobook, that page now appears as a single large page, no longer tabbed sections as it once had. When I tried the Vector skin, the Divhide tag still worked and the Special:Preferences screen was back to having tabbed sections. So, it appears these are further symptoms from the changes to the Monobook skin mentioned in other sections above. --- Barek (talk • contribs) - 17:46, 16 November 2012 (UTC)Reply
...and now all is working again. Although not sure if it's an intermittent issue, or someone changed a setting back somewhere. --- Barek (talk • contribs) - 17:51, 16 November 2012 (UTC)Reply
There have been lots of problems in Monobook skin, many of them affecting javascript-reliant features, see #Style sheet changes et seq. --Redrose64 (talk) 18:16, 16 November 2012 (UTC)Reply

The Education Program extension for structured course pages for classes is now live. (It's actually been deployed for a few weeks, but unrelated platform updates introduced a critical bug that it took us a little while to fix.) Per the RfC on using the extension, it's now available for use by US and Canada Education Program, as well as whatever other courses the community chooses to use it for. See Special:SpecialPages#Education for the various features and lists of courses.

Admins now have the ability to create (and delete) institutions and courses, and to assign the user rights for "course coordinators" (non-admins who will be able to create and remove courses, mark people as instructors or volunteers, and use the rest of the extension features), "online volunteers" or "campus volunteers" (people helping out with courses, such as Online and Campus Ambassadors), and "course instructors".

I'll be beta testing it with one of the current Education Program classes, Education Program:University of Guelph-Humber/Currents in Twentieth Century World History (2012 Q4), as well as building up the documentation for course pages.--Sage Ross (WMF) (talk) 17:55, 16 November 2012 (UTC)Reply

Hotcat has stopped working for me; XP - IE8 - Compatability View off, I can see various discussions above but am still none the wiser...Thanks GrahamHardy (talk) 20:33, 16 November 2012 (UTC)Reply

IE on Win 7 gives me a warning that the page had errors. From the location given, which is in the site startup scripts (line 0, col 529, which is on a call to mw.getConfig()), I conclude that this must be the same cause as in bugzilla:42192. Nothing to do with HotCat, although it does have the effect that, since script startup in general fails, HotCat amongst other things doesn't work. Lupo 21:13, 16 November 2012 (UTC)Reply
I'll be patient and wait for a fix then, Thanks GrahamHardy (talk) 21:17, 16 November 2012 (UTC)Reply
Right now, I am in Chrome on Linux, and HotCat has appeared for me without my choice. Is it checked in your gadgets list? Chris857 (talk) 21:19, 16 November 2012 (UTC)Reply
It appearing is something else, see #HotCat gadget enabled by default above. But I guess if your browser reloads its cache, it'll be gone again due to this bug 42192. Lupo 21:24, 16 November 2012 (UTC)Reply
In fact, it has stopped working for me, too, in Firefox. Firebug indicates in the console indeed "TypeError: mw.getConfig is not a function", so it's definitely bugzilla:42192. I'll go mark it as high priority. Lupo 21:22, 16 November 2012 (UTC)Reply

A fix for this issue has been deployed - please let us know if the problem persists. Max Semenik (talk) 23:09, 16 November 2012 (UTC)Reply

I had a request today from someone who works in hard-copy nanoscale printing on metal. He works on projects in the spirit of the Long Now Foundation which tries to approach humanity on a 10,000 year scale. He wants to print ALL of English Wikipedia onto a small nickel plate using a chemical process that his company developed. A hard-copy backup. In order to do this he wants a .pdf file with every article on English Wikipedia. I pointed him towards data dumps and he said .xml files didn't work for his process as he needs to convert images of article pages to a bitmap format. Print to .pdf is not available for all of English Wikipedia (capped at 500 articles per book); also .pdf files would include images, not all of which are cc licensed. I'm not sure exactly where to point him, but as this project seems to be of particular cultural, historical, and technological interest I wanted to pass along his information. I'm in touch with him directly and can contact him if anyone has ideas. Ocaasi t | c 03:32, 17 November 2012 (UTC)Reply

That sounds like a really cool project. On the technical side, is he aware how large a .pdf file would be (even if it just included articles, no images)? The raw text of just articles is 8.8GB compressed (I'm looking at enwiki-20121101-pages-articles.xml.bz2), which would be much much larger as a .pdf. Is there another way we can give the text? Legoktm (talk) 03:41, 17 November 2012 (UTC)Reply
He is aware of the size of such a .pdf and he's willing to purchase hardware specifically for this project if necessary. Ocaasi t | c 05:38, 17 November 2012 (UTC)Reply
Exporting something like that would need to be done from the backend; however, one could potentially generate an automated process to download information as PDF, either utilizing the 500-page book generator, or by converting the printable versions of each article individually. Of course, working with over four megapages tends to cause problems. TortoiseWrath (talk) 04:56, 17 November 2012 (UTC)Reply
Trying to export Wikipedia 500 pages as a time is a horrible idea. It also doesn't need to be done via the backend. You could easily take a database dump, strip all the xml, add nice page headers, and export as a pdf. Legoktm (talk) 05:04, 17 November 2012 (UTC)Reply
Sure, but where are the images going to come from in that scenario? The need for images breaks all sane ways of attempting something like this. TortoiseWrath (talk) 05:08, 17 November 2012 (UTC)Reply
  • A couple notes.
    • This has already been discussed a few years ago. Main thread: [Foundation-l] Long-term archiving of Wikimedia content (I see that it was the Long Now foundation even then).
    • I don't understand, do they really want to print images as well? I'd suggest to start with text only, it would already be quite a big achievement (it's something like ten billions characters). In any case, I suppose they have some specifications on how many images they could include and at what resolution?
    • Why is copyright of the images a problem? Do they want to distribute this thing?
    • Why PDF? If raster images are needed, isn't some other format possible/better?
    • If they also want infoboxes and so on, the best approach would probably to ask/hire the Kiwix developer Kelson to produce an HTML backup as they want it, and then use some software (which must exist) to convert HTML to raster format.
    • wikitech:Offsite Backups needs editing.
Nemo 13:21, 17 November 2012 (UTC)Reply

What would the point of this even be? This isn't like working on stable versions for a reliable CD-ROM version; this would just be a data dump of whatever crap happens to be out there at some moment in time. At any given moment in time there are dozens, if not hundreds or even thousands, of instances of blatant vandalism and glaring inaccuracies in some articles, somewhere out there. Why would we want to preserve that? Sounds like everyone is too focused on whether we can do it, rather than whether we should. Kafziel Complaint Department: Please take a number 05:37, 17 November 2012 (UTC)Reply

It's proof of concept with regards to his company's technology, for one. I believe the thinking about our increasingly digital civilization is that much of our data might be unrecoverable thousands of years from now. So, this is a thought-piece, at the least, and potentially a useful intentional artifact that would be durable on timescales we rarely consider. Anyway, he's invested in making this happen, so I think the why is settled for him. Ocaasi t | c 05:44, 17 November 2012 (UTC)Reply
The why may be settled for him, but I'm saying helping him with his proof of concept isn't our problem. Let on that something like this is going on, and there will be a flood of sneaky vandals trying to get their name into the most obscure articles out there. And we'll be rewarding them for it. Brilliant. Kafziel Complaint Department: Please take a number 05:52, 17 November 2012 (UTC)Reply
What I'm saying is, printing something like this would make a hell of a lot more sense. Kafziel Complaint Department: Please take a number 05:58, 17 November 2012 (UTC)Reply
It's a proof of concept. There's no reason it needs to be practical. Having a copy of the CD selection that can only be read with a scanning electron microscope doesn't really make that much more sense than having a copy of the entire Wikipedia, anyway. It probably makes less sense, since it would be, like, one square centimetre, which would make it easy to lose. ;)  — TORTOISEWRATH 17:22, 17 November 2012 (UTC)Reply

Ocaasi, thanks for opening up this discussion. I am the guy that is looking into printing all of Wikipedia onto 6-inch nickel discs. We have worked with the Long Now Foundation before and share many of their beliefs. We are thinking floods and earthquakes, we are thinking EMP blasts from nuclear explosions or solar flares. Even though the articles are not all perfect, we believe they should be documented in an analog system that is not dependent on relatively arbitrary, proprietary software. Imagine how many people thought that the stone cutter of the Rosetta Stone was wasting his time (this is a blatent simplification, of course). Without him, we would not have a lens through which to view the later Ancient Egyptian history. And because of the monumental effort of everyone that contributes to Wikipedia, a physical copy to cement its contents in metal for the next 10,000 years is not much to ask. These contents are far more interesting than the actual contents of the Rosetta Stone. At an average of two pages per article, we are estimating the final product to total 270 discs, each about 1mm thick. The purpose is in part to contribute a permanent record for the Wikimedia Foundation and in part to show the world what we can do. There is no other financially practical and efficient way to achieve this other than with our technology. A previous technology of ours would take 10,000 times longer. We are not looking to have the Wikipedia staff do all the work in providing us with the database in PDF format. I only asked because of the current feature that allows for a PDF to be created out of a single or multiple articles. We are not wedded to any particular format and it may be that the images do not have to be included if it is impractical. In the end, what we need is TIFF images or BMP images, and we can get that from a PDF. What we do not have access to is a way to organize the English database in some sort of arbitrary method such as alphabetical. Kafziel, you bring up several interesting points. What exactly is the Wikipedia Version 1.0 Torrent Project? (this) jakubsvec001 — Preceding unsigned comment added by Jakubsvec001 (talk • contribs) 17:09, 17 November 2012 (UTC)Reply

Wikipedia 1.0 was a project to collect stable versions of good articles that could be put on DVD and used in schools. I think they were first distributed in 2007. You can learn more about the contents at http://schools-wikipedia.org/ and you can download the current 2.9GB torrent here. Plenty impressive enough for a proof of concept, and the content is actually reasonably reliable. Kafziel Complaint Department: Please take a number 19:53, 17 November 2012 (UTC)Reply
First, there's no such thing as a "Wikipedia staff".
What do you mean that you don't have a way to sort the English database alphabetically?
If you need raster images, then your problem is parsing the pages, which is what MediaWiki does: producing a good HTML dump is not trivial. On the contrary, there's plenty of tools to produce images from the HTML. There's already an HTML dump. Without images, compressed, it's 10 GiB.[10]
I doubt the PDF export is quick or practical enough for such an amount of content (it's too slow, as you can try yourself; it includes print optimizations which are probably useless to you; it includes things you're not interested in; it prints images in a resolution which is surely pointless for you, making the PDF horribly huge)... but you can ask the PediaPress guys if you want to try.
Finally, your guesstimate of the size of Wikipedia seems extremely rough, so you could at least try Wikipedia:Size in volumes if you don't want to read the links I added above. Regards, Nemo 18:17, 17 November 2012 (UTC)Reply
Some time ago, we conducted a few experiments to evaluate how much effort it would be to create a printed version of the whole english Wikipedia. There are quite a few technical issues that still have to be solved, but a rough guess would be about 3 months of rendering time. Of course, rendering could be parallelized to a certain extend, but creating the pdfs for complete en.wp is still an enormous effort. It's a very nice problem from a technical perspective, but it requires a lot more thinking when you want to make this usable (and useful) for a human being. Ckepper (talk) 19:18, 17 November 2012 (UTC)Reply

I can do that and everything is already there. I used to deal with whole dumps of Wikipedia to generate ZIM files for Kiwix. Here, as example, a demo file of the "Wikipedia" article in Korean. Unfortunately, I do not own the hardware necessary to do it for the whole Wikipiedia in English (but no problem for the others). Kelson (talk) 20:02, 17 November 2012 (UTC)Reply

I am not a technical person and I do not know exactly what questions to ask. For this reason, I am looking for a better perspective on this problem.
Kelson, I think that this is what we are looking for. Ultimately, we need something that can be converted into a TIFF file. A png file may work but I'll have to check. What would you propose would be the next step to first organize all the data alphabetically, then convert each article into an image file in batches of 10,000 or 50,000? From there, we can feed them into the printer. — Preceding unsigned comment added by JakubSvec001 (talk • contribs) 20:49, 17 November 2012 (UTC)Reply
It's perfectly possible to get files in TIFF format, although this really needs more mass storage than PNG. I suggest a meeting on IRC or a phone-call to discuss about the details. Kelson (talk) 12:54, 18 November 2012 (UTC)Reply
My email is jakubsvec001@gmail.com. We can continue from there, perhaps. — Preceding unsigned comment added by Jakubsvec001 (talk • contribs) 17:46, 18 November 2012 (UTC)Reply
Did you see my reply to your question, above? Kafziel Complaint Department: Please take a number 18:46, 18 November 2012 (UTC)Reply
Yes, Kafziel, I did. Sorry for not replying directly to it. I like the idea of using a verified Wikipedia. That kind of effort is monumental in its own right, but it is just not big enough. In analog images, this would not even cover half a disc. Personally, I enjoy the fact that Wikipedia is not necessarily 100% accurate. I particularly like your quote from a previous article about Stephen Hawking being a "dirty lying cripple" or something like that. Jakubsvec001 — Preceding unsigned comment added by Jakubsvec001 (talk • contribs) 19:27, 18 November 2012 (UTC)Reply

This is a great and important project; I'm glad you and your team are pursuing it, Jakubsvec. Working with a kiwix dump and with Kelson sounds like an excellent idea. I would recommend including images if you can, including any 'warning templates' at the top of articles to provide context, and adding an index and page numbers for finding things within the collection. This is only a bit more post-processing and makes the result vastly more usable. – SJ + 20:43, 18 November 2012 (UTC)Reply

Thank you, SJ. Jakubsvec001

Special:Statistics (and its sister pages in other languages) have no interwiki links. Would it technically be possible to add those? Navigating to the individual language versions of Special:Statistics via e.g. Wikipedia:Statistics is imho clumsy for an at-a-glance comparison of the raw statistics tables. --87.79.111.52 (talk) 04:18, 17 November 2012 (UTC)Reply

English special page names, including Special:Statistics, work if you type them into any language version of any Wikimedia Foundation project (and probably just about any other site running MediaWiki). For example, de:Special:Statistics takes you to the statistics page in German, even though the German title is Spezial:Statistik. Graham87 09:51, 17 November 2012 (UTC)Reply
"Complete list of Wikipedias" at the bottom of Special:Statistics is a link to meta:List of Wikipedias. The "Edits" column there is a link to Special:Statistics for that language. You can view the page in English by manually adding ?uselang=en to the end of the url. PrimeHunter (talk) 12:42, 17 November 2012 (UTC)Reply
mediawiki:statistics-footer does not propogate parsing metadata to the special page - so no, not currently. The special page in theory could be changed, one would have to file a bug (and convince a dev) to make sure a change. Bawolff (talk) 20:40, 17 November 2012 (UTC)Reply
Ah, ok. Thanks for all the replies. I don't think I'm going to file a bug report since there is no pressing need or anything. But at least this question is now on the record in the VPT archive. --78.35.255.194 (talk) 04:43, 18 November 2012 (UTC)Reply

I recently noticed a comment here by an editor who does not have a link to his user or talk pages in his signature. I intended to go post a note on his talk page inquiring about it. However, when I click on the talk link in the page history, I arrive at User_talk:Ɱ, which informs me that "User account "Ɱ" is not registered." I get the same result when copying his username into the search bar. Obviously since the user in question is editing and showing up in the page history with a username, he has a registered account - but I can't figure out how to contact him. I also can't see his contributions list. However, both user talk and contribs show up normally in pop-ups when I hover over his username. Any ideas? Nikkimaria (talk) 12:59, 17 November 2012 (UTC)Reply

The user concerned is ɱ (talk · contribs) (see Unicode Character 'LATIN SMALL LETTER M WITH HOOK' (U+0271)), which is not the same character as Ɱ (talk · contribs) (see Unicode Character 'LATIN CAPITAL LETTER M WITH HOOK' (U+2C6E)). --Redrose64 (talk) 13:10, 17 November 2012 (UTC)Reply
Hm, when I UTF8-encode the ɱ letter to %C9%B1 on my Chrome browser and I hit enter it first displays the correctly decoded letter but then just sporadically seems to turn it into its upper-case counterpart, failing to load the user page. I do not see this behavior with Firefox so it might be a Chrome bug. Nageh (talk) 13:37, 17 November 2012 (UTC)Reply
It's apparently an inconsistency in the system to automatically capitalize the first letter in usernames. Some servers capitalize ɱ (LATIN SMALL LETTER M WITH HOOK) to become Ɱ (LATIN CAPITAL LETTER M WITH HOOK). Other servers don't capitalize. It only works without capitalization. The valid talk page url is http://en.wikipedia.org/wiki/User_talk:%C9%B1 (small letter). Some servers keep that url. Other servers redirect it to http://en.wikipedia.org/wiki/User_talk:%E2%B1%AE (capital letter) which gives 'User account "Ɱ" is not registered.' For example, I get the error message on mw44, but mw47 works for me. PrimeHunter (talk) 14:07, 17 November 2012 (UTC)Reply
Interesting, thanks. The user name is quite a problem. I clicked the diff given in Nikkimaria's first sentence above, and it showed an edit by the user. Clicking the user's talk link in the diff happened to work, but clicking the user's contribs link failed (because it was provided by a different server which was confused about "Ɱ"). The user has already been politely asked to provide a link in their signature (per WP:SIGLINK), in a comment dated 14 September 2012 on an old revision of the user's talk, which can be seen using a URL with PrimeHunter's trick of percent encoding the UTF-8 bytes: http://en.wikipedia.org/w/index.php?title=User_talk:%C9%B1&oldid=521774934 (also on 30 August 2012, as can be seen here). Johnuniq (talk) 01:46, 18 November 2012 (UTC)Reply

LOL! I just left the user a message about their signature, with a link to this discussion. I previewed the edit, and it was good (it must have been the correct page because I saw a custom edit notice for the user). When I clicked 'save', my message ended up on the wrong page (at User talk:Ɱ which is at this URL). I have to go now, and would be glad if someone could delete my page and try putting the notice on the correct page. The current situation (where editors cannot communicate with the user) needs to be fixed. Johnuniq (talk) 01:56, 18 November 2012 (UTC)Reply

I have redirected User talk:Ɱ to User talk:ɱ but even if this helps (not sure about that), it only solves a part of the problem. At least it's the only account at Special:ListUsers/ɱ (bad servers show wrong accounts for that link), except for a blocked account with no edits. Other wikis and namespaces may have the same problem. For article space, ɱ and Ɱ are different pages (but may be treated as the same page on bad servers). They both redirect to M with hook so the confusion means less here. PrimeHunter (talk) 03:09, 18 November 2012 (UTC)Reply
Well, I can see the user talk page now - still can't see contribs, and hitting "edit" on talk goes make to the other character (ie. the redirect page). Nikkimaria (talk) 03:35, 18 November 2012 (UTC)Reply
The redirect seems to have helped some, as I was able to leave a message there pointing the user to this discussion. We'll see how he/she responds. Also note that it breaks email as well, as Special:EmailUser/ɱ gave me the error message "Non-existent or invalid username for recipient." jcgoble3 (talk) 05:08, 18 November 2012 (UTC)Reply
The redirect sometimes works, sometimes not, it seems to depend upon the server; when it doesn't work it goes right back to itself, just as if WP:VPT consisted of #REDIRECT [[WP:VPT]]. The solution as I see it is that ɱ (talk · contribs) should be renamed to something beginning with a letter universally recognised as uppercase; this might even be Ɱ (talk · contribs). I don't know the details of WP:CHU - for instance, does it need to be filed by the person whose name is to be changed? Can we force somebody to change their name if they don't want to? --Redrose64 (talk) 10:50, 18 November 2012 (UTC)Reply
Thank you for notifying me of this discussion, jcgoble3. I am aware of all of your problems, as I myself have all of them and more, especially because I primarily use an unstable version of Chrome called 'Canary', which refuses to accept certain characters occasionally. When working on my userpages, I more often than not end up on the corresponding userpage of this - Ɱ (talk · contribs) and occasionally have created userpages for Ɱ (talk · contribs) as an editor mentioned in an above comment. I sincerely apologise for inadvertently causing much confusion. The only foreseeable solution would be for me to change my username, a switch that I am willing yet not ready to undergo, having not yet thought of alternatives.--ɱ (talk) 15:02, 18 November 2012 (UTC)Reply

There have been problems with the search index lagging behind for about a week, as reported above #Search_list_not_updating
Search within articles has now totally broken (XP IE8 Vector) The pop ups of article titles including the term still appear, and still work, but a search for articles containing the search term produces no matches - even when I know there are dozens. Arjayay (talk) 13:03, 17 November 2012 (UTC)Reply

Appears to be working again - albeit still out of date - Arjayay (talk) 14:15, 17 November 2012 (UTC)Reply
Not working here (Firefox 16.0.2 Xubuntu Monobook). A search for "Sarah" notes that there is a page named "Sarah" but there were no results matching the query. Thryduulf (talk) 15:41, 17 November 2012 (UTC)Reply
Concur, it's disappeared again (XP IE8 Vector) - Arjayay (talk) 15:45, 17 November 2012 (UTC)Reply
IE7 and IE8 users: Could you please describe the exact steps for this? On which exact page (I assume en.wikipedia.org)? Do you press the Enter key, or do you click the magnifier symbol with a mouse? Does clicking the suggested text that appears below the search box work to complete the search? This might be https://bugzilla.wikimedia.org/show_bug.cgi?id=42082 which is already fixed in the codebase, but not yet available (deployed) on the Wikimedia servers. This still doesn't explain why Thryduulf sees that with FF16.0.2 though... --Malyacko (talk) 17:14, 17 November 2012 (UTC)Reply
(edit conflict) That's strange. A search for "Sarah" takes me directly to Sarah. (Windows 7; Firefox 16.0.2; Vector)  Hazard-SJ  ✈  17:16, 17 November 2012 (UTC)Reply
Looking at the Server Admin Log, "restarting lsearchd on all eqiad hosts" and seeing messages like "PROBLEM - Lucene on search1016 is CRITICAL: Connection refused" on the wikimedia-operations IRC channel I assume that this is the reason for these current problems. --Malyacko (talk) 17:43, 17 November 2012 (UTC)Reply
Currently working again - but to answer User:Malyacko's earlier questions - yes en.wikipedia.org
As explained above, the pop up links worked, both in the box with a magnifying glass and the alternative options below. However every search for articles containing the search term produced no matches. The same search [11] during the brief re-appearance this afternoon prduced 106 or 107 matches, and it now produces 90. Arjayay (talk) 21:26, 17 November 2012 (UTC)Reply
  • Wikisearch working again, multiple times: Seems to be fixed, and updated for current articles, as a wikisearch for "colloidal probe" reports "Results 1–20 of 46 for colloidal probe" which includes new science article "Colloidal probe technique" from 11 November 2012. Searching for "Sarah" (click "[Search]") reports 54,718 for Sarah. -Wikid77 (talk) 23:44, 17 November 2012 (UTC)Reply

Moving the coordinates display to the upper right-hand corner of the window was a bad move. Please move it back where it was previously. In the Modern skin, the coordinates display is illegible because it is displayed on a dark-blue background. •••Life of Riley (T–C) 18:12, 17 November 2012 (UTC)Reply

Weren't they always in the upper right-hand corner? That's where I have always seen them. Someguy1221 (talk) 19:46, 17 November 2012 (UTC)Reply
The coordinates were not previously at the very top; they about an inch down—on the gray bar of the Modern skin. Someone moved the display to the very top of the page. •••Life of Riley (T–C) 20:04, 17 November 2012 (UTC)Reply
  • Weird... I changed the top from 5em to 0.1em because it was to low, now it is to high. I think some banner CSS is interfering with coordinates positioning. Changing to 6.1em now. — Edokter (talk) — 10:56, 18 November 2012 (UTC)Reply
Now it is good again. Thanks for the fix! •••Life of Riley (T–C) 17:17, 18 November 2012 (UTC)Reply

When I click the edit button for "Origin of the Wisdom of the Golden Rule" at http://en.wikipedia.org/wiki/Golden_rule I get taken to the edit page for the section underneath "Antiquity". Why is this happening? The section I'm trying to edit also disappears when I'm logged in or use a proxy. I had no problem editing it yesterday. http://www.youtube.com/watch?v=ADNTfJ6vStM&feature=youtu.be — Preceding unsigned comment added by 108.176.135.86 (talk) 19:28, 17 November 2012 (UTC)Reply

You can't edit that section because it doesn't exist, having been removed from the article yesterday. That you are still seeing it at all means the old version is still showing in Wikipedia's server cache. Editors and readers look at different caches IIRC, which is why this only happens when you are logged out. Someguy1221 (talk) 19:43, 17 November 2012 (UTC)Reply
Note, i referenced this comment on bugzilla:38879 as it seemed relevant [There is a good chance they are separate issues though. Honestly intermittent issues with squid purging aren't that uncommon]. Bawolff (talk) 20:27, 17 November 2012 (UTC)Reply

This is not new, nor related to any recent changes or other issues. For at least the last year, I've been trying to get Reflinks to show up in my Toolbox. The User Script looks like it should. My preferred skin is Modern, but, one at a time, I've tried it in Monobook, Vector and Modern. I've also tried loading it on the common.js But I never see it in the Toolbox. Right now, I've got the User Script in all four of those .js I'm on Windows XP, Firefox 16.0.2 - what am I missing? Is Reflinks not supposed to be in the Toolbox? — Maile (talk) 23:44, 17 November 2012 (UTC)Reply

You have spaces instead of newlines in all your .js files. Copy-paste the code from User:Dispenser/Reflinks#User script to User:Maile66/common.js if you want it to work in all skins. There should be 8 lines and not one long line. PrimeHunter (talk) 00:36, 18 November 2012 (UTC)Reply
More specifically, any instance of // causes the rest of that line to be treated as a comment (indicated by the syntax highlighter as green italic text) and thus ignored. Since the line begins with //, the whole thing is treated as a comment; you must insert a newline to end the comment and return to code. jcgoble3 (talk) 00:45, 18 November 2012 (UTC)Reply
Ta! Da! What you all were looking at WAS a copy and paste of the code from the above Reflinks page. For some reason, when I clicked on Save Page, it made it all one line. (Same thing happens if I insert an infobox into a page) I inserted manual carriage returns to break it into separate lines, and it works now. Thanks for the help. — Maile (talk) 00:52, 18 November 2012 (UTC)Reply
It sounds like your browser has a problem. Does it happen when you are logged out? Does it happen when you preview a copy-paste, or only when you save? Do you insert infoboxes by copy-pasting code from the documentation page? PrimeHunter (talk) 01:10, 18 November 2012 (UTC)Reply
I'm never logged out of Wikipedia. My browser has multiple issues with Wikipedia, since the changes that happened sometime last Spring. 2012 This is but one of the issues. And my Firefox has undergone multiple upgrades since the first occurrence, so it doesn't matter which version of Firefox I've used. This happens on the Preview. If I save without a Preview, it still happens. Have a look at User:Maile66/Person in the Edit screen. I did that as a copy and paste from Template:Infobox person - the version under the "Blank template with basic parameters". Copied. Pasted. Saved. Conversely, if I copy an infobox from an existing article, replacing the info therein to suit my article, this collapsing never happens. It's when I copy from a Wikipedia Template page.
PrimeHunter, I think you hit on something. I logged off and did this copy and paste on a different blank page. It pasted exactly like it was supposed to and did not collapse the infobox. — Maile (talk) 02:00, 18 November 2012 (UTC)Reply
And since I know the next question is "What gadgets do you have checked?", I unchecked wikEd. The infobox pastes and saves perfectly without that checked. So, that gadget is the culprit. — Maile (talk) 02:04, 18 November 2012 (UTC)Reply
I have tried to enable WikEd and now it also happens for me when I copy-paste something from a rendered page with pre tags, for example the below two-line example. In my tests it only happens for pre tags. PrimeHunter (talk) 02:18, 18 November 2012 (UTC)Reply
This is line 1.
This is line 2.
Yep. It's probably the pre tags. I've only experienced this with infoboxes and with the Reflinks user script. When I looked at that User Script in the Reflinks Edit window, it has pre tags. If I copy the script without the pre tags, and paste it, then it looks exactly like it should. — Maile (talk) 02:35, 18 November 2012 (UTC)Reply
Then this should be reported at User talk:Cacycle/wikEd. Note that Cacycle can sometimes take a while to respond to bug reports, so don't expect a quick fix. jcgoble3 (talk) 04:46, 18 November 2012 (UTC)Reply
Bit belated, but I sleep by the British clock. Anyway, it's not crucial that there be eight lines - only three of the newlines are critical, and as noted above, they are the ones at the ends of the lines containing the end-of-line comment marker //. If a line does not contain the // marker, the following line may be joined to it, so you could lay it out as follows:
// Add [[WP:Reflinks]] launcher in the toolbox on left
addOnloadHook(function () {addPortletLink( "p-tb",     // toolbox portlet
 "http://toolserver.org/~dispenser/cgi-bin/webreflinks.py/" + wgPageName + "?client=script&citeweb=on&overwrite=&limit=30&lang=" + wgContentLanguage, "Reflinks"  // link label
 )});
which is four lines. The presence or absence of the leading spaces is also stylistic. --Redrose64 (talk) 10:08, 18 November 2012 (UTC)Reply
Yeah, but as noted by Jcgoble3, this probably should be reported as a wikEd bug. I've unchecked wikEd as a gadget for the time being, to do some other testing of my own. I've been having some funky issues the last six months or so, and I'm thinking they might also be wikEd. I've posted about them before here on the Pump, and got no response. I need to do some citation editing and multiple other things before I can prove or disprove the connection to wikEd. Off the top of my head, the most annoying issues are:
  • Spacing (inconsistent) - either one too many, or one not enough - seems to trigger malfunctions on insertions. To correct that, I either have to delete an extra space and put it up against the word to the left of it, or add an extra space. If one of those methods works, the other doesn't. And there's no consistency on the why of it.
  • Inserting a link from the icon on the Toolbar - sometimes it works, sometimes it's the Spacing issue
  • Inserting a citation from the drop-down Template menu in the Toolbar (Provelt is not affected by this).
  • Sometimes it works - sometimes it's the the Spacing issue
  • Sometimes it jumps and inserts the citation to the left of the "==" at the section heading
  • Paste - sporadic issues with Spacing, one too many or one not enough
  • Template:DYKproblem - This template has pre-tags. Spacing issue and consistent. This is put on a user's page to refer back to a nomination that has questions. Ideally, it automatically adds the section header and puts a message below that. In reality, it erroneously adds a space or two to the left of the section header. The work-around is to insert the template. Then insert my cursor in front of the template, even though I see no space there, and hit the Backspace twice.
  • Deleting characters/text (consistent issue) by tapping the keyboard "Delete" key . The first one or two deletions happen where they should - then it jumps to elsewhere on the page and deletes in another place.
There are possibly more, but these are the ones that have been irritating and happening on everything I've been editing for months.— Maile (talk) 16:55, 18 November 2012 (UTC)Reply

I have just posted this entire thread at User talk:Cacycle/wikEd to get the dialogue started on the bug. — Maile (talk) 17:10, 18 November 2012 (UTC)Reply

Status: the database server was restarted, tools should be working. Please report again if they are still down. Please update this line as needed.

Is there a problem with the toolserver? A number of tools I use that reference this do not appear to be working at the moment.--Traveler100 (talk) 13:01, 18 November 2012 (UTC)Reply

Same here. All of my favorite tools don't work. Was just about to start a section like this. Hope it isn't those severe server problems or replication lag like last time. 13:13, 18 November 2012 (UTC)
UTRS is down too - database problem. Secretlondon (talk) 13:25, 18 November 2012 (UTC)Reply

No idea yet what the problem is, but it has been announced to toolserver-l [12] which is where it needs to go. I can confirm there is some issue. We'll have to wait for the toolserver admins to diagnose it. — Carl (CBM · talk) 13:42, 18 November 2012 (UTC)Reply

The database server was restarted around 14:30UTC. This has restored some tools, at least. Please comment again if other tools are still down. — Carl (CBM · talk) 14:46, 18 November 2012 (UTC)Reply

What is the hardness of thrust collar and for integral shaft with collar,how it is made ie specially hardened or not ? — Preceding unsigned comment added by Aakkan (talk • contribs) 19:01, 18 November 2012 (UTC)Reply