Contents

Wikipedia:Village pump (technical): Difference between revisions

Revision as of 18:00, 8 February 2011

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

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 (nosubmarine patents). ▫ JohnnyMrNinja 10:57, 7 February 2011 (UTC)[reply]

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)[reply]

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 threadonWP:PERF; I think it you'll find it interesting. Happy‑melon 13:42, 30 January 2011 (UTC)[reply]

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)[reply]

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

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

/* 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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Note: The first comment in this section was originally postedtoTalk:Main Page. Graham87 01:23, 3 February 2011 (UTC)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

• 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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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.

<?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)[reply]

[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)[reply]

"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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 admins who try to assign a single /128 or something non-standard between a /64 and /128. 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 Ljubljanaitseems 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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]