Wikipedia:Village pump (technical)/Archive 85

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 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, 216

Diff shows amendment but page text doesn't

See this diff; I've added a section anchor so that it goes to the "Wh" section. If I look down among those, I see this:

Station (Town, unless in station name)	Rail company	Year closed
Whitchurch Halt	GWR	1959
Whitchurch South (Hampshire)	GWR	1960
White Bear	Lancashire and Yorkshire Railway & Lancashire Union Railway joint	1960

However, an examination of the diff at the very top of the page shows that I changed the second of these from [[Whitchurch (DN&S) railway station|Whitchurch South (Hampshire)]] to [[Whitchurch Town railway station|Whitchurch Town]] (Hampshire) so this row should show as:

Station (Town, unless in station name)	Rail company	Year closed
Whitchurch Town (Hampshire)	GWR	1960

What's going on? --Redrose64 (talk) 18:02, 3 February 2011 (UTC)

I purged the page and it's fine now. Gary King (talk · scripts) 19:53, 3 February 2011 (UTC)

Performance synergism gives amazing performance

Nearing the end of January, and the performance issues are really reaping major synergistic benefits. As you might know, that old, archaic essay "WP:Don't worry about performance" had become a negative mantra, casting a cloudy chill on improving performance issues. As part of the "Performance Resistance Movement", I have done the exact opposite now: to focus on performance in my spare minutes around Wikipedia. While re-writing some string-handling templates to avoid the 40-level expansion nest limit, I have again discovered:

• Performance synergy: Improving just a few aspects, of total performance, will create a synergy which produces other major improvements. I wrote {{strlen_quick}} to focus on using only 5 expansion levels (rather than 9-to-14 deep); however, in the process, I discovered ways to make it 2x times (TWICE) the speed of the "fully optimized" {str_len}, as it runs 12x times shorter. An article now can use 37,000(!) instances of {strlen_quick}. An effort to make {Italic_title} 4x times faster (such as with "(film)" suffix) has synergized as 100x(!) faster. The synergism works that way: start trimming a few if-else branches and end with a template 12x shorter, or 100x faster, than before.
• POV-pushing is overcome by multiple POVs: The cure for POV-pushing seems to be to allow multiple WP:POV forks (not delete them). Example: all algorithms for getting string-length counts had been deleted down to one POV, which used binary search of strings. I resurrected the other deleted variations, and thereby found techniques to transcend the one remaining POV method, with a hybrid POV method, running 2x times faster and 12x shorter. This concept was formalized in the Strategy Wiki, to have an Arab-POV version of article "Palestine" to overcome systemic bias in the so-called NPOV article. Meanwhile, that concept has led to massive improvements of string templates. The whole idea of POV-forks can be seen in the crucial Recovery of Aristotle from the Arab world, which had kept accurate texts of Aristotle, beyond those censored by the Church. As Pliny said, "There is always something new out of Africa."

Performance synergism will "bootstrap" to higher synergism: by improving the performance of string templates, they can be used in lists of string data containing 5,000 examples on 1 page, to analyze ways to further improve those string templates and others. I have discovered simple ways to streamline {Cite_web} and {Cite_book} to allow over 1,000 references within a separate list page, replete with the COinS metadata. We could even have a "references-population" template, which supplies current sources to multiple articles, all sharing from the same large, central {Cite_web} list, because improving performance had made keeping a large central template of current sources possible. The task began as a focus on improving template performance, and then led to the epiphany that POV forks are the solution (not the problem), while leading to a way to maintain current WP:RS sources within numerous articles at one time. Amazing performance synergism. -Wikid77 (talk) 12:58, 30 January 2011 (UTC)

Let me be the first to say that I don't really understand the connection between the Israel-Palestine conflict, and string processing templates... :D But let me also be the first to congratulate you on these performance enhancements.

You might want to read the recent wikitech-l thread on WP:PERF; I think it you'll find it interesting. Happy‑melon 13:42, 30 January 2011 (UTC)

I guess the credit should go to 2006-2007 User:Polonium and others, for the alternate string-length algorithms. I had learned in college that performance can often be improved perhaps 5x faster (re: Donald Knuth), but the template speed increases of 12x, 100x or 1,000x faster are still a shock to me. Also, using many large parameters in a template consumes the "post-expand include size", so reducing a numeric formula parameter by using {#expr: <formula>} can shrink the post-expand or argument sizes as perhaps 5x smaller. I was stunned when {strlen_quick} reduced the post-expand by 12x, increasing capacity from 2,900 instances to allow 37,000 uses of {strlen_quick} per page! The other string algorithms had been deleted, or rather redirected, so there was only one POV for how to check string lengths. I guess the Strategy-Wiki issue for an Arab-POV fork of article "Palestine" would reveal insights not found in the main article, just as the faster string algorithms were gone from the main {str_len} template. A classic case of "POV funnel" is the Amanda Knox case, where many Europeans did not understand how she is in major TV news in America, every few months, as "will she get a fair re-trial and be set free" rather than wondering what motive for killing her flatmate of 6 weeks. The MoMK article was reduced to omit Knox's "POV-boring" background as a guitar-playing, honors student who called her roommate about their Halloween costumes the day before the murder. See, the POV-boring details are what made the case notable in the U.S. as why would a "straight-A" student, who sings with guitar, work 7 jobs in Seattle to pay her way as an exchange student in Italy, then want to kill her British roommate of 6 weeks (whose rent money vanished) but leave no hair, fingerprint or DNA evidence, unless she was hit by police to give a false confession as she testified? Understandably, some European users always removed those boring details as insignificant, as WP:UNDUE POV-boring text compared to other details. Only when an article can focus on the POV-boring concepts of a "huggy bookworm" whose new friend died, can readers understand why millionaire Donald Trump advised boycotting Italy until Knox is freed. Perhaps that focus is similar to a Arab-POV article about Palestine, where seemingly POV-boring or only-an-Arab-would-care details are being omitted, but I'm not sure there. For checking string-length, the better solution was in the deleted (or redirected) WP:POV fork templates which had faster, shorter algorithms. Having multiple pages about an issue can lead to a better understanding of the all-encompassing (encyclopedic) viewpoints. That's the multi-template connection to multi-POV Israel-Palestine articles. -Wikid77 23:49, 30 January 2011 (UTC)

Please stop saying synergy. It makes me retch. OrangeDog (τ • ε) 17:46, 30 January 2011 (UTC)

Perhaps I should say that performance improvements are a "win-win game" (!) where the "pie gets bigger" rather than users fighting over the pieces of the pie?!?! -Wikid77 23:49, 30 January 2011 (UTC)

Oh please, enough! I have to listen to that kind of b/s speak all day long! We need to realign our white space initiatives on a going forward basis. – ukexpat (talk) 16:36, 31 January 2011 (UTC)

• Anyway, more progress: fearing the expansion depth of Template:Val (nested 30 levels for 14-digit decimals), I had been reluctant to use it in complex templates. So, I rewrote portions as 5-depth-level templates {{gapnum}} and {{gapnum/dec}} to put space-gaps in numbers. Then, using those optimized templates, with parameters set to use just 5 expansion-depth levels, I wrote Template:Convert/gaps to put space gaps in numeric conversions, as requested by users for metric measurements. -Wikid77 09:46, 4 February 2011 (UTC)

JavaScript Standard Library Gadget

The Javascript library wouldn't make most of my user scripts work on IE 7 or IE 8, while they do work on Mozilla Firefox 4 Beta 10 and Firefox 3.5. --Yutsi ^Talk/ Contributions 14:08, 3 February 2011 (UTC)

Maybe because IE is a piece of crap? At least, up through IE 8. /ƒETCHCOMMS/ 00:42, 5 February 2011 (UTC)

Texas State Historical Association website

A shot in the dark here - maybe some Wikipedia editor has run across some information. It would appear that the servers at the Handbook of Texas Online have been down for a couple of days. I've tried it on both my Firefox and IE. Even the Main Page either brings up a message of "the connection has timed out", or "server not found". If the web site is down, there's no one to contact about this. Although, the timing of this also tends to coincide with the Egypt events slowing down the internet as a whole. Just wondering if anyone else has heard anything.

Also, I've tried View/Page Source to see their server name. When I do that, it's completely blank - nothing there.

If I go through U of North Texas at Denton, where this is supposedly based, everything on their site comes up. Except what they have for the UNT TSHA portal. Again, same messages and blank that shows no server.

Is it possible the Handbook is no longer available onine?

Maile66 (talk) 16:50, 3 February 2011 (UTC)

OK, It's back, after two days in the cosmos. So, never mind. Maile66 (talk) 19:38, 3 February 2011 (UTC)

• You might want to contact their webmaster, who might explain why the server was offline, in case there will be a repeat pattern. For instance, the Swedish webserver for the article hit-counters (stats.grok.se) has had space limits, which stopped logging hit-counts, and would lose new data. That problem occurred during extreme events, such as the release of new blockbuster films (where zillions of hits were logged), or when the webmaster went on summer vacation. The pattern predicted when to get stats before losing service. -Wikid77 09:46, 4 February 2011 (UTC)

Trouble substituting a #switch block

I'd like to make {{WikiCup nomination}} substitutable. It has a #switch statement in it, which when substituted, should only output the result and not the entire block. However, I notice that {{subst:#switch:}} doesn't work. So, how do I go about substituting this block? Gary King (talk · scripts) 06:37, 4 February 2011 (UTC)

Are you sure it isn't working when the variables have been set? It looked like it worked for me, but I might not understand the issue. There is no default set, so it wouldn't work without variables... ▫ JohnnyMrNinja 06:57, 4 February 2011 (UTC)

(Note: the /doc prescribes and uses {{cupnom}} in the examples, which redirects to {{WikiCup nomination}}). I created Template:WikiCup nomination/sandbox (with subst:#switch and Template:WikiCup nomination/testcases. It looks like the subst acts after processing the parameters, but before the #switch is performed. Without the subst: (as is the main T now) it works fine. -DePiep (talk) 09:47, 4 February 2011 (UTC)

And, if you want the whole template to be subst:-able (as you write), the template should be entered like this: {{subst:WikiCup nomination|some page|FAC}}. Seems to work (see testcases). -DePiep (talk) 11:25, 4 February 2011 (UTC)

Secure server and linking to Robots.txt.

I'm logged into the Secure Server. While looking at the Grub (search engine) article, I find a link to Wikipedia's Robots.txt file used as a source. Clicking on the link takes me to the secure server's Robots file instead of the en.wikipedia file. Is there a way to hardcode the link to prevent this behavior? -- RoninBK _{T C} 08:28, 4 February 2011 (UTC)

But why is this such a problem? Anyhow, I don't think a "robots.txt" file is a reliable source, and, what's more, the link seems to have been removed from the article.. — This, that, and the other (talk) 09:51, 4 February 2011 (UTC)

Yeah, it would seem to be moot at this point. wouldn't it? I suppose the easiest solution for a problem is to simply remove the instance of it. -- RoninBK _{T C} 19:09, 4 February 2011 (UTC)

CSS: a lower diacritic is sometimes cut off (IPA)

In {{IPA vowel chart}} (and its sub {{IPA vowel chart/vowelpair}}), IPA symbols with a lower diacritic are used, e.g. e̞. An editor notes that sometimes that lower diacritic is cut off. Possibly browser/skin/font/zoom related (I can only reproduce this myself by zooming ++ in FF).
My question is: how to set the (inline) box to prevent this? I tried using "vertical-align:" but did not get an effect, so probably I did not use or understand it correctly.
At the moment, sandboxes & vowelpair/doc is prepared and available for this: Template:IPA vowel chart/sandbox(edit talk links history), sub Template:IPA vowel chart/vowelpair/sandbox(edit talk links history). -DePiep (talk) 11:46, 4 February 2011 (UTC)

hold on: the sandbox showed it: lower opaque boxes obscure the lower part. From here it is easy. (But still don't understand "vertical-align:" correctly ...). -DePiep (talk) 12:05, 4 February 2011 (UTC)

The sequence: if I have a letter with no risers (nothing above "x" height, so no "X, h" etc), is there a way to cut off unocccupied top space of the inline-box where "e" is in? -DePiep (talk) 12:31, 4 February 2011 (UTC)

New watchlist for app tabs

Based on this discussion, would it be possible to devise a page that was a modified watchlist: that would both auto-refresh and open links as new tabs by default? This would be great for many editors, and be perfect for Firefox's new app tab feature (sort of a minimized tab that you keep open all the time). ▫ JohnnyMrNinja 22:42, 4 February 2011 (UTC)

I'm sure it could be done with a script, but how exactly is beyond me. /ƒETCHCOMMS/ 00:42, 5 February 2011 (UTC)

Page not loading

Can someone explain why National Register of Historic Places listings in Northwest Quadrant, Washington, D.C. is not loading for me? I've tried it once myself, and my bot has tried it about 20 times. It's a problem that seems isolated to this page. Is it temporary? Magog the Ogre (talk) 18:23, 4 February 2011 (UTC)

•  Works for me ΔT _{^{The only constant}} 18:24, 4 February 2011 (UTC)

Interestingly, it's come up, just very slowly for me now. Apparently more slowly than 30 seconds (the bot timeout default). Magog the Ogre (talk) 18:27, 4 February 2011 (UTC)

It's a very long page, with almost 300+ images, which is the most likely source of your problem. I can't see anything obvious that could cause it to not load at all though. It might be worth investigating a possible split or reduction of that list. --Dorsal Axe 19:08, 4 February 2011 (UTC)

Rendering that page takes the server roughly 55 seconds, I assume due to the high number of {{dts}} and {{coord}} templates. If you didn't get the page from the cache that's probably what tripped your timeout. 93.104.98.209 (talk) 14:50, 5 February 2011 (UTC)

Twinkle notices showing up with redlinks

Resolved

All 3 Twinkle notices I have posted today come up with redlinks to the linked articles, but the articles are there. I even see the redlinks running a different browser that's not logged into my account. I have locally bypassed my cache and done a purge. I can't see anything wrong with the notices themselves. This is driving me crazy. Examples: 1, 2, 3. —UncleDouggie (talk) 19:42, 5 February 2011 (UTC)

It looks like the wikilinks in those notices all have some garbage characters inserted after the 18th character of the intended link title. Probably a recent Twinkle change broke this, but it's possible that the notice coding got broken instead. — Gavia immer (talk) 20:10, 5 February 2011 (UTC)

Not always the 18th. I've replaced them here with a "?": Capital punishment? debate; List of cheerleadi?ng stunts; Tottempudi? Gopichand. --Redrose64 (talk) 20:15, 5 February 2011 (UTC)

This appears to only be happening to you, since none of the Twinkle scripts were edited since January 23, and the warning templates haven't been touched, either. Also, people are still posting Twinkle messages just fine at the moment. Gary King (talk · scripts) 20:41, 5 February 2011 (UTC)

I copied the article names from the diff header of my WP:STiki window whenever I needed to use Twinkle to leave a specific type of user warning. It appears that the STiki client is inserting one unprintable character in-between all printable characters. Everything looks normal when I paste into Twinkle and in the wiki editor when I open the resulting talk page for manual editing. I can only see the extra characters if I copy the resulting text to MS Word and turn on show special characters. They then appear as ÿ. I'll report this as a bug in Stiki. Thanks for pointing me in the right direction. —UncleDouggie (talk) 23:09, 5 February 2011 (UTC)

Way to get the number of empty subcategories - API

I currently run a bot that checks for all the empty subcategories of Category:Wikipedia files with a different name on Wikimedia Commons and Category:Wikipedia files with a different name on Wikimedia Commons and Category:Wikipedia files with the same name on Wikimedia Commons. The only way I know how to do this on the API is to actually run a separate query for each subcategory. That means that any time I want to run the update (~1-3 times per day), I have to make ~1200 queries to the server (which seems like an obnoxiously high number). Is there a way to do this any quicker? I note that the HTML version of the page shows 200 subcategories a time (just click on either category and you'll see what I mean). Magog the Ogre (talk) 23:30, 1 February 2011 (UTC)

It sounds like prop=categoryinfo will give you the information you want about each subcategory. You could pass up to 500 subcategory names (separated by '|') in the titles= parameter, or you could use categorymembers on each parent cat something like this. Anomie⚔ 00:57, 2 February 2011 (UTC)

Thank you. (talk) 04:03, 2 February 2011 (UTC)

OK, where did you figure out how to do that query? I am entirely unfamiliar with this whole "generator" syntax. Magog the Ogre (talk) 22:04, 2 February 2011 (UTC)

Bump. Magog the Ogre (talk) 00:13, 7 February 2011 (UTC)

Random article

Random article used to support the back button going to the previous random article, but now it takes the user back to the main page. Please restore the original behavior. —Preceding unsigned comment added by 66.14.154.3 (talk) 18:29, 2 February 2011 (UTC)

I have this problem too. Windows 7 and Chrome. Of course you can find it by looking at your browsing history... Ericoides (talk) 22:29, 2 February 2011 (UTC)

The problem seems to only be with the Vector skin. I don't have that problem in Monobook. Gary King (talk · scripts) 22:32, 2 February 2011 (UTC)

Note: The first comment in this section was originally posted to Talk:Main Page. Graham87 01:23, 3 February 2011 (UTC)

Thanks Graham. Gary, the problem happens irrespective of the skin (in Chrome). Ericoides (talk) 07:16, 3 February 2011 (UTC)

I have windows 7 and four different browsers. For each, I was not logged in (therefore Vector skin), started at main page, then went for "Random article" three times, then the "back" button once.

• Google Chrome 8.0 - returns to main page
• Mozilla Firefox 3.6.13 - returns to second random article
• MS Internet Explorer 7.0 - returns to second random article
• Opera 11.01 - returns to second random article

In Firefox and Chrome, you can right-click the "back" button to select from a list. This demonstrates that whilst successive articles reached through normal wikilinks are added to this list in both browsers, those reached through "Random article" are not added to the list in Chrome. --Redrose64 (talk) 14:24, 3 February 2011 (UTC)

I just tried this in Safari/Mac 10.6, and clicking the random article link three times and then going back takes you to the page where you first clicked the random link. Given that that's the same behavior as Chrome, perhaps it's just a WebKit-only bug? EVula // talk // ☯ // 23:56, 4 February 2011 (UTC)

It is a webkit bug. https://bugs.webkit.org/show_bug.cgi?id=19422 and has been known about (since 2006). —TheDJ (talk • contribs) 13:46, 6 February 2011 (UTC)

Web crawlers

I noticed that Google is indexing my user space. Try this search. Is there a way to avoid this. I often use my user space for article or template development and so the content is not necessarily ready for prime time. Is there a way to stop this. Is there a way to generate a noindex meta tag for these pages.  –droll [chat] 00:59, 6 February 2011 (UTC)

Have you tried adding __NOINDEX__? I don't know if this does it entirely, but it could be a start. Plastikspork _―Œ^(talk) 01:02, 6 February 2011 (UTC)

See Help:Magic_words#Behavior_switches. It looks like NOINDEX is what you want. Plastikspork _―Œ^(talk) 01:03, 6 February 2011 (UTC)

Thanks. I'll give it a try>  –droll [chat] 04:14, 6 February 2011 (UTC)

You can use {{userpage|noindex=yes}} which not only displays a message, it does a __NOINDEX__ too. As for subpages used for article development, try either {{Userspace draft}} or {{User Sandbox}} both of which do a __NOINDEX__ by default. --Redrose64 (talk) 13:45, 6 February 2011 (UTC)

Checkbox in Special:Watchlist/edit

Normally when you click on a link located in the "edit" menu of the watchlist, and the link happens to be a redirect, you view the target page that the redirect was pointing to. But when you go to watchlist the redirect, you would want to view the full redirect itself and its associated history, and not necessarily the target page itself. I think it'd be much easier to add an opt-in option, preferably something like a checkbox, that would allow you to view the full-redirect page (with redirect=no) or, when unchecked, just point you to the target page like it normally does. :| TelCoNaSpVe :| 07:13, 6 February 2011 (UTC)

Turning off the CentralNotice and/or the SiteNotice across all Wikimedia wikis

The CentralNotice (or SiteNotice) can be a bit annoying, and it's generally inconvenient to have to ask to import the HideFundraisingNotice gadget across all the Wikimedia wikis. Therefore, there should be a general switch (or two) in Special:Preferences, maybe something under "Advanced options" in the editing tab, that would enable a person to disable viewing the CentralNotice whilst on any Wikimedia wiki, not just the English Wikipedia. Much like the metadata already present under the "Advanced options" in the editing tab, this change would have a global effect. :| TelCoNaSpVe :| 07:29, 6 February 2011 (UTC)

signature snippets of tools

Microsoft's translation tool Wikibasha (a machine translation tool for indic languages) creates a code snippet like this - <!-- WikiBhasha v=1 time=2011-2-6:11:20:20:309--> at the bottom of the article everytime it is used to edit. MS representatives claim they need this to track the edits made using wikibasha. As far as i know, we don't all such code snippet signatures in en wiki and i am trying to create a similar policy in Ta wiki. I would be grateful if someone points me to earlier relevant discussions/policies regarding this.--Sodabottle (talk) 11:58, 6 February 2011 (UTC)

It's useless, the last modified information is all there for the taking in every article. Much better to use that. Specific tool tracking should not be allowed, before we know it, we'd have 60 comments for each and every tool users invent. It's no rule, it's common sense. —TheDJ (talk • contribs) 14:18, 6 February 2011 (UTC)

Template issue with Template:Whisperback

See Template talk:Whisperback#Template causes following header to be indented. The template creator seems to be inactive, so I'm cross-posting here to see if anyone else might be able to figure it out. rʨanaɢ (talk) 14:41, 6 February 2011 (UTC)

 Done --Redrose64 (talk) 15:58, 6 February 2011 (UTC)

Why are PNG's limited to 12.5 million pixels?

As a web-safe and lossless format, we should give this format full support. 12.5 mexapixels is now an affordable amateur camera. Is there any way to improve the thumbnail tool so it can support larger png files? - ʄɭoʏɗiaɲ ^τ _¢ 03:55, 20 January 2011 (UTC)

Basically this is just development work that needs to be done. The existing thumbnail tool reads the entire file into memory at once and has other scalability limitations. What's needed is a tool that works incrementally, efficiently, and with minimal memory overhead at any one time. This proves rather tricky because the pixels of a PNG are encoded in scan order, not using a quadtree. The best way to help is to build such a tool, integrate it with the latest Mediawiki, and submit a patch.

One interesting approach I just thought of is to create an "intermediate resolution" version that is cached - the intermediate resolution version would be slow to generate, but it would be under the current pixel limit and could be used to create any thumbnails smaller than itself. Dcoetzee 06:49, 20 January 2011 (UTC)

Heh, if I even knew where to begin, I would. I'm more of the one that takes the pictures; I'll leave coding to the experts. - ʄɭoʏɗiaɲ ^τ _¢ 18:50, 20 January 2011 (UTC)

Alas you rather highlight the issue - it's no-one's idea of fun :) So, in a volunteer-driven project, it's just not going to get done. Maybe one day the WMF could get it programmed (since they have that wonderful motivator known as "money"), I suppose, but I'm not holding my breath. Ah well. - Jarry1250 ^{[Who? Discuss.]} 19:57, 20 January 2011 (UTC)

Some people find coding fun. I think the fact is that much of this stuff is hidden under the hood. Where is the current thumbnail generator code located, for someone to pick apart and modify? - ʄɭoʏɗiaɲ ^τ _¢ 20:22, 20 January 2011 (UTC)

Thumbnailing is currently done by calling the ImageMagick utility which is what generates the high memory usage (roughly 4 bytes per pixel). One would need to either modify ImageMagick to provide a more conservative memory mode (and get those modifications accepted by the ImageMagick developer community) or one would need to develop an alternative means for Mediawiki to generate thumbnails from large images, and get our developer community to use that alternative. Dragons flight (talk) 20:54, 20 January 2011 (UTC)

ImageMagick has support for tera-pixel image sizes, what's needed is probably just to invoke the right ImageMagick options from MediaWiki. Command line example from here: convert -define registry:temporary-path=/data/tmp -limit memory 16mb logo: -resize 250000x250000 logo.miff Nicolas1981 (talk) 05:48, 24 January 2011 (UTC)

Hhmmm, apparently "limit memory" was added in late 2007. I hadn't seen that before. You are right that there may now be a solution. Dragons flight (talk) 06:32, 24 January 2011 (UTC)

PS. Since it appears to substitute disk caching for memory, it might still be too burdensome under some circumstances, but it maybe possible to adjust the limits. Dragons flight (talk) 06:40, 24 January 2011 (UTC)

Even a small boost to 15 million would be enough for most standard cameras. Thats enough to support 4230 x 3420. - ʄɭoʏɗiaɲ ^τ _¢ 15:50, 26 January 2011 (UTC)

Is there a better or more proper venue I could take this to? Its a small change to make a lot more detailed photos compatible. - ʄɭoʏɗiaɲ ^τ _¢ 17:28, 29 January 2011 (UTC)

The suggested fix has been included at bugzilla:9497. Maybe you could vote for that bug too. So far it has received only three votes, which isn't exactly much for such a long-standing and fairly serious limitation IMO. --Morn (talk) 13:04, 30 January 2011 (UTC)

There is no sign of a viable fix at that bug. As pointed out pngds is subject to random crashes. OrangeDog (τ • ε) 11:14, 31 January 2011 (UTC)

I'm just looking to get the current limit increased, not to recode or use new software. I'm guessing I'd do that at the Meta village pump? - ʄɭoʏɗiaɲ ^τ _¢ 15:03, 31 January 2011 (UTC)

No, at bugzilla. However, I imagine that the devs won't increase it by a large amount due to performance, and won't increase it by a small amount as there is little benefit. OrangeDog (τ • ε) 15:40, 1 February 2011 (UTC)

I'm not sure if increasing the size is a good idea. There is a reason why the limit exists ManishEarth^{Talk • Stalk} 16:00, 1 February 2011 (UTC)

I know its there for a reason. I only wish for a 2.5 million pixel increase, which at worst is a 20% increase in load. Two years ago, average consumer-level cameras were 8-12 megapixels. Now they are 12-14 megapixels. Increasing the limit to 15 megapixels would allow 4230 x 4320, which is 14.5 megapixels, your high-end consumer-level camera. Download sizes are irrelevant, because if the image is the same size regardless of whether the thumbnail program is processing it. The difference is that an unprocessed thumbnail requires the user to view the full size (and several megabyte) picture, where as a thumbnail is a smaller several kilobyte equivalent to the full image. I always upload the largest image size possible, regardless of whether its going to show up in the articles as a grey square; thats wiki's issue, and a poor excuse for encouraging lower-quality content. - ʄɭoʏɗiaɲ ^τ _¢ 15:47, 2 February 2011 (UTC)

This should probably be a separate proposal, but it might be a good idea to allow pre-rendered reduced-size versions of images (similar to the text under any SVG image). It'd be neat if a PNG image said "This image rendered as PNG in other sizes: 25% 50% 75% 200% 400%". We could even have a bot running optimizing loss-less image compression. But again, these are separate proposals. I don't want to detract from this thread, merely point-out that problems with large file size can be overcome. Do we really want the photographers with the most high-end equipment reducing their image size? ▫ JohnnyMrNinja 12:00, 3 February 2011 (UTC)

This is already done. Thumbnails are cached, and Commons has an option to download thumbnail images at a variety of thumbnail sizes. In any case there is a simple work around for this bug for now: upload both a larger PNG version and a smaller one, and add links between the two, ideally using standardized templates for this purpose. This is how we have long dealt with the bug that the software cannot render JPEG thumbnails of PNG files (see commons:Template:JPEG version of PNG, commons:Template:PNG with JPEG version). Dcoetzee 17:05, 3 February 2011 (UTC)

There really should be a bug opened to add the behavior switches __lossythumbnail__ and __losslessthumbnail__, so we aren't manually re-uploading images. — Dispenser 02:52, 7 February 2011 (UTC)

Are there any consumer-level cameras that save images as anything but JPG? Mr.Z-man 23:29, 3 February 2011 (UTC)

I don't think many save to PNG, but many do offer a raw image format which is lossless and are often converted into TIFFs and PNGs. It makes sense, as long as you have the capacity. ▫ JohnnyMrNinja 01:21, 4 February 2011 (UTC)

Converting a busy image (like a real photo) to PNG doesn't make sense. In some cases the file will get even bigger. PNG compression just doesn't work like that. OrangeDog (τ • ε) 19:47, 6 February 2011 (UTC)

Jpegs distort gradients when the size is reduced. Any image with a sky that changes shades from top to bottom that has something standing in the foreground will show this very well. Try to thumbnail this image. Jpeg is a terrible image format, and I always delete my jpegs when I upload them by accident. A quick conversion to png in irfanview, even AFTER the image has been compressed in jpg, quickly fixes these distortions. - ʄɭoʏɗiaɲ ^τ _¢ 19:54, 6 February 2011 (UTC)

At the expense of (for a 250px thumbnail) a thumbnailed version that has a 2000% larger file size. Mr.Z-man 20:43, 6 February 2011 (UTC)

Well, we aim for the highest quality and accuracy, and if that comes at the expense of being larger, that's not a loss. I'd rather wait for quality then get served something that doesn't look right quickly. - ʄɭoʏɗiaɲ ^τ _¢ 03:06, 7 February 2011 (UTC)

Also, in fairness, that PNG file was big beyond reason. I uploaded a PNG conversion that I made by simply opening and saving in GIMP and it is almost half the size of the original PNG (and it isn't cropped like the first). There are probably ways to optimize even further. If you save any image into JPEG and then convert that image to PNG it is very unlikely (maybe impossible?) that you will get a smaller file size. That is not the point. PNG is a better file format in general if your end goal is quality because you don't lose a pixel, and you don't continue to lose information every time an image is edited. Anyways, PNG is more in line with our goals, free software and all that (no submarine patents). ▫ JohnnyMrNinja 10:57, 7 February 2011 (UTC)

Transparent table background.

For a long time, the plain table background was white, but this has changed to transparent in the upcoming 1.17 release of MediaWiki. Since there may be templates that rely on a white background, I'm putting the following code in Common.css, in order to spot any glitches that may pop up before 1.17 is deployed. — Edokter (talk) — 21:08, 30 January 2011 (UTC)

/* Transparent table background. Remove when 1.17 is deployed */
table {
    background-color: transparent;
}

• So, now, a table will default to transparent background, but a quotebox or preformat-box will remain white, as shown below:

This indented table now defaults to transparent, but class=wikitable will remain white. This is a quotebox, indented by leading spaces. However, the quotebox (above) & preformat-box (below) remain white. This text is within the tags <pre></pre>. Tables are often used for multiple columns in see-also sections.

So, people should change any unclassed tables which need to be white, by setting style="background:white". -Wikid77 10:06, 31 January 2011 (UTC)

Basically yes, but since all pages already have a white background (in Vector), it would not be absolutely necessary. (PS. Wikitables and pre-formatted boxes have a gray background.) — Edokter (talk) — 19:29, 31 January 2011 (UTC)

• I see the gray now, but the monobook skin shows a bluish "white" which made the gray seem "whiter". -Wikid77 09:46, 4 February 2011 (UTC)

On Monobook, the background is light blue, the "transparent" sections above are white and the quote and pre boxes are grey. OrangeDog (τ • ε) 14:02, 7 February 2011 (UTC)

Add new features to show/hide content based on user's groups?

This discussion was moved to MediaWiki_talk:Common.js#Add_new_features_to_show.2Fhide_content_based_on_user.27s_groups.3F to get more input, and so that it's easier to keep track of. Gary King (talk · scripts) 19:02, 7 February 2011 (UTC)

Malfunctions from visits on someone else's User:Talk page

I experienced malfunctions on from visits someone else's User:Talk page on a couple of different non-successive days with no visits there in between by me. I needed to go off line to fix the problem. I don't know who or what caused them, but I'm not returning there for obvious reasons.

My security settings were all on (I assume anyhow, because they are on now and I don't change them). If it could happen to me, it could happen to lots of others. My guess is that, if I reveal too many more details here, that might violate someone else's privacy or compromise my computer security. But I could be wrong on that.

Any suggestions would be welcome. Thank you for your assistance here and/or through email. Thank you. --Thomasmeeks (talk) 23:05, 4 February 2011 (UTC)

You're going to have to be at least a little more specific. "Malfunctions" is far to vague to diagnose. Mr.Z-man 23:14, 4 February 2011 (UTC)

Er, defining "malfunctions" and saying who's user talk page it happened on would go a very long way in fixing whatever the problem is. EVula // talk // ☯ // 23:49, 4 February 2011 (UTC)

1. Thank you for both your comments. My [last] Edit there [before the malfunctions] was on Feb. 2 [Feb. 1 in my time zone] [per my http://en.wikipedia.org/wiki/Special:Contributions/Thomasmeeks log]. [My] first malfunction occurred at User talk:Kiefer.Wolfowitz on Feb. 2. I could not tell whether my Edit went through [(it did not from my Contributions log)], b/c my browser lapsed into a mark-up browser page that I could make no sense of and had never seen before. When I tried to copy (to Save elsewhere) from the WP Edit mode text, the mark-up text went gray, and I was unable to copy. When I tried to go to earlier pages on my browser, each attempt brought another of cascading web pages. So I went offline, etc.
2. In my 2nd effort to reach that same page on Feb. 4, clicking on that log was associated with my screen freezing. So, I closed my web connection and repeated the same procedure with the same result (freezing), this time on my default page. I went offline to take remedial action.
3. Any suggestions or feedback would be appreciated. P.S. I do recognize that Admins are tremendously overworked and appreciate their great contributions. --Thomasmeeks (talk) 00:36, 5 February 2011 (UTC) Amended per bracketed terms above. --TM 17:15, 5 February 2011 (UTC)

I guess this edit is the one referred to. I have been unable to get my browser to crash loading Kiefer.Wolfowitz's talk page. Ucucha 00:46, 5 February 2011 (UTC)

What browser and operating system do you use? (I meant to ask before) EVula // talk // ☯ // 01:16, 5 February 2011 (UTC)

In addition to EVula's question, does the following code look somewhat familiar? You don't need to remember whether the output you saw was identical, only whether it seems to resemble it.

Click "show" to view extended content
The following discussion has been closed. Please do not modify it.
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="666px" height="333px" viewBox="0 0 666 333" enable-background="new 0 0 666 333" xml:space="preserve"> <polygon fill="#FFE6E6" points="499.5,290.185 412.042,253.958 375.816,166.501 412.042,79.044 499.5,42.818 586.957,79.044 623.183,166.501 586.957,253.96 "/> <line fill="none" stroke="#FFDCDC" stroke-width="3" x1="62.886" y1="124.729" x2="99.113" y2="37.272"/> <path fill="none" stroke="#000000" stroke-dasharray="4" d="M144,132c0,6.627-5.373,12-12,12H30c-6.627,0-12-5.373-12-12V30 c0-6.628,5.373-12,12-12h102c6.627,0,12,5.372,12,12V132z"/> <line fill="none" stroke="#FFDCDC" stroke-width="3" x1="99.113" y1="295.729" x2="62.886" y2="208.272"/> <path fill="none" stroke="#000000" stroke-dasharray="4" d="M144,303c0,6.627-5.373,12-12,12H30c-6.628,0-12-5.373-12-12V201 c0-6.627,5.372-12,12-12h102c6.627,0,12,5.373,12,12V303z"/> <line fill="none" stroke="#FFDCDC" stroke-width="3" x1="199.271" y1="99.113" x2="286.728" y2="62.887"/> <path fill="none" stroke="#000000" stroke-dasharray="4" d="M306,132c0,6.627-5.373,12-12,12H192c-6.628,0-12-5.373-12-12V30 c0-6.628,5.372-12,12-12h102c6.627,0,12,5.372,12,12V132z"/> <line fill="none" stroke="#FFDCDC" stroke-width="3" x1="199.271" y1="233.887" x2="286.728" y2="270.113"/> <path fill="none" stroke="#000000" stroke-dasharray="4" d="M306,201c0-6.627-5.373-12-12-12H192c-6.628,0-12,5.373-12,12v102 c0,6.627,5.372,12,12,12h102c6.627,0,12-5.373,12-12V201z"/> <path fill="none" stroke="#000000" stroke-dasharray="4" d="M648,303c0,6.627-5.373,12-12,12H363c-6.627,0-12-5.373-12-12V30.001 c0-6.627,5.373-12,12-12h273c6.627,0,12,5.373,12,12V303z"/> <circle fill="#C1272D" stroke="#000000" cx="62.886" cy="124.729" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="99.113" cy="37.272" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="199.271" cy="99.113" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="286.728" cy="62.887" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="62.886" cy="208.272" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="99.113" cy="295.729" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="199.271" cy="233.887" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="286.728" cy="270.113" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="499.5" cy="290.185" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="412.042" cy="253.958" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="375.816" cy="166.501" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="463.273" cy="202.726" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="448.269" cy="166.502" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="412.042" cy="79.044" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="499.5" cy="42.818" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="586.957" cy="79.044" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="499.5" cy="115.271" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="463.272" cy="130.276" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="535.726" cy="130.275" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="623.183" cy="166.501" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="550.73" cy="166.501" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="586.957" cy="253.96" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="535.726" cy="202.727" r="4.5"/> <circle fill="#C1272D" stroke="#000000" cx="499.5" cy="217.733" r="4.5"/> <rect y="0" fill="none" width="666" height="333.001"/> <path fill="none" stroke="#000000" d="M489.694,68.434"/> <path fill="none" stroke="#000000" d="M500.305,42.818"/> <g> <line fill="none" stroke="#000000" stroke-width="2" x1="475.899" y1="65.147" x2="475.899" y2="83.147"/> <line fill="none" stroke="#000000" stroke-width="2" x1="466.899" y1="74.147" x2="484.899" y2="74.147"/> </g> <g> <line fill="none" stroke="#000000" stroke-width="2" x1="199.271" y1="224.887" x2="199.271" y2="242.887"/> <line fill="none" stroke="#000000" stroke-width="2" x1="190.271" y1="233.887" x2="208.271" y2="233.887"/> </g> <g> <line fill="none" stroke="#000000" stroke-width="2" x1="62.886" y1="199.272" x2="62.886" y2="217.272"/> <line fill="none" stroke="#000000" stroke-width="2" x1="53.886" y1="208.272" x2="71.886" y2="208.272"/> </g> <g> <line fill="none" stroke="#000000" stroke-width="2" x1="272.933" y1="59.601" x2="272.933" y2="77.601"/> <line fill="none" stroke="#000000" stroke-width="2" x1="263.933" y1="68.601" x2="281.933" y2="68.601"/> </g> <g> <line fill="none" stroke="#000000" stroke-width="2" x1="88.502" y1="53.887" x2="88.502" y2="71.887"/> <line fill="none" stroke="#000000" stroke-width="2" x1="79.502" y1="62.887" x2="97.502" y2="62.887"/> </g> </svg>

If that looks plausible, it was probably a temporary glitch on our end, combined with a well-known deficiency of some browsers. — Gavia immer (talk) 01:25, 5 February 2011 (UTC)

[No, that's not the attempted Edit per Ucucha's excellent question above & Edit below.] "No" per the name of the browser listed on the non-WP page of the first malfunction and similar look therein to the above "Click 'show' to view extended content" drop-down). I use a well-known browser and a well-known operating system. I do appreciate the above efforts to locate the problems. Thank you. --Thomasmeeks (talk) 03:52, 5 February 2011 (UTC) First sentence corrected as bracketed. --TM 17:15, 5 February 2011 (UTC)

"a well-known browser and a well-known operating system" isn't particularly helpful; I would consider Internet Explorer, Firefox, and Chrome to all be well-known browsers, while I would also consider Windows, Macintosh, and Linux to be well-known operating systems. There is a massive difference between Internet Explorer for Windows, Firefox for Linux, and Chrome for the Mac. Furthermore, there can be significant differences between different versions of the same browser (IE5 is a very different beast than IE7, for example). EVula // talk // ☯ // 08:19, 7 February 2011 (UTC)

For earlier readers only: On further recollection, which my http://en.wikipedia.org/wiki/Special:Contributions/Thomasmeeks log confirmed, I amended the first sentence above to that as indicated in the brackets, & similarly my 00:36, 5 February 2011 Edit above that. My Contributions log establishes that no Edit from me occurred there after my 00:15, 2 February 2011 per above. Rather my first malfunction occurred after that, also on Feb. 2. My unsuccessful edit-Save-or-at-least-copy attempt then was in response to an Edit by the User there after my Feb. 2 Edit.

4. IMO two things are worth noting here. First, a malfunction on a particular User:Talk page does not imply that that User was responsible for it. Second, the possibility of a purely technical glitch remains open.

5. At this point, there is only an unsuccessful Edit as it affects me (worth ignoring by itself).

6. I offer this as a question only. Could an Admin or anyone else somehow detect that a section was open for Editing and in the process accidentally cause malfunctions such as described above?

7. What still remains puzzling to me (unless an answer to (6) is an explanation) is that 2 apparently different types of malfunctions (neither previously encountered by me on WP) occurred over the course of 2 non-successive days. If it was a matter only of local or temporary malfunctions and only affecting one person's attempted Edits, that would be one thing. I hope that it is so bounded, as against the more general concern expressed in at the top that "If it could happen to me, it could happen to lots of others." --Thomasmeeks (talk) 17:15, 5 February 2011 (UTC)

A reference showing a map icon

I've added a reference to a reliable source to the articles Ljubljana (No. 28) and Sava (No. 4) and an earth icon to a map appeared next to the reference in the 'References' section. First of all, I didn't intend the reference to include the link to this map. Second, even more important, this map shows the location correctly in the article Ljubljana but at the wrong place (somewhere in the Atlantic near Africa instead of in Slovenia, Europe) in the article Sava. What is the cause of the problem? Is there any way to fix this? --Eleassar ^{my talk} 11:01, 5 February 2011 (UTC)

The Earth icon is automatically added for any Geopedia link with "params" set, try this instead. The popup map is showing the correct location for me in the Ljubljana article? Plastikspork _―Œ^(talk) 01:22, 6 February 2011 (UTC)

The location "somewhere in the Atlantic near Africa" is the point at 0 latitude and 0 longitude. It turns out that both links are broken. In Ljubljana it seems to get the right coordinates because the script never resets the coordinates extracted from the previous link (which is the one generated by the infobox, hovering in the upper-right corner of the page). In Sava there is no link before the Geopedia link (in that article, {{coord}} is at the bottom after the references).

I think most likely the script is broken. At about line 338 of the script, we have the following code:

   if(w.coord_filter.test(coord_params)) {
    w.coord_filter.exec(coord_params);
    marker.lat=(1.0*RegExp.$1) + ((RegExp.$2||0)/60.0) + ((RegExp.$3||0)/3600.0);
    if( RegExp.$4 === 'S' ) { marker.lat*=-1; }
    marker.lon=(1.0*RegExp.$5) + ((RegExp.$6||0)/60.0) + ((RegExp.$7||0)/3600.0);
    if( RegExp.$8 === 'W' ) { marker.lon*=-1; }
   }

In English, that says "Take the value of 'params=' from the URL and update the current set of coordinates if it matches the expected format, but continue on to add the globe icon (with the coordinates from the previous link) even if the format was wrong". Instead, I think it should be this:

   if(!w.coord_filter.test(coord_params)) continue;
   w.coord_filter.exec(coord_params);
   marker.lat=(1.0*RegExp.$1) + ((RegExp.$2||0)/60.0) + ((RegExp.$3||0)/3600.0);
   if( RegExp.$4 === 'S' ) { marker.lat*=-1; }
   marker.lon=(1.0*RegExp.$5) + ((RegExp.$6||0)/60.0) + ((RegExp.$7||0)/3600.0);
   if( RegExp.$8 === 'W' ) { marker.lon*=-1; }

In English, that says "If the value of 'params=' doesn't match the expected format, skip this link entirely; otherwise update the coordinates and continue on to add the globe icon". Since the script is hidden on Meta and wants errors reported somewhere off-wiki, I'll leave it to someone else to try to get it fixed. Anomie⚔ 05:31, 6 February 2011 (UTC)

Thanks. I've filed a bug report at the JIRA.Toolserver.Org, No. WMA-28 --Eleassar ^{my talk} 12:56, 6 February 2011 (UTC)

Thanks guys, I was alerted by the bug tracker and and implemented the suggested solution (thanks). The script is not hidden on meta; it is in use in many projects and meta is a central place to keep it (otherwise I would have to update dozens of copies each time). The reason for off wiki bug tracking should be obvious as well. --Dschwen 13:28, 6 February 2011 (UTC)

Thanks a lot to you for the quick update. --Eleassar ^{my talk} 19:52, 6 February 2011 (UTC)

It may be worthwhile adapting the GeoHack replacement script, as it is more compact and runs slightly faster. — Dispenser 23:41, 7 February 2011 (UTC)

502 proxy error strangeness

Here's something odd. If I attempt to view Israel (or diffs on it) when logged in, I get a 502 Proxy Error (both on Firefox and Safari on OS X). Logged out, no problem. I usually use Monobook but I tried it with Vector; same problem. The heck? --jpgordon^{::==( o )} 05:47, 7 February 2011 (UTC)

When you're logged out, you get a cached version of the page. When you're logged in, you always get a freshly-parsed version. I just tried to load that page and it took quite a while to render. My guess is that the large number of notes, references, and bibliographical citations are to blame; they make up about one third of the total prose of the article by my estimate, and use reference templates that are well-known to be expensive in large quantities. Probably you just hit a timeout while loading the page due to long rendering times. — Gavia immer (talk) 06:00, 7 February 2011 (UTC)

Perhaps, but now it's starting to happen semi-randomly on simple pages... --jpgordon^{::==( o )} 19:57, 7 February 2011 (UTC)

Dates in signatures

I was looking through my talk page when I saw that a message left by Geocraze (talk · contribs) was seemingly misplaced. The timestamp was 17:58, 3 February 2011, and the next message was 13:17, 3 February 2011. But then I look through my history and see that he actually made the post at 12:28! Just to make sure that it wasn't some 5½-hour time zone difference, I looked through his contributions, of which the datestamps were all several hours off. Just out of curiosity, what would be causing this? -- King of ♥ ♦ ♣ ♠ 08:59, 7 February 2011 (UTC)

I note here he also uses a leading zero in his date. I suspect that instead of signing with ~~~~ he is either entering the date manually or substing a template that outputs a date in his local time. Anomie⚔ 12:15, 7 February 2011 (UTC)

Here he used the same date and time as in his previous post 3 days before, so he must be adding it manually. PrimeHunter (talk) 12:32, 7 February 2011 (UTC)

Is there any way to tell how many people are using Twinkle?

I know that there are several ways the thing is implemented, is there any way to tell, in total, how many editors are (or have) used WP:Twinkle? ▫ JohnnyMrNinja 11:46, 7 February 2011 (UTC)

mysql> SELECT COUNT(DISTINCT rc_user) AS Users, COUNT(*) AS Edits
    -> FROM recentchanges
    -> /* Find edit summaries ending in ([[WP:TW]]) in the last 30 days */
    -> WHERE rc_comment LIKE "%([[WP:TW|TW]])";
+-------+-------+
| Users | Edits |
+-------+-------+
|  1997 | 97342 |
+-------+-------+
1 row in set (4.98 sec)

See also: WT:Gadget#Usage-Stats — Dispenser 14:28, 7 February 2011 (UTC)

Oh, that's clever, using the summaries. Thanks! ▫ JohnnyMrNinja 03:12, 8 February 2011 (UTC)

iPad now redirecting to mobile site?

Today was the first time I noticed that navigating to WP on an iPad redirected to the mobile site. Is this a new change, and is there a way to turn it off using personal CSS/js? /ƒETCHCOMMS/ 22:44, 7 February 2011 (UTC)

When you are redirected, there is an option to disable the mobile site, so you continue to get the regular web pages instead. I'm not sure if you have to be logged in for it to work (I was). --RL0919 (talk) 22:59, 7 February 2011 (UTC)

You don't have to be logged in (you can't login on the mobile version). You shouldn't be redirected if you're on an iPad, though. Gary King (talk · scripts) 00:04, 8 February 2011 (UTC)

When I clear cookies I must turn off the mobile site again. I'm not sure why it's happening on an iPad all of a sudden, but is there really no other way to get around this? /ƒETCHCOMMS/ 01:58, 8 February 2011 (UTC)

I would suggest disabling the mobile site permentantly. I've seen maybe a dozen or more people go to Wikipedia on an iPhone or iPad and either they have set it to normal already, soon set to normal themself or ask me how the heck they can set it off, where upon I explain the option for the main site option at the bottom. If every user is finding the mobile site worse then the normal what are we gaining? The iPad and iPhone both have pinch and expand/shrink and that is the way all user in my experience use it. Is the reason for the mobile site for some other mobile phone where the size cannot be altered? Regardless on the iPad and iPhone the mobile site is next to useless imo. Regards, SunCreator ^(talk) 02:19, 8 February 2011 (UTC)

The mobile version is excellent for mobile devices such as the iPhone/iPod. It is not suitable for the iPad, however. I don't know why Wikipedia is redirecting to the mobile version for iPads now, but it shouldn't. For now, though, as has been mentioned, click on the bottom link to get the normal page. Gary King (talk · scripts) 03:40, 8 February 2011 (UTC)

I can confirm it's doing this for me as well; filed as bugzilla:27238. Not sure whether the redir check or the iPad's user-agent changed, but I vaguely recall it not doing this previously. --brion (talk) 08:06, 8 February 2011 (UTC)

It looks like the change was a side-effect of a tweak that just wasn't well thought-out, and would have gone live somewhere since February 3. It may actually go away with tonight's software upgrade as the change isn't in the branch that's about to go out, but we'll get it fixed up properly in a bit. In the meantime, you can hit the link to disable the redirection, and it'll keep as long as the cookie stays. --brion (talk) 08:22, 8 February 2011 (UTC)

(Made an entry for a proper fix for the issue this change was intended to address at bugzilla:27245.) --brion (talk)

The redirection should not be happening with any web browser or device. I hate the mobile view, plus the option to turn it off is hidden at the bottom of the page, and the cookie dosen't work accross language editions. The mobile version should be opt-in, not out. My Android phone is quite capable of the normal site as it is based on Webkit. 178.108.62.154 (talk) 02:30, 9 February 2011 (UTC)

Unknown uglies on my watchlist

Recently I cleaned up my watchlist, first time ever in 6 yrs. I found some very strange page titles: very long, very vandalistic (racist, etc). Any idea how they could have gotten there? Cannot remember I saw or touched such pages, not even for speedy. I'm not an admin. -DePiep (talk) 10:42, 8 February 2011 (UTC)

Page move vandalism, someone vandal moved the page, someone else reverted, admin deleted vandal redirect. Both end up on watchlists. ΔT _{^{The only constant}} 10:47, 8 February 2011 (UTC)

 Thanx. -DePiep (talk) 10:54, 8 February 2011 (UTC)

Server issues

Repeat Wikimedia error - and user "preferences" are non-existant. No edit toolbox, nothing. Problems all the way around with viewing or editing. THIS IS THE ERROR MESSAGE: Request: GET http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical), from 208.80.152.47 via sq61.wikimedia.org (squid/2.7.STABLE7) to ()
Error: ERR_CANNOT_FORWARD, errno (11) Resource temporarily unavailable at Tue, 08 Feb 2011 13:16:26 GMT

Maile66 13:26, 8 February 2011 (UTC)

See section above - it's most likely related to the new software rollout. Hopefully will resolve itself in a little while. the wub "?!" 13:38, 8 February 2011 (UTC)

Formatting issues

What happened to the formatting of the infoboxes and the templates? It makes the articles look horrible in quality and in opening of a lot of space for the user. This makes a lot of newspaper article look good compared to what is going on? Most of us prefer collapsable navboxes as well. Why was this done? Chris 13:55, 8 February 2011 (UTC)

This is probably related to #MediaWiki_1.17_release_is_tomorrow_.28hopefully.29, there are some issues with the rollout. –xeno^talk 14:12, 8 February 2011 (UTC)

This seems to have been sorted now, bypass your cache if you're still seeing problems. the wub "?!" 14:21, 8 February 2011 (UTC)

It is fixed. Thanks. Chris (talk) 15:45, 8 February 2011 (UTC)

preferences gadgets <gadget-section-browsing-gadgets>

• My preferences --> gadgets page looks like this: <gadget-section-browsing-gadgets> Locke'sGhost 14:15, 8 February 2011 (UTC)

Mine, too. And what happened to our clock? Also, the editing toolbar is lacking some good stuff, like the drop down options for citation templates. Not an improvement, so far. Maile66 14:18, 8 February 2011 (UTC)

This is being discussed @IRC. Patience. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 14:20, 8 February 2011 (UTC)

And also, the gadget that used to tell a registered user the class of any article. And no Hot Cat to find and add categories.Maile66 14:23, 8 February 2011 (UTC)

WP:TWINKLE and WP:POPUPS maimed. --Old Moonraker (talk) 14:33, 8 February 2011 (UTC)

• These are not intended; be patient, and it will be back to normal as soon as we figure out what normal is. –xeno^talk 14:40, 8 February 2011 (UTC)

Back to normal for me now. ---— Gadget850 (Ed) ^talk 14:41, 8 February 2011 (UTC)

Nope. Beyond My Ken 16:59, 8 February 2011 (UTC)

Likewise still not normal, and blackscreen gadget not working. DuncanHill 17:04, 8 February 2011 (UTC)

Would be nice to get an update, considering that the last word on this was over two hours ago. Beyond My Ken 17:07, 8 February 2011 (UTC)

Couple of things

• Where's the link to see how many watchers a page has? There used to be a link in the history page, but that seems to have gone.
• Similarly the count of daily page hits?
• <gadget-lefteditlinks> doesn't work (and yes, the Gadgets tab is techno-gibberish now)
• -- Boing! said Zebedee (talk) 14:21, 8 February 2011 (UTC)

I think it's related to the updates which aren't going 100% smoothly lots of things seem to have gone a bit awry, but I'm sure will come back in due course. WikiEd had gone but has just come back so I'm sure other things will too. SmartSE (talk) 14:32, 8 February 2011 (UTC)

Sounds good, thanks - I see the Gadgets tab and the "left edit links" have already been fixed. -- Boing! said Zebedee (talk) 14:44, 8 February 2011 (UTC)

Happy to report that Page View Stats and Page Watchers are back now - my thanks to the hard-working techies. -- Boing! said Zebedee (talk) 16:32, 8 February 2011 (UTC)

Please take the quotes off the article history page

Please take the quotes off the article history page. Using the mouse to copy the article name used to be a simple swipe action. Now it's become a chore that requires concentration. <paranoid mode=on>I've already been driven off Wikisource by "improvements", I feel the same happening here.<paranoid mode=off> Jan1naD ^{(talk • contrib)} 17:21, 8 February 2011 (UTC)

Which quotes? I'm not seeing them. Gary King (talk · scripts) 18:11, 8 February 2011 (UTC)

You'll have to wait for 1.17 attempt 3 to see. We're back to 1.16 now. –xeno^talk 18:13, 8 February 2011 (UTC)

I always miss the shiny new things when I go out for lunch, dammit. Gary King (talk · scripts) 18:15, 8 February 2011 (UTC)

Okay I see the quotes on the test wiki. I can understand why they'd want to separate the article name from the rest of the text, but I also think that it doesn't look very good. Perhaps if they colored the surrounding text a lighter gray instead, that'd be better. Gary King (talk · scripts) 18:17, 8 February 2011 (UTC)

Those quotes shouldn't be there any more. They're part of the software, but that was overridden on-wiki in 2007. Perhaps the deployment problems also affected the message cache? Once it's deployed properly, the problem should disappear. Reach Out to the Truth 04:16, 9 February 2011 (UTC)

infobox alignment out of line

Does anyone else have infoboxes appearing out of line with articles? NorthernThunder (talk) 18:44, 8 February 2011 (UTC)

It's probably due to the recent wiki software upgrade attempt. The pages should be fine now. Try bypassing your cache. Gary King (talk · scripts) 18:47, 8 February 2011 (UTC)

Vector Skin toolbar

Icon	Function	What it shows when editing	What it shows on the page
	Comment (only appears in the code when editing)	<!-- abc -->	Nothing appears on page

Dear Where is this tool in new Vector Skin toolbar.- Jayanta Nath ^{(Talk|Contrb)} 19:26, 8 February 2011 (UTC)

It does not exist I believe. It was determined to be a confusing editing feature for new comers. People who can use it, probably can type it quicker than they would be able to find the button in a new (more newb oriented) toolbar. It's also still in the edittools, below articles, in the "Wiki markup"-section. Hopefully some day, editors will be able to choose their own preferred layouts for toolbars, but that's probably still a while in the future. —TheDJ (talk • contribs) 19:37, 8 February 2011 (UTC)

OK and Thanks for quick reply. But it is not fair for all user.- Jayanta Nath ^{(Talk|Contrb)} 20:01, 8 February 2011 (UTC)

In Special:Preferences, "Appearance" tab, under "Skin", you can change your skin to Monobook; once you have done that, you'll find that when editing, the button in question is in its familiar place between and . --Redrose64 (talk) 20:21, 8 February 2011 (UTC)

Actually, switching the skin will not switch the toolbar. They are separate entities (just launched at the same time), with separate preference items. The one for the toolbar is in the editing section of your preferences. —TheDJ (talk • contribs) 20:25, 8 February 2011 (UTC)

citation entry links strange at SS Edmund Fitzgerald

The citations (in the References section) of SS Edmund Fitzgerald are not linked externally as expected. See, for example, citation ^[1]. This is the first occasion where I tried to follow one in this article so perhaps it is unrelated to the software update.

That article uses a wiki-citation mechanism I have not seen before: <ref> [[#citationNameLink|description]], p. 3.</ref> and, in the References section: <cite id=citationNameLink> {{citation template}} without a closing tag like </cite>. Perhaps it was already broken? A glance at some articles using <ref> citation </ref> and <references/> are okay. —EncMstr (talk) 20:30, 8 February 2011 (UTC)

The article uses shortened footnotes. It uses a lot of markup, but should work. There has been an effort to do away with the use of <cite>...</cite>, as it has a very specific use under HTML5, which we will move to someday. ---— Gadget850 (Ed) ^talk 20:35, 8 February 2011 (UTC)

Just in case it's not clear, clicking on the superscript takes you to the short citation; clicking again on the short citation takes you to the full reference, which has the external link you'd expect. (Clicking on the short citation should result in the full reference being highlighted in blue, but that isn't happening here; I'm not sure why.) I like this style of referencing, as it keeps the citation template clutter out of the article text. You will often find it on good artcles and featured articles for this reason. --NSH001 (talk) 21:00, 8 February 2011 (UTC)

(edit conflict) The lack of a closing </cite> is certainly bad HTML, and whilst it may work with some browsers, it won't necessarily work with all.

Other possible things: first, <cite id= refNTSBReport1978> is HTML markup, not Wiki markup, so there shouldn't be a space between the equals sign and the refNTSBReport1978 (again, it might work with some browsers but not all).

Second, the <cite id=name></cite> method hasn't actually worked properly for well over a year; I think not since October 2009. The {{wikicite}} template can be used as a quick-and-dirty fix, but where citation templates like {{cite book}}, {{cite journal}}, {{cite web}} or {{citation}} are in use, it's better to put an explicit |ref= parameter into the citation template. So, if the shortened footnote contains [[#refNTSBReport1978| then the matching {{cite web}} would contain a |ref=refNTSBReport1978, and would not be enclosed in <cite id=refNTSBReport1978></cite>. --Redrose64 (talk) 21:11, 8 February 2011 (UTC)

The <ref> and <cite> tags used here are not HTML tags (even though <cite>, when used elsewhere, would be an HTML tag), they are custom tags that are (I believe) pre-processed by MediaWiki. The output will be the same in all browsers. --Golbez (talk) 22:32, 8 February 2011 (UTC)

I mentioned <cite id=name></cite> method not working properly... one of the things that's broken is the blue highlighting referred to by NSH001. The |ref= method does give the blue highlighting. --Redrose64 (talk) 21:13, 8 February 2011 (UTC)

Odd— I didn't look closely for the closing cite tag, but the article mostly passed W3C validation.[1] This should be discussed on the article talk page and fixed as Redrose describes. ---— Gadget850 (Ed) ^talk 21:22, 8 February 2011 (UTC)

OK, I've replaced the <cite = > by |ref= so the highlighting now works. Hope that helps, no need for discussion on article talk page, as it's purely a technical fix, no change to citation style. --NSH001 (talk) 22:01, 8 February 2011 (UTC)

Something is wrong

Suddenly Wiki format became completely chaotic on my browser-for example tags have no background colour in their space, the edit bar misses several buttons-do you have any idea what this might be? I am using Mozilla Firefox 3.6. --MyMoloboaccount (talk) 20:36, 8 February 2011 (UTC)

Try clearing your cache and it should return to normal. It is related to the (since rolled back) 1.17 rollout described in threads above. –xeno^talk 20:44, 8 February 2011 (UTC)

Locator Red.svg

Something strange is going on with File:Locator Red.svg. This is the marker in hundreds of infoboxes, but has somehow gone missing: . Is there something wrong with the image caching? Plastikspork _―Œ^(talk) 04:15, 9 February 2011 (UTC)

Until this is sorted out, I changed "Geobox" to use File:Red pog.svg instead, which appears to be working. I'm not sure how File:Locator Red.svg suddenly disappeared. Plastikspork _―Œ^(talk) 04:29, 9 February 2011 (UTC)

Note that the image description page actually says that it's a reupload of a file that "mysteriously disappeared" once before. There's probably some real bug here, though I don't know what it is. — Gavia immer (talk) 04:38, 9 February 2011 (UTC)

It was made and copied with invalid code, and it may have been shaken loose somehow by the system update. The original appears to be fixed (File:Locator Dot.svg), so we should probably just redirect everything back there and delete the un-fixed one. ▫ JohnnyMrNinja 06:26, 9 February 2011 (UTC)

The original does now seem to be functional again. I previously tried to reupload File:Locator Red.svg with the needless Adobe Illustrator breakage removed and got an error, but quite honestly I think the version at File:Locator Dot.svg is the better one in any case. I'd say just use that unless there's a further problem in the future. — Gavia immer (talk) 06:40, 9 February 2011 (UTC)

When I looked at Commons I realized that the new image is actually widely-used. I went over to BS:WP but I couldn't figure out how to switch to the working copy. So, I duplicated the image, copying the vetted code from the original to the duplicate. Bypassing your cache should allow you to see it. We should also maintain a local copy of the image, and protect it, as is the case with any widely-used template image. ▫ JohnnyMrNinja 06:46, 9 February 2011 (UTC)

IPv6, vandalism, and testing it

Will there soon be IPv6 editors? Does Wikipedia have an AAAA record setup and does it answer on IPv6? Is it live and functional? Curious if admins will need to be trained as to what an IPv6 netblock looks like, and how large of a block will suffice to block a particular WP:vandal.

Just FYI, there are a lot of folks intending to test IPv6 on June 8, 2011. I think it's called World IPv6 Day. I propose that the Main Page include the IPv6 article as a good or featured article and that the guys in the server room give this a try. (It's not as easy as it sounds.) I like to saw logs! (talk) 08:52, 5 February 2011 (UTC)

Well, we can't include the IPv6 article as a featured article as "Featured article" is in fact a rating of the article. IPv6 is C-class. It could be improved though...

As for IPv6 support in the software, check out IPv6 support. ManishEarth^{Talk • Stalk} 09:13, 5 February 2011 (UTC)

It'll be quite a while before ipv6 support is live on Wikipedia. For more detail, you might want to read some of the earlier discussions here regarding ipv6. Cheers —DoRD (talk) 13:06, 5 February 2011 (UTC)

We'd better get an urgent message to the devs. We don't want another Y2K. I've posted a high-priority bug (bugzilla:27175), so someone will probably see it soon. ManishEarth^{Talk • Stalk} 13:36, 5 February 2011 (UTC)

They're already having a pretty technical discussion about what needs to be done and by when on the wikitech-l mailing list [2]. - Jarry1250 ^{[Who? Discuss.]} 14:27, 5 February 2011 (UTC)

To briefly summarize that discussion: There is no real urgency here, no ISP is going to give users an IPv6-only connection in the near future because it will break on most of the internet. Initial IPv6 traffic will be light and can be handled with incremental improvements; a massive all-at-once infrastructure change is not necessary. Mr.Z-man 17:15, 5 February 2011 (UTC)

As far as getting ready here is concerned we may already be late. At the very least AAAA records should be added to en.labs.wikimedia.org and/or test.wikipedia.org to see what if anything breaks. The current status of Wikipedia testing can be seen at the Wikitech IPv6 deployment page. – Allen4names 19:17, 5 February 2011 (UTC)

I would agree with Mr. Z... but... I think the best reason to get this test day going is that when Google or Bing start to test their websites, it would be a great thing if a hypothetical properly-connected IPv6 test user could do a search for something on that day and be shown results for a Wikipedia article. Then, the user should be able to click through to Wikipedia's IPv6 version. The critical point might be that the massively-connected Google servers may work flawlessly on IPv6 for said user, while the not-quite-so-connected servers for Wikimedia are being routed across some IPv4 sections of the global network. It would be a great thing at this point to iron out the issues (wherever they may be).

To summarize, the web servers may work fine, the DNS records may be fine, the test user's IPv6 connectivity to the global Internet may be fine but there could be routing issues in between the user and some web servers. See, for example, This incident from a few years ago and for more information, see:

http://ipv6and4.labs.wikimedia.org/

http://wikitech.wikimedia.org/view/IPv6_deployment

I like to saw logs! (talk) 20:57, 5 February 2011 (UTC)

Having some functionality for the few users with an IPv6 connection would be easy. My point was that the switch to IPv6 is not going to happen instantaneously on the ISP side, so there's no urgency for it to happen instantaneously on our side. See this comment by one of the server admins. Mr.Z-man 21:16, 5 February 2011 (UTC)

But does anyone know about vandalism? If I were a smart (?!) vandal, I could come up with an IPv6 block of addresses and vandalize from any one of the addresses in my block. How long until an admin figures out how to block IPv6 addresses, and not just one, but rather block a netblock? I think it is common to be assigned a /64 netblock for a single computer, although there may be folks having a /56 or /57 all to themselves (You can get them for free). There are also inexperienced computer people who try to assign a single /128 or something non-standard between a /64 and /128. Wikipedia admins need to be familiar with this and know how to block IPv6 users when the case arises. One of the strange issues is that a person will not have a unique address anymore, as long as they know how to game the system, they can appear to come from multiple addresses without much effort. I like to saw logs! (talk) 08:08, 8 February 2011 (UTC)

Oxymorons aside, the above problem is a rather large issue. Plus, anyone who knows how to abuse IPv6 in the way mentioned above, would probably know how to even automate it. I've known for a while how to mass-vandalise Wikipedia (No, I've never tested it :P ), and it would be formidable if a user could integrate IPv6 into this. Why not release a premature notice to all admins on IPv6 blocks? ManishEarth^{Talk • Stalk} 12:06, 8 February 2011 (UTC)

Note that MediaWiki already supports IPv6 blocking, including range blocking. The available block sizes are different (Eg, you can do a /64 block :D) but it works the same way in the interface. Best practices will need to be worked out, but the basics will be in place for people to use when they're needed. --brion (talk) 13:11, 8 February 2011 (UTC)

Yep, the admin tools may cover this, but I am just as concerned with admins knowing about this particular problem and how it can be a super-technical issue. For example, is the default or recommended action to block a /64 or a /56? Is there even a tutorial or clue which explains what this means and how to decide on what gets blocked? Do you really think a typical admin knows what a /56 block looks like? Just wondering. This may be an interesting issue every time one of these "test days" come along. I like to saw logs! (talk) 04:59, 9 February 2011 (UTC)

You should use a /64 or a /48 for those using Hurricane Electric's tunnel broker. Other ISPs may use different allocations. – Allen4names 15:25, 9 February 2011 (UTC)

MediaWiki 1.17 release is tomorrow (hopefully)

Please remember that tomorrow morning February 8, 7:00 UTC will see the start of the deployment of MediaWiki 1.17. This can potentially cause; brief downtime, new bugs popping up or just new behavior that some people don't understand. If you think you see a problem, be sure to describe it as accurately as possible, so that it is easier to debug and potentially fix the problem. A full list of what has changed is available here. One of the big changes is the introduction of ResourceLoader. This can cause some older Javascripts to go bust, so if people report trouble, be sure to check/ask what kind of ancient scripts they are running, it might be something in there. —TheDJ (talk • contribs) 22:10, 7 February 2011 (UTC)

Oooh, the new changes look awesome. Some of them fix minor details that always bug me, like the purged article view not highlighting a tab. I just hope the unblockself bit doesn't lead to a drama-filled RfC on whether it should be left enabled for admins here. /ƒETCHCOMMS/ 22:42, 7 February 2011 (UTC)

I see we're still on 1.16wmf4. I asume there is a delay? — Edokter (talk) — 10:27, 8 February 2011 (UTC)

They have been working for hours now getting stuff ready. A lot of issues showed up when it was deployed to test.wikipedia.org. Roan should be deploying it for real, Real soon now ! :D —TheDJ (talk • contribs) 12:44, 8 February 2011 (UTC)

The new code is up now -- still in shakedown, so watch out for issues and beware load may be peaking a little for a bit! --brion 13:13, 8 February 2011 (UTC)

Special:Version was showing 1.17 but seems to have since dropped back to 1.16wmf4. Has the update been rolled back or is it just a caching issue on that page? the wub "?!" 13:46, 8 February 2011 (UTC)

Correct. The load spiked due to the change, and they had to roll back, in order to analyze what was causing the load. no known timeframe for a new attempt. Could be today, could be tomorrow. —TheDJ (talk • contribs) 13:54, 8 February 2011 (UTC)

Resource loader

1. Is the new resource loader that new feature where we no longer have to wait for 31 days before changes to ie. Common.css are visible?
2. I found one very annoying flaw to the resource loader: Chrome (actually the Web Inspector) no longer shows what file certain CSS is coming from. It all points to 'load.php' now, which makes debugging/tracing bad CSS virtually impossible. — Edokter (talk) — 13:31, 8 February 2011 (UTC)

Just add ?debug=yes to a page, and you enter debug mode, which bypasses resourceloader's code bundling and folding. BTW, it looks as if everything will be rolled back for now. more news later. —TheDJ (talk • contribs) 13:45, 8 February 2011 (UTC)

Redrose64's gripe list

Changes observed since about 13:10

• more slow loads, more timeouts, especially when saving an edit
• diffs no longer have the yellow/green or grey backgrounds to show which lines are changed or not
• diffs now show changed text using underlines and strikethrough instead of red text
• "New section" tab in talk pages now shows as "+" (this may confuse less experienced editors)
• "edit this page" tab now shows as "edit" (I guess I can live with that)

(nb: I use Monobook, because Vector gave me too much trouble when it became the default skin) --Redrose64 (talk) 13:57, 8 February 2011 (UTC)

More:

• Boxes of several types - including (but not limited to) infoboxes, navboxes, Template documentation, WikiProject banners have lost their borders
• Infoboxes are now aligned left instead of right, pushing the lead section down
• Template documentation has lost its green background
• In Special:Preferences, the items in the "Gadgets" tab now have cryptic names instead of descriptive. For example, "Add an [edit] link for the lead section of a page" is now shown as "<gadget-edittop>"
• The abovementioned "<gadget-edittop>" no longer works
• WikiProject banners are now full-width (I guess I can live with that)

--Redrose64 (talk) 14:05, 8 February 2011 (UTC) amended Redrose64 (talk) 14:15, 8 February 2011 (UTC)

• The changes have been rolled back (see special:Version), so obviously something went wrong - some of those issues might not be around in the proper rollout. I also noticed some changes to the watchlist, additions/subtractions are no longer green/red and, if I recall correctly, automatically generated section links aren't greyed out... –xeno^talk 14:11, 8 February 2011 (UTC)

This all seems to fall under, "Slow loading, caused some css and js to be missing". I doubt these are bugs. P.S. monobook can be fixed at later times, vector is the only thing that has true priority during a deploy I suspect. —TheDJ (talk • contribs) 14:25, 8 February 2011 (UTC)

Not long after my last post, it started to behave; but about 16:30 screwed up again. It's gradually returning to normal, but I've noticed a curious random variation in diffs regarding entirely new lines: sometimes they show in black on green as per pre-today, see File:Vpt redrose64 fetchcomms.PNG; sometimes, the text is red and boldfaced (like the changes in an amended line would be), see File:Vpt redrose64 boing.PNG; sometimes in black on white (don't have a screenshot of that yet). --Redrose64 (talk) 17:50, 8 February 2011 (UTC)

I think we should probably wait until 1.17 is up and /stable/ before we complain about display issues that might not be displaying as intended. –xeno^talk 17:52, 8 February 2011 (UTC)

When is the new version re-scheduled to roll out again? :| TelCoNaSpVe :| 15:21, 9 February 2011 (UTC)

See http://techblog.wikimedia.org/ –xeno^talk 15:24, 9 February 2011 (UTC)

Comments from Floydian

My Twinkle commands are missing from the header now, and "new section" is now a "+" (thanks to the accessibility gurus for activating that last blunder; did nobody learn from half the editors switching right back to monobook? Stop fiddlin' if it ain't broke!)

Suggest reverting to the previous media wiki version until the bugs are worked out for actual live release. - ʄɭoʏɗiaɲ ^τ _¢ 14:10, 8 February 2011 (UTC)

Also, if you take a look at my userpage, the edit count / summary / purge links are showing up below their normal location. - ʄɭoʏɗiaɲ ^τ _¢ 14:14, 8 February 2011 (UTC)

• A lot of MediaWiki pages (e.g. MediaWiki:Tagline, MediaWiki:Copyrightwarning, and MediaWiki:Copyrightwarning2 are defaulting to their normal text instead of the customized versions. Stifle (talk) 14:13, 8 February 2011 (UTC)

• • twinkle: slowness causing various css and js to be missing. Should not be a real issue.
  • +: That is actually the default under monobook, we have it changed locally however, to read "New message", see also MediaWiki:Addsection.
  • positioning: missing css due to load issues
  • mediawiki messages:again, load issues.
  • So all in all, nothing especially strange, and you insulted a few people who were not to blame. Please swing that blame hammer more carefully next time. —TheDJ (talk • contribs) 14:33, 8 February 2011 (UTC)

Reflist font size is too large. - X201 (talk) 14:34, 8 February 2011 (UTC)

Yes, it seems to have reset to the default ref style—with ↑ rather than ^. The font size is also, as noted above, unaffected by {{reflist}}. /ƒETCHCOMMS/ 16:05, 8 February 2011 (UTC)

And now it's just fixed itself, I think. /ƒETCHCOMMS/ 16:08, 8 February 2011 (UTC)

Clored backgrounds for diffs seem to be gone under Vector too since upgrading to v1.17! This whole upgrade strikes me as badly conceived and premature. How about ironing out those bugs before the code is actually deployed to live servers? If, as TheDJ wrote above, "A lot of issues showed up when it was deployed to test.wikipedia.org", that would suggest to me this update isn't ready for prime time yet. --Morn 17:12, 8 February 2011 (UTC)

Issues are supposed to show up, that's why you have multiple test fases, because you expect to find problems. Also "A lot" is rather relative. A better description might have been "Several issues popped up and they took a lot of time to fix them before a real deploy could be attempted" —TheDJ (talk • contribs) 19:13, 8 February 2011 (UTC)

• Tables with class=wikitable are also not displaying correctly. - ʄɭoʏɗiaɲ ^τ _¢ 17:09, 8 February 2011 (UTC)

"the administrator password"

Early versions of HomePage, such as the one visible at Nostalgia, have a message at the bottom of "Unless you have the administrator password, you cannot currently edit this page". In our early days, when we were still on UseModWiki, were admin rights exercised by logging in with a different password than with your normal one? I'm somewhat confused by the wording at the oldest extant version of Wikipedia:Administrators. Nyttend 13:43, 8 February 2011 (UTC)

Yes, I think so, but also see the FAQ on Nostalgia Wikipedia, particularly the question beginning "How do I keep from getting new user numbers ...". Graham87 14:31, 8 February 2011 (UTC)

There was one password for all administrative activities. Gigs (talk) 17:08, 9 February 2011 (UTC)

MediaWiki 1.17... attempt 2

Just a quick update: 1.17 is in place again, but it still seems to be causing server load issues (see http://ganglia.wikimedia.org/?r=day&s=descending&c=). So there may once again be issues, particularly with css, javascript and Mediawiki messages. the wub "?!" 17:08, 8 February 2011 (UTC)

And back to 1.16 we go [3]. Make sure to bypass your cache first if you're still seeing problems. 86.139.29.138 (talk) 17:17, 8 February 2011 (UTC)

Thanx for updating us here. Just curiuous: when goingover happens, is there a visible action? Seconds of ReadOnly mode, planned (or unplanned)? Just curious. -17:29, 8 February 2011 (UTC) — Preceding unsigned comment added by DePiep (talk • contribs)

Please create a test wiki, import the plugins from en wiki, and TEST CODE BEFORE IMPLEMENTING IT LIVE ON THE SITE. This is programming 101 guys. - ʄɭoʏɗiaɲ ^τ _¢ 17:39, 8 February 2011 (UTC)

Dont assume that the devs are clueless, they do exactly that. However some issues only occur during in high stress environments (aka live platform) that cannot be fully tested. ΔT _{^{The only constant}} 17:41, 8 February 2011 (UTC)

I don't. But hey, here I see someone called Brian Vibber busy with mobile stuff (brands named, and versions). I'd say: wow, isn't that testable then? (Not this about serverloads cluster CPU loads of course, which is the final's final test). -DePiep (talk) 17:54, 8 February 2011 (UTC)

Thats not the same code, that is trunk, the wmf1.17 branch was performed a while back. they are rolling out a wmf branch while development in trunk proceeds ΔT _{^{The only constant}} 17:58, 8 February 2011 (UTC)

OK with me, I'm just following & soaking the stuff (I would not like to sound different nor judging). Is there any extra log where the 1.17 current tech activities are visible? -DePiep (talk) 18:12, 8 February 2011 (UTC)

/branches/REL1_17 for 1.17 release, and /branches/wmf/1.17wmf1 for WMF deployment. And there's also other technical stuff going on that doesn't get committed into SVN. Reach Out to the Truth 04:28, 9 February 2011 (UTC)

(e/c)You mean like how they did exactly that over here? Mr.Z-man.sock (talk) 18:00, 8 February 2011 (UTC)

and test wiki ΔT _{^{The only constant}} 18:07, 8 February 2011 (UTC)

I don't assume them as clueless. However, server load issues aside, failing of the basic javascript and css that make the site look right is indication of faulty code, not too high of a load on the server. I don't see how that couldn't be seamlessly transitioned, without even a blink. Slow loading pages is understandable; borked front page is not. - ʄɭoʏɗiaɲ ^τ _¢ 18:13, 8 February 2011 (UTC)

I think this is a good point. Apart from "they work hard" (noone neg on that), what actually happened? -DePiep (talk) 18:41, 8 February 2011 (UTC)

@floydian, like I stated above, failing scripts and css were a direct consequence of the load issues. The Foundation is already in the process of building future improvements to the testing environment and the deploy environment, exactly to be able to stress test and detect issues like this in advance. This whole thing is just showing how badly we actually NEED that technology investment.

How about people remember that Wikipedia was a small website managed by one person and is now a top5 collection of websites, with basically still the same deploy technology of 8 years ago, making it a wonder that we actually run AT ALL. Breakage is no more than expected at software deploy cycles at this moment in time (Even with more advance testing than ever before), which is why there are 5 highly skilled people already working on this for 18 hours or something. Technology wise, Wikipedia is like Facebook. Resource wise, they are like David and Goliath. It annoys me that people continuously seem to forget this. —TheDJ (talk • contribs) 19:08, 8 February 2011 (UTC)

@dePiep, read the weblog, read the IRC channel and all the other usual places. There is no up to the minute info other than that, ppl are trying to work I presume. I know where to look as a volunteer dev, if you want to follow system operations this detailed, you can follow it just as well, but for most people it's totally uninteresting and worse non-understandable. —TheDJ (talk • contribs) 19:08, 8 February 2011 (UTC)

1.17 includes a major change as to how JS/CSS is served. All (or most) is now concatenated and minified, rather than served as individual static files. This also includes the beginning of a switch to more object-oriented JS; moving away from having a ton of functions in the global scope. Once it works, it should be an improvement. But this means that more of it has to be filtered through programs on the server before being served, so it's more susceptible to load issues. And when it comes to JS, one file breaking can cause everything else to break. Mr.Z-man.sock (talk) 19:22, 8 February 2011 (UTC)

Really, thanx. None of the testsites were known to me as a WP:VPT local. But for example "to more object-oriented JS; moving away from having a ton of functions" says it. -DePiep (talk) 20:18, 8 February 2011 (UTC)

1.17 deployment is postponed for now. See: http://techblog.wikimedia.org/2011/02/1-17-deployment-postponed/ --Eloquence* 18:40, 8 February 2011 (UTC)

I think that they should put it live at 18:00 EST (23:00 UTC), so that (a) the evening editors in Florida get to give it a proper shakedown and (b) I'm safely tucked up in bed. --Redrose64 (talk) 20:01, 8 February 2011 (UTC)

After reading through the notes, it looks like bugzilla:1211 will finally be patched. Finally! No more losing subcategories. ▫ JohnnyMrNinja 06:55, 9 February 2011 (UTC)

again: set maintenance dates in kowiki articles

Hi. i`m from ko.wikipedia. I recently created Template:Dated maintenance category on ko.wiki. but, i can`t categorize former articles that did not appointed date. so, i want to appoint date with my bot ko:wiki:user:Altobot. How to command to my bot to appoint date on maintenance template? Of course, i don`t know when the templates attached.--Altostratus (talk) 05:53, 9 February 2011 (UTC)

• You might want to just edit them by hand, trying to focus on the most valuable articles, as the first priority. Use the 80/20 Rule to focus on the top 20% of articles, and try to guess which articles are important enough to even bother to set each "maintenance date" inside them. Note the complexity of bot-selected dates: what if an article has multiple maintenance tags set at widely different dates? If setting maintenance-dates is that critical, it might be close enough to just set most of them to an arbitrary month, such as "November 2010" as a baseline. As the months and years go by, then "November 2010" will likely seem like a long, long time ago. For English Wikipedia, an article can be pageviewed 27,000 times before someone fixes the simple, glaring errors ranted by a top tag-box. That is why some vandalism lasts over 2 months, 6 months, or 2 years in articles: many people do not care. In fact, moving some maintenance vanity tag-boxes to the end, of each article, might be the most-important function a bot could ever perform, as a way to lessen the distraction for the 26,999 readers who will not be fixing the ranted problems. -Wikid77 06:23, 10 February 2011 (UTC)

MediaWiki:Gadget-searchbox.js

Hello, I've installed wikt:fr:MediaWiki:Gadget-searchbox.js from wikt:pl:MediaWiki:Gadget-searchbox.js. It adds the text treatment functions: "go to line n°", "change the capitalization", "search and replace" (eventually "replace all") and sort alphabetically. JackPotte (talk) 20:39, 9 February 2011 (UTC)

str_replace function

There is a need to be able to display certain things with non-breaking spaces. Consider: lat/long 51.478030°N 0.001954°W / 51.478030; -0.001954, UK & Ireland grid refs TQ 388 773, dimensions 137 metres (150 yd) and ISBN 0 12 345678 9. For all these things it would be very useful to have a function in wiki markup to convert spaces to non-breaking spaces (or a full str_replace() function). It would certainly make life easier for the people working on the vast {{convert}} family of templates - in my example above there is an nbsp between 137 and metres but not between 150 and yd! See also - this moan about Wikipedia's ageing bureaucracy! Is there such a function? — RHaworth (talk · contribs) 21:58, 9 February 2011 (UTC)

Ew, please no. Just use white-space:nowrap; CSS in the rare cases where wrapping would make a bit of difference. ―cobaltcigs 22:46, 9 February 2011 (UTC)

FYI:

bugzilla:26092: Enable or install string parsing wikimarkup functionality on WMF wikis

bugzilla:235: Auto unit conversion

Helder 23:00, 9 February 2011 (UTC)

And as {{convert}} takes the number and unit separately, you can just use &nbsp; directly. OrangeDog (τ • ε) 23:19, 9 February 2011 (UTC)

Many thanks (again!) - white-space:nowrap; does the trick. — RHaworth (talk · contribs) 00:25, 10 February 2011 (UTC)

CSS Font Issues

I prefer serif fonts to sans-serif fonts, so when I figured out how to use CSSs, I changed my vector.css so that Wikipedia renders in Times New Roman. However, for some reason, I cannot change the font for classes of text like IPA and Unicode. Oddly enough, I can change the color of them, but not the font. I have tried to change my IPA font to Times New Roman (my computer has Times New Roman IPA characters) and several of the approved fonts, but I have had no success; IPA text always renders as Arial. My browser, if it makes a difference, is Mozilla Firefox version 3.6. Lunaibis 02:06, 10 February 2011 (UTC)

Winfixes.css (which declares the IPA fonts) is loaded by common.js, which is loaded after your vector.css. So you may need to use !important;. I have made the change for you (and fixed some errors). — Edokter (talk) — 02:30, 10 February 2011 (UTC)

Thanks a million! I never would've gotten that. I'm sure I'll make use of that in the future, too. Thanks for being so fast and so ... correct! Lunaibis 02:35, 10 February 2011 (UTC)

I don't like the "new" Wikipedia

I was editing around 17:00 UTC on 8 February 2011. It appears what I am about to say is related to some comments made on this page at that time.

I saw the word "page" beside "discussion" instead of the word "article", the word "Summary" next to where the edit summary goes rather than "edit summary", large arrows pointing up beside every reference, and numbers with decimal points rather than letters where references were used multiple times. Later in the day Wikipedia seemed to be back to "normal" and has been ever since. I wasn't sure if it was because at 17:00 on 8 February I was on Mozilla Firefox rather than Internet Explorer 8, though my last experiences on the computer where I used that were normal.

I'm hoping this isn't a sign of planned changes.Vchimpanzee · talk · contributions · 19:22, 10 February 2011 (UTC)

There were issues the other day, and it's probably best to wait until 1.17 is up and stable before commenting about - what you saw was probably a display issue related to the problems. See http://techblog.wikimedia.org/2011/02/post-mortem-on-last-nights-1-17-deployment-attempts/ for more details. –xeno^talk 19:28, 10 February 2011 (UTC)

Okay, thanks.Vchimpanzee · talk · contributions · 19:33, 10 February 2011 (UTC)

The arrows, at least, is probably a symptom that the vector.css (or monobook.css or even just common.css) file, which stores all the information that makes the various "themes" look different, wasn't loading properly. It's possible the other changes could also be related to that, but I wouldn't know. —Soap— 21:52, 10 February 2011 (UTC)

Unsolicited new password

I've had one of those "This IP asked us to send you a new password - here it is" emails. It says "If someone else made this request... you may safely ignore this message," but I am uneasy, as email is not that secure and the new password is not a very strong one. So my question is: is there a way to disable this new password? I have changed my main password - will that have done it? JohnCD (talk) 20:56, 10 February 2011 (UTC)

I suppose you could use the new randomly generated password and then set it back to what you had before. –xeno^talk 20:57, 10 February 2011 (UTC)

Good idea - I reset it to the unsolicited one and then reset it again to a new one. Thanks. JohnCD (talk) 21:13, 10 February 2011 (UTC)

Download as PDF and Convert Template

There is a ticket for this issue.

"Download as PDF" is a useful tool for those who want to print an article with an attractive format. Template:Convert is an excellent tool for ensuring that measurements such as lengths, weights, areas and temperatures in an article are given in units that most readers will understand, whether they live in the USA or elsewhere. When rendering into PDF an article such as Cameroon line which uses the "convert" template extensively the result is text like:

• ...San Carlos is 2,260unknown operator: u','unknown operator: u','(unknown operator: u'strong' ft) high
• ...with annual rainfall in some locations of 10,000unknown operator: u','unknown operator: u',' ( in).
• ...The climate is tropical at lower altitudes, becoming about 1 °C (1.80 °F) cooler ...

The browser view is:

• ...San Carlos is 2,260 m (7,410 ft) high
• ...with annual rainfall in some locations of 10,000 mm (394 in).
• ...The climate is tropical at lower altitudes, becoming about 1 °C (1.80 °F) cooler ...

PDF rendering of the template works with some units, but not others. Any chance of a fix? Aymatth2 (talk) 23:57, 10 February 2011 (UTC)

I've reported this issue to the book tool developers.--Eloquence* 03:16, 11 February 2011 (UTC)

• The issue seems to be the &nbsp used by Convert, which becomes &#160 in the text, as: "San Carlos is 2,260&#160;m (7,410 ft) high". Most text does not use &nbsp, so it becomes more common in conversions. -Wikid77 05:46, 11 February 2011 (UTC)

It's a known issue. See box in the top-right corner.Headbomb {talk / contribs / physics / books} 06:01, 11 February 2011 (UTC)

Clock ?

In the top right corner I see a clock, and in my preferences I have selected the correct time zone for my location. Nevertheless, the clock is 1 hour off. What am I doing wrong? ≡ CUSH ≡ 09:01, 8 February 2011 (UTC)

If you added the clock via the "gadgets" tab in your preferences, that's normal. The clock shows the time in UTC (aka GMT), which mainly helps you to check when posts on talk pages were made (since they are always signed in UTC time). Regards SoWhy 09:11, 8 February 2011 (UTC)

Hmm, shouldn't the clock respect the time zone I set? ≡ CUSH ≡ 09:21, 8 February 2011 (UTC)

No, that gadget only works in UTC. However, it should be almost trivial to modify the code at MediaWiki:Gadget-UTCLiveClock.js to reflect any particular timezone (I don't know js, but I'm assuming), and then you could put that code into your own .js user subpage. Someguy1221 (talk) 09:36, 8 February 2011 (UTC)

The point of the gadget is to allow people to have a clock that shows them the respective time in UTC, thus allowing them to be able to better understand when posts were made to talk pages etc. I doubt there is any need for a time-zone-specific gadget though. All operating systems I know of have a clock integrated in their respective task bars, so you could just use that one to check the time. Regards SoWhy 09:58, 8 February 2011 (UTC)

The clock gadget always has, and should display your local time. Are talk page posts showing up as being posted an hour earlier as well? If so you may just have your timezone set wrong in your preferences. The current server malfunction probably isn't helping. - ʄɭoʏɗiaɲ ^τ _¢ 14:22, 8 February 2011 (UTC)

No, "always has" is very wrong. The entire point of the gadget is to show the UTC time, as SoWhy said above (even the description of the gadget says as much). Given that Cush lives in the EU, it's understandable why (to him) the clock would only appear to be off by an hour; I'm in the US, and while the clock is showing 20:49, it's only 14:49 here. EVula // talk // ☯ // 20:50, 8 February 2011 (UTC)

It shows UTC for me now. Before the updating they were doing the other day, however, it was definitely displaying EST for me. Now it makes my mouse cursor tick. - ʄɭoʏɗiaɲ ^τ _¢ 13:32, 11 February 2011 (UTC)

PDF help please

For some reason, my computer keeps insisting on opening PDFs as separate documents, rather than opening them in the same window or a tab. I'm running Windows XP, Firefox and Adobe Reader X.

I get no option to "open window" or anything similar. I usually have 3 or 4 windows open when editing and I cannot cope with having another 2 or 3 separate PDFs open, it is a particular problem as there is no url displayed which makes this arrangement useless for referencing. Mjroots (talk) 09:29, 10 February 2011 (UTC)

See Tools->Options->Applications for configuring this behaviour in Firefox. OrangeDog (τ • ε) 15:40, 10 February 2011 (UTC)

Tools > Options > Applications is configured to use Adobe Reader. Mjroots (talk) 19:13, 10 February 2011 (UTC)

Change it to "Adobe Acrobat (in FireFox)". If that option isn't there, re-install acrobat reader. This is not caused by anything related to Wikipedia, so this is not the correct forum. OrangeDog (τ • ε) 20:21, 10 February 2011 (UTC)

Adobe reader uninstalled and reinstalled, setting changed which seems to have cured the problem, thank you. I had a similar problem before and asked on the Help Desk, and was told to come here next time. If this is not the correct venue, where is? Mjroots (talk) 07:33, 11 February 2011 (UTC)

Wikipedia:Reference desk/Computing might give you better answers. Titoxd^{(?!? - cool stuff)} 07:36, 11 February 2011 (UTC)

Hopefully it won't be necessary to have to ask again, but I'll head there in the event that I need help again. Mjroots (talk) 07:38, 11 February 2011 (UTC)

Automated edits

What'w Wikipedia's policy on automated editing? Not as a bot, but as a user. I have a Java framework which uses the API to make edits. I've kept it so I can mass edit any time I want. As I'm not a bot, is mass editing allowed (I keep a delay so that I don't hit the api rate limit)? I mainly would need this for talk pages, and that too, I'll only do around ten at a time. ManishEarth^{Talk • Stalk} 12:11, 11 February 2011 (UTC)

Depends. How automated is what you plan to do? Compare WP:AWB and various JS floating around. Also, [4]. MER-C 13:46, 11 February 2011 (UTC)

Not as automated as AWB. Basically, if I want to message a few twenty-thirty people or so, it's easier to just use a forloop. ManishEarth^{Talk • Stalk} 14:04, 11 February 2011 (UTC)

If you want to be completely on the safeside, you could file a WP:BRFA. However, if it's similar to a task that would be performed with AWB, you pause between edits (say 5 to 10 seconds), have the consent of the folks you are messaging, and don't run it unattended, you probably won't have any problems. There is an edit speed limit, but if you pause by around 5 to 10 seconds between edits, and aren't performing massive numbers of edits, you will probably be okay. Plastikspork _―Œ^(talk) 01:55, 12 February 2011 (UTC)

A BRFA won't work, as I use my own account. I use User:MER-C 's framework, which has a throttle setting, which I've kept at the default 5 seconds. I was mainly using it for welcoming new users at WP:ONLINE, so I don't think I need consent. Anyways, I only do about seven in one method call, so I can easily monitor what happened. ManishEarth^{Talk • Stalk} 02:33, 12 February 2011 (UTC)

Are you actually reviewing each edit? If not, then it's a bot regardless of the edit rate. From the bot policy, "Any program or tool which does not allow the user to view each edit and give an instruction to make that edit (that is, one which can edit without the operator looking at and approving the change) is considered to be a bot." Mr.Z-man 03:30, 12 February 2011 (UTC)

No, I see all the edits. That's why I don't go over ten iterations in one method call. ManishEarth^{Talk • Stalk} 05:41, 12 February 2011 (UTC)

RfC to change MediaWiki:Common.js for archived citations at Wikiwix

Based on the conversation here, I started an RfC to achive websites at Wikiwix, which requires modifying MediaWiki:Common.js. As this is a major change to Wikipedia, I am posting this information in several places to make certain everybody is notified. Thanks. - Hydroxonium (H₃O⁺) 15:22, 11 February 2011 (UTC)

NRHP infobox template map

Has something happened in the last day or so to affect the map push pin labels of the NRHP infobox? I've noticed that the map included has no label for the red push pin dot in the middle of the map. I've done a number of them lately, and I'm pretty sure that red push pin had label-until today. Here's a couple of examples of ones where the pin label disappeared: Fredericksburg Historic District (Texas), and Wrede School, Gillespie County, Texas. Here's one, a different infobox, where the pin is accompanied by a label (at least, as of my writing this): Zodiac, Texas. So, what happened? What's the point of having the push pin, if the reader doesn't know what it is? Maile66 (talk) 23:52, 11 February 2011 (UTC)

I checked the template, and there have been no recent edits (since December 2010). Are you asking about the label next to the pin or the caption below the map? For the caption, you use |map_caption=. For the label next to the pin, the "label" parameter would need to be passed to {{Location map}}, but right now, no label is passed. Plastikspork _―Œ^(talk) 01:51, 12 February 2011 (UTC)

The label next to the pin. How do we get the label parameter passed to the location map? Seems a bit incomplete otherwise. Maile66 (talk) 01:54, 12 February 2011 (UTC)

I would say request it at Template talk:Infobox NRHP, and if there are no objections, let me know and I will add it. Plastikspork _―Œ^(talk) 03:21, 12 February 2011 (UTC)

How many wiki-years does it take to change a lightbulb

I have noticed, over the past year, that some simple, but technical {editprotected} update requests, for template changes, go 2 or 3 days without being changed. Would it be possible to have a "technical-editreq" category to request protected-updates to be made by admins with strong wiki-technical experience? I'm not sure if delays are due to wiki-burnout because of "too many" templates, or too many fully-protected pages, or too many newbies flooding the system with bizarre protected-update requests. Meanwhile, some people have complained directly, "Hey, this is a wiki" (as in: multiple people are allowed to change almost anything in a real wiki). Yet, some people want highly shocking, warped, twisted changes to be made, so there need to be limits. Meanwhile, changes in enwiki have been so frustratingly S-L-O-W that I have even (ab)used Simple English Wikipedia as a testbed, to test multi-template changes, because enwiki updates are so restricted and so slow. I can understand that most admins would be terrified of changing templates (if you read 20 template-update requests, the staggering twisted, complexity becames obvious). So, changing 200 {{Convert}} subtemplates requires a lot of snail-hail. What to do? -Wikid77 05:39, 10 February 2011 (UTC)

Creating another template would just result in fewer eyes on these changes, which probably wouldn't help. I'd suggest finding a few tech-savvy admins and pinging one or two of them right after putting up the {{editprotected}}, to help it get dealt with faster. Cheers. lifebaka++ 12:17, 10 February 2011 (UTC)

Most templates have /testcases and /sandbox pages, just for this reason. The links at the bottom of the documentation boxes of a template even allow you to create them yourselves. In the past I handled many of these requests a day, but lately i've been too busy, bringing the admin core dealing with these things down to about 2 people I fear. When people are busy, they are busy unfortunately. I say, more tech admins, consider nominating yourself ? :D —TheDJ (talk • contribs) 17:37, 10 February 2011 (UTC)

1): Wikid77: you are not an admin??? 1} theDJ: the Q reads as if Wikid has everything prepeared, but needs some (mass) introduction. Actually, theDJ, your pushback is not a reply at all (who ever could say: "you go back to the sandbox" here?). 3) Wikid: I'd say: befriend an admin, or try WP:TASKFORCE. 4) I think {{convert}} will need a mass, architectureal overhaul. Not a minor 200 T:changes detail. 5) Wikid: nothing will change. Those who wrote the regulations, are now admin. No example of policy/guidelines change in two years. -DePiep (talk) 18:05, 10 February 2011 (UTC)

This isn't really answering the question but maybe we could create a user group of technically minded editors with privileges to edit intricate templates. This way users like Wikid77 could, without being made admins, just go ahead and edit the templates themselves. — Blue-Haired Lawyer ^t 22:25, 10 February 2011 (UTC)

Indeed it does not answer the Q (your contribution is appreciated). This is WP's future: someone who knows well & does well (like Wikid77) gets bogged down in upper layers of adminship. As Joseph Conrad wrote: they do the Central Station. -DePiep (talk) 22:42, 10 February 2011 (UTC)

I don't see the problem, he can try to become an admin if he wants. It's why I became an admin at the time. We have limits for a reason. The templates Wikid77 tends to edit are used in many tens of thousands of articles. You want free for all instead ? There are few technical minded people around, and those who need admin access can usually get it if they present a good case and show a history without bad behavior. It's not easy, but nothing in the real world of a top5 website really is, we're not in Kansas anymore Dorothy. We have testpages and sandboxes for testing, so ppl don't test on live templates before they are sure it works. We have test.wikipedia.org for when things need to be tested live, yet not en.wp live. We are also not on a timetable, we have plenty of time to finish the wiki, so some delay in deploying your tested material should not be a problem. There are plenty of options. —TheDJ (talk • contribs) 00:43, 11 February 2011 (UTC)

So you naughty daring Wikid77, go back to the sandbox. Just how stupid you did not understand this beforehand. When you grow up, you'll become an admin and that day you'll know everything about templates and so. All your sandbox castles will become real. -DePiep (talk) 01:30, 11 February 2011 (UTC)

It sounds like you may want to change dozens of templates. It would help if you had a single document that summarized all your planned changes. You could write up your plans at Template talk:Convert and post a comment here at VPT asking others to review your plan. Some of the reviewers might be admins => maybe solve two problems at once. EdJohnston (talk) 01:33, 11 February 2011 (UTC)

re theDJ, EdJohnston, Lifebaka: you do not get it. Wikid77 is a good editor, and cannot get their improvements ahead. The fact that even good admins like you see the world this way, says it all: adminsmind has taken over. This is "Central Station"-DePiep (talk) 01:44, 11 February 2011 (UTC)

I perfectly well get it dear DePiep. I just accept reality and other people choose to stand on their soapboxes instead of writing/managing an encyclopedia. Start a constructive reform process, start your own encyclopedia, or accept reality. They are easy choices, but I can tell you from experience that this whining will get you nowhere (not in any large project be it wiki or not). —TheDJ (talk • contribs) 15:53, 12 February 2011 (UTC)

To Wikid77, I know this isn't necessarily the point, but I am sure you know you can always drop a note on my talk page. If I am around, I will try to help if I can. I don't always remember to check the protected edits category. Thanks! Plastikspork _―Œ^(talk) 02:20, 11 February 2011 (UTC)

• Good, I will try to coordinate with some admins before I submit an edit-protected request, to allow time for faster response. If I submit several changes at once, then it won't be like spamming for each single edit-request multiple times. I had imagined there were more admins than there seem to be, as if I were in a vast dark room, imagining 75 people out in the darkness, when only 5 existed. -Wikid77 05:46, 11 February 2011 (UTC)

To Wikid77: It isn't clear what you want to do. Apparently you want to make improvements to {{convert}}, but I do not see any discussion on the template talk page. Before you put a lot into this template, you should look at the proposed convert magic word in revision 81074 that would replace the template. ---— Gadget850 (Ed) ^talk 05:46, 11 February 2011 (UTC)

Too much bannerage. Please allow me to suppress all banners

It used to be that banners were rare. The intrusions were tolerable and effort to dismiss the banners was low/infrequent. Unfortunately, the banner frequency has increased to the point where I sometimes get multiple banners on login. This is very frustrating, particularly if I'm on a slow connection on a small device with limited time. I don't want to work so hard to get rid of stuff I don't want. My preferences are set to: 'Suppress display of the fundraiser banner' but how do I set my account to 'Suppress all banners'? Lightmouse (talk) 13:52, 11 February 2011 (UTC)

What banners ae you seeing? I haven't seen any since the fundraiser ended. ---— Gadget850 (Ed) ^talk 15:54, 11 February 2011 (UTC)

I've dismissed them so I can't quote them. I can't find them to tell you what they were. Stuff about meetings, volunteering, stuff I can help with, take part in. Where is the banner spam control room where they decide which banners to show? Lightmouse (talk) 19:25, 11 February 2011 (UTC)

Are you referring to the messages shown in the "Watchlist options" box at the top of your watchlist? At the moment I have three:

• The Wikipedia Ambassador Program is looking for experienced Wikipedians to be Online Ambassadors.
• The Great Backlog Drive has just begun – help clear Wikipedia's backlogs for the next six weeks for the chance to win Wikimedia goodies!
• Volunteers are sought for the Wiki Guides study looking at the effect of directly reaching out to new editors. Come learn more, volunteer or just share your own new user experience on the talk page.

--Redrose64 (talk) 19:32, 11 February 2011 (UTC)

I can't remember because I try my best to ignore them. But that looks exactly like the sort of thing. Lightmouse (talk) 19:36, 11 February 2011 (UTC)

Those all have a dismiss link that works for me. ---— Gadget850 (Ed) ^talk 19:53, 11 February 2011 (UTC)

• Special:Mypage/skin.css, add -

div.watchlist-message {
    display: none;
}

You can find other crud to hide in User:Xeno/monobook.css. Watchlist messages are discussed here. Cheers, –xeno^talk 19:59, 11 February 2011 (UTC)

Thanks. I might try the skin. In the meantime, I've posted at MediaWiki talk:Watchlist-details asking for additional 'Suppress' options. Thanks Lightmouse (talk) 09:45, 12 February 2011 (UTC)

Cannot view m:Talk:Spam blacklist: empty page

When visiting m:Talk:Spam blacklist, I see the page content display as the page loads but when loading is complete the page blanks completely. There are no errors in Firefox's error console. Purging the browser and server cache does not solve the problem. I use Firefox 3.6.13. The HTML is still accessible through view source. Meta is using MW 1.17 and the new ResourceLoader since yesterday, which I vaguely remember is when the problem started. I can't reproduce this problem with the few random other pages on Meta I visited. (I can still edit the page, but I need to be quick to stop the page from loading completely.)

Anyone else experiencing this problem? MER-C 03:35, 12 February 2011 (UTC)

Yes, I see the same problem. Running either Firefox or Safari 5.0.3 on a Mac, the page disappears after it finishes loading. EdJohnston (talk) 04:53, 12 February 2011 (UTC)

Despite having made the last edit to the talk page in question, I can confirm that I had the same issue with both the talk page and the main blacklist page, and that I had that problem prior to my large edit. Meta has just upgraded to to 1.17, and there's probably some issue with very long pages, as both the blacklist and the talk page are. It is plenty annoying. — Gavia immer (talk) 05:01, 12 February 2011 (UTC)

Not an issue with very long pages, see m:User:Anomie/Sandbox. It seems to have something to do with m:User:Pathoschild/Scripts/AJAX_transclusion_table.js, I haven't tracked it further than that yet. Anomie⚔ 05:15, 12 February 2011 (UTC)

Ok, I think I found it. In m:MediaWiki:Common.js at line 246, the document.write causes the entire content of the page to be lost. It's only triggered when a table on the page has class="attable", or it would be happening more often. Anomie⚔ 05:23, 12 February 2011 (UTC)

You are correct, and that is exactly what I was going to post. The reason why it does not work is that the document.write() is within a function passed to addOnloadHook(). Before MW 1.17, onload hooks were run at the end of the body by <script type="text/javascript">if (window.runOnloadHook) runOnloadHook();</script>, allowing document.write to work. Now, old-style (pre-jQuery/RL) onload hooks are run after the page has finished loading using hookEvent('load',runOnloadHook);. The fix would be to replace document.write() with importScript() or the mw.loader equivalent. PleaseStand ^(talk) 06:03, 12 February 2011 (UTC)

So if you need to edit the Spam blacklist talk page in the meantime, turning off Javascript in your browser should work. EdJohnston (talk) 06:47, 12 February 2011 (UTC)

I think this fixed it. --MZMcBride (talk) 07:42, 12 February 2011 (UTC)

I can confirm that this is now working fine for me. — Gavia immer (talk) 07:52, 12 February 2011 (UTC)

Ditto. MER-C 08:22, 12 February 2011 (UTC)

Templates on .css and .js pages

Do templates like {{db-u1}} work properly on .css and .js pages? My recollection is that they do transclude and add categories, but they don't display properly. There is a question at WT:Criteria for speedy deletion#Deletion of css and js user pages. Flatscan (talk) 05:15, 12 February 2011 (UTC)

Xeno confirmed that the template will add Category:Candidates for speedy deletion by user properly. Flatscan (talk) 05:26, 13 February 2011 (UTC)

JavaScript may break on your wiki: Fix it before that happens

Cross posting this from the mailing lists. the wub "?!" 10:16, 12 February 2011 (UTC)

Note: The original posting in the mailing list archive can be found here. Killiondude (talk) 06:38, 13 February 2011 (UTC)

Greetings,

As you may know, the Wikimedia tech team has started to upgrade MediaWiki on some wikis. MediaWiki is the software that runs all Wikimedia wikis.

The most visible change for Wikimedia users will be the deployment of ResourceLoader.

ResourceLoader optimizes the use of JavaScript in MediaWiki, speeding up its delivery by compressing it sometimes, and cutting down on the amount of unused JavaScript that gets delivered to the browser in the first place. The installation of ResourceLoader may cause compatibility issues with existing JavaScript code.

Trevor Parscal and Roan Kattouw, the main developers of ResourceLoader, will be available on IRC on Monday, February 14th, at 18:00 (UTC) (all timezones), to answer questions and help fix issues related to ResourceLoader.

If you maintain JavaScript code on your home wiki, please attend. Don't wait until your wiki's JavaScript is all broken.

Please spread this information as widely as possible; it's critical to reach as many local JavaScript maintainers as possible.

Logs of the session will be published publicly.

-- Guillaume Paumier Product manager - Wikimedia Foundation

To qualm any concerns, most of the scripts on En.wp are rather up to date and well maintained. Any issues on this wiki are more likely to occur from outdated and badly written userscripts, and perhaps a gadget here and there. However if you are active on other wiki's, do keep your eyes peeled for issues, and it might be a good idea to go trough all of the custom JS to look for obvious errors (Usage of document.write being one most obvious issues you can find). —TheDJ (talk • contribs) 15:45, 12 February 2011 (UTC)

Text and media content overlap

Overlap of text and media content

Hi, when viewing articles on countries (e.g. Slovenia, Germany etc.) the media content partially overlaps with the text. See the image to the right. Should this be reported to Bugzilla or is there another way to resolve this issue. --Eleassar ^{my talk} 16:00, 12 February 2011 (UTC)

I don't see the problem, so it is probably a browser specific bug. — Edokter (talk) — 16:09, 12 February 2011 (UTC)

For me the player does extend outside the infobox to the right side in both FF4 beta and Chrome. — Carl (CBM · talk) 16:30, 12 February 2011 (UTC)

There are two issues here. It overlaps the text above it bugzilla:27365, should be fixed reasonably quickly, and the fact that the player has a minimum width of 250px. There is a proposal for a less wide "audio player mode" bugzilla:21996, but that will take some while. Besides, the default html5 players of firefox/opera/safari have similar issues in that they have a minimum width of 150 - 200 px. —TheDJ (talk • contribs) 16:39, 12 February 2011 (UTC)

Settle this: HTML comments do not hinder performance

This is your MediaWiki preprocessor ready to format a template in an article.

This is your preprocessor skipping past HTML comments in a template: lightning fast.

I am looking for a technical essay, or message thread, that explains HTML comments are harmless to performance unless "20,000" are placed in an article or template, or placed outside <noinclude> tags in a subst'd template. Can anyone recommend some good discussion or essay pages to settle these fears about using HTML comments? Or let's settle the issue here. -Wikid77 05:39, 10 February 2011 (UTC)

The best thing to do is just tell people to view the HTML source of a page. HTML-style comments in the wikitext of a page aren't included in the rendered HTML page served to viewers regardless, although some other material is included in comment tags in the rendered version. — Gavia immer (talk) 05:48, 10 February 2011 (UTC)

• Good idea. When people set their browsers to <View><Source>, or similar, they can see how the HTML-style comments were totally omitted (unless subst'd). I have added the 2 greyhound photos, as an analogy, to show just how quickly the comment lines are skipped by the preprocessor. I like the 2nd photo, for how the dog is flying over "the HTML comments" without touching. -Wikid77 07:10, 10 February 2011 (UTC)

• It sounds like you're ready to write that essay yourself. You should if you're willing to, then bring it back here for comments. Cheers, ʄɭoʏɗiaɲ ^τ _¢ 13:54, 10 February 2011 (UTC)

• Do we even need an essay about this? Isn't WP:PERF enough? Svick (talk) 16:33, 13 February 2011 (UTC)

Well, I think some people fear the use of more than 20 comment lines in a template, so they tend to find ways to delete important comments from templates (I know that sounds OCD, but they do delete the comments). Evidently, saying, "Don't worry," doesn't work with them because they know in reality, worrying is extremely important for many issues, and they can't fully live in the imaginary Wikiverse; hence, they worry in superstitious ways about performance. I mean, 20 different way-out-there superstitions about writing templates (such as thinking 14 nested if-else levels won't matter, but all parameter names should be 1-letter names, or whatever). Long story short:

• Can someone who knows the workings of NewPP reassure us that the preprocessor skips, quickly, from "<!--" looking only for "-->" or be honest and tell us, "No, all words in comments are emailed from Florida to England to update usage counts for the OED analysis, and any sentence containing the word "tag" is emailed to the HTML Deprecation Committee in preparation for a Krist-Tag-Nacht raid on all webpages that still use the "<font>" tag to set font attributes".

I don't want to make the mistake of saying (again), "Use <nowiki> tags, because they are tiny with no overhead and preserve spacing for use anywhere (NOT true)", where, instead, the reality is that nowiki-tags bloat a page with 88-character markers that will kill a calculation expecting numeric data. So, I was hoping for someone to confirm if HTML-style comments are rapidly skipped (except inside subst'd markup), and reduce people's extreme fears that comments must be deleted to make templates run much faster. -Wikid77 20:23, 13 February 2011 (UTC)

It is not hard to deduce what happens with HTML comments in templates; they simply disappear. The PP simply ignores these, and no operation in computing is faster then ignoring something. — Edokter (talk) — 20:33, 13 February 2011 (UTC)

See for yourself: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Sanitizer.php?revision=81330&view=markup#l549 Anomie⚔ 21:52, 13 February 2011 (UTC)

Linking to foot of page

WP:ANCHOR tells us that #top and #toc link to the top and table of contents of the current page (though this warns us that #top only exists in some skins). By prowling around I have found that #footer links to the foot of the page (but do footer {{navbox}}s come into it?). I have tried it here and it could be useful in situations like this. I'll document #footer in WP:ANCHOR if it is a supported feature of the Wikimedia software. Is it? Are there any other preset anchors? Thincat (talk) 10:31, 10 February 2011 (UTC)

I have just noticed that #footer is used in the template transcluded at the top of this page (WP:VPT). However, I am still interested in its status. Also, is the remark about skins correct? Thincat (talk) 10:41, 10 February 2011 (UTC)

The #toc anchor will only exist if the page has a table of contents. There are, in fact, a surprising number of anchors which may be jumped to: to see what I mean, go to any page, and view the page source. Look through the HTML for the id= attribute; these are the anchors (from HTML 4.0 on, any tag may bear the id= attribute, so you're not looking for <a>...</a> tags with the name= attribute the way you would prior to HTML 4.0). If I do this for a very short page, I see that there are well over 60; most of these are for items in the menus along the top, down the side, even the copyright box at the bottom. For example, in Monobook skin, #p-search should move to the word "search" just above the search box.

The #footer anchor doesn't take you to the end of the article content; in fact it goes well past that point, to the start of the box with yellow (in Monobook anyway) border, which contains the "Text is available under the Creative Commons Attribution-ShareAlike License ..." stuff. The last anchor that's actually in the editable page content is #catlinks, which appears to be valid even if there are no cats (if there is at least one category, #mw-normal-catlinks is also declared immediately afterward).

Other than #top, #toc (which doesn't appear in all pages) and #catlinks, there are no other useful predefined anchors (there are about ten more within the editable content, but most are at or before the title heading, so duplicate #top). --Redrose64 (talk) 14:16, 10 February 2011 (UTC)

Using the null anchor (<a href="#">link text</a>) should jump to the absolute top of any page, regardless of said page’s content. However, it is impossible to create such a link using wiki-text (see bugzilla:17006). ―cobaltcigs 14:48, 10 February 2011 (UTC)

Thank you for those suggestions. I learnt about HTML in the days before HoTMetaL (!) but my learning curve then went flat so I never got past "name=". I shall look and learn. Thincat (talk) 20:41, 10 February 2011 (UTC)

Essentially, <a id=foo>bar</a> is identical in effect to <a name=foo>bar</a>. Since the id= attribute can be used in any tag which is valid in the body section, we can also have, for example, <li id=foo>bar</li> to make a list item into a link target. Prior to HTML 4.0 you had to do this as <li><a name=foo>bar</a></li>. The shorter HTML 4.0 forms may confuse older browsers. --Redrose64 (talk) 21:08, 10 February 2011 (UTC)

BTW, if anyone isn't sure, you can use "View, Page Source" in Firefox or, it seems, "View Source" in IE8 to see the HTML code generated. Thincat (talk) 23:34, 10 February 2011 (UTC)

Also, #p-personal and #p-logo are both higher than #top. This strikes me as being a bug. ―cobaltcigs 21:35, 11 February 2011 (UTC)

top in this case is meant for the "top of the article" and not necessarily the top of the page. I'm not sure it's a bug or a feature in that case… --Izno (talk) 21:33, 13 February 2011 (UTC)

My mouse cursor is ticking

Hard to explain this. Right now I have the cursor over the textbox, and it shows up as a stylus. However, each time a second ticks in the clock at the top right, the cursor flashes as an arrow for a second. It's getting to be really distracting to my work here, however. Has the clock been changed recently? - ʄɭoʏɗiaɲ ^τ _¢ 14:11, 11 February 2011 (UTC)

If you are using FireFox, you may have enabled Caret Browsing by pressing F7. Press F7 to toggle the state. ---— Gadget850 (Ed) ^talk 17:43, 11 February 2011 (UTC)

Doesn't sound like Floydian's problem... a search for Caret Browsing in Firefox's help system yields several threads, some containing links to this, and our own Caret navigation. --Redrose64 (talk) 18:16, 11 February 2011 (UTC)

I am using Firefox, but caret browsing is turned off. It definitely only happens on wikipedia and not on other websites. The cursor doesn't move, its just flashes between a regular arrow, and some other cursor icon in sync with the clock. - ʄɭoʏɗiaɲ ^τ _¢ 18:16, 11 February 2011 (UTC)

Seems to be back to normal right now. I didn't do anything though. - ʄɭoʏɗiaɲ ^τ _¢ 22:32, 11 February 2011 (UTC)

I've had Firefox do that pretty often and it is solved by opening a new tab and closing the old one. —DoRD (talk) 18:11, 13 February 2011 (UTC)

Again

Hi. i`m from ko.wikipedia. I recently created Template:Dated maintenance category on ko.wiki. but, i can`t categorize former articles that did not appointed date. so, i want to appoint date with my bot ko:wiki:user:Altobot. How to command to my bot to appoint date on maintenance template? Of course, i don`t know when the templates attached.--Altostratus (talk) 05:51, 13 February 2011 (UTC)

Are you asking how to add the category or how to determine the date the category was added? To find out when the category/template was added, you can use WikiBlame. Someguy1221 (talk) 06:00, 13 February 2011 (UTC)

Please see the reply given on your previous post above #again: set maintenance dates in kowiki articles. --Redrose64 (talk) 12:07, 13 February 2011 (UTC)

Oops, Sorry. i missed that. Sorry.--Altostratus (talk) 13:57, 13 February 2011 (UTC)

Removing the timestamp at the bottom

How can i remove the line "This page was last modified on 13 February 2011 at 09:29." at the bottom of a particular page?. I noticed that our mainpage doesn't have this line and i am trying to do the same in ta.wiki. --Sodabottle (talk) 10:00, 13 February 2011 (UTC)

See the first lines of MediaWiki:Vector.css. You will have to adapt the classname to your local variant of Main Page (look at the source code of the main page). —TheDJ (talk • contribs) 10:43, 13 February 2011 (UTC)

Thanks DJ. I have implemented it.--Sodabottle (talk) 12:56, 13 February 2011 (UTC)

Small tags at Wikipedia

What does the small tag do in a Wikipedia article? Does it depend on the context? Does the effect depend on the browser? For example, I see people using these tags, particularly in infoboxes, and then I see others removing them because they say they don't do anything. For me, personally, with my browser (Firefox), I don't see any difference, either, but of course I'm not the entire world. Take a look at the use of the small tag in the infobox of Vanessa Redgrave for her title. With or without the tag, I see the same font size, or at least I can't discern a difference.--Bbb23 (talk) 12:31, 13 February 2011 (UTC)

There is a difference; "CBE" becomes smaller. However, <small> is deprecated and its use should be as well. — Edokter (talk) — 12:42, 13 February 2011 (UTC)

I don't see it, but I didn't use a ruler. :-) As I understand it, deprecation means it should still continue to work because of backward compatibility. However, your comment suggests we shouldn't use the tag. Is there any policy or guideline on the issue? Is there an alternative? Is there any guidance on when the tag (or the alternative) should be used?--Bbb23 (talk) 13:16, 13 February 2011 (UTC)

Who says <small> is deprecated? It isn't listed as deprecated in HTML4 or in HTML5. Anomie⚔ 13:36, 13 February 2011 (UTC)

HTML 4.0 on provides alternatives in the form of style sheets, but I don't know if <small>...</small> is necessarily deprecated as far as HTML goes. However, its use in Wikipedia text can give rise to accessibility issues for partially-sighted readers, so in that sense, it's "deprecated". See also WP:FONTSIZE. --Redrose64 (talk) 13:38, 13 February 2011 (UTC)

HTML5 says <big> is deprecated, so I asumed <small> was as well, but apparently not. — Edokter (talk) — 16:41, 13 February 2011 (UTC)

As mentioned above, <small> is not marked deprecated at [5]. Anomie⚔ 17:12, 13 February 2011 (UTC) NB: Previous comment was changed after this comment (diff).

Ref: www.tutorialspoint.com/html5/html5_deprecated_tags.htm (copy and paste, as it seems to be blacklisted.) — Edokter (talk) — 18:16, 13 February 2011 (UTC)

<small> is not listed there. But I see you changed your earlier comment to claim <big> is deprecated, which actually does seem to be the case. Anomie⚔ 18:42, 13 February 2011 (UTC)

Would someone please give some sources that explain the problem with accessibility and a small font size? Wikipedia:Manual of Style (accessibility) is mute on font size as an issue and even mentions the use of <small>. I have skimmed through the Section 508 and Web Content Accessibility Guidelines and don't see this. I have used some online accessibility tools to check several articles and don't see a font problem. ---— Gadget850 (Ed) ^talk 18:00, 13 February 2011 (UTC)

Bug in the API

I would like to bring up what I believe is a bug in the API, but I want to verify it here first. If I'm not mistaken, it's just cropped up in the past few days, so it might be related to the new mediawiki release (I am however not sure on this point).

As you will see, File:PC280020.JPG has two different images in its history. However, the API is reporting the same hash tag for both images: [6]. This problem is not echoed on the commons version of the image, File:Blyth Staithes.jpg: [7]. As a result, File:PC280020.JPG is being reported as having no duplicates ([8]), despite the fact that the commons version is indeed an exact duplicate.

Should I file this as a bug? Magog the Ogre (talk) 18:50, 13 February 2011 (UTC)

It seems to be fixed. Svick (talk) 20:09, 13 February 2011 (UTC)

disable Firefox spellchecker via css/js

Yes, I know I can switch it off in the browser and all that, don't ask me why I want this, so just flat out: Is there a way to disable Firefox spellchecker via some sort of script? (I know there is one to enable it in the edit.js) Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 19:07, 13 February 2011 (UTC)

just right click in the edit box and uncheck "Check spelling" ΔT _{^{The only constant}} 19:17, 13 February 2011 (UTC)

I know that as well. So I take it it can't be done. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 19:47, 13 February 2011 (UTC)

If you want to disable it for everything:

$j(document).ready(function() {
  $j('input, textarea').attr('spellcheck', false);
});

If you only want to disable it for specific elements, you'll have to select them by ID or something. Mr.Z-man 20:20, 13 February 2011 (UTC)

Awesome. Works. Exactly what I was looking for. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:43, 13 February 2011 (UTC)

This looks weird

[9] --Perseus8235 20:15, 13 February 2011 (UTC)

That's because a semicolon at the start of the line is Wiki markup which triggers the construction of the HTML <dl>...</dl> structure, containing a <dt>...</dt> element for each semicolon, and also a <dd>...</dd> for the first colon which occurs anywhere on the same line. Thus, this:

;The:Red/fgjdr

produces this:

The

Red/fgjdr

A colon at the start of a line also gives a <dl>...</dl> structure, but containing only <dd>...</dd> elements. --Redrose64 (talk) 20:47, 13 February 2011 (UTC)

• The bolding triggered by ";" in your article name ";The:Red/fgjdr" is considered a bug within the processing of text data. Someone should perhaps change the handling of the missing-article message to embed "<b/>" or "<nowiki/>" before a user's specified article name, so that the message appears more coherent, with the text treated as simply ";The:Red/fgjdr" rather than the bolded word "The" repeated on each separate line. It is a relatively new bug, caused by recently fixing another bug, which typically happens in about 10% of bugfixes in the world at large (hence, a fairly common mistake for most software engineers). -Wikid77 21:32, 13 February 2011 (UTC)

  Actually, it's a very old bug: T14974 opened in 2008 was caused by the fix for T2529 in 2004. There is nothing we can do here to work around it here, as it's the output of {{PAGENAME}} that is incorrect. Anomie⚔ 22:05, 13 February 2011 (UTC)

Seeing deleted image logs?

When I click on a deleted image, the upload form appears. Is there somewhere I should look to see the deletion log? Maury Markowitz (talk) 16:29, 13 February 2011 (UTC)

Left-side menu, under "toolbox", Special pages; then under "Recent changes and logs", Logs. In the first drop-down menu, select "Deletion log"; in "Title:", enter your image name (with the "File:" prefix). Then click "Go". --Redrose64 (talk) 17:00, 13 February 2011 (UTC)

Oh, forgot to mention, if the image was held on commons, that won't work - instead, go to commons: first, then proceed as I described. --Redrose64 (talk) 17:02, 13 February 2011 (UTC)

This will be fixed in the MediaWiki update coming Wednesday (hopefully), but there is a useful script at User:Gary King/show upload deletion logs.js which adds links to both local and Commons deletion logs at the top of the upload form when you click on a redlinked image. /ƒETCHCOMMS/ 18:06, 14 February 2011 (UTC)

Subst sometimes not working

Normally when I do {{subst:FULLPAGENAME}} I get what I expected - for this page, it is "Wikipedia:Village pump (technical)", but it didn't work here. Any ideas as to why? T. Canens (talk) 20:08, 13 February 2011 (UTC)

How odd, apparently subst doesn't work inside <includeonly>.^[10] Does anyone know if this is a known bug? Anomie⚔ 23:09, 13 February 2011 (UTC)

Umm I wouldn't call it a bug, it's what I would see as expected behaivor. "<includeonly>...</includeonly> – the text between the includeonly tags will be transcluded (substituted), but will not be processed on the template's own page". Taemyr (talk) 02:03, 14 February 2011 (UTC)

It's certainly a bug when you try to put <includeonly><nowiki>~~~~</nowiki></includeonly> in a template and it expands the signature inside the <nowiki> tags (T2093). I'm not sure whether people generally expect substitution not to work inside <includeonly> or not, although I know they do expect it to work inside <ref> where it similarly doesn't. Anomie⚔ 04:35, 14 February 2011 (UTC)

I admit I'm surprised to find that tilde expansion and pipe-trick expansion work inside includeonly tags, while subst doesn't. (IIRC, none of these expansions work inside ref tags.)--Kotniski (talk) 08:07, 14 February 2011 (UTC)

Some templates rely on the behaviour of subst: inside <includeonly>...</includeonly> in order to detect if they have been substed when they shouldn't have been, and vice versa. See, for example, {{unreferenced}} --Redrose64 (talk) 14:04, 14 February 2011 (UTC)

I don't think that's quite the same thing (since there it's only the word "subst" that's inside the tags, not the whole substituted object), but there may be some connection.--Kotniski (talk) 14:48, 14 February 2011 (UTC)

No, that's a very different beast - and there the subst is actually supposed to work... T. Canens (talk) 15:21, 14 February 2011 (UTC)

It is certainly not the same thing, and that template would continue to work were either of the patches to T2093 applied. OTOH, usages like that are exactly why safesubst: had to be created instead of just "fixing" subst:. Anomie⚔ 18:19, 14 February 2011 (UTC)

It should really be surprising to find that <includeonly> disables <nowiki> for tilde expansion and pipe-trick expansion. Anomie⚔ 18:19, 14 February 2011 (UTC)

Citation templates add extra space in Preview or Save Page

Resolved

 – Gary King (talk · scripts) 21:18, 14 February 2011 (UTC)

New little quirk that can be worked around, but it adds extra proofing time and extra steps. Been noticing it for about a week, maybe. When editing and using citation templates, they are exactly placed when I put them in. Perfect. When I click "Preview" or "Save Page", that actions sticks an extra space in front of the citation. Doesn't matter what I put the citation next to. If it's a sentence end, I end up with a period, a space, and then the citation. If it's two citations together, I end up with a citation, a space, and the other citation. Never used to do that. Annoying. Is this happening to anyone else? I use Firefox. Maile66 (talk) 20:07, 14 February 2011 (UTC)

Do you have any scripts or gadgets enabled, such as wikEd, which may affect your editing area? This isn't supposed to be happening to you; it's certainly not happening to me, regardless of what browser I try it in. Gary King (talk · scripts) 20:30, 14 February 2011 (UTC)

I don't work with scripts. But WikiEd for Firefox is enabled. Is that what is doing it, maybe? Maile66 (talk) 20:48, 14 February 2011 (UTC)

Try disabling it to see if that helps. Gary King (talk · scripts) 20:50, 14 February 2011 (UTC)

What pages is this occurring with? Please give some examples where the saved page was not as you intended. --Redrose64 (talk) 20:51, 14 February 2011 (UTC)

Un-checking the WikiEd, clearing my cache, then re-checking it...worked. Must been a "hiccup" in the gadget. Thanks for your help.Maile66 (talk) 21:08, 14 February 2011 (UTC)

User losing text and data when uploading

Can someone technical have a look at the two Help desk threads by Catchthedream (talk · contribs)? One, Two. It looks like text and data is being randomly damaged/truncated on its way from the user's PC to the Wikipedia servers. -- John of Reading (talk) 10:16, 15 February 2011 (UTC)

search messages tidyup proposal

I have suggested a couple of minor adjustments for the search result messages here, partly aesthetics, partly logic... hopefully short yet sweet. Lee∴V (talk • contribs) 00:08, 16 February 2011 (UTC)

Reverting images with API

I cannot find any documentation under mw:API:Changing wiki content on how to revert an image to an earlier version. It is in fact written in the software: (click here to see what I'm talking about). Is there a way to do it through the API? Magog the Ogre (talk) 22:05, 15 February 2011 (UTC)

Not directly. The workaround is to do a query like [11] then feed the image or the URL to upload. MER-C 02:20, 16 February 2011 (UTC)

I don't believe Wikimedia/Wikipedia have URL based uploads enabled; am I wrong? Magog the Ogre (talk) 07:33, 16 February 2011 (UTC)

You are correct. —TheDJ (talk • contribs) 11:37, 16 February 2011 (UTC)

Did the appearance just change for anybody else?

Right in the middle of editing DYKs (as in, preview on the prep, fine, then go to another hook on the talk page, and wha?!) the appearance of the editing window changed. I have 'monobook' set as my skin, but all of a sudden the editing window has the "fancy" appearance of Vector/default, but everything else is the same? (I'm using Firefox 3.6.10) - The Bushranger _{One ping only} 06:23, 16 February 2011 (UTC)

...aha. I just found the 'enable enhanced editing toolbar' thing in the Beta section of Editing Preferences, unchecked it, and it's back to normal. Panic averted, I've found my towel. - The Bushranger _{One ping only} 06:46, 16 February 2011 (UTC)

was fine for me until about 5 mins ago, then it went and broke, Everything was there, but it appeared that all the page formatting had broken. Pages taking ages to load too. I swapped to IE, and that is taking forever to load (one reason I use Firefox) so I abandoned the attempt to use IE. Seems to have settled now. Mjroots (talk) 10:23, 16 February 2011 (UTC)

This was due to maintenance. There was an attempt to switch to 1.17 again, first one was problematic, the last one succeeded. —TheDJ (talk • contribs) 11:42, 16 February 2011 (UTC)

• Pages are showing up in monobook for me, but I'm getting the hideous Vector edit window. I'd just got used to it and then the RefToolbar buggered off. Can I get the monobook edit window, or at least the gadgets, back somehow? HJ Mitchell | Penny for your thoughts? 12:31, 16 February 2011 (UTC)

Well, I'm using Monobook and I followed the advice in 2nd post above and it  Works for me - Special:Preferences → Editing → Beta features - make sure that "Enable enhanced editing toolbar" is not checked. --Redrose64 (talk) 13:22, 16 February 2011 (UTC)

Ahh, I thought it was just me. Thanks, I've switched it back. More to the point - why on earth was it changed? Any discussion links about this? Lugnuts (talk) 19:13, 16 February 2011 (UTC)

Esams

And now the esams bits cache is dead again.[12] Secure WP server to the rescue...[13] --Morn (talk) 10:36, 16 February 2011 (UTC)

Try browser text-size smaller with MW 1.17

If your browser text size gets very large, then try setting Text-Size as smaller, to continue editing, when {{CURRENTVERSION}} = "1.17wmf1 (r82223)" or similar. Version now: 1.44.0-wmf.5 (d64f667). Most likely, the text will not appear quite as normal as before, but it will be similar in size, to resume work on updating pages (without too much mindfry from the changed screen appearance). Try to be patient, and imagine some improvements that will come with MW 1.17. Or not, if you prefer. -Wikid77 10:59, 16 February 2011 (UTC)

Automated template updates on talk pages

There are 45 entries in the Category:Unknown-importance Pittsburgh articles, with

{{WikiProject Baseball|class=stub|importance=low}}
{{WikiProject Pittsburgh|class=Stub|importance=|auto=yes}}

templates on the talk pages. I would like to learn how to make all of these talk pages say

{{WikiProject Baseball|class=stub|importance=low}}
{{WikiProject Pittsburgh|class=Stub|importance=low}}

in an automated way. Please provide me with the tools and technical assistance to do this task.

I want to learn how to do it, not have it done for me, because I have other instances where I need to do likewise.--DThomsen8 (talk) 13:34, 16 February 2011 (UTC)

WP:AWB and/or WP:BOTREQ is the third door down. ΔT _{^{The only constant}} 13:57, 16 February 2011 (UTC)

ResourceLoader is awesome

It took literally one second to log in, usually it takes 30 seconds or so to load all the js.

However, I have a gadget or script that shows a UTC clock at the top right with a purge link, and while the clock is fine, it no longer links. Any ideas? It might be the Twinkle clock, I'm not sure. /ƒETCHCOMMS/ 14:57, 16 February 2011 (UTC)

I believe it is MediaWiki:Gadget-UTCLiveClock. And now it is smaller and doesn't purge. –xeno^talk 15:02, 16 February 2011 (UTC)

Had the same issue with the clock, but it is now working. ---— Gadget850 (Ed) ^talk 16:12, 16 February 2011 (UTC)

I fixed the UTC clock. —TheDJ (talk • contribs) 16:15, 16 February 2011 (UTC)

Confirmed. Back to the original size too. –xeno^talk 16:16, 16 February 2011 (UTC)

Predictive search suggestions not working in Monobook anymore?

Is there a reason that the predictive search suggestions aren't working in Monobook anymore? –xeno^talk 15:04, 16 February 2011 (UTC)

I disabled it because of a bug, fixed the bug, then forgot to re-enable it. Should be fixed now (immediately for logged-in users, may take time to propagate for anons). --Catrope (talk) 15:19, 16 February 2011 (UTC)

Only works for me in the edit screen. Monobook, Chrome, WinXP. DuncanHill (talk) 15:32, 16 February 2011 (UTC)

Try WP:BYPASS. Working again for me, thanks Catrope. –xeno^talk 15:49, 16 February 2011 (UTC)

I tried BYPASS, and now it doesn't work in the edit box either :( DuncanHill (talk) 15:59, 16 February 2011 (UTC)

Search suggestions work for me in Monobook right now. Gary King (talk · scripts) 16:59, 16 February 2011 (UTC)

Bottom notice displaying in navigation bar in Monobook

The bottom wikipedia notice (disclaimer, privacy policy, and About Wikipedia) are being displayed on the left in the navigation bar instead of being displayed at the bottom of the page. I am using Monobook, I tried vector and it appears correctly. Also, the section edit buttons are displaying on the left instead of the right. Alpha Quadrant ^talk 15:22, 16 February 2011 (UTC)

I tried Monobook on this page, and the section edit links are appearing on the right for me. I also can't reproduce the different location of the footer. Please try disabling user scripts and gadgets one at a time, and see if that fixes it. --Catrope (talk) 15:36, 16 February 2011 (UTC)

Found the issue, it is MediaWiki:Gadget-edittop.js in gadgets. After disabling this script it appears correctly. Alpha Quadrant ^talk 15:53, 16 February 2011 (UTC)

Spurious/unwanted watchlist RSS token

I'm still trying to work through a problem that's causing my watchlist to hang briefly on load, but in the course of investigating it I that the watchlist RSS token field in my preferences had been filled with a random value. This could have lead to my watchlist being read by someone willing to try a lot of brute force, though of course in practice it's not very likely. The token was probably generated by various work that was done to fix preference breakage, and there's probably no way to fix erroneous tokens without clobbering good ones, but it's worth letting people know that they might have an unwanted token set. — Gavia immer (talk) 16:32, 16 February 2011 (UTC)

Code update finished?

Is the code update finished. If so, I am still having problems with inoperative scripts and gadgets (WikEd, Twinkle, Navpopups, UTC clock). --ukexpat (talk) 16:36, 16 February 2011 (UTC)

Yes finishes. Try disabling them one by one to find out which script EXACTLY is your problem, or use a javascript console. UTC clock was fixed, twinkle was fixed, popups works for me, so it's likely something other than that. —TheDJ (talk • contribs) 16:40, 16 February 2011 (UTC)

Wow, all my top links (my user page, my talk, my watchlist, etc.) are gone. Time to fiddle with the CSS again. Gary King (talk · scripts) 16:43, 16 February 2011 (UTC)

No gadgets working for me, AFAIK. Blackscreen, popups, twinkle, clock/purge, all not working. Preferences page doesn't have the tabs, it is just one long page with all the different bit under each other. Have tried bypass, logging-out-and-again. Monobook, Chrome, WinXP. DuncanHill (talk) 16:49, 16 February 2011 (UTC)

None of mine are either. In fact, unless I hit the stop button just before any page loads fully, the page disappears completely and I just get a blank white page. Something is afoot.--ukexpat (talk) 16:58, 16 February 2011 (UTC)

Also, it seems like the !important keyword in CSS doesn't work, after some quick testing. This is a crucial keyword to have. Gary King (talk · scripts) 16:56, 16 February 2011 (UTC)

Neermind, it looks like they've added "&version" to the CSS's URL, so that you won't always be loading the latest stylesheet. Which makes debugging more difficult—unless there's a way to set &debug to true? Gary King (talk · scripts) 17:10, 16 February 2011 (UTC)

Yep, just set debug=true in your query string; it will be passed to load.php and enable debug mode. It still passes version though. Reach Out to the Truth 17:37, 16 February 2011 (UTC)

Where do I do this? The wiki loads the CSS, not me, so I'm not quite sure? Gary King (talk · scripts) 17:41, 16 February 2011 (UTC)

D'oh nevermind, figured it out. Gary King (talk · scripts) 19:02, 16 February 2011 (UTC)

Change the "new section" tab text to instead display the much narrower "+". gadget looks broken (Vector, no personal js/css games). Tried unchecking (and saving) the rechecking/saving, and purging local cache and force-reloading everything. Still have "New section" instead of "+". Other gadgets (popups, UTC clock) are working correctly. DMacks (talk) 16:50, 16 February 2011 (UTC)

Well, gadgets now seem to be working, but the blackscreen is clunky - the page loads in whitescreen, then jumps to blackscreen. It used to load smoothly in blackscreen. DuncanHill (talk) 17:13, 16 February 2011 (UTC)

That's probably because all JavaScript files have been moved to the bottom of the page now, so I think all scripts will experience this "choppiness". Gary King (talk · scripts) 17:19, 16 February 2011 (UTC)

I have the same problem as DMacks; I get new section rather than +. /ƒETCHCOMMS/ 17:34, 16 February 2011 (UTC)

Fixed now —TheDJ (talk • contribs) 20:40, 16 February 2011 (UTC)

Not for me, and I am still having the other problems I mentioned above...--ukexpat (talk) 20:52, 16 February 2011 (UTC)

Better now ? I did some fixes. BTW you have a gigantic amount of userscripts installed, many VERY old and just bound to break on the smallest changes. —TheDJ (talk • contribs) 00:11, 17 February 2011 (UTC)

Haven't checked in the past few hours, but "+" is now working correctly for me. Thanks for all the hard work on this update! DMacks (talk) 01:17, 17 February 2011 (UTC)

I removed some scripts and all appears to be working fine now, thanks! – ukexpat (talk) 03:16, 17 February 2011 (UTC)

Clear buffer if page shifted?

Hi,
This has happened to me countless times, so presumably others see it too.

The page is drawn. I click on something I want to see.
Then, it happens that WP is seeking donations, or I have new messages.
Page shifts downward.
But my mouse click is still active.
So I get something I didn't ask for.

Isn't it straightforward just to clear the input buffer in cases where you do a page redraw?
Or shift the co-ordinates of the pending click(s) to reflect the fresh page layout?
Clearly the former option is simpler.
Cheers, Varlaam (talk) 17:42, 16 February 2011 (UTC)

This is a browser-related issue, I believe. I don't think JavaScript can control what element is activated when the mouse is clicked on something else. Gary King (talk · scripts) 17:48, 16 February 2011 (UTC)

Freenode

I've just had access difficulties for quite some time - enough to make a hot drink and feed the cat. Whilst this was going on, all I could get was the standard message beginning "WIKIMEDIA FOUNDATION Error Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. You may be able to get further information in the #wikipedia channel on the Freenode IRC network.". I have two problems here.

First, the #wikipedia link doesn't do anything at all in Chrome; in Firefox it asks me to choose an application, but I have no idea which application would be correct for this; whereas in Opera, I get to a "New account wizard". I don't necessarily want to post anything yet: I just want to find out what's wrong.

My second problem is that Freenode IRC network takes me to an "About the Network" screen, and there doesn't seem to be anywhere where I might enter this "#wikipedia" channel name, other than the Google search box upper right, which gives me a whole heap of irrelevant and out-of-date stuff. --Redrose64 (talk) 17:50, 16 February 2011 (UTC)

IRC. Prodego ^talk 17:53, 16 February 2011 (UTC)

You might want to try the Freenode webchat. --Morn (talk) 18:14, 16 February 2011 (UTC)

@Prodego: I had already worked out that it meant "internet relay chat". The point is, I can't get to anything that might tell me what's wrong with the Wikimedia servers.

@Morn: this wants me to create an account. Wikipedia (normally) allows non-registered users to read pages, so does Bugzilla. I would like to do similarly with Freenode. --Redrose64 (talk) 18:24, 16 February 2011 (UTC)

It asks you to supply a nickname, not to create an account. You'll need a nickname to connect to an IRC server, you can't connect otherwise. –xeno^talk 18:26, 16 February 2011 (UTC)

Also if you connect to freenode, your IP address will be publicly viewable by anyone else in the chat. Prodego ^talk 18:27, 16 February 2011 (UTC)

But if you have an account you can apply for a cloak. --Ron Ritzman (talk) 02:31, 17 February 2011 (UTC)

The signature button is not working

The "Your signature with timestamp" button on the toolbar above editor window as well as signature sign in Wiki markup, is not working properly. When I press it while editing, nothing happens, expect my screen moves upwards towards start of the discussion. In case where I am starting a thread (like now), when I pushed the button or Wiki markup symbol, the signature appeared in Subject/headline textbox.Redtigerxyz ^Talk 18:14, 16 February 2011 (UTC)

Seems to be working in Monobook (nb with "Enable enhanced editing toolbar" disabled) - --Redrose64 (talk) 18:26, 16 February 2011 (UTC)

Horizontal scrollbar on nearly all pages

Now that the new updates have been installed, my browser places a horizontal scrollbar on nearly all pages I view while logged in. This happens in both Firefox and IE. Is this a known issue and is there a known solution? It's minor but annoying. ElKevbo (talk) 18:27, 16 February 2011 (UTC)

I'm having the same experience here; does anybody have any input? — Fourthords | =/\= | 22:05, 16 February 2011 (UTC)

I'm not experiencing this. Which skin are you guys using? Most people are using Vector and don't appear to have any problems regarding this. I'm using Monobook and don't have this problem. Gary King (talk · scripts) 01:25, 17 February 2011 (UTC)

I finally figured it out after some trial and error: in my preferences, I had enabled the gadget to widen the Wikipedia search box ("Widen the search box in the Vector skin."). Once I disabled that, my stupid horizontal scrollbar went away! Hope this works for you! — Fourthords | =/\= | 01:31, 17 February 2011 (UTC)

Yup, that's it! Thanks! ElKevbo (talk) 01:52, 17 February 2011 (UTC)

Thank you. I was wondering about that. I'm actually using a different searchbox-widening script; it looks like 1.17 forces the searchbox to grow to the right rather than touch the pristine empty space to the left. — Gavia immer (talk) 01:43, 17 February 2011 (UTC)

Mobile site redirects to regular site first now

Since JavaScript files are moved to the bottom of the page now, whenever a mobile device visits the wiki, it first loads the entire regular page, then is redirected to the mobile version. It seems better to at least move the mobile redirect code to the top of the page like it was before. Gary King (talk · scripts) 18:48, 16 February 2011 (UTC)

This is not possible at the moment I think. What is needed is that the squids take care of redirecting. JS is just an ugly bandaid that we really shouldn't use for this. There is a bugzilla ticket for that bugzilla:24859. —TheDJ (talk • contribs) 20:51, 16 February 2011 (UTC)

Wiki loads older CSS version

Okay, so after fixing up my monobook.css, everything looks like it's back to normal now. However, the only problem is that the wiki is loading an older version of my stylesheet. What I am currently doing right now, as a (hopefully) temporary solution, is I created a Greasemonkey script to remove the "&version=" where the wiki calls my monobook.css, so that it will always grab the latest version rather than grab a version that's a few hours old. However, does anyone have a more permanent fix for this, or should I just always wait for the cached CSS on the server-side to catch up to the actual version? Gary King (talk · scripts) 20:11, 16 February 2011 (UTC)

This shouldn't happen. RL was written so that this would not be necessary. —TheDJ (talk • contribs) 20:59, 16 February 2011 (UTC)

Things seemed to have settled down regarding this. Initially, I did spend a few hours working on it, though, noticing that CSS appeared differently in Firefox and Chrome, whether debug was enabled or disabled, and whether &version= was there or not. Gary King (talk · scripts) 01:19, 17 February 2011 (UTC)

Preload text may be incorrect

1.17 includes a fix for T7210, which means that "preload" pages will now honor <noinclude>. This can cause breakage if the preload page includes <noinclude> text that should be included in the newly-created page. It can be fixed easily enough, to output a <noinclude> into the editbox use something like <noin<noinclude/>clude>. If you understood that, please check any preload texts to ensure they still generate the correct edit box contents. Anomie⚔ 20:14, 16 February 2011 (UTC)

Broken file

See File:Blinx Time Controls.png. When I go there, I get a weird SQL error. Any ideas? SnottyWong ^talk 21:12, 16 February 2011 (UTC)

Interestingly enough, the image displays just fine, just can't go to its page: — SnottyWong ^converse 21:14, 16 February 2011 (UTC)

Fixed

!log catrope synchronized php-1.17/wmf-config/db.php  'Depool srv178 from ES'

. —TheDJ (talk • contribs) 21:19, 16 February 2011 (UTC)

Thanks. SnottyWong ^prattle 21:34, 16 February 2011 (UTC)

Underlined links and a more general changes query

How comes i can no longer have links underlined? Frankly, something as seemingly small as this was actually one of the biggest reasons i could tell whether i was logged in or not.

Whilst we are on the subject of links, can someone point me in the direction of the changes to the user interface that have taken place today? Also what does global account do? Simply south...... 22:02, 16 February 2011 (UTC)

See #Links aren't being underlined. — Edokter (talk) — 22:20, 16 February 2011 (UTC)

Edit toolbar preference no longer works

The new editing toolbar will not go away even when "My preferences" -> "Editing" -> "Show edit toolbar (requires JavaScript)" is cleared. :( —Lowellian (reply) 11:53, 16 February 2011 (UTC)

See thread above, this is in the process of being fixed. the wub "?!" 12:04, 16 February 2011 (UTC)

What has been done by now to fix it? Who was that who coercively enabled this so called "enhanced editing toolbar" ? And when this is going to be reverted? — Klimenok (talk) 06:58, 17 February 2011 (UTC)

StupidNah, it's not stupid, it's just annoying banner is not working

Resolved

The stewards elections banner keeps appearing and disappearing whenever I reach a page. Before I can click it, it disappears. --Perseus8235 15:43, 16 February 2011 (UTC)

It's probably an old banner that you already dismissed. You can clear your cookies for en.wikipedia.org to make them all reappear again. — Edokter (talk) — 15:52, 16 February 2011 (UTC)

The fact that the banner appears before it disappears was fixed recently; it was a problem with the steward elections banner borrowing very old code. --Catrope (talk) 22:49, 17 February 2011 (UTC)

RSS feeds?

Why have RSS feeds stopped working? Specifically the one for new pages. — RHaworth (talk · contribs) 22:06, 16 February 2011 (UTC)

Another unrelated regression. When I am doing speedy deletions, I used to get the reason supplied automatically for me from th speedy tag. This has stopped. Why? (I believe it was a bit of javascript.) — RHaworth (talk · contribs) 22:11, 16 February 2011 (UTC)

I don't know but it's working for me. —Soap— 22:34, 16 February 2011 (UTC)

Worksforme. Happy‑melon 22:49, 16 February 2011 (UTC)

Which is working for you? Deletion reasons or RSS feeds? Atom feeds also seem to be broken. — RHaworth (talk · contribs) 01:21, 17 February 2011 (UTC)

See Wikipedia:Village_pump_(technical)#Speedy-deleting_oddity for speedy deleting issue. Atom feeds seem to work for me, in Chrome 9. Gary King (talk · scripts) 01:31, 17 February 2011 (UTC)

This is crazy! I have tried with Chrome and all I get is about a dozen links to http://en.wikipedia.org/wiki/ . Same with rss. I have e-mailed you specimens. These were created with Lynx which, I think, can be trusted to give the raw feed as sent by Wikipedia. Nothing has changed my end - as far as I know. What is happening? — RHaworth (talk · contribs) 14:52, 17 February 2011 (UTC)

Please compare and contrast:

• http://starwars.wikia.com/index.php?title=Special:NewPages&feed=rss - generated by MediaWiki 1.16.2
• http://en.wikipedia.org/w/index.php?title=Special:NewPages&feed=rss - generated by MediaWiki 1.17wmf1

But why is no-one else complaining - that is what puzzles me. — RHaworth (talk · contribs) 15:38, 17 February 2011 (UTC)

I received your email. What you sent to me is what I see in my browser, which outputs nothing, so yes, that is definitely broken. What does work for me are feeds for page histories. Gary King (talk · scripts) 16:36, 17 February 2011 (UTC)

The new pages RSS feed is fixed now. --Catrope (talk) 23:18, 17 February 2011 (UTC)

Rollback quirk

Today's changes affected the rollback "button". In Firefox, I used to be able to <Ctrl><Click> on the rollback button to roll back vandalism from my Watchlist in a new tab. Today that no longer works. <Ctrl><Click> rolls back the vandalism in the current tab.

Not a big deal, but it was a convenience to preview the edit in Pop-Ups, roll it back in another tab, and continue down the Watchlist. — Malik Shabazz ^Talk/_Stalk 22:47, 16 February 2011 (UTC)

I don't have any issue doing this still. As far as I know ctrl+click is a browser thing. Killiondude (talk) 07:26, 17 February 2011 (UTC)

What browser are you using? I'm experiencing this problem on Firefox 3.6.13 and 4b11 on different machines, and it started yesterday. As far as I know, nothing changed in my browsers on Tuesday night. Thanks. — Malik Shabazz ^Talk/_Stalk 19:41, 17 February 2011 (UTC)

 Works for me in FF 3.6.6 (monobook). Try disabling all user .js and gadgets maybe, then re-enable one-by-one if the functionality comes back? –xeno^talk 19:46, 17 February 2011 (UTC)

Thank you for that suggestion. (I'm kicking myself for not thinking of it myself.) Unchecking the gadget "After rolling back an edit, automatically open the contributions of the user rolled back" solved the problem. Thanks again. — Malik Shabazz ^Talk/_Stalk 20:08, 17 February 2011 (UTC)

No problem =) –xeno^talk 20:09, 17 February 2011 (UTC)

Disambigs, main topics, and dablinks

Today, I had to go through and about 200 links of proper names to a table, knowing that on initial entry many of these links would be "wrong", pointing to the wrong topic or a disambig page. No problem, I thought, I'll just dablinks on the toolserver to resolve them. However, I realized that dablinks only checks if the link goes to a disamb page and that's it, and so only 11 of what I'd estimate are 50 problem links were caught.

I was wondering if dablinks can be modified with two features:

• First, taking the case where "Topic" and "Topic (disambiguation)" exist, Dablinks should recognize that the disamb page exist and highlight that area for the user, likely a different color, using the dab page to get that data. The user may have intended "Topic" in which case the user ignores the change, but if not this gives them the chance to change it.
• Second, in cases where "Topic" exists, there is no "Topic (disambiguation)" but one or more "Topic (other term)" exist, it would be helpful for dablink to at least notify the user that other pages like "Topic" exist; I wouldn't expect Dablinks to list out them all but at least notification would be helpful.

I would expect this could be easily done with dablink programming and the addition of a hidden template on the affected pages, but this can be done automagically through the {{otheruses}} family of templates. --MASEM (t) 22:58, 16 February 2011 (UTC)

(edit conflict)I don't get all of your question, but this might be relevant. {{dablinks}} is a part (only) of Hatnotes world. Another metatemplate used is {{rellink}}, btw. All in all there are ~100 hatnote templates, based on these two meta T's (mostly actually using one of these). The automated (dab)-check you are mentioning, is currently applied by using multiple intrinsic options per template (overloaded templates, software speaking). So the 100 different templates can produce 200+ different hatnotes. Before we would apply your proposal, I'd like to get how the current situation will be covered, and how non-dab links (such as {{main}}) can go along. Hatnotes are not just disambiguation, really. -DePiep (talk) 23:54, 16 February 2011 (UTC)

He's talking about the Dablinks tool. I had at least partial implementation of both method in Dab solver, but found they unsatisfactorily solved the problem. I since removed the kludge that was the code and an unfortunately busy reimplementing stuff that mw 1.17 broke :-(. — Dispenser 02:56, 18 February 2011 (UTC)

CSS for new edit toolbar

Where is the CSS for the new (ajax) edit toolbar located? I suspect it's not editable, but it does have an error that needs adressing. — Edokter (talk) — 23:46, 16 February 2011 (UTC)

Where in the toolbar and how is it wrong ? Then I an use webkit inspector to find which part loads it. —TheDJ (talk • contribs) 07:29, 17 February 2011 (UTC)

I also use the webkit inspector; it shows the URL for the edit page. Anyway, to see the problem (which I already fixed in common.css), click Help on the toolbar; the 'What you type' column suffers the same (now fixed) monospace fontsize bug. — Edokter (talk) — 12:23, 17 February 2011 (UTC)

The resourceloader inserts that into the head of the document when it is actually needed. It is in extension, WikiEditor/modules/jquery.wikiEditor.toolbar.css —TheDJ (talk • contribs) 18:04, 17 February 2011 (UTC)

Cheers for finding that. I've filed a bugreport. — Edokter (talk) — 18:48, 17 February 2011 (UTC)

Show commons categories on Wikipedia image page

When one clicks on a Commons image in Wikipedia, one gets a page of metadata along with a note that says "This is a file from the Wikimedia Commons. Information from its description page there is shown below." Most of the information in the Commons file is copied over, but the Commons categories are not and I often find I need to go to the Commons file to see those categories. It would save me a lot of time if the Common category links could be shown on the initial Wikipedia image page, perhaps in the same box as the "This is a file from the Wikimedia Commons..." note.--agr (talk) 00:26, 17 February 2011 (UTC)

Make a feature request in bugzilla: —TheDJ (talk • contribs) 07:28, 17 February 2011 (UTC)

Done. Bug 27501. --agr (talk) 18:19, 17 February 2011 (UTC)

Writing user scripts for ResourceLoader

Knowing that use of the new modular JavaScript libraries will become necessary in a future version of MediaWiki, I am attempting to update User:PleaseStand/highlight-comments.js to not use any deprecated functions. My new version is at User:PleaseStand/highlight-comments-dev.js, and I have decided to add a feature to highlight other user's comments, not just one's own. My work on implementing this feature raises a few questions. What will be our replacement for importScript? Why aren't mw.Map and mw.user.name() (as documented on the MediaWiki site) exposed to user scripts in the currently live version of MediaWiki? What should be the standard way to give custom settings to user scripts? PleaseStand ^(talk) 12:31, 17 February 2011 (UTC)

Roan and Trevor have told me that those are all features of Resource Loader 2.0 —TheDJ (talk • contribs) 14:13, 17 February 2011 (UTC)

Noticed any random script problems? wgVectorEnabledModules

I was having problems with some of my scripts not running... and from some of the posts above it seems that others in the last few days have as well. For me it was killing easyblock and some others, but I was able to track the JS error back to a protection script. It seems like wgVectorEnabledModules has either been deprecated or is not valid in all skins (and I'm using vector). I tried to put some error protection around it, but if anyone notices problems with my kludgy coding the feel free to revert back to this version of the protection script. If you are having other problems with your scrips you may want to look at whether it uses wgVectorEnabledModules.  7  13:21, 17 February 2011 (UTC)

wgVectorEnabledModules was removed; I guess that may not have been the best idea, because things were relying on it. However, there is now a generic interface for grabbing preferences (mw.user.options.get('preferenceName')) that you can probably use to do the same thing. I've filed a bug for reintroducing wgVectorEnabledModules and wgWikiEditorEnabledModules for back compat at Bugzilla. --Catrope (talk) 23:23, 17 February 2011 (UTC)

Thanks Catrope!  7  00:21, 18 February 2011 (UTC)

Problem with monobook

I see the ongoing hoopla over some changes that were made but can't see anything directly related to my problem. User:Brad101/monobook.css is supposed to set gray backgrounds but it's changed into this nauseating robin egg blue. Hope somebody can help me before my eyes start bleeding. Brad (talk) 14:24, 17 February 2011 (UTC)

Replace the second line with the following:

div#content { background: #CCCCCC; }

And you're done. Gary King (talk · scripts) 16:27, 17 February 2011 (UTC)

The specificity of the monobook script was raised, requiring this change. The monobook css is a bit 'safer' now, and harder to mess up. Before it was very easy to pick your own classnames that happened to match a monobook class and use it in the wiki code. Then you would get the monobook css and weird effects. This makes it harder to fall into that trap. —TheDJ (talk • contribs) 17:16, 17 February 2011 (UTC)

Ahhhhhhh it's gray again. Let us rejoice. Thanks! Brad (talk) 17:20, 17 February 2011 (UTC)

Reference not working

 Fixed

On Max Page (actor) reference #2 isn't displaying right.Vchimpanzee · talk · contributions · 14:44, 17 February 2011 (UTC)

|title= had a newline. PS— IMDB is not a reliable source. ---— Gadget850 (Ed) ^talk 14:49, 17 February 2011 (UTC)

I am aware of that, but until I can find something better it'll have to do wherever I need to use it. I'm not certain but I think this applies mainly to trivia and not to lists of shows' or movies' casts. Thanks.Vchimpanzee · talk · contributions · 14:51, 17 February 2011 (UTC)

FN SCAR infobox template

The infobox template in the article FN SCAR is broken. The template appears to be choking on the "variants" argument, but I'm not sure why, since it works fine on other articles that use the same infobox template. Anybody know what's wrong with this one? —Lowellian (reply) 15:08, 17 February 2011 (UTC)

I believe it's your bullet points: < li > Templates don't seem to like those. Brad (talk) 15:23, 17 February 2011 (UTC)

I tried removing those < li > elements (and BTW, they're not my bullet points; I didn't add them) from the "variants" argument even before I asked, and that doesn't fix it. Moreover, they do not appear to be the problem, as the template still breaks at the "variants" argument, rather than further down the template where the first < li > elements are used, assuming the ones in the "variants" argument are removed. —Lowellian (reply) 15:52, 17 February 2011 (UTC)

I just had a look myself, Template:Infobox weapon has recently been updated. The same issue is seen on all pages that use this template (eg AK-47, V-2, MIM-104 Patriot etc). Might be worth giving whoever edited it a heads-up. Nanonic (talk) 16:04, 17 February 2011 (UTC)

Ah, thanks. Someone reverted that change and the infobox looks good again. —Lowellian (reply) 20:26, 17 February 2011 (UTC)

NPP script broken

I do a lot of NPP (particularly in the lesser namespaces, where spam and defamatory content can hide for days if not weeks), and to make it easier I use a script that user:Mr.Z-man wrote for me.

However, it's stopped working -- now it tells me that there's been a "Session Failure: There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking."

I've left Mr.Z-man a message, but he's quite busy, so I'm wondering if anyone else might have an idea as to how to fix this. DS (talk) 15:10, 17 February 2011 (UTC)

I believe scripts always have to use patroltokens and the API now... Not 100% sure, but I read something like that in the IRC channel I think. —TheDJ (talk • contribs) 17:35, 17 February 2011 (UTC)

There are 2 scripts. The autopatrol script, which I migrated to jQuery and the API last month, and the links script, which just adds a "patrol" link to each entry on Special:Newpages to allow people to manually patrol. From a quick look, the manual patrol links now also require a token, so the script will need to be modified to get the tokens to put in the links, or just use JS and AJAX to patrol the page, the latter is probably better, but I won't have time to actually do it until Monday at the earliest. Mr.Z-man.sock (talk) 18:44, 17 February 2011 (UTC)

"widen searchbox"(gadget) is dead

How come? Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 17:59, 17 February 2011 (UTC)

Fixed —TheDJ (talk • contribs) 18:09, 17 February 2011 (UTC)

ah, thx Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 18:10, 17 February 2011 (UTC)

Editing box distorted

The buttons above the editing box are distorted, much in the same way as New Features reformed this part of Wikipedia. Most of the buttons are gone, including bluelink, strikethrough, superscript. I have disabled New Features a long time ago. I can't find anything relevant in My Preferences to change it back. Help! Geschichte (talk) 18:57, 17 February 2011 (UTC)

Try Special:Preferences → Editing, "Enable enhanced editing toolbar" (uncheck). –xeno^talk 19:00, 17 February 2011 (UTC)

Links not being underlined any more?

I'm still using the classic look, rather than the new one which didn't grab me.

As of today links in articles are no longer being underlined (until you move the mouse onto them).

Sometimes in past years this has happened before for an hour or two, until (presumably) somebody has restored the code to what it was without the bug. This time it seems to be taking longer?

Does anyone know whether this time the change was intentional? (ie is this a bug, or a misconceived unwanted new feature?) And if it is here to stay, how do I get my underlined links back?

Thanks, Jheald (talk) 19:35, 17 February 2011 (UTC)

See here. Gary King (talk · scripts) 19:38, 17 February 2011 (UTC)

Edit toolbar (once fixed) is now broken again

Yesterday I was able to restore my edit toolbar by running through they typical steps: My preferences → Editing → Beta features → unclick "Enable enhanced editing toolbar". Everything was working fine until now, when all of a sudden the "cite" button on the toolbar disappeared. It was working fine and then *poof*. I'm using Monobook/Firefox. Jezebel'sPonyo^{bons mots} 20:26, 17 February 2011 (UTC)

Sigh...you're correct. It was working fine this morning. Now the Cite button is gone again. I'm also Monobook/Firefox. Maile66 (talk) 20:33, 17 February 2011 (UTC)

Ditto for me, I'm using the same as Ponyo, unclicked "Enable enhanced editing toolbar" to get the cite button back yesterday, but it just disappeared again. Davewild (talk) 20:36, 17 February 2011 (UTC)

It is also gone for me. I am on Firefox 3.6.13 with the vector skin, and the old toolbar (both beta features checkbox are cleared, the refTools gadget box is checked. -- Whpq (talk) 20:50, 17 February 2011 (UTC)

It seems to be fine again. At least for the last 10 minutes. But ever since the update, it does take an awfully long time to load above the edit field. Jared Preston (talk) 21:12, 17 February 2011 (UTC)

Yes it's back again now for me. Davewild (talk) 21:38, 17 February 2011 (UTC)

There is still some problem here. The cite button appears to have moved from the right hand end of the bar to the left end of the bar away from the <ref></ref> button. Much easier with the two buttons together. Keith D (talk) 21:52, 17 February 2011 (UTC)

ClueBot NG down?

It would seem ClueBot NG is down, no edits for the last two days. I would poke the maintainers but neither have edited in the last two weeks. Can anybody help? Rjwilmsi 22:20, 17 February 2011 (UTC)

WP:STiki is working if you change the queue from ClueBot NG to STiki Metadata to get recent changes. It uses the ClueBot NG queue by default, which will only show unreviewed edits from prior to CBNG going down. It's not fully automated, but much better than just going through the RCs. —UncleDouggie (talk) 01:20, 18 February 2011 (UTC)

I've sent User:Crispy1989 an email and left a message on his IRC channel. Nothing yet. —UncleDouggie (talk) 03:38, 18 February 2011 (UTC)

CBNG is down due to a server problem that seems unrelated to the MediaWiki upgrade. —UncleDouggie (talk) 04:08, 18 February 2011 (UTC)

It's now running! —UncleDouggie (talk) 05:49, 18 February 2011 (UTC)

watchlist not loading in Ta.Wiki

We are facing a strange problem in Tamil wikipedia. The watchlist is loading as a blank page since yesterday (feb 17). The page loads first, but when it tries get data from toolserver.org ("transferring data from toolserver.org"), it goes blank. If i hit the stop button in the broswer before the query to toolserver.org initiates (say while "bits.wikimedia.org" is being contacted) the page is fine. From my very limited technical knowledge, i am guessing something is broken in toolserver and the query on watchlist page load, to it is not returning pages/data.

Can anyone help throw some light on this?--Sodabottle (talk) 04:36, 18 February 2011 (UTC)

document.write is used in ta:MediaWiki:Common.js at line 785, conditional on the page being the watchlist. See Wikipedia:Village pump (technical)/Archive 85#Cannot view m:Talk:Spam blacklist: empty page for discussion of a similar problem; the fix applied there should be able to be easily adapted to your situation. Anomie⚔ 04:59, 18 February 2011 (UTC)

Thanks a ton Anomie :-). I have fixed the issue now--Sodabottle (talk) 05:47, 18 February 2011 (UTC)

Resource loader and Tracing CSS

With the new resource loader, all CSS is loaded through load.php, making it impossible to trace the origin of CSS declarations. Adding the ?debug=true to the URL does not change that. Is there another solution that enables me to trace CSS to its origin? — Edokter (talk) — 14:27, 16 February 2011 (UTC)

There's currently no way, no, though I guess it would be helpful. You can find some information in the modules= parameter to load.php, but that's it. Comments indicating where a file ends and the next one starts could be useful here. You can file a enhancement request on Bugzilla. --Catrope (talk) 15:16, 16 February 2011 (UTC)

Comments wouldn't help; the files are still loaded seperately as modules. However, if the module names were to match the filenames (or add a dummy parameter indicating it's origin), it would solve my problem. — Edokter (talk) — 15:24, 16 February 2011 (UTC)

Actually, ?debug=true does work for me. Using that tells me the correct line number for CSS declarations. If the URL already has a "?", then you need to use &debug=true instead, though. Gary King (talk · scripts) 01:28, 17 February 2011 (UTC)

I still get the same cryptic URLs (starting with load.php), except that it shows 'debug=true'. I don't see linenumbers or what else. I'm using Webkits Web Inspector. What are you using? — Edokter (talk) — 12:56, 17 February 2011 (UTC)

You don't see any line number next to load.php? It should tell you line number 1 if you have debug disabled (by default). With debug enabled, it should give you the line number. It works for me in Safari, Chrome, and Firefox. In Web Inspector, try enabling resource tracking with the Resources panel to see if that helps. Gary King (talk · scripts) 16:44, 17 February 2011 (UTC)

OK, I see them. I still have to skim the entire file to find the original location though. — Edokter (talk) — 16:57, 17 February 2011 (UTC)

If you click on the line number it should jump you directly to it in the file. Gary King (talk · scripts) 19:08, 17 February 2011 (UTC)

I know, but I still have to find out what file it comes from. Modules are merged in one big load, hence why I need to skim the file for the filenames. — Edokter (talk) — 19:16, 17 February 2011 (UTC)

I need to load debugged scripts. How can I load debugged resources? Kwj2772 (talk) 10:05, 18 February 2011 (UTC)

You add debug=true to you page url. It's only been mentioned 3 times in this very thread. :D —TheDJ (talk • contribs) 10:18, 18 February 2011 (UTC)

Missing on toolbar - Cite button and cite templates

Resolved

Once again, the cite option on the Editing toolbar is missing, as are the cite templates. Maile66 (talk) 16:53, 16 February 2011 (UTC)

... and for me. Tried changing skin, toggling refTools, edit toolbar with cache clear. Fiddling with vector.js didn't help either. Thincat (talk) 18:04, 16 February 2011 (UTC)

... and for me. I've really become quite dependent on the availability of the Cite button and templates. Darrell_Greenwood (talk) 19:16, 16 February 2011 (UTC)

And for me. --j⚛e decker^{talk to me} 20:22, 16 February 2011 (UTC)

Following this advice above, here is a faltering start towards a work-round (for me). In My preferences, Editing turn off the two options very near the bottom under beta features "Enable enhanced editing toolbar" and "Enable dialogs for inserting links, tables and more". Save. Then, when editing, position the cursor appropriately in editing window, scroll up the window (not merely the editing box) and click the button marked {{CITE}} (last on the right). Select appropriate button appearing underneath. "Preview citation" works but, sadly, "add citation" seems to do nothing. I still have "Show edit toolbar (requires JavaScript)" and "RefTools" on and I don't know whether their status matters. Thincat (talk) 22:31, 16 February 2011 (UTC)

Thanks, but this does nothing for me. I have Firefox. Since today (and not before), if I uncheck the suggested boxes in Preferences and Save, it tells me the Preferences were saved. But it puts the check marks right back. I have the old toolbar. It's just the Cite button that is missing. Also, some interesting funky stuff that is probably related to what they are working on. On any edit page, on the upper right, I get a red lettered "Page notice", and if I click on it, it tells me there is no Template with the name "Template/EditNotices/Page/whatever page I have open". So, I think they're still working - because I don't think that Page Notice is supposed to be there. Hopefully, the Cite button will come back soon. Maile66 (talk) 00:06, 17 February 2011 (UTC)

This is (mostly) fixed now. You'll have to bypass your cache. They removed the variable that I was using to detect whether the toolbar was enabled. The script will still be broken if you have dialogs disabled as I don't know how to detect whether the dialogs are enabled or not. Mr.Z-man 01:12, 17 February 2011 (UTC)

Consider this a virtual dancing in the aisles. The Cite button is fixed!! Thanks. Maile66 (talk) 01:16, 17 February 2011 (UTC)

I'm still a wallflower waiting for a dance;-( For the last three options in My Preferences, Editing ("Beta Enhanced toolbar", "Beta Enable dialogs for inserting" and "Labs Enable preview dialogs"), if all are off I get a {{CITE}} button which goes fine until the last moment when "add citation" does nothing. This has functionality for fillling in other fields from data extrracted from the supplied URL. However, if the last two options are off and on (in order) I get no cite option. Otherwise, I get the previous "Cite" tab (after "special characters...help") which seems to work as before. Thincat (talk) 09:28, 17 February 2011 (UTC)

Ah ha! I have switched from Vector to MonoBook skin after reading this. Now, with the three options I mentioned above Off, Off, On I get a working "Cite" button (new style). I have kept "edit toolbar" and "RefTools" On and I think this is also a requirement. Thincat (talk) 09:46, 17 February 2011 (UTC)

RefTools not working

Hi there. Since Wednesday, 18th February 2011, I've noticed that reftools is no longer working on my browser (I'm using Windowx XP, Firefox 3.6.13). Been using reftools since 2009 without any issues. I've tried out all options both in "Appearance" and "Gadgets" in the Preferences menu, yet the reftool bar doesn't appear each time I edit an article. (btw, I have java installed on my system as well). Any idea why I can't access reftools anymore? Amsaim (talk) 09:36, 17 February 2011 (UTC)

This side of the dateline: confirming. They're broken. --Old Moonraker (talk) 10:52, 17 February 2011 (UTC)

For the original edit toolbar, the only way to make it work is to disable wikEd either in gadgets or on the fly with the on/off button on the wikEd toolbar. For the enhanced toolbar, it works more often, but sometimes the cite window becomes wider than my browser window and there's no horizontal scroll bar. I greatly prefer the original toolbar & refTools plus anyway. I actually don't need the rest of the toolbar because I have wikEd, I just need the cite button. I don't like the ProveIt UI. I'm running FF 3.6.13. —UncleDouggie (talk) 11:15, 17 February 2011 (UTC)

This is also being discussed above at Wikipedia:Village_pump_(technical)#Missing_on_toolbar_-_Cite_button_and_cite_templates. Thincat (talk) 12:22, 17 February 2011 (UTC)

I see I am not alone in being affected by the recent media wiki and reftools changes. See Wikipedia talk:RefToolbar 1.0#broken since 14 February 2011? where I tested various Gadget combinations. I still wish that the old toolbar was brought back ([14] [15]), but this combination at least gets me the new-style Cite button working on Firefox 3.6.13 with monobook:

"Show edit toolbar" off

"refTools" Gadget ON

"Enable enhanced editing toolbar" ON

"Enable dialogs for inserting links, tables and more" ON

-84user (talk) 12:45, 17 February 2011 (UTC)

Also on FF 3.6.13 and having gone to Monobook (for exactly this reason), this gives me the Cite tab as previously but not the new Cite button. For this I need (as I reported above)

"Show edit toolbar" ON

"refTools" Gadget ON

"Enable enhanced editing toolbar" OFF

"Enable dialogs for inserting links, tables and more" OFF

"Enable preview dialog" ON

I would prefer your setup if it worked for me. Thincat (talk) 13:06, 17 February 2011 (UTC)

Maybe something changed in media wiki very recently but I can now get the old edit toolbar plus the old "cite" icon with this combination:

Preferences / Editing / Advanced options : ON: Show edit toolbar (requires JavaScript)

Preferences / Editing / Beta features  : OFF: all options

Preferences / Gadgets / Editing gadgets  : ON: refTools

I tested the icons B, I, #R, <ref /ref> and <<CITE>> for web and news.

Here is the combination that gets a working new-style toolbar plus working new style cite (it previewed and inserted citations for {{cite web}}):

Preferences / Editing / Advanced options : OFF: Show edit toolbar (requires JavaScript)

Preferences / Editing / Beta features  : ON: Enable enhanced editing toolbar

Preferences / Editing / Beta features  : ON: Enable dialogs for inserting links, tables and more

Preferences / Editing / Labs features  : OFF: Enable preview dialog

Preferences / Gadgets / Editing gadgets  : ON: refTools

I have no other Editing gadgets on, but I do have Browsing gadgets / Navigation popups ON; I also have this monobook.js. -84user (talk) 13:47, 17 February 2011 (UTC)expanded the prefs. -84user (talk) 13:55, 17 February 2011 (UTC)

Correction to my preferences above. It appears that the above preferences do not get the old CITE working. Instead I forgot that I still had "importScript('User:Apoc2400/refToolbar.js');" in my User:84user/monobook.js. That line is essential. Without it there is no CITE icon displayed in the old style edit toolbar. -84user (talk) 20:11, 17 February 2011 (UTC) strike through correction; I can confirm Kaldari's report that the old settings work again. Thanks all. -84user (talk) 10:53, 18 February 2011 (UTC)

OK, all the RefTools stuff should be fixed now. Feel free to go back to your old settings. Kaldari (talk) 02:45, 18 February 2011 (UTC)

For remaining issues with wikEd compatibility, see Wikipedia_talk:RefToolbar_1.0#wikEd_compatibility. —UncleDouggie (talk) 07:58, 18 February 2011 (UTC)

Disable smaller font size of elements gadgets no longer works without javascript

The gadget "Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists" worked fine without javascript until today with Mediawiki 1.17. I prefer to leave javascript off most of the time, but I also love being able to read the references etc text at the same font size. Is there a way to resolve this (new) issue? TransUtopian (talk) 17:52, 16 February 2011 (UTC)

What browser and skin are you using? —TheDJ (talk • contribs) 20:45, 16 February 2011 (UTC)

I'm using Opera 10.60 and Monobook. TransUtopian (talk) 23:09, 16 February 2011 (UTC)

It should work even without JS enabled for your browser, since it uses CSS, not JS. Gary King (talk · scripts) 01:25, 17 February 2011 (UTC)

Actually, it now relies on the resource loader, which is javascript, to load all the gadgets. I don't know if gadgets required javascript before the update. — Edokter (talk) — 01:32, 17 February 2011 (UTC)

Since I disable JS unless I specifically need it for something, I'd say this gadget didn't require it before. Is there something I can add to my CSS that'll duplicate the gadget, or can specific gadgets be removed from using the resource loader (or have a duplicate version that doesn't use it)? TransUtopian (talk) 12:01, 17 February 2011 (UTC)

(←) Put the following line at the top of your skin CSS file:

@import url(http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-NoSmallFonts.css&action=raw&ctype=text/css);

That should do the trick. — Edokter (talk) — 12:46, 17 February 2011 (UTC)

That workaround works. Thank you very much, Edokter! And thanks to everyone else for helping in the process. TransUtopian (talk) 16:25, 17 February 2011 (UTC)

Update: The NoSmallFonts works, but it disables the non-display of citation needed tags I added long ago to my skin CSS. (I briefly reverted to confirm.) My CSS includes

.Template-Fact {display:none;}
.Inline-Template {display:none;}

Can you please tell me if there's a way to make this work again? TransUtopian (talk) 18:18, 17 February 2011 (UTC)

That is weird, but try the following:

.Template-Fact {display:none !important;}


.Inline-Template {display:none !important;}

— Edokter (talk) — 20:09, 17 February 2011 (UTC)

I tried it but I'm afraid it didn't work. FYI, I also have .ambox {display:none;} in there to suppress maintenance boxes, which still works fine. I tried the two lines you suggested atop the ambox line, and then with ambox in the middle (its original position). Do you have any other ideas? TransUtopian (talk) 21:30, 17 February 2011 (UTC)

There were some chages in CSS with regards to specificallity; that may be the cause. Try the following:

span.Template-Fact {display:none;}


span.Inline-Template {display:none;}

— Edokter (talk) — 23:03, 17 February 2011 (UTC)

Tried it and a couple variations (moving them around, adding a period before span), saving the CSS each time and force-refreshing a page with [citation needed]s. I can still see them. I'm willing to try more ideas if you've got them. TransUtopian (talk) 00:19, 18 February 2011 (UTC)

OK, I need to know what you ar trying to hide, so I can come up with the proper CSS. — Edokter (talk) — 00:21, 18 February 2011 (UTC)

(←) OK, I found what you need:

sup.Template-Fact {display:none;}


sup.Inline-Template {display:none;}

— Edokter (talk) — 00:25, 18 February 2011 (UTC)

I'm afraid that didn't work either. You're correct that I'm trying to hide the superscripted templates (I assume that's what sup means) at Wikipedia:WikiProject Inline Templates, primarily Template:Citation needed. "View source" told me it's based on Template:Fix so I tried sup.Template-Fix {display:none;} after I tried Fact, but no dice. TransUtopian (talk) 02:09, 18 February 2011 (UTC)

YES! It finally works, after reordering the elements, like so

@import url(http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-NoSmallFonts.css&action=raw&ctype=text/css);
.ambox {display:none;}
sup.Template-Fact {display:none;}
sup.Inline-Template {display:none;}

Result: No small text, no maintenance amboxes, no citation needed inline templates. I don't know why only that order works, but I'm thrilled it does. Thank you again, Edokter, for your invaluable and patient help. TransUtopian (talk) 19:01, 18 February 2011 (UTC)

Glad it works. Yes, the @import line should be at the top, but I already said that :) — Edokter (talk) — 21:04, 18 February 2011 (UTC)

Yes, you did. :) I played around with it afterwards just to see if everything would quirkily work in another position. The .ambox has to be above the sups to make everything work. Having it below or between the sups was making the sups not work. TransUtopian (talk) 21:11, 18 February 2011 (UTC)

I can't explain that one. Oh well... — Edokter (talk) — 22:05, 18 February 2011 (UTC)

Blue new message bars?!

Is there a CSS snippet I can get to change it back to orange? /ƒETCHCOMMS/ 19:09, 16 February 2011 (UTC)

Better still, change it back. I don't remember seeing any discussion or consensus for this change. Mjroots (talk) 19:15, 16 February 2011 (UTC)

(edit conflict) Is there a good reason (or consensus, for that matter) for the change in the first instance? Should be restored in the common css, imo. –xeno^talk 19:15, 16 February 2011 (UTC) (FWIW, it is still orange for me, on monobook)

Yeah, I like the orange one better too. Catches your eye better. --T H F S W (T · C · E) 19:25, 16 February 2011 (UTC)

I don't care what color the bar is, but if someone is going to change the 'new message' notice, could I make a plea for the addition of a history button? "Last change" fairly often leads me to miss messages (when multiple edits are made to the page in short succession). WhatamIdoing (talk) 19:32, 16 February 2011 (UTC)

div.usermessage { background-color: #FFCE7B; border: 1px solid orange; } in your css would change it back, I suspect. @WhatamIdoing, there's some script to do that I believe, I'll see if I can find it for you (here you go) . - Kingpin¹³ (talk) 19:38, 16 February 2011 (UTC)

Whose decision was this? Bad. Very bad. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 19:49, 16 February 2011 (UTC)

Someone isn't reading what is written. I don't want to have to go round fiddling with codes that I don't understand to get back something that appears to have been changed without discussion and therefore without consensus. I want the message bar changed back to how it was. A RFC or similar should then be opened on whether or not the community desires the change, or whether it should be an option, like the [edit] button at the end of header text instead of at the right side of the page. Mjroots (talk) 19:55, 16 February 2011 (UTC)

I believe this can be easily fixed by editing Mediawiki:Common.css (or maybe just MediaWiki:Vector.css) and I have suggested it be changed back at MediaWiki talk:Common.css#MW 1.17 now live, juicy style/script excitingness for all. –xeno^talk 19:58, 16 February 2011 (UTC)

Mr. MediaWiki 1.17 isn't very nice. --Perseus8235 19:56, 16 February 2011 (UTC)

Now that's not very fair, I wouldn't put it down simply because it changes the colour of the new messages banner. Just to better explain how to apply my piece of css up above, simply visit Special:MyPage/vector.css, click edit, paste in div.usermessage { background-color: #FFCE7B; border: 1px solid orange; } and then select save. Everything will be back to normal for you. If we placed this code in the MediaWiki:Vector.css as xeno mentions, it would be back to normal for everyone, but we'd need consensus for that. For those asking why this was changed, it was originally changed at another wiki (they do exist) specifically for vector, because it works better with the colour scheme. It was discussed briefly at bugzilla (I believe). - Kingpin¹³ (talk) 20:11, 16 February 2011 (UTC)

I don't think we need consensus to restore the status quo. Why was it changed globally, instead of for the particular wiki that requested it? –xeno^talk 20:14, 16 February 2011 (UTC)

Consensus???? Per Xeno. Despite your sracasm Kingpin most of us are aware that other wikis exist. Pedro :  Chat  20:23, 16 February 2011 (UTC)

Could you clarify what you mean by "consensus??"? I think xeno meant it wasn't needed to restore it at enwiki, not that there was no need for consensus to restore it globally.. - Kingpin¹³ (talk) 20:28, 16 February 2011 (UTC)

Yes, that would be the "per Xeno" bit. Pedro :  Chat  20:38, 16 February 2011 (UTC)

Well it was to start with, you see it was changed for that particular wiki first, and they decided it worked well enough to make it global. Yeah, maybe we can just change it back, I guess the only problem is we want to be sure, so we're not going backwards and forwards with the common css files - Kingpin¹³ (talk) 20:21, 16 February 2011 (UTC)

I must admit, I'm fairly confused as to why that this change was made without local consensus. I understand that en.wiki is not the only Wikimedia project, but it is the largest. And we have a hard enough time getting changes through where unanimous local consensus exists - why was this changed without so much as a "hey, we're planning on doing this?" (I realize you personally were not responsible, do please don't take this as shooting the messenger - my question is to whoever knows the answer) –xeno^talk 20:24, 16 February 2011 (UTC)

this is the dumbest thing I've seen lately; this bar is not supposed to blend in, it's supposed to pop out at you. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:22, 16 February 2011 (UTC)

Geez, people could show some appreciation for the work that went into this update, it's not particularly "dumb". After-all you don't want it flashing-bright-pink do you? :). It's really a matter of personal preference, and I've given you some code up above which allows you to set it on a personal level. - Kingpin¹³ (talk) 20:28, 16 February 2011 (UTC)

As a matter of fact, flashing-bright-pink would be even better than orange. People are supposed to see it. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:30, 16 February 2011 (UTC)#

If you say so, but I doubt many would agree with you about that, - Kingpin¹³ (talk) 20:45, 16 February 2011 (UTC)

I appreciate the hard work that developers do, and generally cringe when I see them being bitten; but I think that they would be even more appreciated (and incur less bite marks) if they asked us, or gave us a heads up, prior to making a sweeping change like this. The new messages bar is a central component of Wikipedia that has been orange for as long as I can remember. Do you happen to have any links to where this was discussed? I couldn't find anything using an advanced bugzilla search. –xeno^talk 20:34, 16 February 2011 (UTC)

Don't worry, it's not your comments I have an issue with. Yeah, bugzilla's search is impossible to use, here's a link to a discussion about it. I got that from searching through my history, I think I originally went there from another discussion on-wiki about the changes. Apparently my memory may be a little bit wrong, and the German Wikipedia didn't actually implement it as a standard, just as a common change users made. - Kingpin¹³ (talk) 20:45, 16 February 2011 (UTC)

Thank you for the link. Based on that, I'm still pretty astonished that it went through on a global basis despite the objections raised there. –xeno^talk 20:49, 16 February 2011 (UTC)

← I've initiated an editprotected request at MediaWiki talk:Vector.css#Change "You have new messages bar" back to orange. –xeno^talk 20:49, 16 February 2011 (UTC)

Status Quo restored. However might I suggest we look at ways to make the messages bar more "vector" like, but keeping it more visible ? I think that is the least we can do. —TheDJ (talk • contribs) 21:04, 16 February 2011 (UTC)

That sounds reasonable, as long as the discussion is well-trafficked and widely-advertised and so any changes have consensus and do not take users by surprised. Thanks for fulfilling the editprotected request. –xeno^talk 21:11, 16 February 2011 (UTC)

They've been made aware of our displeasure at the lack of discussion over at bugzilla. As I stated earlier, this should really be the subject of a RFC, with all options explored (status quo, change to blue, enable blue [and possibly other colours] as a user option etc). Mjroots (talk) 21:19, 16 February 2011 (UTC)

Parkinson's Law of Triviality is in full effect. the wub "?!" 22:35, 16 February 2011 (UTC)

Sometimes the color of the bike shed really does matter (it might seem trivial to you, but the neighbors have to see it too). —Emufarmers^(T/C) 23:32, 16 February 2011 (UTC)

In this instance, a better analogy might be "the color of the life raft." The bar's appearance was based upon something other than aesthetics, and it appears that this fact was overlooked/ignored (even after it was pointed out). —David Levy 00:28, 17 February 2011 (UTC)

The orange has always driven me crazy, but I agree that the light blue was worse because it didn't stand out at all. Thanks to this thread, I now have my own pleasing medium purple. It might be a good candidate for other vector users as well. I rounded the corners slightly, but less than the blue version. —UncleDouggie (talk) 11:00, 17 February 2011 (UTC)

You have new messages (last change).

I've reverted it in revision 82315. (X! · talk)  · @064  ·  00:32, 17 February 2011 (UTC)

Is Phase3 the live version? Or do we have to wait until 1.18? — Edokter (talk) — 00:40, 17 February 2011 (UTC)

"Phase 3" simply means MediaWiki. The key part of that path is "trunk", which is the current development branch (1.18alpha). Wikimedia sites are running the 1.17wmf1 branch, and it hasn't been reverted there. Reach Out to the Truth 03:04, 17 February 2011 (UTC)

Yay, this seems to be fixed. However, is it just me or are redlinks appearing in a darker red? Can I have the CSS snippet to change that back to #CC2200, or is this not possible? /ƒETCHCOMMS/ 03:11, 17 February 2011 (UTC)

They look identical to this text sample that is #CC2200 for me. —UncleDouggie (talk) 09:14, 17 February 2011 (UTC)

Hmm, it was different before (I compared) but looks back to normal now to me. /ƒETCHCOMMS/ 22:23, 17 February 2011 (UTC)

I like the purple bar, but I just don't know if it's obnoxious enough. Amazingly, some people claim to not even notice the retina-burning orange bar. :/ --Dorsal Axe 21:20, 17 February 2011 (UTC)

Perhaps you would prefer one of these? —UncleDouggie (talk) 01:11, 18 February 2011 (UTC)

You have new messages (last change).

You have new messages (last change).

You have new messages (last change).

This might be even more obvious:

<div style="background-color:#5aed43; border:1px solid #ff570a; color:#cc0bbd; font-weight:bold; margin:2em 0 1em; padding:.5em 1em; text-align:left; border-radius: 0.6em; box-shadow: 2px 2px 3px #CCC; 3px;">You have new messages (last change).

Unfortunately, the text-decoration:blink property is apparently blocked by MediaWiki. Sadness :( /ƒETCHCOMMS/ 21:21, 18 February 2011 (UTC)

No it's not, but it isn't support by Internet Explorer or Google Chrome. — Dispenser 22:47, 18 February 2011 (UTC)

Can I make a suggestion here? something I used to do was resize the message bar and make it fixed position, so that it would always pop up on my browser window in the same position. I'm not suggesting anything that drastic, but, we could keep the vector blue message bar (which looked nice) but add in a small, separate fixed-position div of some bright color that would always be visible onscreen when you have a message waiting. best of both worlds that way. I'd give a demo, but (if I remember correctly) fixed position divs get flagged by the vandalism software because of abuses. --Ludwigs2 23:02, 18 February 2011 (UTC)

Confused

I heard We were rolling out Media Wiki software updates and today I see alot features that are popping up. Is there some place where I can read about all the new features in simple terms? I am not a programmer but would like to know what the average Wikipedia can now do now that we couldnt do before. The Resident Anthropologist (talk) 22:17, 17 February 2011 (UTC)

It was yesterday, I believe. Here's a list of what changed: [16]. It should be mostly accurate; I don't know if all the changes are live here. /ƒETCHCOMMS/ 23:24, 17 February 2011 (UTC)

The biggest change is probably the implementation of ResourceLoader, which is supposed to basically speed up the loading of CSS and JS files, essentially making pages load faster. So it's mostly advantageous for developers as they should be implementing it into their scripts. Gary King (talk · scripts) 00:13, 18 February 2011 (UTC)

WP:BRION</shameless self plug> Also check out the issue that comes out on Monday for coverage :) - Jarry1250 ^{[Who? Discuss.]} 17:30, 18 February 2011 (UTC)

MediaWiki software and scripts

I have recently been experiencing problems when running scripts since about Thursday 17 February. Note that I have had similar problems before, but they went away. Recently, the problems resurfaced.

I run a number of regex-based scripts (which can be seen among the stuff at my user page). I made some changes to one of them yesterday, after which I can no longer access any of the sidebar script buttons. I reverted back to an earlier version that I know worked yesterday, but still no joy. The earlier problem was due to a fatal error in the script – another editor who uses my scripts (including the one changed) noticed the script became inaccessible, and informed me. After I had fixed the bug, it resumed working for him; my cupboard remains bare. :-( My friend uses FF on Mac; I have had no success when running FF, Chrome or Safari on Windows. I then tried removing the script from my vector.js, expecting most of the scripts to be restored, but still no.

I suspect the problems may be caused by the MW software, with which I have noticed recent instabilities, which included (amongst other problems) pages 'disappearing' from browser history when surfing WP – I go forwards several pages, but some of the intermediate pages in history are not accessible when I navigate back using the back-arrow; also some pages load without the skin. Does anyone have any similar experiences with scripts recently? --Ohconfucius ^¡digame! 08:36, 18 February 2011 (UTC)

E-Mail User Links not Working

When I click to email someone via Popups, I get the message: "You have not specified a target page or user on which to perform this function." When I go to the Special page, I get: "You have requested a special page that is not recognized by Wikipedia. A list of all recognized special pages may be found at Special:Specialpages." Both times, it gives me a link to the Main Page to click. Is this related to the 1.17 update? - Neutralhomer • Talk • 09:00, 18 February 2011 (UTC)

bugzilla:27526. I can fix it for popups, but this is just a bug in the new software and really should be fixed there. —TheDJ (talk • contribs) 09:34, 18 February 2011 (UTC)

I have never been good at filing BugZilla reports. If you can fix it, please feel free. I have also posted this at the Popups page. - Neutralhomer • Talk • 09:54, 18 February 2011 (UTC)

• Popups are not working for me at all. Glad not to be the only one... --Ohconfucius ^¡digame! 10:04, 18 February 2011 (UTC)

Fixed in r82392, but it may be some time (hopefully only a couple of weeks) until that's deployed to the WMF cluster. Happy‑melon 11:30, 18 February 2011 (UTC)

User Interface Gadgets-Display assessment

New quirk. More than an hour ago, maybe something happened in the system. I did a couple of edits that didn't show up on my Watch List, Contributions, or the actually edited pages for about half an hour. That particular thing cleared up. There have been no changes in my profile. During that same time, and since, if I change the page assessment on a Talk page, it will show on the Talk page fine. But on the main page assessment display at the top, it doesn't update. I changed the assessment on Homeboy Industries, and the display on the main page shows the old assessment. I have Firefox and Monobook. Maile66 (talk) 19:37, 18 February 2011 (UTC)

When the servers are very busy, at times it can happen that they serve you outdated content. (There are multiple servers handling the requests, and when they are really busy, they sometimes get out of sync with eachother.)—TheDJ (talk • contribs) 00:19, 19 February 2011 (UTC)

Atom feeds no longer work to track contributions for a certain user or IP

I'm sorry if this issue has been already reported or if this isn't the right place to announce it, but I've just found out that, as I state in title, Atom feeds for any contribution page are empty, no matter how many editions the user (or IP) has done.

Thank you. --Canyq (talk) 21:51, 18 February 2011 (UTC)

You are right. Thanks for reporting it. Filed as issue bugzilla:27339. —TheDJ (talk • contribs) 23:59, 18 February 2011 (UTC)

Excellent! Thank you very much.--Canyq (talk) 00:11, 19 February 2011 (UTC)

Bloody awful appearence

All the gadgets stopped working, the stuff from the top of the page (my talk, prefs, etc, and all the page/discussion/edit etc) all jumped down to the bottom of the page, and it ll generally looked hideous. Now in the edit screen, it's almost back to normal but the edit box toolbar has changed its appearence and the cite hutton etc has disappeared. Is this one of the regular "improvements"? I would upload a screenshot, but the upload screen seems to have changed again and I can't find the option for WP screenshots (which I'm sure there was for a while). DuncanHill (talk) 10:18, 16 February 2011 (UTC)

That was another attempt to deploy MW 1.17. They've already reverted it. MER-C 10:23, 16 February 2011 (UTC)

IT's still taking ages for pages to load, the "discussion" and "edit" tabs at top of page are overlapping. Mjroots (talk) 10:28, 16 February 2011 (UTC)

• Well, the blackscreen gadget is working again, but the tbs and links are still in the wrong place. Edit screen (I unchecked the beta thing referred to in the post above) now has no edit toolbar at all, and the special characters are all showing up at once with no drop-downs, and no clickability. DuncanHill (talk) 10:39, 16 February 2011 (UTC)

We're in software upgrade mode, and various parts of the server structure are getting hammered. Hold on to your hats, and hopefully things will settle down again soon. Happy‑melon 10:53, 16 February 2011 (UTC)

Indeed, it's called a maintenance window for a reason, and some strangeness was expected. Good news, all ok now, and were running 1.17. —TheDJ (talk • contribs) 11:43, 16 February 2011 (UTC)

All ok, except blackscreen gadget not working (except in edit screen, when the pge loads without the blackscreen and then the blackscreen "switches on" after it loads), pop-ups not working, and the clock gadget not shoing up on watchlist (or anywhere else except in the edit screen). So not all OK at all. DuncanHill (talk) 12:00, 16 February 2011 (UTC)

I think he means that, unlike the previous attempts to deploy MW 1.17 which crashed the entire cluster, this deployment has been successfully implemented. There was plenty of warning that there would be bits of user JS and CSS which would need fixing after deployment. Happy‑melon 12:04, 16 February 2011 (UTC)

And HotCat isnz't working either. Are any of the gadgets in user preferences working? DuncanHill (talk) 12:05, 16 February 2011 (UTC)

And, for the record, where were these warnings? I never had any warning that all the gadgets would stop. DuncanHill (talk) 12:09, 16 February 2011 (UTC)

The CentralNotice that you've probably hidden :P And all over wikitech-l, the techblog, etc. Happy‑melon 12:10, 16 February 2011 (UTC)

No offense to you personally, but using centralNotice as the only onwiki channel for critical issues is very stupid. It has so often been abused for trivialities and outright spam that many editors have disabled it. — Gavia immer (talk) 12:16, 16 February 2011 (UTC)

(ec)If a Central Notice is the same thing as the bloody fundraising banners, then of course it's hidden. I'm pretty sure it's not been on a watchlist notice. No idea what wikitech-l is, and not an habitué of the techblog. DuncanHill (talk) 12:18, 16 February 2011 (UTC)

It's been posted to every major Wikimedia mailing list, and here at the tech village pump. And if you're at all interested in Wikimedia technical matters, the techblog is an excellent way to keep up. I'll admit that a watchlist notice might have been a good idea though. the wub "?!" 12:24, 16 February 2011 (UTC)

My interest in Wikimedia technical matters extends to "does it work?" and "will someone please make it work again?" DuncanHill (talk) 12:29, 16 February 2011 (UTC)

Then you should read the many other venues that the wub pointed out. We can't read peoples minds and magically figure out who wants what information directly delivered to his brain at what time. —TheDJ (talk • contribs) 19:48, 17 February 2011 (UTC)

I shouldn't have to traipse around "many other venues" to find out if Wikipedia is working, or if anything is being done to fix things that are broken. DuncanHill (talk) 22:22, 17 February 2011 (UTC)

Yet you would complain if we constantly had banners stating what was broken (couple dozen things every day), because they would be constantly in your face and you wouldn't be able to use the encyclopedia. I mean, you can't have it both ways. In situations where things constantly change, break and get repaired, there is no informing that will ever satisfy your criteria of not being spammed, yet being constantly informed of everything. Perhaps not ever making a change would be an idea ? But then developers would of course be shouted at by the other users clamoring for new functionalities and worried that the non-patched security issues are exposing their private information. I leave you all in this discussion, with this very nice column I once read. If Architects would work like software engineers. —TheDJ (talk • contribs) 13:49, 19 February 2011 (UTC)

Hey, how about a venue where people could come and ask what's gone wrong without being blamed for not reading the notice that was hidden from them? And to be frank, if you can avoid demanding money from me with disturbing pictures, I really wouldn't mind too much getting messages! DuncanHill (talk) 14:20, 19 February 2011 (UTC)

It's very easy to make the mistake of thinking that the MediaWiki world revolves entirely around enwiki and that everyone should use enwiki's preferred notification methods to inform about changes like these. This deployment affected all 850 wikis in the Wikimedia cluster; there is no justification for saying that the sysadmins should have laboriously gone around and identified the preferred channels for each and every wiki, including those in languages they don't even speak; and equally no reason for enwiki to get any special treatment. Rather, the sysadmins used the channels which are already set up to allow crosswiki communication. It's unfortunate that you've chosen not to receive those messages, but really not anyone's fault but your own. Happy‑melon 12:35, 16 February 2011 (UTC)

I chose not to receive poorly written and offensive begging messages. I don't see why editors and readers should be expected to spend their time on a techblog just in order to have some idea of what is happening. When you find that your method of communication is not working, blaming the people you have failed to communicate with just comes across as arrogant. DuncanHill (talk) 12:45, 16 February 2011 (UTC)

I'd say that it would be claiming that one particular person, group or community should be given special treatment in that communication, which comes across as arrogant. By hiding the CentralNotice you have also hidden information about the Steward elections, Wikimania, and various other Wikimedia-wide issues. It's entirely reasonable to say that you are not interested in crosswiki issues, and to hide the entire CentralNotice. Or it's reasonable to say that you only dislike the fundraiser banner, and to hide that specifically. But to say that you want to be kept informed of crosswiki issues, and then to deliberately block out the communication channel which has been created for those issues, is counterproductive at best. Happy‑melon 13:04, 16 February 2011 (UTC)

Had Centralnotice not been abused for those ridiculous Jimbo fundraising banners, few people would have disabled it. From then on, Centralnotice has been perceived as spam. And the WMF has only itself to blame for it. --Morn (talk) 13:16, 16 February 2011 (UTC)

I'm sorry, Happy-Melon, I didn't realise that we weren't allowed to want to know about changes to Wikipedia unless we also wanted to know about lots of other irrelevant stuff. And, FWIW, I have seen messages about the Steward elections, and Wikimania. Like (I suspect) most editors and readers I really do not care much about cross-wiki stuff, but I do care about the reading and editing environment here. You obviously don't regard that as acceptable - it's "all or nothing". DuncanHill (talk) 13:30, 16 February 2011 (UTC)

Anyway, the thing I've got suppressed is "display of the fundraising banner", according to my prefs/gadgets. Doesn't say anything about "suppress notice of planned cross-wiki disruption" DuncanHill (talk) 14:34, 16 February 2011 (UTC)

You certainly don't seem to realise that you're not allowed to expect other overworked and un- or under-paid people to alter their professional behaviour to accommodate your personal definition of what is and is not "irrelevant", no. Essentially this is a "the world does not revolve around you" discussion, and I doubt it's going to go anywhere productive. Happy‑melon 14:45, 16 February 2011 (UTC)

Umm, just a note here - I am not sure what you mean by CentralNotice, since I also have only the Fundraising banners disabled (and that only after a glitch appeared that made them reappear immediately after they were dismissed). I can see and do notice all the other stuff at the top of pages, such as the Stewards' election notice. And I didn't see word one about this rollout on en.wiki; in fact I specifically looked for a notice about it after I saw it on de.wiki. I suspect you will find it did not actually get advertised on en.wiki. (Whether users should have been alerted that "We are enabling a new feature" means "Your preferences may get mucked up" in addition to "Things will be a bit wonky while we fine-tune this" is a separate issue.) Please stop assuming bad faith when folks tell you they didn't see the notification. Yngvadottir (talk) 22:15, 16 February 2011 (UTC)

According to this the generic maintenance CentralNotice about this upgrade ran from 06:00 to 12:00 UTC on the 16th. Now, I am certain that I didn't see it when I came online on the 16th. Is it possible to check if it actually deployed properly? Also, does the "suppress the fundraising banner" option given to all logged-in users also suppress other notices, such as this one? DuncanHill (talk) 14:30, 17 February 2011 (UTC)

This is actually my mistake. Because the fundraising people didn't use proper CSS ids and classes, i was forced to adapt the fundraiser gadget to suppress all centralnotices. The idea was that the gadget would be removed after the fundraiser, so it wouldn't be a problem, but I (nor anyone else though) remembered. That's the problem with these kinds of hacks, they have a way of backfiring. I'm removing the gadget now. —TheDJ (talk • contribs) 19:52, 17 February 2011 (UTC)

Firstly, six-hours is an inadequate time-scale, as the disruption was somewhat longer. Try leaving it up until the major issues are fixed. Secondly - thanks for the apology. Next time someone says they didn't get any notification, check first that you actually did notify them. DuncanHill (talk) 22:22, 17 February 2011 (UTC)

As long as we're reporting issues here, I have another one: loading my watchlist in Firefox 3.6.13 now renders almost all of the way and then hangs briefly, obviously due to some javascript not loading properly. I haven't been able to work out the exact cause, so I will simply note that it is definitely a 1.17 issue. — Gavia immer (talk) 12:16, 16 February 2011 (UTC)

There's another change under Help, which gives the user a lot fewer options when searching Help. Now you get "Browsing", "Editing", "Guidelines", "Communication", "Questions", "Technical". OK for somebody Wikipedia savvy enough to know words or phrases to narrow their search. But what about someone who has never used Help before? If you want to narrow your search down to, say, only finding a template or a wikiproject, you need prior knowledge of Wikipedia to know to put it all in the search bar. The user does not have check boxes to help him/her narrow their search. Maile66 (talk) 12:37, 16 February 2011 (UTC)

I suspect that's a completely separate issue - someone tried redesigning Help:Contents (it's been reverted for now). Discussion at Help talk:Contents.

Thanks. Maile66 (talk) 13:01, 16 February 2011 (UTC)

The new messages bar appears to be partly broken, it still links ok, but the colour is wrong (Firefox). Mjroots (talk) 14:30, 16 February 2011 (UTC)

Yes, mine too (baby blue instead of the "orange bar of death" we've come to know and love). This is in IE. Ruhrfisch _><>°^° 15:43, 16 February 2011 (UTC)

That's the expected behaviour (r76017, T27145). No comment on whether it's a positive development... Happy‑melon 16:59, 16 February 2011 (UTC)

Hm, it's definitely not the best colour choice. Would have missed it if someone didn't mention it. It really should be more of an obnoxious blue, like the {{talkback}} template uses. — Preceding unsigned comment added by Dorsal Axe (talk • contribs) 17:12, 16 February 2011 (UTC)

You can change it. I changed mine to screaming bloody red as a joke a few months ago and realized I liked it so I never switched back. Just add

.usermessage {

background-color: #ff0000

border: 1px solid #ffa500;

color: black;

font-weight: bold;

margin: 2em 0 1em;

padding: .5em 1em;

vertical-align: middle;

}

anywhere in your CSS file and it will override the default appearance. (I don't remember if the attributes for things other than the colors are redundant or not.) —Soap— 22:09, 16 February 2011 (UTC)

This has already all been sorted out down at #Blue_new_message_bars.3F.21 :) - Kingpin¹³ (talk) 22:13, 16 February 2011 (UTC)