Wikipedia:Village pump (technical)/Archive 74

• 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, 217

RfA votes and automated edit counts

Are these tools still available? Jeffrey Mall (talk • contribs) - 12:36, 8 April 2010 (UTC)

These ones? Chris Cunningham (not at work) - talk 21:06, 8 April 2010 (UTC)

Ahh I found them thanks! Jeffrey Mall (talk • contribs) - 23:20, 8 April 2010 (UTC)

wildcards for template subcategories

With User:DASHBot/Wikiprojects wildcards work. The bot lists articles in a wikiproject by category, for example:

Category:* Germany articles

I am using User:DASHBot/Wikiprojects/Templates which creates a list by template.

Do wildcards work for a bot to list certain subcategories in a template?

For example, to have the User:DASHBot/Wikiprojects/Templates bot list all templates with have a&e in them like:

{{WPBiography|living=yes|class=stub|a&e-work-group=yes|needs-infobox=yes|listas=108}} 

could I use

Template:WPBiography*a&e*?

If this question does not make sense, here is a more detailed explanation. Okip 01:24, 9 April 2010 (UTC)

Help with Penthouse Pets category

The category for Category:Penthouse Pets has a bunch of navigation templates. There is a subcat to contain those (Category:Penthouse Pets navigational boxes) and the entries also appear there. I went to remove the templates from the super cat but cannot figure out why they are there in the first place. The templates (e.g., Template:Penthouse_Pets_of_1969) only seem to use "noinclude" for the subcat and not for the supercat and I don't understand where why its being included in the super cat. Could somebody remedy my confusion? Jason Quinn (talk) 02:07, 9 April 2010 (UTC)

I partly figured it out... has to do with the "includeonly" tag in Template:Penthouse Pets. It's really late and I've been editing for a while now and I'm not thinking straight about the differences at the moment. Jason Quinn (talk) 02:19, 9 April 2010 (UTC)

Your best bet might be something like:

{{#switch:{{NAMESPACE}}
| {{ns:10}} = [[Category:Penthouse Pets navigational boxes]]
| {{ns:0}} = [[Category:Penthouse Pets]]
}}

The variables ns:10 and ns:0 will expand to “Template” and the null string respectively, but may differ on other language-projects which may wish to copy this interface. This would also ensure that no category appears when you invoke the template on a talk-page for demonstration purposes. ―AoV² 05:52, 9 April 2010 (UTC)

Will $2 million Google donation be used to actually FIX BUGS?

Or will it be used for Jimbo to try to invent another search engine, or for further development of the near-useless Liquid Threads?

How about we use the money to fix most of the around 4000 open bugs?

How about spending money on some simple usability fixes such as integrated watchlists, talk page section watchlisting, GIF scaling, and so on.

When Firefox's Mozilla Foundation got millions of dollars from Google over the years, they wasted a lot of it in my opinion. They worked on grandiose plans, and failed to listen to people about fixing all the many Firefox bugs. They ignore their discussion boards much of the time.

So what exactly are Wikipedia's plans for using the $2 million as concerns the many technical problems discussed in places such as this technical village pump? Where else but here can this be best openly discussed? Or is this one area where the Wikipedia consensus process (or at least open discussion) goes underground to unaccountable boards? --Timeshifter (talk) 12:08, 2 April 2010 (UTC)

As far as I know this money has not specifically been allocated, but I'm quite sure that it was one of the donations that convinced the foundation that it would be possible to extent the contracts of the Usability Initiative team, which would otherwise have reached the end of their contracts and objectives in the coming two months. The only proper place to discuss this is on the Foundation wiki, or the foundation mailinglist I suspect. —TheDJ (talk • contribs) 13:29, 2 April 2010 (UTC)

This is a village pump where we discuss technical issues. Other wikis, such as the Foundation wiki, get very little traffic and community participation due to the lack of one of the feature/bugs I mentioned, integrated watchlists. The mailing lists do not get much community participation due to the email list format, and because one's email address is exposed in the public archives. Same as at Bugzilla. That is another requested bug/feature, by the way, that has been ignored for years. I am talking about hiding email addresses in Bugzilla and the mailing list archives, as has long been done in most blog comments, major media page comments, Wikipedia, etc..

It is good to extend the contracts of those members of the Usability Initiative team that are making progress worthy of their pay. There needs to be open discussion though in my opinion about the balance between what is being budgeted for major initiatives such as the Usability Initiative, versus fixing bugs, and implementing long-requested bug/features. How do they blend together too? --Timeshifter (talk) 17:17, 2 April 2010 (UTC)

I'm not sure what integrated watchlists are, but I believe talk page section watchlisting is something that will be accomplished with the "near-useless Liquid Threads", it would not be in any way simple to do with the current discussion page format. Mr.Z-man 15:11, 2 April 2010 (UTC)

Implementing talk page section watchlisting would be simpler to do than fixing everything wrong with Liquid Threads in my opinion. My experience with Liquid Threads at http://liquidthreads.labs.wikimedia.org was not good. I left many suggestions for improvement as did many others. --Timeshifter (talk) 17:19, 2 April 2010 (UTC)

Most of the fixes you suggested seem to be mainly UI improvements. That is still far easier than redesigning almost the entire watchlist system, which is what would be required to do that with the current discussion page system. Adding individual talk page threads to watchlists (without redesigning how talk pages work in the process, which is how liquidthreads does it) is probably one of the least-simple commonly requested features, which is why it hasn't been done. Mr.Z-man 19:29, 2 April 2010 (UTC)

I think I read that watchlisting individual sections of watchlists was a numbering problem. People sometimes add more sections higher up on a talk page. Section breaks and so on. So a basic fix might be implemented now, but it wouldn't be perfect. I would settle for that, even if some of my watched sections break now and then. I think a lot of problems occur when people try for perfection when mediocrity will suffice. ;)

Kind of like the GIF scaling problem. Static GIF scaling worked fine. Animated GIF scaling became a problem. Rather than separate the two, the developers tried for one massive fix of both together. Turned out to be a big mistake. Should have kept what worked. How does the saying go,... If it aint broke, don't fix it. --Timeshifter (talk) 23:21, 2 April 2010 (UTC)

That's only part of the problem. The other part is that the watchlist system is designed with the assumption that only entire pages are watched. There currently isn't even a place in the database to put the section information. As for the GIF scaling fix, I believe it was turned off again because it was broken; it caused some animated GIFs to be displayed as still images or something similar. Mr.Z-man 00:43, 3 April 2010 (UTC)

Please see: commons:Commons:Graphics village pump#GIF scaling (animated and non-animated) still not working and commons:Commons:Graphics village pump#Can static GIF scaling be separated from animated GIF scaling?. See also the related sections above and below them. Static GIF scaling/resizing has worked fine for years. The problem is with scaling/resizing animated GIFs. The solution is to separate the 2 tasks in MediaWiki. Problems pop up now and then with animated GIF scaling, due to the fact that scaling animated GIFs is far more complex, and there are many options on how to do it. It makes no sense to keep static and animated GIF scaling together. See the thread. It has been discussed there for months. --Timeshifter (talk) 12:48, 3 April 2010 (UTC)

Talk page section watchlisting would be most effective on Village Pump pages. That is where it is most needed in my opinion. Maybe if Liquid Threads could be adjusted enough to fix the major problems, then maybe it could be tested on a Google $2 million dollar discussion page on a special village pump here on English Wikipedia. The main problem with Liquid Threads in my opinion is its lack of integration with current watchlists. We need integrated watchlists, not more separate watchlists. Plus Liquid Threads uses a really unsatisfactory form of "watchlist" called "new messages." It is not really even a watchlist. Most people prefer the simple scannable watchlists used everywhere else. --Timeshifter (talk) 12:58, 3 April 2010 (UTC)

Talking of liquid threads (near useless or otherwise) - any news about when they're going to be deployed?--Kotniski (talk) 15:40, 2 April 2010 (UTC)

You might check here:

http://liquidthreads.labs.wikimedia.org

mw:Extension:LiquidThreads

mw:Extension talk:LiquidThreads --Timeshifter (talk) 17:17, 2 April 2010 (UTC)

The $2 million is an unrestricted grant and will go toward Wikimedia's general budget. Much of that budget is spent on technical costs, including (increasingly) paid development. If you think that a few million dollars is enough to fix a significant number of bugs, though, you're mistaken. Even if it were entirely spent on hiring new developers, two million dollars would only get you two dozen or so. Many of the bugs users complain about the most would require weeks or months of developer time to properly fix. So it doesn't add up to thousands of bugs being fixed.

If you don't believe me, notice that Google made over $23 billion in profit for 2009, but there are 12582 open issues in their browser, Chrome. Users of normal software inevitably outnumber developers by thousands to one, or (in our case) tens of millions to one or more. There is never any guarantee that the bugs you want fixed will be prioritized, unless you do it or pay for it yourself. That's reality for you. —Aryeh Gregor (talk • contribs) 18:43, 2 April 2010 (UTC)

Bug/feature focus

You just gave me an interesting idea, although I have no idea whether it is reasonable: targeted donations to Wikimedia. I don't have enough money to fund something as big as Usability Initiative, but I would still like it if my few dollars would go towards fixing certain bug(s). Currently, there is no way I can do this, except maybe finding a developer and giving the money directly to him. Svick (talk) 20:33, 2 April 2010 (UTC)

Maybe we can put features/bugs to a vote. Get some discussion going, and find out what most editors would appreciate most, and how they would prioritize resources. Of course, let people know the difficulty involved with fixing particular bugs, or implementing certain features. Continue this process indefinitely. When it becomes apparent that some things are too resource-intensive, then move on to others if people feel that way. The board and staff can do what they want in the end, but at least they will have more grassroots perspectives to help in their decisions. --Timeshifter (talk) 23:39, 2 April 2010 (UTC)

Bugs in bugzilla already have votes, but I'm not sure whether developers actually consider them when deciding what to do. Svick (talk) 23:48, 2 April 2010 (UTC)

Not really, AFAIK. I did create WP:DevMemo in an effort to improve (two-way) communication between devs and enwiki community. Rd232 ^talk 11:46, 3 April 2010 (UTC)

That is an idea. A dedicated Village Pump on Bug/Feature prioritization would get more traffic and discussion. If people could bookmark and watchlist the individual talk sections, then even more participation would occur.

I found this interesting talk page that combines the standard talk page and Liquid Threads:

strategy:Proposal talk:Global watchlists

Standard talk page sections are on top. Liquid Threads is on the bottom. Note that the Liquid Threads topics can be watched individually, but "watched" means only that new replies show up in "new messages" linked from the top of the talk page. --Timeshifter (talk) 13:25, 3 April 2010 (UTC)

There are votes for bugs, in Bugzilla, but they aren't paid too much heed, for at least two reasons. First, Bugzilla voters are nowhere close to a cross-section of Wikipedia users. They aren't even close to a cross-section of Wikipedia editors (and far more people view than edit). Just because something has the most votes doesn't mean it's actually supported by the most people.

Second, users can't assess implementation cost or other development problems. Bug 164 is one of the most-voted-for bugs in Bugzilla, but it's quite difficult to implement acceptably. Although other bugs are less important, many also take less effort to fix, so they receive more priority. On the other hand, some back-end changes are actually quite important for developers to do further work with, but have no direct effect, so users would never vote for them.

On top of that, of course, many developers are volunteers, and don't necessarily care what anyone else thinks. I implemented HTML5 support because I'm enthusiastic about HTML5, for instance, not because anyone asked for it. I do try to be helpful, but not to the extent of putting a lot of effort into things I don't personally care about much (like that collation issue, which doesn't affect me at all). —Aryeh Gregor (talk • contribs) 17:32, 4 April 2010 (UTC)

Perhaps the money should be used to pay for bounties for bug fixes, rather than to hire staff developers. The hiring of freelance developers on a contract basis could provide incentives for a larger group to gain proficiency at MediaWiki development. We might do something similar to the Summer of Code — pay a stipend to students who are looking to get real-world experience fixing bugs, developing new extensions, etc. They will be "hungry" and wanting to build a portfolio and develop good references for starting their web development careers, so it might lead to some good work; and given their inexperience, the price might be lower than what we would otherwise pay. Plus a lot of students these days love Wikipedia and rely heavily upon it, so that could provide another, more altruistic incentive to help us (i.e. a desire to "give back" to a project that has helped them so much). Tisane (talk) 20:37, 5 April 2010 (UTC)

As a former GSoC mentor, I have to point out that students require a lot of supervision by seniors, fail often and deliver work that can almost never be directly used. This is not their fault, this is how learning works. The point is that even letting others do the work still requires a lot of work. I think in general however that bounties is something that the Foundation should consider. But they can only work, if they are extremely well managed. This is where most past bounty systems in Open Source software have failed. —TheDJ (talk • contribs) 21:04, 5 April 2010 (UTC)

What do you suppose causes the failures? Do they get overly ambitious and bite off more than they can chew, not realizing how hard the projects will be? And what are the factors that contribute to the success of a bounty system? Perhaps there is a successful one out there than we can learn from and model ours after. I know part of the problem with MediaWiki bounties has been that someone will commit to a project and then fail to produce any deliverables after several months. Perhaps we should give students and other inexperienced programmers relatively simple projects to work on, and give the harder projects to those with a record of producing working deliverables in a timely manner.

It is generally easier to write than to code, or in any event, there seem to be a lot more people proficient at the former than the latter. I wonder if we can get an intern or someone to do some work on neglected documentation at MediaWiki.org? Maybe someone who is trying to get into the field of technical writing. The better the documentation of MediaWiki is, the easier it will be for new developers to get an understanding of the system and produce code, rather than having to figure everything out the hard way. Tisane (talk) 21:29, 5 April 2010 (UTC)

The failures are usually caused by inexperience (with a specific project or in general), mixed with lack of guidance. It isn't fun to be stuck on something for 2 days just because you can't find that one developer who is the only person who understands the code you are working on. This leads to people giving up. The other problem is of course that people just get in way over their head. In GSoC this has led many projects to require "qualification patches" from students. Those are quick bugs (1 or 2 day problems) that people are told to fix before they are allowed to commit to an actual larger project. The idea is that you can get a quick assessment what experience people have and of how they deal with problems (do they ask questions), while giving students a quick glance of the project and what quality and expertise a project requires. It's far from a perfect system, but has helped a bit.

Also projects are often not well defined, or far too large. The idea of "Liquid Threads" as a GSoC project clearly showed that by that time (2006), Wikipedia had become so large that this was a much too complicated project for that GSoC. Projects of this level of complexity need multiple projects, with intensive oversight and should probably not ever be GSoC projects again. This brings us to an interesting point. Almost all 'projects' considered for Wikipedia have become of a complexity (mostly due to the complexity of mediawiki/wikipedia itself) that makes them unsuited for this type of development. So I would keep the bounties to the simpler bugs (1 week jobs), hopefully freeing up some time for senior engineers. With a LOT of preparation, some larger tasks might be defined of the "sub project" scale perhaps.

Lastly, I'd like to point out that not every bug is currently 'solvable'. There are often "fault patterns" that have not been pinpointed to a cause yet. Investigation of such problems can be complicated, require custom queries on the database by senior administrators, looking at the php errorlogs (not available for the normal public due to privacy issues) and what not. And again, at the scale of Wikipedia, everything is complicated (see the GIF issue). —TheDJ (talk • contribs) 22:00, 5 April 2010 (UTC)

I find these 2 points relevant to many endeavors, not just coding: "The better the documentation of MediaWiki is, the easier it will be ..." And: "It isn't fun to be stuck on something for 2 days just because you can't find that one developer who is the only person who understands the code you are working on. This leads to people giving up."

Those are some of the reasons I consolidated some resource and how-to pages here: commons:Category:Commons resources. I also created a few pages. I noticed similar problems at the Firefox forums. I discussed some bugs at Firefox forums, and noticed the lack of consolidation of info.

People were constantly creating similar threads about similar bugs, but people weren't seeing each other due to the threads being spread out across multiple message boards. One suggestion I made there was to create separate discussion boards for each category of bug. At the time, there were many problems and discussions about bookmark/favorites. The discussion threads were, and probably still are, spread out across multiple message boards. A simple aid would have been to have one message board just for bookmarks/favorites. There were some good ideas and solutions getting lost in the chaos.

So, the same is true here. Need focused bug/feature topic boards. Also need to be able to watchlist individual threads. Wikia has figured out how to do watch individual threads. See their forum:

http://community.wikia.com/wiki/Forum:Index

But they don't have integrated watchlists. So it is still difficult to follow discussions since most people only check the watchlist for their own wiki there. The forums are on a different wiki, the community wiki. --Timeshifter (talk) 15:25, 6 April 2010 (UTC)

Integrated watchlists would be helpful, and that is an enhancement that is long overdue. I'm sure a lot of people would be very pleased to see that be added to the MediaWiki codebase, and it could help revitalize projects like meta and wikiquote. Do you want to collaborate with me on implementing that?

As for the integration of discussion forums, I have suggested that WikiProjects be formed to deal with various aspects of MediaWiki development. E.g., a WikiProject might be devoted to cross-wiki integration. We could get some esprit de corps going, with a standing group of volunteers available as a resource to anyone wanting to work on a particular aspect of MediaWiki, rather than just the present amorphous group of volunteers. In fact, it is probably more important to have WikiProjects for MediaWiki.org than on Wikipedia, because it's harder to write code than to write articles. In fact, I just took the liberty of creating mw:Project:WikiProject Cross-Wiki Integration, so check that out if it isn't deleted by the time you read this. :) Tisane (talk) 01:05, 7 April 2010 (UTC)

Anyone very familiar with MediaWiki's code who's willing to work on it for money is already employed by Wikimedia (or I guess other places like Wikia). Paying people who aren't familiar with the code, on the other hand, isn't likely to be very productive. It's well recognized among programmers (see, e.g., Brooks' law) that you can only do productive work on a large software project after you've taken a lot of time to get up to speed with the codebase. New developers always need hand-holding, in other words, even if they're very experienced as programmers. —Aryeh Gregor (talk • contribs) 17:02, 8 April 2010 (UTC)

True, but perhaps we can get a set of mentors to train new developers, who in turn can become mentors of a larger group of new developers, and so on, and the group can expand outward by that means, in a way that does not consume too much staff time. Tisane (talk) 02:40, 10 April 2010 (UTC)

extra space

In {{Infobox_NRHP}}, the following syntax are the 1st 2 lines:

{{#ifeq:{{{embed|}}}|yes|</td></tr><tr><td colspan=20>}} {| class="infobox vcard" style="{{#ifeq:{{{embed|}}}|yes|width:100%; border:0; margin:0; background:transparent|width:250px; font-size:90%}}"

The first line, a syntax for collapsation (or something), the second line, the start of a table.

Is this the reason [1] has that line of white space after the hat note? I've seen this in many articles. If this is the case, can we file a bot report to fix this in templates? If not, this has to be fixed with templates manually.174.3.123.220 (talk) 01:20, 9 April 2010 (UTC)

One might fix it by removing the line-break, or surrounding it with comment tags, etc.:

{{#ifeq:{{{embed|}}}|yes|</td></tr><tr><td colspan=20>}}<!--
-->{| class="infobox vcard" …

Of course the template is protected so getting “consensus” for this edit could take weeks. In any case this is a sloppy way to “embed” multiple infoboxes. ―AoV² 01:59, 9 April 2010 (UTC)

Oh, ok, this makes sense. Yea this is a big problem with a lot of info boxes:-).174.3.123.220 (talk) 02:13, 9 April 2010 (UTC)

Actually this wouldn't work, because the {| has to be on a new line (and newlines in comments are ignored). The following code should work:

{{#ifeq:yes|yes|end_table
{{{!}}|{{{!}} }} class="infobox vcard"

Svick (talk) 13:34, 9 April 2010 (UTC)

Converting the template to use {{Infobox}} would do the trick as well. ---— Gadget850 (Ed) ^talk 14:38, 9 April 2010 (UTC)

I can't edit

Every time I try to type or use any other key I don't see what I intended to do for several seconds.

It's only happening on Wikipedia.Vchimpanzee · talk · contributions · 19:20, 9 April 2010 (UTC)

Okay, that's weird. It's only happening over there, not here. And part of one of my toolbars didn't show up over there.Vchimpanzee · talk · contributions · 19:21, 9 April 2010 (UTC)

This may be one for the reference desk. I can't even click on the red X there, or do much of anything. Here, everything seems fine.

Actually, I can click and go other places there, but I can't type. And I can't use the red X. Wait, I can click on some things and get results, but not on others. Vchimpanzee · talk · contributions · 19:28, 9 April 2010 (UTC)

Now I've tried going to Yahoo email and everything is completely frozen over there. And I can't even click on the rectangle at the bottom of the screen to go back there. Not that I need to. Vchimpanzee · talk · contributions · 19:34, 9 April 2010 (UTC)

Just so everyone will know, across the bottom of the screen are rectangles with a blue e on the left, with the words "Inbox (167) - Ya...", "Compose Mail -...", Dial-up Conn...", "Village pump (t...", "October 16th ep...", "Hammie's Poetr...", and then a rectangle with a ? in a blue circle followed by "Windows help a..." and finally one with the Norton logo and "Full System Scan". Some of those were added after the problem began.Vchimpanzee · talk · contributions · 19:38, 9 April 2010 (UTC)

Don't pay attention to the words "Dial-up". The software treats what I have as if it were. My Internet is three times as fast and can be used when I'm on the phone.Vchimpanzee · talk · contributions · 19:40, 9 April 2010 (UTC)

Each rectangle with a blue e on the left is an instance of Internet Explorer running in its own window. Try to restart your computer and if that doesn't help then clear the entire cache. PrimeHunter (talk) 21:01, 9 April 2010 (UTC)

In future, assume that problems with your computer are due to problems with your computer, and not Wikipedia. Turn your machine off and on again before even thinking about asking for help. If you do ask somewhere, try reading something like this or even some Windows help files beforehand. OrangeDog (τ • ε) 21:27, 9 April 2010 (UTC)

I didn't want to lose anything. If it had been everything doing that I would have known. When I turn my computer off, I'll report back if I have any useful information.Vchimpanzee · talk · contributions · 21:41, 9 April 2010 (UTC)

Okay, no way to know just what happened. I couldn't get anything to happen by clicking on the first rectangle, and the page was completely frozen before that. It also filled the entire computer screen. When I clicked on the red X for the other pages, this screen ("Internet Explorer running in its own window") was only taking up the upper right corner of the screen (display). I clicked on Maximize and everything was working normally.

I realize I frequently use a lot of "Internet Explorer running in its own window", but it never caused this problem.

That one section of the toolbar is still missing. I'll turn off the computer and see if that fixes it.Vchimpanzee · talk · contributions · 22:00, 9 April 2010 (UTC)

Fixed.Vchimpanzee · talk · contributions · 22:03, 9 April 2010 (UTC)

Namespace not shown in page title

The namespace prefix is no longer shown in page titles of non-mainspace pages. Trying to edit the page seems to trigger the bug. If this problem is not affecting just me, this could be a significant source of confusion given the number of non-mainspace pages that are created every minute. -- Black Falcon ^(talk) 19:51, 9 April 2010 (UTC)

Display of namespaces

(edit conflict)It seems that someone is messing around with the display of namespaces. For example my user page now displays MSGJ instead of User:MSGJ and this page shows Village pump (technical) instead of Wikipedia:Village pump (technical). Has this been discussed anywhere? — Martin (MSGJ · talk) 19:51, 9 April 2010 (UTC)

I see the same issue when I am in edit mode of a user talk page or an article talk page; the talk-related prefix is missing. Erik (talk) 19:53, 9 April 2010 (UTC)

It appears to be resolving... Making an edit to a page seems to make the namespace prefix visible again. However, in the edit window, the title no longer reads as "Editing {PAGENAME}"; it is, instead, merely {PAGENAME}. -- Black Falcon ^(talk) 20:28, 9 April 2010 (UTC)

Yes. Also, {{DISPLAYTITLE}} no longer works, or so it seems. Ucucha 21:38, 9 April 2010 (UTC)

Working again now. Ucucha 23:27, 9 April 2010 (UTC)

Log-on Problem

Recently I created a new account, "Grand Bison", on the secure server, secure.wikimedia.org. I have no trouble logging in on the secure server, but when I try to log in on the regular wiki.riteme.site, it doesn't recognise my account. I don't like having to use the secure server, so how do I get the regular server to let me log on? Note all I did to create the account was to go to regular page, clicked on create a new account, then clicked "secure server" Grand Bison (talk) 20:35, 9 April 2010 (UTC)

It's clear from Wikipedia:Help desk#Log In? that your user name is recognized but not the password. Maybe your browser has stored a wrong password at the unsecure url and that password is submitted without your knowledge. Go to http://wiki.riteme.site/wiki/Special:UserLogin and write the password very carefully. If it still doesn't work then try another browser if possible, and say which browser you use. Some browsers with some settings can be tricky about automatically changing what the user writes in certain fields if something else is stored in the browser. PrimeHunter (talk) 20:56, 9 April 2010 (UTC)

"diff" and "history" flipped in contributions lists

This seems to have happened in the past few hours... when I list contributions, the "hist" (history) and "diff" (difference between edits) buttons in the list are now reversed and appear as "diff" and "hist". Was there a change, and if so, why? --Ckatz^chat_spy 09:23, 9 April 2010 (UTC)

See bug 2971. --Catrope (talk) 09:51, 9 April 2010 (UTC)

This is related to the fact that last night, Wikipedia was switched to MediaWiki 1.16 pre-release. It seems to have gone without any major issues. The list of changes is here, though much of it had already been deployed on Wikipedia for a long time. Still, this is the first major release since May 2009, and it hopefully the software will be able to return to a more regular update pattern now. —TheDJ (talk • contribs) 13:14, 9 April 2010 (UTC)

Aha! Then I think I have stumbled over another bug/change/wrinkle in this release. Ajax rollback has stopped working for me. Has there been a change to the API in the area of rollback or of getting the rollback token? Philip Trueman (talk) 13:19, 9 April 2010 (UTC)

What are you using for AJAX rollback ? —TheDJ (talk • contribs) 13:48, 9 April 2010 (UTC)

I'm using PILT. Take a look at User:Philip Trueman/recent2.js and search for the function "recent2.tryFastAdminRollback". Philip Trueman (talk) 13:59, 9 April 2010 (UTC)

My JavaScript API library keeps returning a badtoken. I assume something related to verifying these tokens has changed, because I haven't changed how I encode them. I'll look into it. Hmmm... Ale_Jrb^talk 16:06, 9 April 2010 (UTC)

Cluebot, which uses API rollback, has stopped reverted but is still logged in and editing. Related? Can anyone get it to work? Ale_Jrb^talk 16:36, 9 April 2010 (UTC)

API rollback doesn't work. Reported at bugzilla. Incidently, if it turns out to not be broken, and someone gets it to work, please tell me how. :D Ale_Jrb^talk 16:43, 9 April 2010 (UTC)

It seems to be fixed for me now. Philip Trueman (talk) 17:23, 9 April 2010 (UTC)

If I may, what does "The user groups ACL system was improved by allowing rights to be revoked, instead of just granted" mean, rather, what is the "ACL system?" ~ Amory (u • t • c) 15:10, 9 April 2010 (UTC)

Just a guess, but probably related to meta:Access control. –xeno^talk 15:17, 9 April 2010 (UTC)

That's annoying =( –xeno^talk 13:55, 9 April 2010 (UTC)

gah, it is, I thought I just kept slipping and clicking diff instead of history. Is this going to be fixed, or could someone please write a .js fix for it before I get used to it--Jac16888^Talk 16:08, 9 April 2010 (UTC)

I think a .js would slow things down way too much (especially for those of us who have our settings to 500) but I could be wrong. I'll just bite the bullet, but I fear change. –xeno^talk 16:09, 9 April 2010 (UTC)

I meant a personal, vector/monobook.js fix--Jac16888^Talk 16:12, 9 April 2010 (UTC)

I know, I still suspect this would lag things too much while the .js re-writes the screen. Could be wrong tho. –xeno^talk 17:26, 9 April 2010 (UTC)

Diff/hist links

Hello, have the diff/hist links on contribs/watchlists been switched lately? I keep clicking on hist instead of diff, presumably out of habit, which indicates a change. Aiken ♫ 17:32, 9 April 2010 (UTC)

Look up--Jac16888^Talk 17:35, 9 April 2010 (UTC)

Could they be flipped as a gadget in preferences, or would that be the same as a .js fix? TransUtopian (talk) 20:49, 9 April 2010 (UTC)

Can someone please make a js fix for monobook/vector (I plan to continue to using monobook)? It might be slow for people with settings at 500, but it would be a partial workaround for the moment. TransUtopian (talk) 00:54, 10 April 2010 (UTC)

importScript ( 'User:Ale_jrb/Scripts/contreverse.js' ); // [[User:Ale_jrb/Scripts]] - will switch them back i.e. (hist | diff). It should be fast enough as to be barely noticable, even on 500 (unless your browser is very old, or your computer is very slow). Ale_Jrb^talk 14:22, 10 April 2010 (UTC)

Thank you very much, Ale jrb! It didn't work for me though. I tried it with and without spaces, purged cache, made sure javascript was enabled, and tried it on 2 different browsers. They're older Opera and IE versions though. So I'll try the latest IE later on another computer. TransUtopian (talk) 18:55, 10 April 2010 (UTC)

Ha! The world is right again. Thank you, Ale_rjb. –xeno^talk 20:27, 10 April 2010 (UTC)

Cheers--Jac16888^Talk 20:30, 10 April 2010 (UTC)

table of contents – hide the bullet numbers

Is there a (simple) way to hide the numbers before every bullet? The best solution would bei a __NONUMBERSTOC__ or something like this in style like here. Thank you very much, Hæggis (talk) 13:52, 9 April 2010 (UTC)

Do you want to do it for yourself on all pages or for everyone on particular page(s)? If it's the former, you can add the following code to your user CSS:

.tocnumber { display: none }

Svick (talk) 20:47, 9 April 2010 (UTC)

Yeah, that´s the thing: I want it for all users, just for a WP-page, not for an article. The bullets on this page are numbers oneself, and so the bullet numbers before make the whole table of contents confusing & the typeface very unpicturesque. But thanks for the CSS-code ;-) --Hæggis (talk) 08:43, 10 April 2010 (UTC)

MediaWiki:Common.css addresses this with .nonumtoc .tocnumber { display: none; }, so something like <div class="nonumtoc">__TOC__</div> will display a table of contents with no numbers. Perhaps a template exists containing exactly this code but I couldn′t find it. ―AoV² 10:13, 10 April 2010 (UTC)

I have created {{nonumtoc}}, so you should need only put it directly above the first heading on the page in question, and in place of any __TOC__-related keywords/templates. ―AoV² 00:26, 11 April 2010 (UTC)

Edit conflict behavior broken

It seems that starting today the edit conflict behavior is broken. The upper window contains my version, and the lower window contains the version without any changes made. The diff shows what was changed by the other person, but neither window shows the change. Is anyone else seeing this? Gigs (talk) 17:47, 9 April 2010 (UTC)

Yes, this still seems to be broken. (Does anyone know what these recent software changes were meant to fix? Presumably the devs don't choose simply to break much of WP's functionality occasionally just as a way of reminding us that they still exist?)--Kotniski (talk) 10:32, 10 April 2010 (UTC)

Well now, things could be worse. I′m not sure whether this this is a symptom of faulty edit-conflict behavior (or an assessment of quality) and I′m afraid to ask. ―AoV² 10:54, 10 April 2010 (UTC)

Clicking a File redlink no longer always gives links to deletion logs

When clicking a file (often an image) redlink, it used to give links to Wikipedia and Commons' deletion logs for the file, if there were any. It's very useful to know who, when and why the filename was deleted, and if it ever was. Now all I get is the upload instructions. I couldn't find a link to the logs.

Oddly, for this image from just above here at FFD, I get the deletion reason.

For this old image from Rome's page, I get just the upload form. Both have the File: prefix.

I don't know if this is related to the upgrade. TransUtopian (talk) 02:44, 10 April 2010 (UTC)

The one is a link to an image, the other is a thumb, with a missing image. That is the difference. In case one, you go to the edit page, in case two you now go to the upload page. This might be new behavior from MediaWiki 1.16, i'm not sure. I agree that it is a bit hard to find the logs now. Navigating away from the upload page is difficult. —TheDJ (talk • contribs) 14:10, 10 April 2010 (UTC)

bugzilla:23140. There are at least two problems here, I created a bug ticket. —TheDJ (talk • contribs) 14:19, 10 April 2010 (UTC)

Thank you, especially for creating the bug ticket! You're right. Replacing Wikipedia:Upload with Special:Upload, i.e. http://wiki.riteme.site/wiki/Special:Upload?wpDestFile=MinervaSapienza.JPG brings me to the page with the links to the WP & Commons deletion logs at the top. TransUtopian (talk) 18:02, 10 April 2010 (UTC)

Editbox size in Preferences

I imagine this is related to the recent changeover - the editbox size set in Preferences / Editing seems not to be working. Beyond My Ken (talk) 04:22, 10 April 2010 (UTC)

You can set something like this in your monobook.css.

#wpTextbox1 {
	width:100% !important;
	height:300px !important;
	/* etc. etc. etc. */
	}

These attributes will override anything in your user-prefs. ―AoV² 04:37, 10 April 2010 (UTC)

Thanks, I will try that. Beyond My Ken (talk) 05:31, 10 April 2010 (UTC)

Actually 300px might be too small, but the point is you can use this to change the size, font, color, etc. of the <textarea> to whatever you want [2]. ―AoV² 07:08, 10 April 2010 (UTC)

What does "seems not to be working" mean ? What is the behaviour you expect vs. the behaviour you are actually seeing ? It should be now, that if your browser supports it, the textarea is always the full pagewidth. I tested both the column width and the height setting, and the width setting works if i disable the 100% setting, and the height setting works as expected. —TheDJ (talk • contribs) 14:24, 10 April 2010 (UTC)

Logo position

For a few days now, the Wikipedia logo, here and on other language Wikipedias and on Commons, is not shown in its normal position (top left), but offset to the right by about half that image's width, obscuring the first two letters of whichever article I'm reading. This happens in IE8, logged in used MonoBook or Vector, or logged out (which should exclude my monobook.js, monobook.css, vector.js as culprits). I also get this error on every page:

 User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.4; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
 Timestamp: <Current UTC><br /><br />
 Message: Not implemented<br /><br />
 Line: 52
 Char: 15
 Code: 0
 URI: http://bits.wikimedia.org/skins-1.5/common/IEFixes.js

None of this happens in Firefox. How can I fix this in IE8? -- Michael Bednarek (talk) 05:05, 10 April 2010 (UTC)

Switching the compatibility mode on in IE8 fixed both problems (logo position and the error above). This was not necessary until now and I rather not have to do that. Is there a problem with IEFixes.js? -- Michael Bednarek (talk) 10:56, 10 April 2010 (UTC)

I have asked a developer to test this, and he could not reproduce the problem. Your download of IEFixes.js was probably stored broken in your browser cache (likely an incomplete download). —TheDJ (talk • contribs) 14:25, 10 April 2010 (UTC)

Missing User Scripts

All my user scripts appear to have stopped working - or at least the tabs don't show up any more. Is there a reason for this that anyone can think of? I haven't touched my monobook.js file so I can't see its anything I did and I did restart my PC. Does anyone have any ideas on this? Spartaz ^Humbug! 07:51, 10 April 2010 (UTC)

Probably related to your computer, as I imported your monobook.js into my account and your scripts work. Gary King (talk) 08:15, 10 April 2010 (UTC)

Strange, they came back. *rubs his eyes* I must be losing it. Thanks Gary. Spartaz ^Humbug! 08:35, 10 April 2010 (UTC)

That's bizarre, I can see them on the edit window but on the loaded project page. How strange. Spartaz ^Humbug! 08:36, 10 April 2010 (UTC)

Transparent Background

Resolved

 – Behavior is as expected.Smallman12q (talk) 13:07, 10 April 2010 (UTC)

Why is it that the image at File:Cello_old.gif appears to have a transparent/alpha background, but when clicked, the background becomes white? Is this a bug?Smallman12q (talk) 11:14, 10 April 2010 (UTC)

It′s your browser. ―AoV² 11:36, 10 April 2010 (UTC)

I see the same thing in firfox 3.6 and IE 8...so I doubt its my browser...I've put up a screenshot at imageshack.Smallman12q (talk) 12:35, 10 April 2010 (UTC)

The the background is the same as the screen background isn't it (i.e. white)? That's the definition of transparent. OrangeDog (τ • ε) 12:55, 10 April 2010 (UTC)

Does the turquoise above not show through the transparent pixels of the image, on your screen? When and where do you see it being opaque white? ―AoV² 13:01, 10 April 2010 (UTC)

The turqoise shows through...I see that the image is transparent...my bad.Smallman12q (talk) 13:07, 10 April 2010 (UTC)

Lack of #c0ffee indeed—how do you think I chose the background color? ―AoV² 13:13, 10 April 2010 (UTC)

I believe this is related to the "problem" I describe above! ~Kaimbridge~ (talk) 14:03, 10 April 2010 (UTC)

No, there is no bug here at all, merely a misunderstanding. Also, the change with math images only affects math images, assuming it relates to all image rendering is simply incorrect. Dragons flight (talk) 00:30, 11 April 2010 (UTC)

I would like to add data but I have questions

I have been doing research at various archives on the Ordnungpolizei and German Security Service in general. I would like to begin adding it. My question is how do I do it in pieces? Much of it is long and would require days to type in. Do I just type it in, let it go live? Then come back to it?

Thanks. --Readerofdoom (talk) 13:11, 10 April 2010 (UTC)

I do all of my "major edits" offline in a text editor (Smultron on MacOSX). That way I have all the time I need to collect information and edit it, so when I do cut-n-paste it I get one big upload and the article "just starts".

I do want a true WP offline editor though. It would basically be a text editor window with a floating pallet that collects the elements inside the text. For instance, one tab of the pallet would scrape out all the references, so you could edit them there instead of blubbering about in the inline text. Pictures and tables could work this way too.

Maury Markowitz (talk) 13:14, 10 April 2010 (UTC)

You can use your user space to gradually create the article and then move it to the article namespace. Svick (talk) 14:05, 10 April 2010 (UTC)

About the possibility of an offline editor for Wikipedia: that would be a great idea and is something I might be interested in creating, but to some extent it has already been done.

• On references hiding: although currently it is specific to Wikipedia's online editor, I have already created an implementation (short instructions on how to use it). wikEd, although unsuitable for major editing due to copy/paste issues, also has reference hiding, and so does another earlier script.
• For shorter editing, I use the sans-serif text gadget to enhance readability of text on the edit screen (under the "User interface gadgets: editing" section of the Gadgets tab of Special:Preferences).
• Currently, I use Notepad++ with It's All Text! for lengthy editing (you can install MediaWiki syntax highlighting rules, selectable from the Language menu). I run my script before the external editor, leaving the Wikipedia edit window open.
• And yes: if you are doing lengthy edits that are not ready to go live, it would be good to copy-and-paste the article text to a user subpage (leaving a link in the edit summary to the revision you copied by using Copy Link/Shortcut from the history screen), make your changes and then copy-and-paste back into the article (checking all diffs, or a combined diff, since the revision you copied from first). Just remember though: if you do this, comment out all fair use images when you start working and uncomment when you bring your changes live (regex could help with that).

PleaseStand ^(talk) 20:33, 10 April 2010 (UTC)

I found a MediaWiki syntax module for GtkSourceView (whoa, red link) here [3], but it really doesn′t do so much. I′m not sure whether to improve upon it or leave that task to TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚​N̐Y. ―AoV² 22:23, 10 April 2010 (UTC)

No, the Notepad++ syntax highlighter, when used with the MediaWiki highlighting rules, doesn't highlight HTML-style tags such as ref tags. It does, however, change colors/font styles of the codes for headings, wikilinks, and template transclusions. PleaseStand ^(talk) 02:29, 11 April 2010 (UTC)

And if you have "strange" characters in Notepad++, you need to choose "Encode in UTF-8 without BOM" from the Encoding menu. PleaseStand ^(talk) 02:45, 11 April 2010 (UTC)

I′m not using Notepad++ and do not have that problem. That′s why I suggested the gtk plugin. ―AoV² 03:02, 11 April 2010 (UTC)

OK, so Notepad++ doesn't work on Linux, but gedit does. Does syntax highlighting really matter though? Depending on your perspective, editing in a good text editor without syntax highlighting still can be better than editing in the browser edit box or wikEd (the latter I no longer use). I recently did major editing to a new article. That included rearranging paragraphs to divide the article into sections. Of course I took advantage of my ref-hiding script and Notepad++, but I did not use the special syntax highlighting for that one. PleaseStand ^(talk) 03:27, 11 April 2010 (UTC)

refToolbar and enhanced toolbar

On pl.wiki refToolbar's been working pretty well with the new enhanced toolbar for some time now (it appears under "Advanced" tab). Couldn't you copy this solution to en.wiki? The Polish verison of the script is here. Lampak (talk) 14:29, 10 April 2010 (UTC)

User:Mr.Z-man/refToolbar_2.0 has been in testing for some while. I'm sure it will soon be deployed. —TheDJ (talk • contribs) 14:52, 10 April 2010 (UTC)

I've modified User:Mr.Z-man/refToolbar.js using the Polish version to work with Beta, as a temporary fix until reftools 2.0 can be deployed. It can be found here. Sorry if this already exists somewhere. Intelligentsium 17:02, 10 April 2010 (UTC)

As far as I know, there aren't any major issues with the script itself anymore. The only real bugs I believe are part of the Usability Initiative code; a minor visual glitch in Chrome and the new toolbar doesn't support the necessary features (dialogs) at all in IE. Mr.Z-man 21:22, 10 April 2010 (UTC)

Wiki-markup included in internal searches

Does anyone know why wiki-markup is included in internal searches? When I search for "Gray]]'s ''Elegy"; "Gray's Elegy"; "Gray's]] ''Elegy"; "Gray's [[Elegy"; and so on, I get different results. Which for some purposes is good, but for others is extremely annoying. Anyone know how to make the search engine a bit more flexible when wiki-markup is tangled up with the search terms? Carcharoth (talk) 01:09, 7 April 2010 (UTC)

Changing this without an option would make it very difficult to find particular instances of markup, for example if using AWB. OrangeDog (τ • ε) 12:29, 7 April 2010 (UTC)

I thought the internal search engine was primarily for the use of readers searching for something, which should take priority over editors searching for wiki-markup problems. If a reader is searching for "SEARCH TERM" (using quote marks to search for an exact phrase), then the search engine should be searching the text as it is seen on the page, not letting wiki-markup such as the square brackets and piping symbols mess up the search. But as you say, it is probably difficult to change. I just thought it was strange that no-one seems to have realised this before. The end result is that some searches are not finding all examples of what the person is searching for, and a Google-search will find those instances that the internal search engine misses. Carcharoth (talk) 23:29, 7 April 2010 (UTC)

That's why I said leave the option behind to turn the old way back on per search. OrangeDog (τ • ε) 11:45, 9 April 2010 (UTC)

Seems it was an intermittent parsing bug. See below. Carcharoth (talk) 01:25, 12 April 2010 (UTC)

This is a byproduct of a search query parsing bug, internal search ignores wiki markup. --rainman (talk) 15:58, 8 April 2010 (UTC)

Ah, OK. Thanks for the note. I will remember not to use internal search to search for wiki markup! (I presume API queries, or something, can do that). Carcharoth (talk) 01:25, 12 April 2010 (UTC)

Chronology if importScript() and OnloadHook

Does anyone know if addOnloadHook() waits for all of the importScript()s to load before it executes? In other words, if I import a script, and then add an onload hook which uses the script, can I be perfectly sure to have the script on hand when the hook runs? Additionally, does this apply for nested imports (A imports B, and B imports C)? The structure of my js is:

• Monobook imports A.js
• A.js imports B.js and C.js
• B.js adds an onload hook which requires C.js
  • (Actually, in my case, its much more complicated: Vector.js imports monobook.js, which imports X.js, which imports Y.js, which then imports A.js)

Thanks, ManishEarth^{Talk • Stalk} 15:29, 9 April 2010 (UTC)

This depends on the browser. Safari, for example, can't cope with this at all - if you try to import nest anything, they won't run (except the first one) in most circumstances. Firefox, Chrome and IE are better and will usually manage fine. However, imagine your first script imports a second one, and the second one uses onload to import a third. The third will only be imported once the page has finished loaded, which means that onloads in the third script often won't run (though they sometimes seem to, I don't know why). The trick is to replace any code in that third script that runs onload with a direct call, because the page will already have loaded, so it works as expected. Ale_Jrb^talk 15:54, 9 April 2010 (UTC)

None of the scripts are imported thru the hook. A imports B and C. C contains a variable, which is wanted by B after load.

//A.js
importScript('B.js')
importScript('C.js')

//B.js
addOnloadHook(function(){
alert(fromC)
})

//C.js
var fromC="A variable in C.js"

ManishEarth^{Talk • Stalk} 03:34, 10 April 2010 (UTC)

In Safari, that should break. In the others, it should work. Have you tried just testing it? Ale_Jrb^talk 13:46, 10 April 2010 (UTC)

For reference, here's what's happening. A is telling the browser to download and execute the code in B.js and C.js, by adding them as scripts to the head tag (like AoV says below). If C loads first, they the variable will definitely be there when B loads. There would be a problem if B loads first, because the variable won't be defined until C finishes, but addOnloadHook means the code won't be fired until everything in A (which includes C) has finished. So it should work fine. Safari will generally refuse to fire onload hooks in imported scripts, so while B and C would both load, it probably won't run the onload at all. Hope that helps. Ale_Jrb^talk 13:49, 10 April 2010 (UTC)

I′m pretty sure B.js would need to contain importScript('C.js'); for this to work reliably. The importScript function is an abstract way to append the following tags to the <head> element:

<script src="/w/index.php?title=B.js&action=raw&ctype=text/javascript" type="text/javascript">
<script src="/w/index.php?title=C.js&action=raw&ctype=text/javascript" type="text/javascript">

However it checks each one against an array of previously imported urls to prevent multiple loading (in a manner vaguely similar to #include guards in C/C++), ensuring that the second call to importScript('C.js'); does nothing. ―AoV² 04:28, 10 April 2010 (UTC)

As more and more browsers will work asynchronously during script execution, expect this to become a more prominent problem. I already tried adding a onLoad hook to the script loading, but onload() does apparently not mean that the script has been parsed yet. So the only way is a wait loop and check if the variable you need is available yet. User:TheDJ/twinkle.js does something like that, and the new JS2 loader that is being developed for the new videoplayer and stuff, uses a similar trick. —TheDJ (talk • contribs) 14:49, 10 April 2010 (UTC)

That only applies after the page has finished loading in the first place. Firefox, Chrome and IE will all wait for immediately visible scripts to finish loading before firing onload. I do this in igloo. Problems occur if you try to put an importScript call inside some code that's executed onload, because onload won't refire when that script appears. Then you have to start looping. Ale_Jrb^talk 15:05, 10 April 2010 (UTC)

Well, my problem is that, the variable I'm looking for may not be defined at all (User-end config) on a first run. So I guess I'll have to AJAX fetch and then use a wait loop.

PS: Won't the Safari issue stop Twinkle from working on Safari? ManishEarth^{Talk • Stalk} 03:29, 11 April 2010 (UTC)

Correct. That is why I have my own personal twinkle loader, to fix that. —TheDJ (talk • contribs) 11:03, 11 April 2010 (UTC)

Real-time updates of Wikipedia mirror

I want to create a mirror of enwiki that will be continually updated. I am not proposing the creation of a live mirror that would hit Wikipedia every time a page is loaded by one of the mirror's readers. But I would want to update my wiki every time an edit is made to Wikipedia. So, what I have in mind is downloading the data dump, setting up the mirror as a MediaWiki installation, and then setting up a bot to update my mirror every time a change is made to Wikipedia. The question is, how to minimize the server load on Wikipedia (and will that even be a major issue)? I submitted this bug suggesting an XML feed of RecentChanges, (and I see there has been a similar bug in reference to XML feeds of watchlists). And I know there used to be an OAI-PMH Wikimedia update feed service which evidently Wikimedia isn't all that interested in offering anymore. It would be great to get a diff that would save bandwidth by just providing the lines that are changing in the + ... and - ... format we see in SVN diffs, if it could be done in a way that could be readily processed and incorporated into the mirror's database. That could theoretically be done via the RSS or Atom feed of recent changes, although I'm told that XML is a superior format to use for transferring data between wikis. But, it seems that XML dumps of revisions list the entire page text for each version.

Anyway, my thought is that lacking such an XML or OAI-PMH feed, I could just set up a bot to use the API to get the page IDs, revision IDs, etc. of revisions that appear in RecentChanges, and then use the API to grab the text of those revisions, e.g., with http://wiki.riteme.site/w/api.php?action=query&prop=revisions&revid=355085522&pageid=19035&titles=Mormon&rvprop=content&rvdiffto=355046139&rvgeneratexml . There are, perhaps, 100 edits a minute so I would only be hitting Wikipedia a couple times a second. Do you think they'd mind? I know Wikimedia has gotten annoyed at the live mirrors that were hitting them 50 times a second and told them to stop or they'd be blocked. But I'm hoping I can actually cause a net reduction on server load on Wikipedia if people use my site rather than Wikipedia, and if other mirrors mirror from my mirror.

I anticipate that this mirror will be used by a lot of editors (rather than just readers), as it will be not just a mirror but also a supplement of Wikipedia. In addition to hosting all of Wikipedia's articles, it will also allow pages to be added that are outside the scope of Wikipedia. If someone clicks on an edit tab on a mirrored Wikipedia article, however, it will take them to the appropriate Wikipedia url, e.g., http://wiki.riteme.site/w/index.php?title=Mormon&action=edit . Users will also be able to override the content of mirrored Wikipedia articles by appending front and back matter and adding forced wikilinks (i.e. causing words to be wikified that aren't wikified on Wikipedia — e.g., because the wikilinked article doesn't exist on Wikipedia but exists on the mirror/supplement wiki). The upshot of this is that maintaining full page histories and up-to-date versions will be more important than if it were just readers using the site. Tisane (talk) 05:37, 10 April 2010 (UTC)

Just a suggestion, why not try to hit the toolserver or the backup server? You'd have to cope with replag, though... ManishEarth^{Talk • Stalk} 06:16, 10 April 2010 (UTC)

The Toolserver doesn't store page text, so I'm pretty sure you can't use it for mirroring purposes. — The Earwig ^(talk) 06:35, 10 April 2010 (UTC)

Is there any way to access the backup server (read-only)? ManishEarth^{Talk • Stalk} 06:36, 10 April 2010 (UTC)

Question: why do you think people would use your mirror rather than visiting the actual site? This is a serious question - I can't think of any reasons, especially as you won't appear in search engine results (Wikipedia will). Point: a live mirror is unecessary, clunky and generally not a very good idea. You may or may not get blocked - probably not, as the AV bots request virtually every change, but still. If you feel the need to mirror, read about spidering and build one that perhaps records and counts edits, and periodically grabs the latest text of the most updated articles. Or something. Ale_Jrb^talk 14:34, 10 April 2010 (UTC)

I expect people to use it partly for the same reason they use Answers.com, which is that it is not only a mirror but a supplement that includes other information Wikipedia lacks. For instance, someone might create an article on my wiki about the Scrabble Wordbook (a subject deemed too non-notable for inclusion here). The article would appear in Google search results because the article is not on Wikipedia, and therefore would not be deemed by Google to be a duplicate page. However, there would be wikilinks from the Scrabble Wordbook article to mirrored Wikipedia articles, e.g. Scrabble. It would also be possible for a user to override mirrored content; e.g. by creating wikilinks from the mirrored Scrabble article to the Scrabble Wordbook article, either by adding the wikilink to a "see also" section by appending back matter (which could be implemented through pages such as Scrabble (back matter) that would automatically be transcluded, or through a new database BLOB field for back matter text), or through forced wikilinks, described above, that would likewise be implemented either through pages like Scrabble (forced wikilinks) or database fields; both of these functionalities would be implemented through extensions, in all likelihood.

If Wikipedia were hyper-inclusionist, then the world would only need one wiki encyclopedia. But, in much the same spirit that Greg Papadopoulos recently said that the world only needs seven computers,[4] I still envisage that the world basically needs only two wiki encyclopedias. Wikipedia, to cover the notable; and my wiki encyclopedia, to cover everything else while also mirroring Wikipedia's content. The new wiki will, of course, license all of its software and content under the same licenses that Wikipedia and other Wikimedia projects use, and the advertising policy will be to make advertisements no more obtrusive than the ones you see here, or the banner ads that Wikipedia itself uses. Tisane (talk) 16:15, 10 April 2010 (UTC)

Supplement: How 'bout you load all revisions/changes immediately from enwiki, and allow the RC bots to hit the mirror instead of enwiki. As there are many bots individually fetching RC, it'll be much more efficient to fetch RC in a bundle and hand it over to the bots from somewhere else. As for allowing mirrors, you must make sure that oversighted stuff is erased immediately. Mirrors like <mirror name removed> are quite potent here. Searching <mirror name removed> on Google will give you two results from the mirror site itself. One: the main page. Two: <A recent controversial page which was oversighted>. This just shows that the oversighted page was the most viewed on the mirror, an consequently that mirrors are used only to bypass oversight. ManishEarth^{Talk • Stalk} 03:54, 11 April 2010 (UTC)

Did you seriously type that out with things like "Mirrors like <mirror name removed>"? Why would you do that? Prodego ^talk 04:03, 11 April 2010 (UTC)

Because, searching the name of the mirror (If you're an admin I'll mail it to you if you want) will lead you to the oversighted material. The oversighted material in question, though I've never read the page, can be seen to have scope of being controversial by the title itself. So I'd rather not disclose it. ManishEarth^{Talk • Stalk} 11:23, 11 April 2010 (UTC)

How am I supposed to ensure that oversighted stuff is erased immediately? I proposed that oversights be publicly logged with some very limited data about what was done, but it got shot down. If there were a log that would provide just the rev_id of the oversighted revision, if nothing else, then I could automatically remove that stuff. I do agree that it would be good to have the RC bots fetch from the mirror, as long as lag can be kept to only a few seconds. Tisane (talk) 07:02, 11 April 2010 (UTC)

If you're importing all actions realtime, instead of the dumps, I guess that Oversight actions could be imported, too. No they won't, as there's no public Oversight log as you said. Darn. Well, the only way to do this Oversight stuff is to request a blocked Oversighter account (One which can see Oversight logs, but not use the Oversighting power), which I doubt you can get. Oh, well. Forget the Oversighted material thing... ManishEarth^{Talk • Stalk} 11:39, 11 April 2010 (UTC)

And it is also possible that a mirror using a database dump has oversighted material. The database dump is not "redone" when a revision in it is oversighted. PleaseStand ^(talk) 07:28, 11 April 2010 (UTC)

Oversighting of an edit is typically done within a few hours of the edit, so its unlikely that many oversighted edits end up in the dumps, which are only produced once every month or so. Mr.Z-man 12:28, 11 April 2010 (UTC)

Images much darker when uploaded?

I hope this is the right place to post this...

I'm trying to upload screen shots from historically important (IMHO) video games. The images look fine on my screen, but when uploaded, added to an article and then viewed there, they are much darker, to the point of being very difficult to make out.

Any hints?

Maury Markowitz (talk) 13:11, 10 April 2010 (UTC)

I would suggest adjusting the brightness and contrast using a raster graphics editor (such as The GIMP) except I′m not sure policy permits doing this to non-free images. ―AoV² 13:20, 10 April 2010 (UTC)

If the files are in PNG format, it could be due to the presence of a specified Gamma chunk, and how this interacts with various software. AnonMoos (talk) 13:23, 10 April 2010 (UTC)

AnonMoos, how would I go about checking if this is the case? Can you look at my contribs and check? Maury Markowitz (talk) 15:07, 10 April 2010 (UTC)

You can confirm the presence and view the contents of the Gamma chunk with the little "pngcheck" command-line program (downloadable from the libpng website, I believe). If it has a value radically different from around 0.5 (for example 0.1 or 0.9), then that could be a sign of a problem. You can remove the gamma chunk without otherwise editing the contents of the file using the pngcrush command-line program or similar... AnonMoos (talk) 15:42, 10 April 2010 (UTC)

I'm having a hard time finding a tag that works for OSX. You wouldn't happen to be able to compile me up a binary would you? Maury Markowitz (talk) 13:02, 11 April 2010 (UTC)

Again, I believe this is related to the "problem" I describe above! ~Kaimbridge~ (talk) 14:03, 10 April 2010 (UTC)

No, it is not. Math images are simply rendered with different options now. Normal images don't go through the Math rendering engine. Normal images go trough the thumbnail server, which uses ImageMagick in order to create thumbnails. Both image systems are fully separate. When you thumbnail images, they can change. Why that is can have varying causes, but the changes to the Math engine are not related to it. —TheDJ (talk • contribs) 14:59, 10 April 2010 (UTC)

Epidemic of white space

[[:File:United States Capitol subway system.jpg|thumb|United States Capitol subway system#Network]] [[:File:Cromford and High Peak Railway.jpg|thumb|Cromford and High Peak Railway]]

I've come across four six instances today of excessive whitespace in articles, caused (I think) either by templates or images. Examples:

• United States Capitol subway system#Network
• Berner Oberland Bahn#Recent improvements
• Wikipedia:Reference_desk/Science#Bus_brand
• 2010 Polish Air Force Tu-154 crash
• Cromford and High Peak Railway#Construction
• Ashbourne Line (above Ashbourne Line#Construction

I'd be grateful if someone more familiar with the ways of layout markup would opine on whether we should be concerned about this. I can get my head around someone erring when putting a template together, but I'm finding it harder to understand why images seem to be causing this. The number of instances I've found in a single day is, for me, without precident. Tagishsimon (talk) 02:07, 11 April 2010 (UTC) [[:File:Berner Oberland Bahn.jpg|thumb|Berner Oberland Bahn]]

Your examples look normal to me (on Firefox 3.6 with Monobook skin). Perhaps it is a problem with your browser or something specific to your configuration. Dragons flight (talk) 02:11, 11 April 2010 (UTC)

Maybe it is something to do with MS IE? I get great ugly swaths of whitespace in all of the examples above except Ashbourne Line, which looked fine. LadyofShalott 04:09, 11 April 2010 (UTC)

I know I see great ugly swaths of white-space in thousands of places (and remove it except when it stems from a protected template), but these are not among them. Could you provide a screenshot? ―AoV² 04:34, 11 April 2010 (UTC)

Screengrabs attached. They are from IE7 (on a locked down machine). I take it they are IE mangling formatting; and this being the case, am more relaxed about the problem. I'd like to state for the record that I normally use Mozilla, which is why these format glitches are today a novelty for me --Tagishsimon (talk) 16:47, 11 April 2010 (UTC)

Looking at these with IE8. Berner Oberland Bahn suffers from edit bunching— see WP:BUNCH. The rest look OK. ---— Gadget850 (Ed) ^talk 17:14, 11 April 2010 (UTC)

I believe this is a known bug in IE (at least IE<=7): IIRC, if a page has a float (A), then some inline content (B), then another float to the same side with a clear (C), then more inline content (D), the top of D will align with the top of C rather than going directly under B like it should. Anomie⚔ 20:03, 11 April 2010 (UTC)

That is what I see too. By my testing, it works fine in Firefox, SeaMonkey, Opera, and Chrome, but IE messes it up. The note above that Ashbourne Line did not show the problem in IE appears to be due to the fact that the inline content (B) is as long as the float (A). If you shrink the text size down enough, you will see the problem in that article too. -- JPMcGrath (talk) 22:59, 11 April 2010 (UTC)

To demonstrate the problem on this page, I moved the last of the float-right screen images from the initial message down to the end of that message. -- JPMcGrath (talk) 23:09, 11 April 2010 (UTC)

Extra space (2)

[5]

There is a line between the hatnote and the lower text.

There is an above section that deals with this problem template. Can we fix this article without having to delete the line?174.3.123.220 (talk) 06:16, 11 April 2010 (UTC)

I don't understand. Why wouldn't you want to delete the blank line? -- œ^™ 15:12, 11 April 2010 (UTC)

Garbled video thumbnails

Why are thumbnails of certain videos garbled? File:Translational motion gif.ogv, File:Dmitry Medvedev - 2010 Polish Air Force Tu-154 crash.ogv PleaseStand ^(talk) 08:39, 11 April 2010 (UTC)

The system seeks halfway into the file and then tries to take a screenshot. Perhaps the server was under a lot of load, which may cause it to skip a frame here and there. That could lead to this problem. The bigger issue, how to repair the screenshot. As far as I know, there is no system for that atm. —TheDJ (talk • contribs) 11:05, 11 April 2010 (UTC)

See also commons:Commons:Village_pump#Video_thumbnails_corrupt_since_9_April and bugzilla:23160. —TheDJ (talk • contribs) 23:58, 11 April 2010 (UTC)

Extra space (3)

[6]

There is extra space below the hatnote. Can someone please fixTIA174.3.123.220 (talk) 22:44, 11 April 2010 (UTC)

Fixed Gary King (talk) 23:50, 11 April 2010 (UTC)

Please look at this template with me

I am having a problem getting a template to output the content described.

There are two templates to make galleries for images - Template:Image_gallery and Template:Gallery. Both of these are run by Template:Gallery/aux, which I think connects to some code on the backend. Is this description of what happens correct?

Look at the examples on the pages of the two templates. The template is set up for the user to insert a picture, then insert alt text, then insert a description. But it seems that the alt text is ignored and the description text is duplicated into its place, so the output even in the on-page example is not as described.

I am not accustomed to playing with templates. Can someone confirm that the problem I am having actually exists? If the problem is more interesting than my own cluelessness or someone's vandalism of the example, then I would be appreciate being told of what it is. Blue Rasberry 00:34, 12 April 2010 (UTC)

I think you are confusing the alt property of an image, with the tooltip of a link. They are two different things. It seems to me that the images have their specified alt attribute. —TheDJ (talk • contribs) 00:48, 12 April 2010 (UTC)

That is exactly what I was doing. I read up on the topic and now understand how I came to this misconception. Thanks for teaching me the word "tooltip". Problem resolved.Blue Rasberry 03:31, 12 April 2010 (UTC)

You could invoke the internal template one cell at a time, e.g.

{{foobar|IMG_0001.jpg|Description 1}}
{{foobar|IMG_0002.gif|Description 2}}
{{foobar|IMG_0003.png|Description 3}}
{{foobar|IMG_0004.svg|Description 4}} asdf gh jkl;

I believe this would be better in the long run as it does not depend upon an arbitrary (read: pathological yet finite) number of [odd, even] parameters in the outer template. It would also avoid rendering errors when somebody removes, for example, one description parameter from the series. Also, changing “float:left;” to “display:inline;” inside such a stand-alone template would ensure that the trailing text “asdf gh jkl;” begins on a new line below the templates (and not to the right of the first row). Perhaps we can make something like that and call it Gallery2. ―AoV² 01:24, 12 April 2010 (UTC)

Oh, I have never made a template before. I did create the error with text to the right of the original template when I was using it, just as you described, and this single-entry template does sound interesting. Let me think about this and see if I can follow your suggestion about making a new template with the simple code replacement, just for fun. Blue Rasberry 03:31, 12 April 2010 (UTC)

Basically, copy Template:Gallery/aux to another title and make the above-described change to the style attribute. The only functional difference would be the lack of a title bar above the gallery. However, some == Headline text == would suffice in most cases. ―AoV² 05:36, 12 April 2010 (UTC)

Tables: thead, tbody & tfoot

I'd like to be able to use thead, tfoot and especially multiple instances of tbody in articles and templates, for their added semantic richness, and particularly to assist in wrapping groups of table rows in an HTML class as part of a microformat (this will also facilitate more specifically-targeted styling). Can we do this; and if not, do we need to enable an exiting; or request a new; MediaWiki extension? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:00, 12 April 2010 (UTC)

Just a note here, the sortable table implementation does not handle thead correctly. Additionally, Firefox does not correctly handle multiple tbodys. — Dispenser 16:29, 12 April 2010 (UTC)

See also bugzilla:986 for the related <col> and <colgroup> properties. I suspect thead and friends will be even more difficult to properly support. —TheDJ (talk • contribs) 16:40, 12 April 2010 (UTC)

Number of sections

I'm looking for something that will return the number of sections in a page as a variable, so that I can, for arguments sake, tell a separate page to transclude the details of section x as the last section of the page, along with a link to http://wiki.riteme.site/w/index.php?title=title&action=edit&section=x. I am looking for something that can be embedded as code so that all users can access as opposed to a JS solution, and something that can work on a "real time" basis, so each time the page the code is on is looked at it will update. PuppyOnTheRadio (talk) —Preceding undated comment added 04:23, 13 April 2010 (UTC).

You could use includeonly to wrap the part that you want included. Gary King (talk) 05:27, 13 April 2010 (UTC)

The transclusion I've sorted using dpl, but it's actually being able to say on a page "Hey, could you have a look at title of target page and tell me how many sections are in it?" PuppyOnTheRadio (talk) —Preceding undated comment added 05:59, 13 April 2010 (UTC).

iPad editing?

Is there any way to make it possible to fully edit Wikipedia articles on an iPad? The problem I run into is that there is no way to scroll within the editing text box, since the iPad web browser lacks scroll bars. --agr (talk) 21:29, 8 April 2010 (UTC)

Use two fingers to scroll. –xeno^talk 21:30, 8 April 2010 (UTC) (that being said, my kingdom for a decent app to edit Wikipedia)

Yes, but will it blend? --Deskana (talk) 21:38, 8 April 2010 (UTC)

He already blended an iPad? The horror... –xeno^talk 21:41, 8 April 2010 (UTC)

Oh, they'll never approve an app that's better then their own browser. If you've ever tried developing for iPhone you'll know how evil Apple are. OrangeDog (τ • ε) 22:52, 8 April 2010 (UTC)

If the iPad has Safari similar to the Mac than to the iPhone, then you can use a script to expand the editing box to show the entire text so that there is no need to scroll. Gary King (talk) 00:34, 9 April 2010 (UTC)

Wikipedia is not iPhone/iPad friendly :(. Big pages, dis-coordinated conversation requiring multi tags open and big sections which are difficult to edit. Regards, SunCreator ^(talk) 00:45, 9 April 2010 (UTC)

ITYM the iPad is not Wikipedia friendly. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:43, 12 April 2010 (UTC)

That seems broadly accurate. It seems that mobile safari is generally unwilling to play nice with text entry boxes. Still, its amazing that the official iPhone app doesn't support editing, insofar as I can tell from the Help:Mobile Editing page. Protonk (talk) 23:33, 13 April 2010 (UTC)

Check out their latest device [7]. ―AoV² 01:02, 10 April 2010 (UTC)

Broken archiving

What the heck happened here? [8] The bot seems to have delete among others a post about minarchism, which I was looking for. Is this a common bug or an isolated event? Oo --JokerXtreme (talk) 15:05, 11 April 2010 (UTC)

Anyone? --JokerXtreme (talk) 19:25, 12 April 2010 (UTC)

Anyone else? Should I report this somewhere or something? --JokerXtreme (talk) 12:38, 13 April 2010 (UTC)

VFD not moved to AFD

Although I can't remember how I did it, I found my way to Wikipedia:Votes for deletion/User:Rambot, which was discussed in August and September of 2004. Aside from the questions discussed there, I was most interested by the fact that this was never moved to Wikipedia:Articles for deletion/User:Rambot. Any idea why not, and any idea if there's a way to search for other VFD pages that weren't moved to AFD? Please note that the VFD was an attempt to delete the articles created by Rambot, rather than the Rambot userpage; consequently, it should have been moved to AFD instead of VFD. Nyttend (talk) 02:01, 12 April 2010 (UTC)

Special:PrefixIndex/Wikipedia:Votes for deletion shows many unmoved pages. Titles in italics are redirects, usually or always left by a move. I don't know why some were moved and some not. User:Uncle G's major work 'bot moved those I examined. PrimeHunter (talk) 02:17, 12 April 2010 (UTC)

(edit conflict)Special:Prefixindex/Wikipedia:Votes for deletion/ plus Special:Prefixindex/Wikipedia:Votes for Deletion/ should be a complete list. — Gavia immer (talk) 02:21, 12 April 2010 (UTC)

I spot-checked the lowercase prefix (Vfd) back in January. It seemed like there was a cutoff somewhere in early 2005. Flatscan (talk) 04:18, 12 April 2010 (UTC)

Short of scraping it with a bot, CSS like this would make the non-redirects easier to spot visually:

#mw-prefixindex-list-table a { background:yellow; }
#mw-prefixindex-list-table div.allpagesredirect a { background:transparent; }

Replace these properties by whatever is most conspicuous for you on the normal links, followed by whatever negates it for the redirects. ―AoV² 05:31, 12 April 2010 (UTC)

I remember asking about this awhile ago (might of been on IRC), it was caused when the original page was moved it had the sub pages option selected and then it did them till the job queue or something gave up due to the size so it never got completed. Peachey88 ^{(Talk Page · Contribs)} 06:04, 12 April 2010 (UTC)

That explanation is incorrect, since the move-with-subpage feature was introduced in May 2008 while AFD was renamed in August 2005. Also, the move-with-subpage feature will only move up to 100 subpages; this limitation seems to have existed when the feature was introduced or shortly afterward. Graham87 15:19, 12 April 2010 (UTC)

There was an even earlier version of VfD, I remember cleaning up the transfers of that process that had been missed. Rich Farmbrough, 15:45, 12 April 2010 (UTC).

Yes, in the template and MediaWiki namespaces. Also in the very old days, VFD's were just stored on the Wikipedia:Votes for deletion page and sometimes copied to talk pages of their respective articles, or to a "/Delete subpage of the talk page, whether or not the article was deleted. For examples, see the logs of MediaWiki:Vfd-Injektilo, Template:Vfd-Injektilo, and Talk:The World Islands/delete. Graham87 03:21, 13 April 2010 (UTC)

Also see the history of the MediaWiki namespace. Graham87 03:23, 13 April 2010 (UTC)

• Special:Prefixindex/Wikipedia:Votes for Deletion/ was mainly mistakes, so I fixed those.
• Special:Prefixindex/Wikipedia:Votes for deletion/ I have moved a bunch of these, and will get most of the rest done once I have bot approval, unless there's a good reason not to. Rich Farmbrough, 19:12, 13 April 2010 (UTC).

Monobook.js

My monobook.js is not loading. Last time someone pointed out an update to FirefFox (and hence the version of JS) was responsible, and I just needed to change a function call. Any ideas this time round? Rich Farmbrough, 15:27, 12 April 2010 (UTC).

In User:Rich Farmbrough/monobook.js, the code causing the problem is:

function addPurge(){
    ta['ca-purge'] = ['g', 'Purge the internal cache for this page'];
    if(!document.getElementById) return;
    var x = document.getElementById('ca-history');
    var tabs = document.getElementById('p-cactions').getElementsByTagName('ul')[0];
    if(!x) return;
    if(x.children) x = x.children[0];
    else x = x.childNodes[0];
    addlilink(tabs, x.href.replace(/=history/, "=purge"), 'pge', 'ca-purge');
}

In particular, the second line of that code. This is because of the recent MediaWiki update. Assuming that all this code does is add a Purge tab to your page, you could use the code that I use to add a Purge tab next to History. Simply replace the above code with the code below:

function addPurge()
{
	if (!(wgCanonicalNamespace == 'Special'))
		addPortletLink('p-cactions', wgServer + '/w/index.php?title=' + encodeURIComponent(wgPageName) + '&action=purge', 'Purge', 'ca-purge', 'Purge server cache for this page.', '0');
}

If you'd rather just remove this functionality (meaning, you don't want to add the new code above), then you have to also remove the following line as well:

addPurge();

Gary King (talk) 17:09, 12 April 2010 (UTC)

Thanks! This would have taken me at least many hours to find. Rich Farmbrough, 17:45, 12 April 2010 (UTC).

I'll check about readding that ta variable btw. the bugs are annoying. —TheDJ (talk • contribs) 19:17, 12 April 2010 (UTC)

bugzilla:23175. You could also remove the code btw, and just install the Purge gadget in your preferences. —TheDJ (talk • contribs) 19:38, 12 April 2010 (UTC)

My scripts also stopped loading, though they oddly only stopped loading on User/talk, Special:Log, and Special:Contributions; my scripts load when viewing all other namespaces. Removing User:ais523/editcount.js from my monobook.js seems to have corrected the problem, so if anybody is bored and likes correcting code, that one needs some correcting. --auburnpilot talk 02:21, 13 April 2010 (UTC)

Yeah, that script has the same problems (i.e. the ta[] array). Gary King (talk) 03:46, 13 April 2010 (UTC)

I repaired the script. —TheDJ (talk • contribs) 14:16, 13 April 2010 (UTC)

Purge is the least important one (I have ctrl f5 or whatever it is). All my other tabs are dead too. Looks like they broke my bots (with the extra token messing) and my monobook in one release. Luckily I am using the package so fixing the PERL was just a pm update. Rich Farmbrough, 19:16, 13 April 2010 (UTC).

Just as a reminder btw: Scripts are hacks. They have always been and always will be. They might be very handy, functional or essential to operating Wikipedia, but they remain hacks. The continuing functioning of scripts depends on the authors and maintainers of such scripts, not on the developers of the core software and to expect this is not realistic (we might as well halt all development effort because you couldn't get any work done). This is one of the primary reasons as to why editors should importscripts instead of copying them into their own userspace, so that updates that are made to scripts, propagate. This also means that at times, scripts break and need to be repaired. It is fundamental to their nature. When scripts break, they usually take along all of the other scripts you have installed. Again this is inherent to using scripts. Either notify the author of the script, or come to the village pump for assistance. —TheDJ (talk • contribs) 20:05, 13 April 2010 (UTC)

You had a full copy of addlilink included to add links to sidebars and stuff that needed fixing and the edit-section0 script was broken as well. —TheDJ (talk • contribs) 20:23, 13 April 2010 (UTC)

Many thanks. The reason I am chary about transcluding js is that it makes a bad single point of weakness. Rich Farmbrough, 03:34, 14 April 2010 (UTC).

Strange title effect

So I have had the page User:Icewedge/links into which I have transcluded {{Special:NewPages/12}} for many months now and everything has been normal until today when I visited the page and the display title was now "Special:NewPages/12" (with the same thing in the Firefox tab title). Am I hallucinating? Or does anyone know if there has been a transclusion related bug recently? Not that I really mind, its just strange. Its the same across several browsers, and after purging the cache. Icewedge (talk) 03:16, 13 April 2010 (UTC)

The page's title looks fine to me. Appears as "User:Icewedge/links" as it should. Gary King (talk) 03:48, 13 April 2010 (UTC)

I saw the page title as "Special:Newpages/12", came here to write this comment, and upon reloading the page to check again it now appears as "User:Icewedge/links". There's something going on with this for certain. — Gavia immer (talk) 04:37, 13 April 2010 (UTC)

Yeah okay I see it now, too. It seemed to have happened after I visited Special:NewPages/12, then purged User:Icewedge/links. Gary King (talk) 05:26, 13 April 2010 (UTC)

Still says "Special:NewPages/12" for me. —MC10 (T•C•GB•L) 02:51, 14 April 2010 (UTC)

<gallery>

Does this tag have an alternative text function such as [[file:]] does? If not, this needs to be filed on bugzilla.174.3.123.220 (talk) 09:57, 13 April 2010 (UTC)

This feature is requested in bugzilla:18682 (can't provide alt text for files in <gallery>). Sadly, this bug is now inactive. I wish the devs could work on it, it's important for accessibility. Dodoïste (talk) 11:31, 13 April 2010 (UTC)

New design for MediaWiki:Protectedpagetext

Three weeks ago Rd232 implemented a new design for MediaWiki:Protectedpagetext, to make it easier to submit edit requests. It is with the same intent that I suggest a clearer design, without using tables. Here is a draft: User:Dodoïste/Sandbox.

On Wikipedia, we are almost always using tables for layout. This is an outdated practice, and I believe Wikipedia could learn new designs from many websites. I tried to make it look clearer by removing every unnecessary detail, so the eye would not be disturbed. The two groups of text are separated by a large space, so they are spontaneously identified as two different things, per Gestalt Psychology#Prägnanz (a theory often used in usability). I get the feeling that it will fit in with the new theme Vector. Yours, Dodoïste (talk) 13:15, 13 April 2010 (UTC)

Please fix the spam filter

I just made an edit using what I considered to be acceptable sources and I got a warning that I needed to remove one of the sources before I could save my edit. I didn't use preview because I wanted to see the sources (I know, add {{reflist}} and maybe one day I'll figure that out and even remember to remove it). But when I went back to remove the offending link, EVERYTHING I had typed was gone. I had to do a couple of searches to find and redo every one of those references. Ironically, the offending link contained information that several reputable-looking sources had, and I didn't have to use that one, but this particular offending link LOOKED respectable to me.Vchimpanzee · talk · contributions · 16:58, 13 April 2010 (UTC)

Yeah, I think think that MediaWiki should show you what you typed on the same page that it tells you that you have entered a blacklisted URL, similar to what happens when you have edit conflicted with someone else. What happens instead is that MediaWiki relies on your browser to remember what you typed; if you use most current browsers, though, they should remember what you typed when you hit the Back button to go back to the edit page. Gary King (talk) 20:11, 13 April 2010 (UTC)

Obviously, that didn't happen. I haven't asked what I was using but I was told to click on an e at the bottom of the page to look at certain databases at the library where I was, and that's my only clue.Vchimpanzee · talk · contributions · 22:35, 13 April 2010 (UTC)

If you try to save a blacklisted link, for example http://suite101.com, then you see both the box at MediaWiki:Spamprotectiontext and an additonal text below it saying:

"The following link has triggered a protection filter: http://suite101.com
Either that exact link, or a portion of it (typically the root domain name) is currently blocked.

Return to [link to page you were editing]"

The last line causes some users to click the link there but it doesn't go back to the edit window so they don't recover their edit text. Many have complained about losing it. Maybe MediaWiki:Spamprotectiontext should add a note about using the browsers back button to possibly (depending on the browser) recover the text. Maybe the text below the box should be altered. The start is from MediaWiki:Spamprotectionmatch. I don't know where the last line with the link is generated. The same "Return to [link to where you were]" is produced in several other situations. PrimeHunter (talk) 22:52, 13 April 2010 (UTC)

The worst flaw with this is that it stops you editing an article with a blacklisted URL (already in it) to make any other improvement. Maybe admins or confirmed users should be able to save past the filter if the url was there before the edit. This has even prevented me from doing maintenance on my talk page archives. Rich Farmbrough, 03:43, 14 April 2010 (UTC).

You should have been able to make some edits since bugzilla:1505 was resolved. PrimeHunter (talk) 04:16, 14 April 2010 (UTC)

Extra Space

Regions_of_Slovakia

Can someone fix?174.3.123.220 (talk) 04:42, 14 April 2010 (UTC)

Y'know, you've asked for someone to do this multiple times already. The fix isn't as hard as it might seem, most of the time anyway. Gary King (talk) 06:32, 14 April 2010 (UTC)

Adjustment to Random Article

An adjustment to Special:Random has been proposed at Wikipedia:Village pump (proposals)/Archive 61#Random Article improvement. Comments and suggestions would be appreciated. Thank you, -- Black Falcon ^(talk) 05:26, 14 April 2010 (UTC)

Images no longer opaque?

Resolved

 – Via FireFox css modification given below.

I don't know if this is a new "feature" or a bug, but any new TeX image created is no longer opaque. For example, if the previously created TeX image,

$\int \sec ^{8}x\tan x\,dx$

is at all modified (thus creating a new upload.wikimedia.org image),

$\int \sec ^{8}x\tan x\,dx.$

the background becomes transparent. While most people——who use the browser default white background——won't notice anything different, others who use a colored background (such as black) will: The image is only a half visible mash. If this is a new "feature", is there a way to disable it in user settings? ~Kaimbridge~ (talk) 15:38, 9 April 2010 (UTC)

This is a feature (T2008, one of our very oldest). You can style it in your personal CSS:

img.tex { background: white; }

Happy‑melon 18:47, 9 April 2010 (UTC)

No, that's no good——you have to have your browser set to "allow pages to choose their own colors"! P=( ~Kaimbridge~ (talk) 23:44, 9 April 2010 (UTC)

Yes, that's the default. If you intentionally configured your browser to override our settings, then we can't be responsible for how content appears on your screen. Dragons flight (talk) 00:25, 11 April 2010 (UTC)

Okay, that is the corrective type instruction. However, if using FireFox (or other Mozilla based browsers), it is best applied to the userContent.css file found or created in the chrome folder in the desired Profile FF/Mozilla folder (as this will apply it to all transparent images, regardless if "allow pages to choose their own colors" is checked or not!):

IMG{background-color: #FBDBAB !important; }

/*
   A couple codes, easy on the eyes:

   #FBDBAB - "Light Skin";
   #F0E68C - "Khaki" (faint yellowish-gray);
   #====== (#FFFFFF -> #000000) - Shades of Gray (Pure White through
                                  Pure Black);

   Color Code Chart:  http://www.sitetutor.biz/tutorials_html_codes.php
*/

 

^{There is probably a comparable modification for other browsers. ~Kaimbridge~ (talk) 15:11, 14 April 2010 (UTC)}

Good job on fixing that, whoever did so. Ninety percent of the time, calling attention to our math-rendering hack is the wrong thing to do. — Gavia immer (talk) 22:06, 9 April 2010 (UTC)

I have corrected the "black skin" gadget for this btw. —TheDJ (talk • contribs) 15:07, 10 April 2010 (UTC)

Excellent. We ought to purge the existing images so they re-render in a consistent manner. ―AoV² 00:51, 10 April 2010 (UTC)

Also could we get some halfway meaningful alt-text like “∫ sec⁸ 𝑥 tan 𝑥 𝑑𝑥”? All I see in lynx in place of the images is the LaTeX source code of “\int \sec^8 x \tan x \,dx” which means nothing to me (see screen-shot). ―AoV² 02:41, 10 April 2010 (UTC)

If we could get alt text like that, then we could just render the formula like that instead of using an image... The point of alt text is to be readable by text browser and screen readers, not to be pretty. — Carl (CBM · talk) 13:56, 10 April 2010 (UTC)

Those concepts go hand-in-hand, usually. I′d say we could do better than catting the input markup, except that would imply we also could adopt a better input markup. ―AoV² 14:25, 10 April 2010 (UTC)

Looking nice visually, and being readable by a screen reader don't really go hand-in-hand at all, actually. The concepts are basically unrelated, which is somewhat the point. Ale_Jrb^talk 15:00, 10 April 2010 (UTC)

You might be able to make better alt text for something relatively simple like the example above, but what would you do for something like the following?

$\overbrace {\rho {\Big (}\underbrace {\frac {\partial \mathbf {v} }{\partial t}} _{\begin{smallmatrix}{\text{Unsteady}}\\{\text{acceleration}}\end{smallmatrix}}+\underbrace {\mathbf {v} \cdot \nabla \mathbf {v} } _{\begin{smallmatrix}{\text{Convective}}\\{\text{acceleration}}\end{smallmatrix}}{\Big )}} ^{\text{Inertia (per volume)}}=\overbrace {\underbrace {-\nabla p} _{\begin{smallmatrix}{\text{Pressure}}\\{\text{gradient}}\end{smallmatrix}}+\underbrace {\mu \nabla ^{2}\mathbf {v} } _{\text{Viscosity}}} ^{\text{Divergence of stress}}+\underbrace {\mathbf {f} } _{\begin{smallmatrix}{\text{Other}}\\{\text{body}}\\{\text{forces}}\end{smallmatrix}}.$

(used in the Navier–Stokes equations article) Mr.Z-man 21:31, 10 April 2010 (UTC)

Well, that has no chance of being readable with either approach. ―AoV² 21:44, 10 April 2010 (UTC)

How 'bout users are allowed to define the alt text For the original example, it could be "Integral of sec^8 of x times tan^8 of x dx". For the Second example, it could be "Inertia (per volume): {p times (Unsteady acceleration: {dv/dt} + Convective acceletation: {v.<upside down delta>v)}} = Divergence of stress: {Pressure gradient: {-<tri>p} + Viscosity: {mu<delta>^2v} + Other body forces: {f}}". ManishEarth^{Talk • Stalk} 04:05, 11 April 2010 (UTC)

That's already possible, using the "alt=" parameter. See Help:Displaying a formula#Rendering. Graham87 04:16, 11 April 2010 (UTC)

Changing edit summaries

I was under the impression this was impossible. But I copied from one of the reference desks to contribute to an article, and now the edit summary of what I contributed says this was archived.Vchimpanzee · talk · contributions · 23:06, 13 April 2010 (UTC)

huh? Are you saying your original edit summary did not use the words "(now archived 2010_February_1)" Because it was already archived at the time you made the edit. Maybe you just can't remember typing that... –xeno^talk 23:09, 13 April 2010 (UTC)

Right. The text was copied from Wikipedia:Reference desk/Archives/Mathematics/2010 February 1#What are the formulas for a Mercator Projection? The archive was made February 6, four days before your edit. PrimeHunter (talk) 00:28, 14 April 2010 (UTC)

Maybe I did forget.Vchimpanzee · talk · contributions · 15:19, 14 April 2010 (UTC)

Is the wiki.riteme.site server down?

I'm using the secure server right now to post this. I can't seem to access Wikipedia using the wiki.riteme.site server. Is it down for anyone else? ctzmsc3|talk 04:10, 15 April 2010 (UTC)

It's just you. Mr.Z-man 04:12, 15 April 2010 (UTC)

Scripts suddenly borked

Hi; beginning today, all of the scripts installed at User:Steve/monobook.js have stopped working. I haven't changed skins, updated Firefox (v. 3.6.3) or meddled with the page recently; indeed, it appears the same on a different machine using another version of Firefox, so I'm not sure what's happened. I assumed it might be related to the 1.16 update, but I'm not seeing complaints from anyone else, so ... any ideas? Steve ^T • C 21:52, 9 April 2010 (UTC)

I can only say that I have the same setup (Firefox 3.6.3 + monobook skin) and I haven't had any problem with scripts not working. If it happens for you on multiple machines, it's almost certain that some script is causing it, even if it seemed to work before. — Gavia immer (talk) 21:58, 9 April 2010 (UTC)

Try bypassing your cache or checking the error console for JavaScript-related errors? --MZMcBride (talk) 22:02, 9 April 2010 (UTC)

Everything's checking out OK. I've just disabled each one-by-one, bypassing my cache each time, and still nothing. Steve ^T • C 22:07, 9 April 2010 (UTC)

Checked your gadgets? Ale_Jrb^talk 22:14, 9 April 2010 (UTC)

I tried using your monobook.js and I got an error on the line ta['pt-future'] = ['1', 'FAC'];. When I changed it to tb['pt-future'] = ['1', 'FAC'];, all your scripts started working. But I have absolutely no idea why would this error manifest itself now, since this error was there for years. Svick (talk) 22:25, 9 April 2010 (UTC)

Ah! Seems to have fixed all but one; I can live with that for now. If it persists, I'll contact the editor who wrote it. Thanks for your help. Steve ^T • C 22:40, 9 April 2010 (UTC)

This is because before MediaWiki 1.16, there was some old code for akeytt() that fixed tooltips and accesskeys in portlets. This code was removed, and one of the variables that this code was using, was "ta". So you had this error in your monobook, and before last night's software update, that error was non-fatal, because ta actually existed. Now ta disappeared and the error became fatal. —TheDJ (talk • contribs) 01:22, 10 April 2010 (UTC)

Hi, just my function addEditSection0 stopped working, can someone fix? - RoyBoy 02:30, 13 April 2010 (UTC)

Fixed by itself, must have been a code tweak. - RoyBoy 01:44, 16 April 2010 (UTC)

Wikimedia counter

The 1 billionth edit took place in April 16, 2010. http://toolserver.org/~emijrp/wikimediacounter/

Is http://toolserver.org/~emijrp/wikimediacounter/ an actual live count in realtime of edits currently being made to all Wikimedia projects? or is it just an estimate animated for show? -- œ^™ 00:49, 11 April 2010 (UTC)

It updates the totals regularly (like every 10 minutes) and calculates a 'pace'. The latest total (+time of measurement) and the pace are then loaded in the page, and it displays a value estimated on those numbers. —TheDJ (talk • contribs) 00:53, 11 April 2010 (UTC)

For some, the estimate probably is incorrect. To get a correct estimate, the date, time, and timezone of your computer's clock must be set correctly. PleaseStand ^(talk) 01:40, 11 April 2010 (UTC)

Note that you can watch the real time RC feed for a particular site on the IRC RC feed. For example: [9]. Prodego ^talk 04:14, 11 April 2010 (UTC)

So at the current pace when should we expect to hit 1 billion edits? :) œ^™ 10:39, 11 April 2010 (UTC)

At the moment, 8 per second. So about 515,600 seconds= 8,600 minutes =143 hrs = almost 6 days. Lets throw a WikiParty!!!!!!! ManishEarth^{Talk • Stalk} 12:00, 11 April 2010 (UTC)

Afterthought: Oh no! What if there's a M2B or a M2G problem like the Y2K!!! Da servers will crash!!!! *Takes cover prematurely. ManishEarth^{Talk • Stalk} 12:03, 11 April 2010 (UTC)

2³² = 4,294,967,296. So we've got about 12 years to go at the current rate before we get an overflow on 32bit revision ids. Happy‑melon 17:53, 11 April 2010 (UTC)

Not if it is a signed int.... Rich Farmbrough, 15:24, 12 April 2010 (UTC).

Based on the rate for last 12 hours or so, it comes to about 8PM EST Friday (Midnight UTC Saturday). It will probably be earlier than that, since activity is typically low in that period. -- JPMcGrath (talk) 20:27, 11 April 2010 (UTC)

Revids are wiki-specific. This counter seems to be all languages and all wmf projects. At Special:Statistics, we've got 380,183,543 edits. And, I think that, sooner or later, MediaWiki will allow 64-bit numbers... ManishEarth^{Talk • Stalk} 16:50, 13 April 2010 (UTC)

Looks like it will hit the 1-billion mark about 10AM EDT Friday (2PM UT) -- JPMcGrath (talk) 23:31, 15 April 2010 (UTC)

Special:RecentChangesLinked

It's quite nifty that Special:RecentChangesLinked works on categories, so you can see recent changes for members of that category. There's also a handy checkbox option to see changes on pages which link to the "given page" (or category). But what would really make this useful is an option to see changes on the mainspace equivalent of a page, in particular where the talk page is the member of the category.

Having such an option would allow us to construct clickable links for WikiProjects showing recent changes to all pages tagged by that project, on the basis of a category which includes all the pages. The category bit is easy as project banners have an optional MAIN_CAT parameter which many projects already use to place all their articles in, in addition to the importance and class assessment categories (eg Category:Latin America articles). So - good idea? Easy to do? Can we get a dev's attention and get it done in record time? Rd232 ^talk 10:33, 13 April 2010 (UTC)

I agree, this would be a great feature to have. Right now the same thing is accomplished rather inefficiently with public watchlists. —Quibik (talk) 11:18, 13 April 2010 (UTC)

If I understand the above suggestion correctly, it is bugzilla:13202. ―AoV² 23:22, 13 April 2010 (UTC)

I think so. Sadly, some links from there suggest it's actually way harder than it sounds. Rd232 ^talk 14:57, 14 April 2010 (UTC)

It looks like a job for the to-be-extended CatScan.

Magnus Manske's CatScan V2.0β can already do something similar:

• Recently changed articles in Category:Latin America or its (level 1) subcategories, which have Template:WikiProject Latin America on their talk pages
• Recently changes articles about Greek mythology which the Wikiproject Gender Studies claims as theirs

It has its limitations, but you can play around with it or the original CatScan (which some WikiProjects already use to check for AfDs in their field or such).

CatScan is supposed to be integrated into MediaWiki as an extension at some point.

Regards, HaeB (talk) 01:09, 16 April 2010 (UTC)

EEkk

Template:Infobox_martial_art_school

Is there anyway to remove the white space caused by the line break between the {{estoric}}</noninclude> and the { of the start of the template without breaking it?174.3.123.220 (talk) 11:40, 15 April 2010 (UTC)

Moved the tag to the documentation page. ---— Gadget850 (Ed) ^talk 12:18, 15 April 2010 (UTC)

List of AFDs in Closing

Resolved

I'm looking for a way to supress the categories on transcluded AFDs. Specifically, Wikipedia:Articles for deletion/In closing is a list that transcludes the AFD log from 7 days ago, since this is the log of AFDs that are now eligible for closure or relisting. The problem is that each of those AFDs adds its category to the "In Closing" list - which adds Wikipedia:Articles for deletion/In closing to the categories of AFD Debates (Found at CAT:AFD - Biographical, Society, etc). The actual daily logs (such as Wikipedia:Articles for deletion/Log/2010 April 6) don't parse the categories, so what's different? I know there's some obvious answer, but I'm missing it. Thanks! UltraExactZZ ^Said ~ Did 14:52, 13 April 2010 (UTC)

The template {{REMOVE THIS TEMPLATE WHEN CLOSING THIS AfD}} currently adds the category if the first part of the page title (delimited by slashes) is “Articles for deletion” and the second part is not “Log”. If Wikipedia:Articles for deletion/In closing is the only page with this problem, then I think adding another check to that template would be the best solution. Svick (talk) 15:48, 13 April 2010 (UTC)

That's exactly it, this page is the only one with a recurring issue. The daily log pages themselves are occasionally included in the categories due to a malformed AFD or template, but that is easily corrected. I'll tinker with it a bit, see if I can't get something akin to the Log exception. Unless someone with more skill in this area wants to take up the challenge? Thanks! UltraExactZZ ^Said ~ Did 20:43, 15 April 2010 (UTC)

I requested that change at Template talk:REMOVE THIS TEMPLATE WHEN CLOSING THIS AfD#Do not add category on In closing. Svick (talk) 21:52, 15 April 2010 (UTC)

Wonderful. Thanks! UltraExactZZ ^Said ~ Did 04:00, 17 April 2010 (UTC)

Image type now checked on upload

When I cleanup and convert a file to a new type, I can no longer upload it over the old file and then rename it to the new file type. I get "File extension does not match MIME type." even if "Ignore any warnings" is checked. I guess we are back to the grind of uploading a whole new file, copying the rationale and licensing and orphaning the old file. ---— Gadget850 (Ed) ^talk 03:37, 16 April 2010 (UTC)

Yes, I'm considering if we should not request that at least administrators have access to the old behavior. —TheDJ (talk • contribs) 12:23, 16 April 2010 (UTC)

Considering that I cleaned up over 2000 images earlier this year, it made things so much easier to simply do a reupload then a rename. ---— Gadget850 (Ed) ^talk 13:52, 16 April 2010 (UTC)

I kinda agree, on the other hand, the previous checks were a bit 'too loose' for the general public in my opinion. A lot of people were making errors. But I do find myself kinda stuck with the BMP images now. I'm not yet sure what the best idea is. I'll see about talking to Bryan. —TheDJ (talk • contribs) 14:33, 16 April 2010 (UTC)

It seems like this is a good check in general. I do practically no image work, so forgive me for asking - is it not possible to move the image description page first and then reupload after the move? — Gavia immer (talk) 14:01, 16 April 2010 (UTC)

Nope, that isn't possible either anymore. —TheDJ (talk • contribs) 14:33, 16 April 2010 (UTC)

Checking the type on a move came in months ago— you can't move to the wrong type; checking on reupload is very recent. It would be OK if the page displayed a warning on a wrong MIME type, but still allowed the reupload. ---— Gadget850 (Ed) ^talk 15:32, 16 April 2010 (UTC)

toolserver JIRA

Is http://jira.toolserver.org down? ManishEarth^{Talk • Stalk} 14:08, 16 April 2010 (UTC)

According to Betacommand, "JIRA was disabled until DaB can fix a security hole.". –xeno^talk 14:09, 16 April 2010 (UTC)

Thanks! When do you think it'll be back? ManishEarth^{Talk • Stalk} 14:19, 16 April 2010 (UTC)

I've no idea. Hopefully soon. –xeno^talk 14:21, 16 April 2010 (UTC)

For interest. Basically, the Apache foundation got totally owned by a security hole in JIRA; a fix is available, but they're keeping JIRA offline until they're sure that it has been properly fixed. Happy‑melon 20:24, 16 April 2010 (UTC)

thead, tbody & tfoot

I'd like to be able to use thead, tfoot and especially multiple instances of tbody in articles and templates, for their added semantic richness, and particularly to assist in wrapping groups of table rows in an HTML class as part of a microformat (this will also faciaite more specifically-targeted styling). Can we do this; and if not, do we need to enable an exiting; or request a new; MediaWiki extension? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:20, 17 April 2010 (UTC)

Just file a request in bugzilla:. —TheDJ (talk • contribs) 21:26, 17 April 2010 (UTC)

Of course, thank you. I've added my voice to the existing bug id=4740. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:05, 17 April 2010 (UTC)

Firefox, Macbook, or wikipedia?

Bold text

Having some odd issues with svg's not showing up, and the alt text showing in its place as a link to the image. Going to the image (File:whatever), it displays the filename of the image in its place. If I click on THAT filename, then the image loads fine and dandy. If I go back, nothing has changed. What the hell?!?

Some svg's show, others do not. The one that won't show for me is the map on Ontario Highway 404. Is it just me? - ʄɭoʏɗiaɲ ^τ _¢ 20:57, 17 April 2010 (UTC)

I'm using Firefox 3.6.3 on Windows, and File:Ontario_404_map.svg shows the same way for me, as a link instead of a thumbnail. However, the actual SVG file renders properly for me, it's only the PNG thumbnail that appears broken. It's not a large file, and it has no text rendered in the image, which are the usual culprits when SVG rendering breaks, so I'm stumped. — Gavia immer (talk) 21:07, 17 April 2010 (UTC)

If you open the image in its own window click, you will see that the file is referencing an external resource. —TheDJ (talk • contribs) 21:25, 17 April 2010 (UTC)

Turns out you had several jpg dependencies like:

<image width="640px" height="414px" xlink:href="Ontario 404 map_14.jpg" transform="matrix(0.74996567 0.0 0.0 0.75100404 0.0 0.0)"/>

―AoV² 23:37, 17 April 2010 (UTC)

Odd... Wonder how those got in there. I imagine they exist in all the svg's, but I'm not sure why only this one has given me issues so far. The Highway 400 and 401 maps worked absolutely fine. - ʄɭoʏɗiaɲ ^τ _¢ 03:15, 18 April 2010 (UTC)

No, there is nothing like that in the source code of File:Ontario 400 map.svg, File:Ontario 401 map.svg. ―AoV² 03:39, 18 April 2010 (UTC)

White Space

MKEK-1

Has a problem with an extra line before ==Notes==. Please teach me how to fix it.174.3.123.220 (talk) 00:55, 18 April 2010 (UTC)

Fixed. A couple of blank lines in the wikitext. Ucucha 01:38, 18 April 2010 (UTC)

Wikipedia:Help desk#Accidentally disabled mobile site

A user left a query here; and later left another note that the Wikipedia re-enabling the mobile site link doesn't work for him. Any suggestions? (please leave a note on the Help Desk). Thanks ♪ ♫ Wifione ♫ ♪ _―Œ ^{♣Łeave Ξ мessage♣} 11:44, 18 April 2010 (UTC)

A more permanent link to the same section is here. Graham87 06:24, 19 April 2010 (UTC)

Question

Does anyone know why TT:DYK redirects to the Russian Wikipedia, which then redirects to this one? There is no known link between this and the Russian one, so this perplexes me. Thanks. Kevin Rutherford (talk) 15:51, 18 April 2010 (UTC)

It doesn't. It leads to the Tatar Wikipedia. That's expected behaviour when you use tt, the Tatar language prefix. Algebraist 15:56, 18 April 2010 (UTC)

(edit conflict) That is actually an interwiki link, where tt is the language code for Tartar per meta:List of Wikipedias. I'm guessing someone tried to set TT as a redirect to template talk so it would link to Template talk:Did you know. ---— Gadget850 (Ed) ^talk 16:03, 18 April 2010 (UTC)

Thanks for the help there. Kevin Rutherford (talk) 00:10, 19 April 2010 (UTC)

If you don't want your work edited, don't submit it

This isn't exactly a software issue, but I guess the software would have to be changed.

Let's say a redesign is being done, at some future time, of how it will look below where we are typing when we edit. As part of this, a change might be made to "If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here. All text that you did not write yourself, except brief excerpts, must be available under terms consistent with Wikipedia's Terms of Use before you submit it". This has "it." on the second line, at least when I see it. Would it be possible to shorten the message so it all goes on one line? I think that would look better.Vchimpanzee · talk · contributions · 20:14, 16 April 2010 (UTC)

The relevant page is MediaWiki:Wikimedia-editpage-tos-summary. I hide that warning with my .css, to be honest. –xeno^talk 20:17, 16 April 2010 (UTC)

Whether the message fits on one line and the position of the line break depends on screen resolution, so I don't think it should be rewritten just because you see a bad line break there. Svick (talk) 22:15, 16 April 2010 (UTC)

Okay, that makes sense.Vchimpanzee · talk · contributions · 17:10, 19 April 2010 (UTC)

Login unification process

I could not complete the login unification process, because one project (Finnish Wikipedia) has an account with the same user name. I am providing links to the main page, the user page, the user talk page, and the user contribution page.

• http://fi.wikipedia.org/wiki/Wikipedia:Etusivu
• http://fi.wikipedia.org/wiki/Käyttäjä:Wavelength
• http://fi.wikipedia.org/wiki/Keskustelu_käyttäjästä:Wavelength
• http://fi.wikipedia.org/wiki/Toiminnot:Muokkaukset/Wavelength

The user has edited Finnish Wikipedia only three (3) times, all in June 2006. Is it possible for me to usurp the user name "Wavelength" for the Finnish Wikipedia, so that I can complete the unification process? Wikipedia:Unified login directs me to http://meta.wikimedia.org/wiki/Help:Unified_login. The section http://meta.wikimedia.org/wiki/Help:Unified_login#Someone_is_using_my_name_on_another_wiki.2C_how_can_I_get_that_account.3F says "If you want to usurp an account on another wiki, you should make a request to a bureaucrat on the problem wiki." To do that, apparently I need to register (temporarily) with a different user name. There is a link to http://meta.wikimedia.org/wiki/SRU, which has a link to http://meta.wikimedia.org/wiki/Index_of_pages_where_renaming_can_be_requested; http://meta.wikimedia.org/wiki/Index_of_pages_where_renaming_can_be_requested#fiwiki has a link to http://fi.wikipedia.org/wiki/Wikipedia:Käyttäjätunnuksen_vaihto, which has a link to http://fi.wikipedia.org/wiki/Wikipedia:Käyttäjänimen_haltuunotto, which says "A valid usurpation request can be made only by a registered user." -- Wavelength (talk) 00:20, 19 April 2010 (UTC)

What's your question? Yes, you need to go to fi:Wikipedia:Käyttäjänimen haltuunotto and follow the instructions there. Amalthea 13:34, 19 April 2010 (UTC)

Wikipedia:Username policy#Using multiple accounts says "It is recommended that contributors do not use multiple accounts without good reason." Should this be considered as a valid exception to that guideline? I just want to be sure that, after I register (temporarily) with a different user name, I will still be able to register as "Wavelength" on Finnish Wikipedia. -- Wavelength (talk) 15:37, 19 April 2010 (UTC)

Yes (← short answer). What's going to happen is that you create an account on fi.wikipedia named "fi:User:Wavelength (enwiki)" or something, and during the usurpation that account is renamed to "fi:User:Wavelength" which you can then unify under your SUL, so you'll ever only have one account on fi.wikipedia anyway. Amalthea 16:08, 19 April 2010 (UTC)

Thank you very much. -- Wavelength (talk) 16:45, 19 April 2010 (UTC)

Runtime error

Don't the developers have their "debug messages" turned on, on their browsers, when testing changes? I'm getting an error message pop-up box on every page. There is an error on line 1 of in upload.wikimedia.org/centralnotice/wikipedia/en/centralnotice.js - the line itself is not readable to me. --A Knight Who Says Ni (talk) 01:15, 19 April 2010 (UTC)

It's gone now, was only there for a few minutes. I've also seen errors like this on my watchlist page, which seem to stay for a few days at a time, then go away, presumably the result of changes. To developers, please test with debug messages turned on; some of us have this feature turned on normally. Thanks. --A Knight Who Says Ni (talk) 01:18, 19 April 2010 (UTC)

Actually if you had this in centralnotice, it's more likely it was because your browser had a broken download of the script. There haven't been any recent changes to the centralnotice (not in code, not in deploy, not in messages and local administrators cannot touch that file). If the download of a script fails for some reason (dropped connection or data corruption along the way or whatever) sometimes a browser uses the script anyway (don't ask me why, no idea). Then you get problems like this. —TheDJ (talk • contribs) 01:29, 19 April 2010 (UTC)

Though the people who update centralnotice have a history of never testing any of their code (see last (or indeed every) fund-raiser for example). Many people just block the js entirely partly due to this, but mostly because nothing of use or interest ever appears in a centralnotice. OrangeDog (τ • ε) 11:43, 19 April 2010 (UTC)

SMS Updates

Something I've been recently thinking about is implementing a feature in which Wikipedia sends a text message to a user's cell phone upon a page being edited. More specifically, this could be of helpful use for one's talk page, as one would be able to be notified as to when they have a new query, leaving out having to check on one's talk page every so often, especially when awaiting a reply. Theoretically, would this be possible, and would it be able to be done in terms of funding, considering that Wikipedia is a charity? ~SuperHamster Talk Contribs 02:54, 19 April 2010 (UTC)

I suspect it would be too expensive. Someone would have to pay for those texts, and with the number of changes made and number of possibly interested users, the costs would soon explode. OrangeDog (τ • ε) 11:40, 19 April 2010 (UTC)

Makes sense, thanks for the reply. ~SuperHamster Talk Contribs 19:36, 19 April 2010 (UTC)

This is already possible! Use the page's RSS feed and one of several free RSS>SMS services and Bob's your uncle! ╟─TreasuryTag►Counsellor of State─╢ 11:42, 19 April 2010 (UTC)

Oh! Very nice, I'll look into this. Thanks, ~SuperHamster Talk Contribs 19:36, 19 April 2010 (UTC)

Easy question - Special:LinkSearch

Really hard to know where to ask this question, and this certainly isn't the 100% correct spot. That being said, someone will probably know... Special:LinkSearch shows outgoing links; is there something similar that shows outgoing interwiki links?? — Timneu22 · talk 17:34, 19 April 2010 (UTC)

On that very same page, there's a link to this. Is that what you're looking for? Gary King (talk) 17:40, 19 April 2010 (UTC)

Not really; I should have specified that I was looking for a MediaWiki answer, not a Wikipedia answer. (Again, this question is probably not in the right spot.) — Timneu22 · talk 17:44, 19 April 2010 (UTC)

No. Mr.Z-man 17:53, 19 April 2010 (UTC)

That's what I thought... and that sucks. Oh well, thanks. — Timneu22 · talk 17:54, 19 April 2010 (UTC)

Minification of all JS into one file

For me, there are 23 JavaScript files loaded on this edit page altogether (including Wikipedia Beta code and files loaded by 7 gadgets, no Twinkle/Friendly). Yes, I know that the developers have rejected this before, but is there any way to have JavaScript code minified and combined into a single file? It seems that to not do so is a waste of bandwidth that could add to load time. For example, when running a script I wrote, User:PleaseStand/segregate-refs.js, through Closure Compiler with the optimization level set to "whitespace only", I get:

• Original Size: 22.13KB (7.35KB gzipped)
• Compiled Size: 12.76KB (3.92KB gzipped)
• Saved 42.35% off the original size (46.71% off the gzipped size).

I also get similar savings with YUI Compressor and JSMin. This should be important because of the upcoming deployment of the Vector skin and Beta enhancements. I do know that sometimes, minification can cause problems, but if necessary the minification part could be done on an opt-in basis (those who check their code with JSLint can safely do so). PleaseStand ^(talk) 22:07, 18 April 2010 (UTC)

The problem with combination is mostly regeneration and cacheability. The problem with minification is of course that it makes the files less readable, and again regeneration of course. In the complex world of wikipedia, those are big problems, though it should become easier in 1.17 after michael dale finishes his script loading core redesign. And remember that all scripts are usually cached after you download them once. —TheDJ (talk • contribs) 22:25, 18 April 2010 (UTC)

(edit conflict) Although JavaScript is client-side cacheable for 31 days, we must not forget those who regularly clear their web browser caches. At least for the first-time load, each file requires an extra HTTP request (additional latency). PleaseStand ^(talk) 23:09, 18 April 2010 (UTC)

No. ¦ Reisio (talk) 22:48, 18 April 2010 (UTC)

We do want to combine all JavaScript into one or a few files at some point in the future. The current situation is out of hand. Minification is more controversial; Usability Initiative JS seems to generally be minified, but other JS not. Possibly we could minify but keep line breaks, so that at least errors would correspond to sensible line numbers that could be matched up to readable source. But in any event, combining is obviously a must, just no one has gotten around to it yet. —Aryeh Gregor (talk • contribs) 16:40, 19 April 2010 (UTC)

Isn't the server connection zipped anyway? In that case minifying would not make a difference. And multiple files are not a problem due to browser caching. Cacycle (talk) 07:24, 20 April 2010 (UTC)

He actually gives an example of minifying reducing the gzipped files by 47%. I've seen similar results. GZip is invertible compression, but minifying can provide additional savings by being lossy. Simply eliminating all comments and non-functional whitespace can often save a great deal in file size both before and after gzip. Dragons flight (talk) 07:44, 20 April 2010 (UTC)

Also, multiple files are a big problem for a first-time view, with no cache. There are a lot of those, even on Wikipedia. In many browsers, each script completely blocks page processing until it's downloaded and executed, including retrieval of later scripts, so script retrieval is actually serialized. (This is not the case in most up-to-date browsers, but a lot of people use old versions.) Even in browsers that will retrieve scripts in parallel, they'll still only retrieve a few resources in parallel for a given page, to avoid overloading the server. So yes, this really is a good idea to do. —Aryeh Gregor (talk • contribs) 17:32, 20 April 2010 (UTC)

"diff" and "hist" links switched around

About a week ago, I noticed that "diff" and "hist" are now swapped around when viewing a contributions page, so I often get the opposite of what I want. Why was this done?

See Wikipedia:Village_pump_(technical)/Archive_74#.22diff.22_and_.22history.22_flipped_in_contributions_lists. —TheDJ (talk • contribs) 15:02, 19 April 2010 (UTC)

Did the developers bother to get consensus for this change? I read the archive and it sounds like a lot of other people wanted things to display the way we're used to. Rather than talking about javascript hacks, perhaps the developers should be asked to revert this ill-considered change. Does anyone actually prefer the new layout? *** Crotalus *** 15:06, 19 April 2010 (UTC)

I certainly don't and I think the change is counter-intuitive. The "diff" link should appear closest to the name of person responsible for the diff, rather than separated by the gulf of "(hist)". (Ok, slight hyperbole, but such it is). –xeno^talk 15:09, 19 April 2010 (UTC)

So I was not in the twilight zone clicking on the wrong link every time. :) I probably could get used to the change, but I see no reason why it was changed. Like Xeno said above, diff link close to the name makes more sense. Garion96 (talk) 15:12, 19 April 2010 (UTC)

I like it - it matches the watchlist now. Ale_Jrb^talk 15:25, 19 April 2010 (UTC)

As the OCD-type person I am, I actually prefer the current (diff) (hist), too. In addition to matching the watchlist, it's also in alphabetical order, which in my twisted world makes a lot more sense than anything related to actual efficiency :) Gary King (talk) 17:42, 19 April 2010 (UTC)

I'd have rather the watchlist made right than the contribution list made wrong =) –xeno^talk 17:44, 19 April 2010 (UTC)

WHERE WAS THE CONSENSUS!!!!!!!!!!!!!!!!!!!!! --MZMcBride (talk) 17:52, 19 April 2010 (UTC)

MZ, clearly some individual or small group of people entrusted with advanced access and tools decided that they knew best and started significantly "fixing" things before gaining consensus. OrangeDog (τ • ε) 18:00, 19 April 2010 (UTC)

I'm afraid you missed the irony in MZMcBride's comment. MediaWiki development is not contingent on what the community of this particular Wikimedia project tries to decide. Amalthea 18:08, 19 April 2010 (UTC)

Yeah. MediaWiki should not be required to come to each project asking for consensus on changes like this. It's an open source project; it's up to the developers to decide these things. Wikipedia is simply yet another website that runs the software. The things that SHOULD be discussed here includes changing the default skin, installing extensions, etc. Anyway, if you guys really want, someone can whip up a script to switch the two back for you only. Gary King (talk) 18:11, 19 April 2010 (UTC)

Ale_jrb already prepared such a script, but some of us (me, anyway) are having trouble getting it to cooperate with popups... and we are starting to get used to the new way... And we don't like it. –xeno^talk 18:15, 19 April 2010 (UTC)

importScript ( 'User:Ale_jrb/Scripts/contreverse.js' );

What problems does the script have with Popups? Gary King (talk) 18:28, 19 April 2010 (UTC)

Popups simply doesn't work when it's enabled. But as I joked above, I'm getting used to the new way now so don't worry too much if it's just lil' ole me. –xeno^talk 18:29, 19 April 2010 (UTC)

It should work if you move this script above Popups. Gary King (talk) 18:31, 19 April 2010 (UTC)

And if popups is loaded via gadget? –xeno^talk 14:40, 20 April 2010 (UTC)

Manually include popups instead. User:OrangeDog/monobook.js has an example. Just in case the irony above wasn't intentional, I thought I'd point out the hypocrisy instead. OrangeDog (τ • ε) 18:06, 20 April 2010 (UTC)

syntax for voucher specimens

What is the syntax for adding to images info on vouchered specimens? Popovkin (talk) 18:59, 19 April 2010 (UTC)

What's a vouchered specimen? OrangeDog (τ • ε) 11:19, 20 April 2010 (UTC)

He might mean DNA_barcoding#Vouchered_specimens. But I still don't understand. He might mean wikimarkup. ManishEarth^{Talk • Stalk} 19:59, 20 April 2010 (UTC)

Well that article section is entirely unhelpful. When someone turns up who knows what a vouchered specimen is, could they make sure that it gets explained there too? OrangeDog (τ • ε) 22:24, 20 April 2010 (UTC)

Presumably they are looking for this, i.e. information on how to insert images in general. Gary King (talk) 04:27, 21 April 2010 (UTC)

Static GIF images not being resized by MediaWiki for years now. When will MediaWiki resizing return?

Static GIF resizing by MediaWiki worked fine years ago. Then some idiot Wikimedia developer saint turned it off, and the rest of the developers left it turned off for years (except for a few months). See commons:Commons:Graphics village pump/GIF thread#GIF scaling (animated and non-animated) still not working and commons:Commons:Graphics village pump/GIF thread#Can static GIF scaling be separated from animated GIF scaling?

See commons:Category:Octave Uzanne or any category with lots of charts, graphs, diagrams, or maps in GIF form. They take many minutes for dialup users to load. The Octave Uzanne thumbnail images look blurry now, but looked sharp when MediaWiki resized them. --Timeshifter (talk) 18:55, 30 March 2010 (UTC)

For that particular issue, convert the images to PNG format. When properly done and then run through optimization software, the file size is often less. PNG crusade bot and 718 Bot (here, not on Commons) used to automatically process GIF images tagged with {{ShouldBePNG}} (where conversion results in a file-size reduction of the full size image), but that task does not seem to be active anymore. PleaseStand ^(talk) 21:25, 30 March 2010 (UTC)

Unnecessary. GIF is an accepted copyright-free format for graphics and grayscale images such as commons:Category:Octave Uzanne. Graphics such as drawings, Line Art, graphs, charts, diagrams, typography, numbers, symbols, geometric designs, maps, engineering drawings, posters, banners, and flyers. GIF is a lossless format that works fine for graphics with less than 256 colors (which is true for most graphics).

See also: commons:Commons talk:Superseded images policy. GIF images are fully accepted. Conversion to PNG might be necessary for some GIFs that use transparency. By the way, if you want an easy way to make PNG images smaller (in kilobytes) I recommend Irfanview. It can losslessly compress PNG images so as to use less kilobytes for the same image without any loss in image quality. Install the Irfanview plugin pack too. It installs instantly and includes even better PNG compression, PNGOUT, which is easy to use in Irfanview. --Timeshifter (talk) 10:25, 31 March 2010 (UTC)

WP:NPA still applies even if you're talking about a paid staff member. They're still a member of the Wikimedia community. Mr.Z-man 21:48, 30 March 2010 (UTC)

See also WP:BITED. —TheDJ (talk • contribs) 00:23, 31 March 2010 (UTC)

Lol. I repent. I will do 3 "Hail Jimbos" and smoke a fatty to calm down. Love the image. --Timeshifter (talk) 10:25, 31 March 2010 (UTC)

Can some developers please respond? --Timeshifter (talk) 10:28, 31 March 2010 (UTC)

It seems like it works to me: —Aryeh Gregor (talk • contribs) 18:36, 2 April 2010 (UTC)

The browser, not MediaWiki, is doing the GIF image scaling. The number of kilobytes downloaded for a thumbnail is the same as for the full-size GIF image. See commons:Category:Octave Uzanne for example. Check the image properties for some thumbnail GIF images there. You might have to use MS Internet Explorer to get the image properties if you are not using the most recent version of Firefox. Example thumbnail info: "327.96 KB (335,832 bytes)," and "1,971px × 2,714px (scaled to 87px × 120px)". That scaling is done in the browser. The full 327 KB is being downloaded for that tiny thumbnail GIF.

That particular category has sharp, not blurry, thumbnails when MediaWiki does the scaling. Viewing that category's thumbnails is an easy way to tell if MediaWiki scaling of static GIF images has been turned on. --Timeshifter (talk) 23:55, 2 April 2010 (UTC)

Okay, right. The problem seems to be these lines in CommonSettings.php:

// Re-enable GIF scaling --catrope 2010-01-04
// Disabled again, apparently thumbnailed GIFs above the limits have only one frame,
//  should be unthumbnailed instead -- Andrew 2010-01-13
$wgMediaHandlers['image/gif'] = 'BitmapHandler_ClientOnly';

You need to ask sysadmins about that. Developers can't help you, unless there's some underlying software issue that's preventing the thumbnailing from being re-enabled that needs to be fixed. —Aryeh Gregor (talk • contribs) 17:38, 4 April 2010 (UTC)

It seems that all animated GIFs have only one frame shown when scaled. See bugzilla:22041 and comment #3: "After further investigation it appears that this issue is affecting all or nearly all thumbnails created from animated GIFs since the software update." --Timeshifter (talk) 16:55, 5 April 2010 (UTC)

Re-enabled GIF scaling

Hi all,

I've just re-enabled GIF scaling on Wikimedia sites. Hopefully you won't notice the difference.

If you do have problems with images rendering as single frames, then you should tell me so, by leaving a note on my talk page, e-mailing me at firstinitial surname at wikimedia dot org, or finding me on IRC.

— Andrew Garrett • talk 04:47, 6 April 2010 (UTC)

Just to be clear, it's reenabled for both static and animated GIFs, correct? Even if it's just static GIFs, that's good news. — Gavia immer (talk) 05:02, 6 April 2010 (UTC)

Great! Thanks. I just checked commons:Category:Octave Uzanne. The thumbnail GIF images are now sharp due to MediaWiki scaling. A few kilobytes per thumbnail, versus hundreds of kilobytes per thumbnail without MediaWiki GIF scaling.

Animated GIF scaling is currently rendering as single frames, though. I left more info on your talk page. --Timeshifter (talk) 16:33, 6 April 2010 (UTC)

If you see these images, purge the filepage, and force a reload of your browser directly on the image url. This should fix them. They are old cached images from last time. —TheDJ (talk • contribs) 19:09, 6 April 2010 (UTC)

File:Translational motion.gif. This is supposed to be a 300-pixel-wide, 398 KB, self-running animation. It had achieved FA status in January 2007 and is used on six of Wikipedia’s technology-related articles. Click here to see what the animation is supposed to look like.

Many articles have been adversely affected. Please undo whatever you just did. Many self-running animations, such as the one shown at right (and which is used on Thermodynamic temperature) worked fine for years but no longer do so. Note another self-running animation here on Non-uniform rational B-spline; same error. This is what it is supposed to look like in our articles. The animation on Thermodynamic temperature (and many other articles, including Equipartition theorem) was awarded FA status in January 2007. Now all one sees is a gray boxes saying “Error creating thumbnail: Invalid thumbnail parameters or image file with more than 12.5 million pixels.” As the Translational motion animation is used in the following articles: Thermodynamic temperature
Kinetic theory
Elastic collision
Neutron moderator
Equipartition theorem
…and since it can reasonably be assumed there are many other animations being affected that are used in very many articles, it would be exceedingly nice if whatever just changed was undone and greater caution exercised hereon. Greg L (talk) 18:08, 6 April 2010 (UTC)

The changes were explicitly made to avoid the crashing of the scale routines of the servers. I doubt the deployment of GIF scaling will be reverted yet again. We don't allow PNG images of 12 million pixels, and now we don't allow GIF images of over 12 million pixels either. I suggest we focus on finding ways to better deal with these large GIFs, but honestly, any animated GIF of this size, should probably never be presented to users. (And never have been). —TheDJ (talk • contribs) 19:14, 6 April 2010 (UTC)

I have created a small javascript importScript('User:TheDJ/largeanimatedgifs.js');. This script replaces the error message with a play button. The play button links to the image page and will force the unscaled full version of the animated GIF. (Note that currently there is no filetype check, so it does the same for PNGs). —TheDJ (talk • contribs) 20:38, 6 April 2010 (UTC)

It seems that purging the animated GIF image page directly worked to get a different animated GIF to show up. I don't understand why it is not working in this case. File:Translational motion.gif is only 398 kilobytes at full size. --Timeshifter (talk) 21:07, 6 April 2010 (UTC)

But it is also 370 frames. I wouldn't be surprised if there is a frame limit, as well as a total pixel size limit. I'll try to find out. —TheDJ (talk • contribs) 21:13, 6 April 2010 (UTC)

The earlier version of that animated GIF is still working. See:

http://upload.wikimedia.org/wikipedia/commons/archive/6/6d/20080328033120%21Translational_motion.gif

I wonder what is different in that version. --Timeshifter (talk) 21:22, 6 April 2010 (UTC)

I'm not sure if Purge works for the thumbnails of old file versions.....Interesting effect indeed. —TheDJ (talk • contribs) 21:28, 6 April 2010 (UTC)

I understand you need a cutoff, but I'm curious: does it have to be 12.5 million pixels? Moore's Law considered, I'd wonder if it could be increased periodically, or even as a defined function of time. Though you'd need fully 29,193,000 pixels for the image that is missing here if I calculated right. Wnt (talk) 19:43, 6 April 2010 (UTC)

The animation should be shortened a little. Also, I know that one-half of the frames could be dropped (to a 10 frames/s rate), although the animation would not run as smoothly: thanks to Internet Explorer's and Safari's (and others') incorrect animated GIF handling of delays 50 ms and less, the animation runs twice as fast in Firefox as in the two other browsers. (The delays are exactly 50 ms.) Does anyone know of a GIMP script that could do so? It would be much more convenient than having to manually remove 185 frames individually. Alternatively, we could convert the animation to a Theora video, preserving the 20 frames/s rate and also the length. PleaseStand ^(talk) 20:23, 6 April 2010 (UTC)

I have converted File:Translational motion.gif to Theora video File:Translational motion gif.ogv, and it plays Ok, only wikimedia is now sending a garbled thumbnail. Will this clear in a few days once the current thumbnail backlog clears? -84user (talk) 09:04, 9 April 2010 (UTC)

Oh, and could someone please amend that error message to include a direct wikilink to the image? Thanks. Wnt (talk) 19:54, 6 April 2010 (UTC)

I hav created bugzilla:23071, specifically for this issue. —TheDJ (talk • contribs) 20:41, 6 April 2010 (UTC)

Given that people's browsers have been perfectly capable of downloading the full image and scaling it for display, why can the servers not cope? Why not load, scale and save each frame separately (gifs support this kind of sequential access)? Or even implement a scaling queue to reduce server load, with some kind of "thumbnail not yet completed" for those images that are waiting? OrangeDog (τ • ε) 20:27, 6 April 2010 (UTC)

For the origin of the 12.5 megapixel limit, see http://lists.wikimedia.org/pipermail/wikitech-l/2005-October/019681.html -- I guess it's a tradition by now... -- AnonMoos (talk) 20:46, 6 April 2010 (UTC)

Wow. That's 4.5 years ago. From the Moore's Law article it's unclear to me whether that is two or three doublings of RAM memory storage, but that would mean an equivalent limit today should be 50 million to 100 million pixels. This would allow an animation 1.6 to 3.2 times larger than the one in the example above. Wnt (talk) 20:58, 6 April 2010 (UTC)

My point being there is no need whatsoever to load every frame of the gif into memory in order to scale it. OrangeDog (τ • ε) 20:51, 6 April 2010 (UTC)

Ideas are welcome on bugzilla. And the problem isn't the amount of memory per say (leading to server crashes), in the case of GIFs. If memory servers me right, it was also that these were taking SO long to process, they were keeping up other resize jobs. Remember (1,5 years ago) when you randomly would have it that an image took 5 minutes before a thumbnail was generated after you uploaded it ? You were waiting for an animated GIF. And the big problem with animated GIFS is that they cannot be reliably identified from normal GIFs. So you can't create separate pipelines, because only when you start processing, you will know. Well you could create separate pipelines of course, but it's a lot of design work. —TheDJ (talk • contribs) 21:00, 6 April 2010 (UTC)

I would say waiting 5 minutes once at upload is far better than waiting 5 minutes for every page load, or having broken thumbnails on featured content. I don't want to use bugzilla as you have to reveal your email address as far as I can see. OrangeDog (τ • ε) 21:11, 6 April 2010 (UTC)

I use a throwaway email address at bugzilla for that reason. I check its inbox around once a week. It's on my calendar. I would prefer that bugzilla be part of wikimedia's unified login. That way email addresses would remain private, and I could check a watchlist instead, or get emails at my main email address. --Timeshifter (talk) 21:34, 6 April 2010 (UTC)

Actually, those 5-minute delays at Wikimedia Commons were a truly fearsome deterrent. Fix this problem, but yes, let's not have that again! Wnt (talk) 22:44, 6 April 2010 (UTC)

Last I checked, loading all frames in memory is a requirement of ImageMagick (our preferred image scaler) when you ask it to rescale a whole animated GIF. We could render each frame as a temp file, scale it, and recompose the result, but we don't have such a process set up right now. Dragons flight (talk) 21:01, 6 April 2010 (UTC)

With all due respect, it's not that difficult to knock up a streaming animated gif re-scaler just using libgif of somesuch, and as ImageMagick is open source, you already have a very good starting point. I'd do it myself, but I prefer to leave my programming time at work. OrangeDog (τ • ε) 21:11, 6 April 2010 (UTC)

That is perfectly fine. The programmers of MediaWiki prefer to do their programming in their free time for fun. Each form has its drawbacks apparently. —TheDJ (talk • contribs) 21:15, 6 April 2010 (UTC)

In general we try to avoid approaches that require Mediawiki users to compile custom code as that tends to be unsuitable for some Mediawiki users and environments. Like I said, it can be done with ImageMagick and temp file(s) (it could also be done with PHP GD, or several other ways, but new compiled code should be avoided if possible). One of the problems that makes GIFs more difficult is that the GIF specification doesn't tell people in advance how many frames an image may have. You know there is an additional frame only when you read the file and encounter an additional frame marker. Yes, it is entirely possible to write a streaming process. But we haven't done so and as far as I know none of the scaling tools we support use that approach either. If you want to volunteer to write it, then your contribution would be appreciated. Dragons flight (talk) 21:41, 6 April 2010 (UTC)

I've never bought the whole "can't be done in pure php" excuse, but if it's a concern, I'm sure the ImageMagick community would welcome a few more developers to write a streaming animated gif scaling function for the next release. OrangeDog (τ • ε) 22:01, 6 April 2010 (UTC)

This gif and this featured gif were displaying fine recently. Now, purge or not, they just give error messages. I see from above that "now we don't allow GIF images of over 12 million pixels". Does this mean we have to abandon many of the more sophisticated gifs? If so, it is a serious backward step and a body blow to Wikipedia, at a time when computer resources still rapidly continue to become cheaper. --Epipelagic (talk) 08:05, 7 April 2010 (UTC)

Partial solution

This was discussed last night again on IRC. Current thinking is for the short future, to limit scaling to 12.5MP total, but send clients unscaled animated GIFs between 12.5MP and a higher number (possibly 50MP). If we assume 50MP, then in a worst case scenario, you are asking for 200MB of RAM on the browser side if you have a rather dumb image handling routine in your browser, and 50MB for the smarter ones. Above that value, the error would remain (or just thumb the first frame), because it doesn't seem healthy to send such big files at unsuspecting clients. Actually, even with this there are still problems remaining. Especially on Category pages with lots of animated GIFs, and probably for mobile phones as well. For the longer term a solution with a scaled frame 0 + "play button" is probably the better solution for over 12.5MP, but that requires more work. Note that this is not a promise, nor a commitment, it was just a brainstorm session. —TheDJ (talk • contribs) 13:48, 7 April 2010 (UTC)

We are defining image size as length*width*frames, which tends to die on images with a very large numbers of frames. However, the smart implementation would only require RAM for something of order one frame, i.e. length*width pixels. Hence the memory burden on the browser could be far less than you estimate above (if the scaling algorithm is smart about animations). Dragons flight (talk) 15:22, 7 April 2010 (UTC)

I doubt my Sony Ericsson phone browser is that smart. And Safari 3 and earlier was terrible with larger animated GIFs. In general, it is good to assume the worst, because browsers have behaved like that. And especially if you have 200 of those full sized images in a Category page, safeguards are probably wise. Hell, ImageMagick doesn't even work frame by frame apparently, so if the problem exists there, it is likely to occur in client implementations. —TheDJ (talk • contribs) 17:04, 7 April 2010 (UTC)

Some new code was deployed last night.

1. If an animation is more than 12.5MP total, you get a single frame
2. If an animation is more than 12.5MP per frame, you get the thumberror.

Old thumberrors are cached, so you might have to purge the filepage. (Remember to purge on Commons for Commons files). This is still not optimal of course. —TheDJ (talk • contribs) 14:00, 8 April 2010 (UTC)

Category:Animations of geometry

See commons:Category:Animations of geometry. Why are some of these thumbnails animated and some not? Is it just a matter of time before MediaWiki gets to them? Purging? Purging what? Exactly what are the page URLs and the keys being pressed to purge one of the problem thumbnails? I have had no luck so far.

By the way, I found this comment at bugzilla:22041:

 Andrew Garrett      2010-04-06 04:11:51 UTC

 andrew@fenari:~/php-1.5$ php maintenance/eval.php
 > print $wgMaxAnimatedGifArea
 1

 Seems like the cause.

 I've fixed this.

It is comment number 11. --Timeshifter (talk) 22:04, 6 April 2010 (UTC)

You can expect the servers to take at least several days before caches clear and new animated images are created for everything that the servers can process. Directly purging the file will jump the queue and update it now. Dragons flight (talk) 22:09, 6 April 2010 (UTC)

Please try purging one there to see if it updates now. I am not so sure that it is working that way. For example; try this one:

File:Hyperpyramide-animation.gif

File:Hyperpyramide-animation.gif

I already tried awhile back, and there still is no animated thumbnail of it for me at commons:Category:Animations of geometry even after purging the page. --Timeshifter (talk) 22:21, 6 April 2010 (UTC)

Thumbnail of File:AnimPYRAMIDE2.gif wasn't animating in the category listing, so I purged the image description page and then bypassed my browser cache and now the thumbnail animates properly. Svick (talk) 22:20, 6 April 2010 (UTC)

thumb

I must be doing something wrong. I found this: Wikipedia:Purge#For images. What exactly are you doing? I use Firefox.

I have also studied Wikipedia:Bypass your cache#Mozilla family some more. Still no luck getting an animated thumbnail to show up for this animated GIF on the category page:

File:Hyperpyramide-animation.gif

But a different-size animated thumbnail of that image shows up to the right. --Timeshifter (talk) 23:16, 6 April 2010 (UTC)

For reference, the thumb in question is this one —TheDJ (talk • contribs) 23:34, 6 April 2010 (UTC)

The same situation for me: the thumb didn't animate, so I purged the description page on commons (clicking the “Purge” tab, i.e. http://commons.wikimedia.org/w/index.php?title=File:Hyperpyramide-animation.gif&action=purge), then Ctrl+F5 directly on that thumb and now it animates. Svick (talk) 23:41, 6 April 2010 (UTC)

It is now animated. It must be taking a very long time after purging for MediaWiki to get around to creating new animated thumbnails in some cases. I have been purging and bypassing that image and its category page for a long time now, and the 120-pixel-wide category thumb only now showed up on the category page. --Timeshifter (talk) 23:44, 6 April 2010 (UTC)

Extra-strength purge

From Timeshifter's comments elsewhere, it seems that many might not know about the http://commons.wikimedia.org/w/thumb.php?f=IMAGENAME.gif&w=PIXELWIDTH trick (where "IMAGENAME" is the name of the image, and "PIXELWIDTH" is a number such as 120). It sometimes works to regenerate one specific thumbnail size of an image when ordinary purging doesn't. AnonMoos (talk) 00:33, 7 April 2010 (UTC)

Actually, I was told a while ago by Tim Starling that this should NOT be used, because it stores images on the servers instead of on the scalers, making them unreachable for any future purges (read permanent). The page really shouldn't be publicly accessible at all in the Wikimedia deployment, but no one has gotten around to that. I'm not sure if that is still the case, but this is what I was told. —TheDJ (talk • contribs) 00:37, 7 April 2010 (UTC)

It's kind of a little late now, since knowledge of that has been circulating among people on Wikimedia Commons for at least a year now (if memory serves), unaccompanied by warnings... AnonMoos (talk) 00:43, 7 April 2010 (UTC)

 02:37 < thedj> TimStarling: You once told me that we shouldn't 
  use thumb.php directly. Is that still the case ?
 02:37 < TimStarling> yes

Apparently, it is "inefficient", but not really dangerous. Avoid doing it in general (don't make buttons/menulinks for it) and avoid it on the secure server especially. I'm still not quite sure what problems this creates especially. I know that SVGs might not render properly, because the right software/fonts might not be installed on the thumb.php server for instance. But not sure of the caching implications. —TheDJ (talk • contribs) 01:06, 7 April 2010 (UTC)

Could this be the reason why the category thumbnails for some animated GIFs are not rescaling? I bet many people over the last year have tried that URL with many animated GIFs:

http://commons.wikimedia.org/w/thumb.php?f=IMAGENAME.gif&w=PIXELWIDTH

I tried it today when I first saw it. Did this cause a problem? Is this repairable?

Further work on GIF scaling/resizing by MediaWiki is going on at bugzilla:23063. Some more animated GIF categories to look at are commons:Category:Abstract Animation and commons:Category:Animations of gears and gearboxes. --Timeshifter (talk) 01:07, 7 April 2010 (UTC)

Anyway, it's actually kind of recommended on the Commons FAQ; see commons:Commons:FAQ#Why is the old picture and not the new uploaded picture on my screen? (Or-- my thumbnail is wrong.) -- AnonMoos (talk) 01:50, 7 April 2010 (UTC)

Note, for the regular thumbnail urls the path will contain something like /a/a9/Example.jpg, where “a” is the first hex-digit of the md5 hash of the file-name, and “a9” are the first and second digits of same. You’ll need to know that to make a gadget which thumbnails arbitrary images. ―AoV² 07:22, 19 April 2010 (UTC)

Page purge

I noticed something on this page:

• Incarceration in the United States

That page uses static GIFs. Even after bypassing the browser cache (CTRL-F5 on Firefox) the page was still using browser-resized GIFs instead of MediaWiki-scaled GIFs. See Wikipedia:Bypass your cache.

I tried a WP:null edit (click the edit link at the top and then save the page without making changes to the wikitext) and that fixed the problem. All the static GIFs on that page are now scaled by MediaWiki.

As for animated GIF images and their thumbnails it seems like the scaling is taking days for all those many thumbnails at various sizes. I believe I am seeing a few more animated GIF thumbnails on category pages each day. --Timeshifter (talk) 20:52, 8 April 2010 (UTC)

Documentation

Can someone who knows the exact details update Wikipedia:Images#Consideration of image download size and any other relevant documentation? Thanks. OrangeDog (τ • ε) 11:58, 9 April 2010 (UTC)

Anyone? OrangeDog (τ • ε) 12:02, 15 April 2010 (UTC)

I'll see if I have some time tomorrow —TheDJ (talk • contribs) 23:49, 15 April 2010 (UTC)

Many low-kilobyte, animated GIFs still not thumbnailed

I have been watching, purging, bypassing several animated-GIF category pages now for days, and see no more progress in those categories in the number of GIFs thumbnailed in animated form. A few example categories:

• commons:Category:Animations of geometry
• commons:Category:Abstract Animation
• commons:Category:Animations of gears and gearboxes

Can others try getting some more of the animated GIFs in those categories to thumbnail as animated GIFs? Why is this one thumbnailing:

• File:Gears animation A-B.gif

And this one is not:

• File:Gears animation.gif

Those 2 similar animated GIFs are next to each other in this category:

• commons:Category:Animations of gears and gearboxes

There are many other examples. Multiplying the number of frames times the image kilobytes does not go above the 12.5MP limit mentioned in bugzilla:23063, I believe. So they should thumbnail as animated GIFs, and not single frames? Am I correct? See megapixel. --Timeshifter (talk) 01:58, 12 April 2010 (UTC)

Maybe if people stopped repeatedly purging then the thumbnailers might actually get some work done. OrangeDog (τ • ε) 11:27, 12 April 2010 (UTC)

Maybe, if people actually knew what they were talking about something might get done. I have purged a few specific commons image pages. Others have been left alone. So your theory doesn't seem to hold water. Few additional animated GIF images have been thumbnailed after the first couple days when GIF scaling was turned back on. Purging the category pages shouldn't cause the images to be thumbnailed. It would help pull up newly thumbnailed images though. --Timeshifter (talk) 18:14, 12 April 2010 (UTC)

I'm not saying that every purge re-sets the wait time (unless someone was very silly when they wrote it), I'm just saying that purging more than once isn't really going to help. Sure, the image jumps to the front of the queue, but then so do all the other images that everyone else is purging. Just have some patience and give the servers a few more weeks to deal with the re-scaling of every gif that's been uploaded, then see what things look like. I'd only be worried if that were the only image yet to be re-thumbnailed. As it is, there are lots still to go, and there's nothing anyone can do but wait. OrangeDog (τ • ε) 21:40, 12 April 2010 (UTC)

The first step is to see that there is a problem. I am not sure it is a matter of time. I have written and rewritten many templates, and they don't take this long to propagate throughout all the pages that transclude them. Even multi-layer templates within templates. Almost all the resizing of the animated GIFs happened the first couple days. I believe something else is happening now.

Some animated GIFs are obviously too big when calculating the total kilobytes by multiplying the number of frames times the size of a fully-filled-in frame. That is part of the problem. The MediaWiki GIF resizer does not seem to be using partial frames when scaling. So the thumbnails are oftentimes larger in kilobytes (sometimes much larger) than the original-size animated GIF.

Maybe the calculation of the total kilobytes has bugs depending on the complexity of the GIF. Maybe the purging has bugs. Or the queue. Something is wrong. I am not at all sure what is the correct way to purge an animated GIF on the Commons so that the thumbnails are recreated. Others have written about thumb-errors getting in the way.

From participating in several previous discussions about GIF scaling, I really don't think any MediaWiki developers have much of a handle on animated GIF scaling. See: commons:Commons:Graphics village pump/GIF thread#Some animated GIFs inappropriately shown as still images. And see: http://www.imagemagick.org/Usage/anim_mods/#resize

It seems that the animated-GIF scaling expertise (what there is) is spread among the ImageMagick developers. The MediaWiki developers are trying to integrate ImageMagick scaling of animated GIFs without really understanding it.

User:Greg L seems to be an expert at animated GIFs, but does not seem to be using ImageMagick. At the Commons village pump I discovered that animated-GIF scaling can be very complex with multiple choices to be made. This will take more knowledgeable people than you or I. --Timeshifter (talk) 23:35, 12 April 2010 (UTC)

1. A partial frame is still a frame and the scaling will take them into account as such. ImageMagick decodes an image to a full frame, in full colors with full transparency options (4 bytes per pixel). Then it scales the result. It does this to create the maximum scaling quality. Any other process will result in inferior quality result.
2. It is much easier to optimize a GIF image for a certain size than it is to scale any and all GIF images to any and all size. The process of authoring an efficient GIF animation is not the same as scaling random GIF images.
3. Thumbnails are not normally purged at all. You will have to purge the File description page for images to purge (Commons page for commons images, local page for local images). This goes for any image of any type anywhere in the mediawiki system. After such a purge you will always have to reset your browsercache, because otherwise no new thumbnails are requested by your browser
4. Your condescending nature towards the developers is hurting your cause to address an issue with the developers
5. If you have input, give input. If you know someone who can do better, please let him contact Mediawiki and it's developers and let him deliver a secure, controlled and improved scaler.

—TheDJ (talk • contribs) 23:47, 12 April 2010 (UTC)

And I will add that all your complaining is terribly funny considering you are the one who got this ball rolling again by posting "Any GIF scaling is better than none" —TheDJ (talk • contribs) 23:50, 12 April 2010 (UTC)

I was referring to static GIF images. Maybe try reading what I write more carefully? The problem is that many mediawiki developers and admins can be far more condescending than I can be after I and others have been ignored on this issue for years.

Static GIF image scaling has always worked fine. It was turned off when the problems with animated GIF scaling were noticed long ago. Turning off static GIF scaling is a really bad "solution" to problems with animated GIF scaling.

Purging the file description page on the Commons does not seem to be working for many animated GIFs on the Commons. Bypassing the browser cache afterwards does not help then, nor on the next day. On the category page, nor directly on the thumb image.

The solution is to separate static and animated GIF scaling in my opinion. Because the animated GIF scaling still has problems. I am only trying to point out the problems. Burying the problems does not solve the problems. Attacking the person pointing out the problems does not help either. Admins have been getting out of control lately in my opinion. How does the saying go... [imagined] "power corrupts..."

By the way, I haven't been condescending to the developers since my first comment at the very beginning for which I apologized. I think you should apologize to me. --Timeshifter (talk) 00:19, 13 April 2010 (UTC)

I choose to ignore you instead and am unsubscribing from all GIF related bugtickets and refuse to act in my self appointed role as communication bridge between editors and developers on this particular issue any longer. —TheDJ (talk • contribs) 00:25, 13 April 2010 (UTC)

Timeshifter - a few things. a) nobody cares. b) You are talking about the MediaWiki devs, not the Wikipedia administrators. If you're going to complain (and oh my, yes. Yes you are...) get your facts straight. c) nobody cares. d) You have been condescending in every single point you've made. e) nobody cares. f) if you have a better solution for the problem, get off your ass and fix it. If you don't, shut up. h) oh, and get over it.

In case the above didn't make it perfectly clear, it really bugs me when users who have no idea about the development of the software get angry that the volunteer devs, who donate their spare time to help MediaWiki, don't do what they want because 'omg I have to have it'. You've had this attitude for the entire thread... Seriously. Seriously... Ale_Jrb^talk 00:34, 13 April 2010 (UTC)

(unindent) Actually, I have done a lot of image editing. Low level stuff, but editing nonetheless. Many people care about static GIF editing and scaling, so "get your facts straight." Fewer care about animated GIF editing. The fact that you and DJ don't care about GIFs just fits in with many past discussions with many people besides me being involved. There seems to have been a religion against GIFs long ago that had a semi-rational reason (GIF code was under copyright back then). The religion seems to be continuing nowadays long after GIF code is no longer under copyright. If you don't care, then please don't participate in this discussion. By the way, the main development is done by paid devs. We pay for their work. I have not been condescending since my first remark in this thread, for which I apologized. You and DJ, though, have been very rude. Please stay ontopic. --Timeshifter (talk) 00:52, 13 April 2010 (UTC)

"By the way, the main development is done by paid devs. We pay for their work" This only shows how uninformed you are about how the MediaWiki software and thus Wikipedia is developed. As far as I know only Tim Starling is currently employed to work on the software. He spends his time mostly reviewing, commenting, rewriting, committing and deploying code that volunteers have developed (and he hardly has enough hours in a day to do all that). All other paid developers are contract workers, working on specific issues (usability, flagged revisions, liquid threads) often using money that was donated under conditions that make it impossible to legally use that money for other purposes than the allocated project. Most development work is still to this day done by volunteers. Adding some folks to the payroll is planned for this year I believe, but your comment certainly doesn't do justice to the current situation of Mediawiki development. You might want to do as other volunteers and try to find the money to support a project and get the feature you want fully developed. That is what will be leading to full Tiff support very soon now. —TheDJ (talk • contribs) 02:11, 13 April 2010 (UTC)

My bad then. I knew that Andrew Garrett was paid, and that he was the one who turned GIF scaling back on. Did Brion do any development of MediaWiki? I believe I read that the $2 million donated by Google was an unrestricted donation. Maybe some of that money can go toward further ImageMagick development concerning scaling of both static PNGs and animated GIFs.

Concerning the number of GIF images on the commons see the number pulled up with this:

http://www.google.com/search?q=site:commons.wikimedia.org+inurl%3A.gif

Greg L mentioned something interesting on Andrew Garrett's talk page: "Take the example of the broken animation at the top of this thread. It has 160 frames but is only 398 KB because I used every trick in the book (like 2 bits of custom color data and frame optimization) to encode it."

So I am not sure animated GIF scaling can ever be done consistently well by ImageMagick. Static PNG scaling has similar problems when limited color palettes are used in the original image. The scaled PNG image uses truecolor or better, I believe. I am probably not getting the exact details right, but I believe the point is true about problematic scaling when custom coding is used in the original images.

My main concern has always been the static GIF images though. I discuss the animated GIF images mainly to try to help out. People far more skilled than me will have to work on ImageMagick. --Timeshifter (talk) 03:35, 13 April 2010 (UTC)

Animated gif thumbnails no longer animated

I greatly appreciate the vital yet mostly thankless work of our developers, I rarely find myself here for an actual "problem".

Yesterday I uploaded an animated gif and noticed it was static in the thumbnail yet animated on its file page. Today I happened upon another animated gif stuck on frame 1 and wondered if there is/was a known issue with gifs already being troubleshooted. Arriving here I see there was indeed a discussion about gifs and wondered, did the animated thumbnails get sacrificed so that static gifs will rescale properly?

Since I make animated gifs I just need to know if this is a permanent thing, because if it is I can adjust accordingly. (Thanks again) Anynobody(?) 21:15, 19 April 2010 (UTC)

It is a lot of discussion, so I'll reitirate some of what was said higher up:

• If an animation is more than 12.5MP total (width x height x number of frames), you get a single frame
• If an animation is more than 12.5MP per frame, you get the thumberror.

Note that if an animation requires no thumbnailing (can be shown in it's native resolution), it still works. This explains why your animation can work on a file description page, yet fail when included as a thumbnail. —TheDJ (talk • contribs) 22:13, 19 April 2010 (UTC)

I'm very sorry, didn't mean to give the impression that I'd ignored the above discussion. The somewhat confrontational tone made me choose words too carefully to actually get my point across. Bearing in mind that the last thing I want to do is offend anyone, I'll be blunt. In March the animation in this article Operation Chastise#The bombing raids was animated, now it is not. I noticed an editor brought up concerns about scaling static gifs and the time it takes dial up users to load this category Category:Octave Uzanne. I'm sure he or she had the best interests of the project in mind when voicing these concerns, but it seems like most everyone else either didn't notice the problem or didn't care. (In their original post they plainly said someone turned it off, and the rest of the developers left it turned off for years (except for a few months). I'm wondering if it was turned off to allow gifs like the one I linked above to work as thumbnails, and if so could it be disabled again? Anynobody(?) 22:20, 20 April 2010 (UTC)

No the thumbnailing for GIF images was turned off because the thumb scaling server could not reliable operate on the GIF images. That it took so long to fix and reinstate thumbnailing for GIF images is unrelated to what is the intended behavior that the developers desire. —TheDJ (talk • contribs) 00:14, 22 April 2010 (UTC)

Licensing drop down box when uploading a new version

Is it possible to remove the licensing drop down box that shows up when uploading a new version of a file? It seems kinda pointless to have it there because if someone was to use it, they'd have to go back and remove the old license probably anyway.--Rockfang (talk) 05:12, 18 April 2010 (UTC)

As a matter of practical policy, I′d require the second uploader to choose a different file-name if he or she is unwilling to accept the previous license tag. If I have uploaded something as public domain, yes you legally can make a few changes then restrict the license to cc-2.0-if-by-sea, but I′d prefer you forked it to a different title first. ―AoV² 05:28, 18 April 2010 (UTC)

Are you agreeing that the box should be removed?--Rockfang (talk) 05:33, 18 April 2010 (UTC)

Sorry, I didn′t know this was a vote. I′d go beyond removing the selector menu actually—I′d replace it by the existing license tag with a note saying “please upload to a different title if this license is unacceptable”. ―AoV² 05:58, 18 April 2010 (UTC)

Thank you for clarifying. It isn't actually a vote, I just wanted to make sure I understood what you were saying. And now I do. :) Rockfang (talk) 06:01, 18 April 2010 (UTC)

I saw the reupload dialog now has the licensing selector. I wonder if it changes the licensing or just adds a new one? See also #Image type now checked on upload. ---— Gadget850 (Ed) ^talk 16:06, 18 April 2010 (UTC)

It appears it does neither. In fact, it appears to do absolutely nothing. I uploaded the first version of this file with {{PD-author}}. I then chose a different PD license for the 2nd version I uploaded. The license did not change. This result could be another reason to get rid of that box when uploading a new version of a file.--Rockfang (talk) 21:13, 18 April 2010 (UTC)

• Support Oh, wait, this isn't a vote. Agree with changing/removing it though (maybe say "if you want to relicense it, upload a new version" too).  fetchcomms☛ 22:25, 18 April 2010 (UTC)

I've submitted a bug report for anyone interested.--Rockfang (talk) 09:07, 21 April 2010 (UTC)

And seconds later it was marked as a duplicate of another bug that was submitted 2 days earlier. :) Rockfang (talk) 09:13, 21 April 2010 (UTC)

Sorry for your trouble, I forgot to add the ticket here when I created it. :( —TheDJ (talk • contribs) 12:17, 21 April 2010 (UTC)

Javascript help needed with experiment on image links and alt text

Alt text on Wikipedia is hamstrung by the that fact that nearly all our images serve a purpose in addition to the information they contain: they provide a link to a larger version, to image details and to licence/attribute information. See Wikipedia:Alternative text for images#Blank alt text problem for the consequence. Several suggestions have been made such as default alt text and the creation of a new Wikipedia Skin for screen reader users. Such a skin could eliminate the image links (and the thumbnail icon link too), thereby allowing blank alt text to work as expected: to make a purely decorative image disappear. The Skin could also, with help from accessibility experts, make Wikipedia pages more accessible to screen reader users. (For example, it has been suggested that removing the [] round our inline citation superscripts will cut down the chatter.) However, a new skin is probably a lot of work.

What I'm considering is whether we could experiment with a Javascript addition to users' monobook.js that strips out all the image links to the image description page. Then to ask some screen reader users to see if this is an improvement. An alternative would be to move the links at the bottom of the article, in text like: Description page for file Dannebrog.jpg, in a box that could be skipped by screen reader users. This would satisfy any attribution concerns created by completely removing the image links. If anyone with good Wikipedia Javascript abilities is interested in trying something, could you contact me on my talk page. Thanks, Colin°^Talk 08:08, 18 April 2010 (UTC)

This Javascript could be useful for a few blind power users, such as Graham87. But with a new skin the main issues would remain unchanged.

An accessible Website improves the user experience for everyone, and has a wide number of uses. It's way too long to explain everything in detail, but among the benefits are search engine optimization, easier reuse of the content, and other things that are part of Wikimedia's goals. Such a skin could help a few blind users, but accessibility is much wider than that.

An accessible skin can only solve a few issues among dozens. For example, non-linear content issues, lack of alt text, lack of semantics, and other lack of information will remain. Thus, the accessible skin would be of limited use. And since you have to go trough your preferences to change the skin, the number of users will be low too. Plus, the link to an accessible version of a Website, though often used, is a bad practice. The whole Website itself should be accessible, not a different version of it. Dodoïste (talk) 01:18, 19 April 2010 (UTC)

Fortunately, I have a script which ignores customized image links, so that they always point to the file description page (otherwise I′d be really upset about this). ―AoV² 00:09, 19 April 2010 (UTC)

Let me see if I understand this correctly:

• We′re removing the alt tags for image which we want screen-readers to ignore.
• Then we′re removing the link because some screen-readers choke on a link with no inner text inside it.
• Then (despite having to copy the file-name out of the source code and paste together our own urls to navigate to the image page), we go around telling ourselves the result is more “accessible” than the status ante.

Having any image unclickable is terrible “accessibility” from my perspective. The license status is irrelevant. I′d suggest leaving the thumbnail icon as last-resort access to the image page (though you′d have to make it more prominent as I suspect few people notice it exists), but I see you already want to get rid of that too. Yes, please do make the predescribed changes in a separate skin. ―AoV² 03:23, 19 April 2010 (UTC)

How many readers (let alone listeners) do you suppose ever care about the licensing or FUR details of an image? I'm also pretty sure that there is no requirement to have an "on-line click-able hyper-link" in any of the CC/GFDL licenses, but you'd have to check with User:Mike Godwin. OrangeDog (τ • ε) 11:54, 19 April 2010 (UTC)

The license requirements are not relevant my concerns. ―AoV² 19:04, 19 April 2010 (UTC)

There's a bunch of misunderstandings here. I wanted some help with an experiment, which Dispenser (talk · contribs) has kindly obliged. This isn't a proposal to change Wikipedia. The javascript idea is only a means to test out what the pages looks like (to a screen reader user) if we change such-and-such. I'm well aware it is not a viable solution for anything.

AoV2: most of your "see if I understand this correctly" points are wrong.

Wrt to clickable images: this is a Wikipedia thing. It just isn't done elsewhere unless the image is truly a thumbnail. We put images into our articles for the effect they have on articles when read by people wanting to read an encyclopaedia. These people do not care that the image was copied from such-and-such a site, was taken at F4 on a Canon, or was taken by Joe123 on 4th August 2009. A tiny minority of our readers want to know this. Yet in order to supply this, most of our images have two hyperlinks and screen readers have to suffer the image filename being read twice.

My preferred "for screen readers" version would have the image links in a box at the bottom of the article where it doesn't interrupt the flow and can be skipped. But perhaps this is a user-preference that some may want differently. Note: screen readers don't need the image links for attribute/licence requirements as they don't actually download and display the images. Colin°^Talk 12:11, 19 April 2010 (UTC)

Not all screen reader users are totally blind. Some have partial sight, and either use screen readers in addition to screen magnifiers, or only use screen readers because reading text is too slow for them. I also know of a fully sighted computer user who uses screen readers because he has severe dyslexia. Screen reader users can interrupt their speech synthesizers at any time; personally, when I know that a filename is coming up, I just press down arrow to interrupt the text and move to the next line. Graham87 13:08, 19 April 2010 (UTC)

Thanks for the info, Graham. This sort of good information should probably go on the alt text talk page. This section was really just me asking someone to write some code for an experiment. It got sidetracked into a discussion on things I had no intention of discussing here. Colin°^Talk 13:48, 19 April 2010 (UTC)

OK, I've copied it to Wikipedia talk:Alternative text for images#Screen reader audiences and uses. Graham87 14:02, 19 April 2010 (UTC)

Colin, that’s because most other sites don’t have a dedicated page describing each image in detail. As long as such a page exists, good “accessibility” would imply being able to navigate to it by clicking on the image, or in some obvious place very close to the image, without having to feel like I’m cheating the system.

As a new unrelated feature I would welcome a file list below the editing form, to accompany to the template and category lists. This would save me from needing to preview my edit before I can open the image pages in another tab (to make sure I’m describing them correctly in the article, etc).

I think in the future we should design some way to store all captions and alt-text for an image on the file description page itself and load them that way. Then we could add a standard “nav-bar” interface like we have for the templates which float nearby, with links to “view” the full-size image, “edit” the displayed caption independently of any article, or even “edit” the file itself (well, at least in the case of SVGs). ―AoV² 19:04, 19 April 2010 (UTC)

Neither caption nor alt-text should be stored with the file. The caption is nearly always article-specific; the alt text often so. Wikipedia has conflated the purpose of the image (to inform the reader) with the purpose of the link (to supply more detail/licence/bigger version). This makes it hard to write alt text and impossible to pick blank alt text for decorative images because of the residual purpose of the link (which the screen reader wants to talk about). There's an argument for having the images completely unlinked/unclickable and using the little magnify icon for that task (provided someone fixes the broken blank alt text on that). But that only works for thumbnail images. Other options might be to provide a read-only version of the page without any image links, edit-this-section links, etc, that was free of clutter. That might be a joy to read/hear. A reader interested in editing the article or finding out more about the images could then flip to the full-fat version of the page. Colin°^Talk 10:33, 21 April 2010 (UTC)

"Try Beta" description gives no real information on the consequences of the two options

The link on all the pages inviting me to "Try Beta" is very disconcerting. The text at the "Try Beta" page simply says "The Wikipedia Usability Initiative has been working hard to improve the usability of Wikipedia. Would you like to try our Beta?" and two buttons "Let's do it" and "No thank you". But what happens if I click "Let's do it"? Will there be an option to turn it off later if I can't use it or don't like it? What happens if I click "No thank you"? Will I now lose the ability to ever try beta again? Does it need JS to work? Do I have to enable images to use it? The two buttons seem to be very dangerous, and offer no explanation about the possible consequences of clicking on either button.

Maybe someone can consider adding a short description to explain the consequences of each possible action "Let's do it" and "No thank you". Is there a way out if I mistakenly click one of the buttons. And also to say if it needs some special browser settings like images turned on, or JS enabled, or something. HumphreyW (talk) 14:19, 19 April 2010 (UTC)

Well the silence is telling. Perhaps no one knows what the two buttons really do and thus no answers? I guess the "Try Beta" thing is not very successful then, since no one in control of the page has bothered to explain what it actually does or what it needs. HumphreyW (talk) 01:50, 20 April 2010 (UTC)

What exactly were you looking for here? You didn't say that you wanted a reply here as to what the beta is. To answer your questions:

Will there be an option to turn it off later

Yes.

What happens if I click "No thank you"?

Nothing.

Will I now lose the ability to ever try beta again?

No.

Does it need JS to work?

Technically no, but you won't be able to use most of the new features without it.

Do I have to enable images to use it?

No, it won't look much worse than the current interface does with images off.

The page lists the improvements that the Beta interface makes and gives a link to a site where you can learn more. The people "in control" of the page do have things to do other than check the village pump for questions every few hours, please assume good faith. Mr.Z-man 02:27, 20 April 2010 (UTC)

I think the silence was telling the story "The link and buttons have been there for 6 months, and the month before they will disappear, you bring this up?" —TheDJ (talk • contribs) 09:32, 20 April 2010 (UTC)

Thanks to Mr.Z-man for answering my questions.

TheDJ: Okay, I never realised this was an old thing. I only just noticed the link up there recently. HumphreyW (talk) 10:20, 20 April 2010 (UTC)

If you find yourself clicking this by accident (as I did), you can use:

#pt-optin-try { display:none; }

in your monobook.css. ―AoV² 00:25, 22 April 2010 (UTC)

Toolbars and Wiki markup

I have a question for you, let me explain first. It's about user preferences and toolbars. In my preferences under the "Editing" tab I keep the box checked at " Show edit toolbar (requires JavaScript)" which shows this Edit Toolbar #1 at the top of the edit window. I like this tool bar and use it frequently. On an Edit page, below the edit window there's a "Drop down window" which at default shows "Insert" (The only screenshot I could find) Wiki Markup Symbols #2. Now the problem, and in this senario let's assume at my user preference the edit toolbar is checked and saved, and I had the drop down window set to Wiki markup when I logged off. Now when I sign back in obviously the edit toolbar in user preferences is still checked and saved. But now the "drop down window" resets to "Insert". Now I can go to user preferences and un-check the edit tool bar and save the settings, then go to a page click the edit tab as if I were going to edit the page and at this the drop down window is still at "Insert" I can go to this window and select "Wiki markup" and the section of symbols appear, which include Wiki markup: {{}} {{{}}} | [] [[]] [[Category:]] #REDIRECT [[]]  

. And a number of very useful and time saving unseen brackets and commands. Now I can go to user preferences re-check the edit toolbar and save my preferences and now I can edit and do whatever, all day with Both the edit toolbar at the top of the edit window and the Wiki markup symbols. Once I log out and sign back in. I'm back to square one, if I want to have both available, I need to do the whole process all over again. So, is it my Computer or it's settings, is it my OS (XP Home), is it internet explorer, is there a .js script that will adjust these settings at each login ? Mlpearc MESSAGE 03:54, 20 April 2010 (UTC)

If I understand correctly, and there's a good chance that I don't, you're unable to access the symbol drop-down menu when the edit toolbar is enabled (which you're saying becomes a problem when logging off and on, since your drop-down choice isn't saved between sessions). That doesn't sound like the intended behavior. I don't have the edit toolbar enabled right now, but I did for years, and I'm pretty sure I had access to the symbol drop-down menu at all times (at least, once it was implemented). There could be a browser/javascript issue on your system. If I've misinterpreted what you said, please correct me; and either way, let us know which browser and operating system (including version numbers) you're using. Equazcion ^(talk) 04:48, 20 Apr 2010 (UTC)

• I can acess both bar and markup after alittle juggling each sesion but I have to do the juggle act each time I sign in. I use IE8 and XP home Mlpearc MESSAGE 17:36, 20 April 2010 (UTC)
  • It's probably IE which is tripping. Javascript soln: You can set the onchange event handler of the dropdown to save the choice in a cookie, and add an onload hook to read the cookie and set the shown choice accordingly. ManishEarth^{Talk • Stalk} 20:04, 20 April 2010 (UTC)

The list of symbols is called edittools. You normally would use MediaWiki:Edittools.js, but if there is a JS problem it falls back to MediaWiki:Edittools. You can bring this up on the talk page. ---— Gadget850 (Ed) ^talk 20:22, 20 April 2010 (UTC)

I understand what you are saying Manishearth, but I don't have the knowledge to write the onload hook, and Gadget850 I took a look at MediaWiki:Edittools, but again I have no idea which part(s) to paste to my monobook.js page. If you think adding this script might help, could you give me a start and end point of the script to grab ? Thanks to both of you for your time and input. Mlpearc MESSAGE 22:01, 20 April 2010 (UTC)

I would've written the script in its entirety, but I don't have the time. If you're js-savvy, I'll give you a skeleton if you want later. ManishEarth^{Talk • Stalk} 23:30, 20 April 2010 (UTC)

I will take your skeleton and learn how to adapt it, Thank you very much. You can post it here skeleton. Mlpearc MESSAGE 05:03, 21 April 2010 (UTC)

Actually, by examining the onchange handler of the dropdown, I see that it already uses cookies. The value is stored in a cookie called "edittoolscharsubset". Does your browser delete all cookies on restart? (To check, login with remember me enabled, close the browser without logging off. Then reopen the browser. If remember me worked, then its not a cookie problem). ManishEarth^{Talk • Stalk} 14:01, 21 April 2010 (UTC)

Your right. I even went to my IE tool box and un-clicked "clear cookies at shutdown". Did a complete re-start of my laptop (without logging out of Wiki) and came back, the "remember me" worked I still have both the edit toolbar and Wiki markup, which is ok but I think this will not work as move back and forth from laptop to desktop. But then you always thaat one word poping up we all have to deal with "Compromise". Well If you ever hear of a "trick" or come up with one I will always interested. Thanks for your time and input, Guessbook Mlpearc MESSAGE 14:36, 21 April 2010 (UTC)

Consider where your browser stores its cookies. If you roam between platforms regularly, it might be worth setting your browsers to use a roaming profile, either on a server or (safer) on a portable storage device like a USB key. User:LeadSongDog come howl 14:59, 21 April 2010 (UTC)

Moving back and forth from different computers won't work, as cookies are local. You could modify the handler to use AJAX and save your preferred selection, but I think that its going a bit 2 far. I'm very bad at AJAX so I wouldn't know how to do it. If you want, here's the existing event handler. Note that it does use cookies.

//This is an exact copy of the function availible in the existing Mediawiki framework.
//It is probably dynamically created in a method, so it's not accessible (typing "javascript:selectSubset()" in the location bar/js console doesn't do anything)
function selectSubset()
     {
	//remember previous (for "recall" button)
	prevSubset = curSubset;
	curSubset = sel.selectedIndex;
        //save into cookies for persistence
        try {
           var expires = new Date ();
           expires.setTime( expires.getTime() + 30 * 24 * 60 * 60 * 1000 );  // + 30 days
           document.cookie = EditTools.cookieName + "=" + curSubset + ";path=/;expires=" + expires.toUTCString();
        } catch (err) { /* ignore */ }
	//hide other subsets
	var pp = box.getElementsByTagName('p') ;
	for (var i=0; i<pp.length; i++)
	   pp[i].style.display = 'none';
	//show/create current subset
	var id = sel.options[curSubset].value;
	var p = document.getElementById(id);
	if (!p){
	   p = document.createElement('p');
	   p.id = id;
	   if (id == 'Arabic' || id == 'Hebrew'){ p.style.fontSize = '120%'; p.dir = 'rtl'; }
	   EditTools.createTokens(p, EditTools.charinsert[id]);
	   box.appendChild(p);
	}
	p.style.display = 'inline';
     }

ManishEarth^{Talk • Stalk} 16:20, 21 April 2010 (UTC)

Buggy

When I click on changes, it doesn't take me to the last message. This may be a bug. This needs to be posted on bugzilla.174.3.123.220 (talk) 16:47, 21 April 2010 (UTC)

 Works for me Gary King (talk) 00:38, 22 April 2010 (UTC)

Article generation times

This has been brought up before but I wanted to throw it out again. United States is well known for taking ages to generate. Not download; generate, or whatever Wikipedia does. I click the link and it takes ~20 seconds for the article to even begin downloading to me.

But tonight I found out something very interesting. When not logged in, the article begins downloading instantly. I was amazed at this. I then logged back in, and it resumed taking ~20 seconds. This surprised me; what is it about being logged in that causes this article to generate so much more slowly? --Golbez (talk) 06:06, 16 April 2010 (UTC)

User preferences; MediaWiki caches previous renderings to save time when serving the same copy. If you have different preferences (image size, date setting, stub link formatting) MediaWiki will have to render a different copy. Also, since there are a lot more anonymous users than users with your particular preference configuration, it's more likely there will be a cached copy to serve up. — Dispenser 07:28, 16 April 2010 (UTC)

In addition to what Dispenser said, if you're not logged in, then the site doesn't need to load any of the personalizations either like user scripts or the personal toolbar (user page/watchlist/preferences/etc), so it can store the fully rendered HTML and serve that directly, making it about as fast as loading a static HTML page. Mr.Z-man 13:58, 16 April 2010 (UTC)

I have no scripts (and why would user javascript affect server-side generation? Client-side display, yes, but that's after it's downloaded. This is 20 seconds before it even starts downloading). I know it's a combination of factors, but I'd like to know if this occurs with a brand new account with default settings. I really don't want to wipe my personal settings, nor do I want to create a throwaway account just to test this, but do you know if such an account would be able to load United States instantly? If not, then there still is a problem that needs mitigating. --Golbez (talk) 14:34, 16 April 2010 (UTC)

This happens whenever something is not cached. That means when you are logged in, after each edit of a page, this will happen for each combination of usersettings (or when a page hasn't been accessed with that combination of settings for a while, where while depends on the amount of RAM memory of the serverpark). The time of a page to re-parse is dependent on the complexity of the page. That means it's length, the templates that it uses and amount of parserfunctions that it uses. For simple pages this a milliseconds, for complex pages it can be up to 20 or more seconds. It is expected behavior for editors. —TheDJ (talk • contribs) 14:59, 16 April 2010 (UTC)

Even if you don't have any scripts, the software still needs to check for them, and if you do, it needs to include it in the <head> element. If you're logged out, it doesn't need to check, so it can use the fully cached version and doesn't need to do any generation at all (if there's a cached version). For logged-in users, the rendered wikitext can be cached for each combination of preferences that affect the output, but the software still needs to add the skin elements. For logged-out users, the full HTML including the skin can be cached, and there's only possible version (since logged-out users have no preferences). But the majority of the generation time is spent parsing the wikitext (which can take 1-60+ seconds depending on complexity/size of the article and server load) if there's no cached version. If there is one, then the amount of time it takes is mostly independent of the size/complexity of the article (and it should only take a second or 2 in that case). Mr.Z-man 15:40, 16 April 2010 (UTC)

In principle, if you kept all parser-related settings default, you would get much quicker display in most cases on large pages, yes. It still won't be as fast as if you're logged out, because of personalization, but a large page should begin to display about as quickly as a small page (although it will still take longer to fully load).

It would be interesting to document which settings should be left at default to ensure pages load at the same speed. Or better yet, to move as much of the variation as possible into a post-processor of some kind, which would allow most or all settings to be respected without a full reparse, just a simple one-pass substitution on the cached text. But the latter sounds like more work. —Aryeh Gregor (talk • contribs) 16:45, 16 April 2010 (UTC)

This is interesting and very useful info. Maybe some info can be put in the "my preferences" intro page about this. Also, maybe indicate which preference changes cause the most time delays in page loading. --Timeshifter (talk) 00:59, 17 April 2010 (UTC)

I so happen to have a test account, so I played around with the settings to see what was fastest. United States is indeed notorious for being ridiculously slow to load; the 30 seconds estimate is accurate for me, too. What I discovered was that if you go to Preferences -> Appearance -> Math -> HTML if very simple or else PNG (select this), then pages load ridiculously faster. Long pages, including all country articles (which are typically quite long), are generated in under a second. I had this "Math" setting selected to "Recommended for modern browsers" for as long as I could remember (seemed like the most logical option to choose at the time), but I will definitely sacrifice this setting in exchange for much faster load times. Please report back if you have tried this. Gary King (talk) 02:14, 17 April 2010 (UTC)

Maybe it would be worth it not having versions of the article for different <math> settings in the cache, when the article (nor included templates) doesn't contain any such tags. I think most articles don't have any <math> tags and this would speed up loading of articles for those who changed their <math> setting. Svick (talk) 10:50, 17 April 2010 (UTC)

The sets of preferences become hash values. So the parser doesn't know which settings you have selected, just that you have a different combination than other users. also, at this moment, it wouldn't know a page had a math tag, until after parsing... such info is not retained. To change this would probably be rather difficult. —TheDJ (talk • contribs) 14:21, 17 April 2010 (UTC)

Some pages are still loading slowly for me. The only non-default setting I have is my timezone. Am I correct in assuming that the only place this is used in articles is in the footer for the "Last Modified" date? Kind of silly to skip the cache in favor of getting that date corrected to local time. Gary King (talk) 01:13, 18 April 2010 (UTC)

Your timezone will not affect parsing, I'm pretty sure. Some pages can be expected to load slowly regardless, for a variety of reasons, even if all your settings are default. —Aryeh Gregor (talk • contribs) 18:05, 18 April 2010 (UTC)

Various improvements in this vein could be made, yes, in principle. I don't know how many users are seeing parser cache misses solely because of their math preferences, though. —Aryeh Gregor (talk • contribs) 18:05, 18 April 2010 (UTC)

While we're on the subject, why does it take long to get to the Edit page of some pages? Even they are really short (e.g. contain two WikiProject banners). Gary King (talk) 22:05, 18 April 2010 (UTC)

Click default settings link in My Preferences to solve problem

It took 30 seconds to load United States in my browser. So I went to My Preferences and clicked the link at the bottom of the page called "Restore all default settings."

Now all pages load almost instantly. I have been living with slow article generation times for various articles for a long time. I always just blamed Wikipedia overload.

This needs to be noted in My Preferences. Where do I go to suggest this? Who can add this info to the My Preferences introduction?

Here are some country categories to find more long country articles to test:

• Category:Northern American countries
• Category:Countries bordering the Pacific Ocean
• Category:G20 nations

I put back my custom timestamp-signature via My Preferences. It does not increase article load times. It makes sense since it is a simple change that does not effect articles. --Timeshifter (talk) 01:53, 20 April 2010 (UTC)

Yes, only a few specific settings will affect page load times. Your signature won't. Most things that affect how the actual text of articles is rendered will affect page load times, depending on how they're implemented, but things that only affect editing or the user interface usually will not. Try it and see, I guess. —Aryeh Gregor (talk • contribs) 17:33, 20 April 2010 (UTC)

It must be discouraging to many editors to think that a slow Wikipedia is normal. I noticed on default settings that looking at diffs pulled up the whole article below it. This can really slow down checking a watchlist for changes when there are multiple edits to articles that one wants to check out individually.

That can be remedied at "My Preferences" on the Miscellaneous tab by checking the box for "Do not show page content below diffs". I had set that long ago, and forgotten what a help it is until I went back to default settings overall. This change did not slow down article loading, of course, since it only changes diff stuff. We need a page called Wikipedia:Speeding up article loading. --Timeshifter (talk) 04:02, 24 April 2010 (UTC)

Image type now checked on upload (continued)

This is a followup related to Wikipedia:Village_pump_(technical)/Archive_74#Image_type_now_checked_on_upload. I have asked Tim regarding this problem and he considers this new behavior the fixing of a terrible bug that should never have existed in the first place bugzilla:23255. The new behavior will be:

• You cannot move an image to a file extension that does not match its type.
• You cannot upload an image of one type of top of a different file extension.

This means that for any future file format changes we will lose the file history, so it should be added by hand.

So what to do now with all the mismatched and non-supported items we have ? This is my proposal.

• Clear out the remainder of Category:Wikipedia files requiring renaming (manual)
  • Convert GIF files with .png extension to PNGs (unless they are animated of course)
  • Convert BMP files with .png extension to PNGs and upload over the old version (this still does work)
  • Convert BMP files with .jpg extensions that really are better off as jpgs to JPGs and upload over the old version
• Move all other BMP files to .bmp targets
• Convert .bmp files to png and reupload to new targets using a bot (alla PNG crusade bot conversion of GIFs)
• Delete the .bmp files
• I have created {{Unsupported media requiring review}} to tag images that are not one of our permitted file types: png, gif, jpg, jpeg, xcf, pdf, mid, ogg, ogv, svg, djvu, oga

Anyone got better ideas ? —TheDJ (talk • contribs) 14:45, 21 April 2010 (UTC)

In general, how do we handle attribution history for non-free orphaned images that have a non-trivial history (for example, user-created derivative works)? Or for orphaned free images from which other images have been derived? — Carl (CBM · talk) 15:07, 21 April 2010 (UTC)

Item 1(a) of the above proposal will not work for animated GIFs: 3 of the Big 5 web browsers (IE, Safari, Chrome) do not support APNG. Those files will have to be renamed. Item 1(c) requires human judgment to determine whether a file should be made a JPEG or not, and we should not replace a file's lossless format with a lossy format. Item 3 should be undertaken, ideally renaming then uploading the PNG in place to avoid issues with maintaining file history. That would require a way to override the file extension check when moving, perhaps triggered by the bot flag or some sysop-only flag. PleaseStand ^(talk) 23:07, 21 April 2010 (UTC)

All points in 1 are manual work, marked as such. Animated GIFs are not likely in the pool of images. Moving with preservation of history bypassing file extension checks will not be something that will be implemented any time soon.—TheDJ (talk • contribs) 23:16, 21 April 2010 (UTC)

To preserve history, would it be possible and desirable to upload the new format file with its appropriate file extension then redirect the former file to the new one? Eg for example.gif: #REDIRECT [[File:example.png]] Can you redirect in the file namespace? — Richardguk (talk) 23:45, 21 April 2010 (UTC)

This is possible, sounds like a good idea. —TheDJ (talk • contribs) 23:49, 21 April 2010 (UTC)

Redirects do work in the file namespace— a redirect is created on a move unless it is suppressed, which is why moving to a new extension worked so nicely. One issue is that such redirects tend to get deleted if nothing links to them. ---— Gadget850 (Ed) ^talk 16:32, 22 April 2010 (UTC)

Why couldn't we take care of edit history the same way that Commons does, by including in the image description the complete log from the original image? Nyttend (talk) 00:55, 24 April 2010 (UTC)

Well that would be the idea, but it is something considerably different than keeping the actual file history (in the database, as opposed to in text). —TheDJ (talk • contribs) 02:41, 24 April 2010 (UTC)

WP:AFC pathway is broken for IP editors

While surfing as an IP I noticed there's no longer a link via hitting the "Go" or "Search" buttons which takes IP editors to WP:AfC for a non-existent article. Log out and [see for yourselves.

Are we really expecting anon editors to type in the URL of the article they want to create manually in order to stumble upon the Article Creation Wizard? -- Kendrick7^talk 22:41, 21 April 2010 (UTC)

This already came up a couple of days ago, but i forgot to follow up on it. I agree that this is a bad thing, and have added a comment to bugzilla:20976 regarding this specific problem. Resolving this problem in the software will take some time I fear. Does anyone think we should take Javascript action here ? —TheDJ (talk • contribs) 23:33, 21 April 2010 (UTC)

Thanks, although I can't imagine it would take long to simply revert the change that broke this. I could swear this was OK a month ago, or less. -- Kendrick7^talk 02:31, 22 April 2010 (UTC)

Surely one of the interface messages can be edited to achieve this? What produces the "There were no results matching the query." message? — Martin (MSGJ · talk) 11:08, 22 April 2010 (UTC)

MediaWiki:Search-nonefound. Do you know a trick to present something only to anon users ? —TheDJ (talk • contribs) 11:44, 22 April 2010 (UTC)

We can just link to WP:WIZARD. There is no separate article wizard for AfC anymore. — Martin (MSGJ · talk) 11:46, 22 April 2010 (UTC)

I'm a little mystified how it is that the powers that be are distinguishing between IP's and logged in users somehow by accident to begin with. But be that as it may, please implement your solution, gentleman, forthwith! Moving new users down the path of creating articles and even perhaps registering an account at some point is the very lifeblood of this project!!! -- Kendrick7^talk 03:40, 23 April 2010 (UTC)

They don't actually, they distinguish between users who are allowed to create pages and those that are not allowed to create pages. For the english wikipedia, the latter is the case for users that are not autoconfirmed. —TheDJ (talk • contribs) 11:15, 23 April 2010 (UTC)

Hey, I was expecting a cat picture to go with that edit summary, and you disappointed me. :( Tisane (talk) 03:48, 23 April 2010 (UTC)

I still don't have a method of targetting anon users. Anyone ? —TheDJ (talk • contribs) 11:13, 23 April 2010 (UTC)

David Gothberg had a possible solution but he didn't divulge the details. See User talk:Davidgothberg#Auto-detection of user status. — Martin (MSGJ · talk) 11:37, 23 April 2010 (UTC)

(e/c) Because the existing messages only show in case of either "article exists || you can create article". Or do you suggest to deprecate MediaWiki:searchmenu-new in favor of MediaWiki:Search-nonefound ? That doesn't work, because the "noexists" is not mutual exclusive with "nonefound". —TheDJ (talk • contribs) 11:54, 23 April 2010 (UTC)

AWB

Can not re-install AWB after notified of update. Get error message( Could not find file 'C:\Docume~1\My personal name\LOCALS~1\Temp\$AWB$Updater$Temp$\AWBUpdater.exe'. ). Please help. Mlpearc MESSAGE 16:26, 22 April 2010 (UTC)

It's a bug. Sourceforge didn't seem to have the new code, but you can download and install it from toolserver. —Ost (talk) 20:17, 22 April 2010 (UTC)

• Thank you Mlpearc MESSAGE 21:38, 22 April 2010 (UTC)

You can also copy across AWBUpdater.exe yourself from the ZIP in your main installation directory to the directory given in the error message (well, that's what I did, anyway), but yes, it's a bug. - Jarry1250 ^{[Humorous? Discuss.]} 21:41, 22 April 2010 (UTC)

Hey thanks, I'll keep that in mind for next time. In fact going to copy / paste to my talk (my archive is a lot smaller) Thanks Guys Happy Editing Mlpearc MESSAGE 22:24, 22 April 2010 (UTC)

Invalid HTML in Episode list template

{{Episode list}} produces invalid in HTML in some cases; please see Episode list#Invalid HTML. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:23, 23 April 2010 (UTC)

First And Last Edit On What links here

Similar to clicking on user contributions and clicking on earliest and latest, this feature should be made for What links here. Post on bugzilla.174.3.123.220 (talk) 05:24, 24 April 2010 (UTC)

Attempted Cross-site scripting? pc-look.com

I first posted this over at WP:ELN and was forwarded here. Perhaps, it's no big deal.

I'm a little concerned about what the user was attempting to do with this edit. It appears to be an attempt to inject javascript into the page. Perhaps even an attempt at Cross-site scripting? I'm sure Wikipedia is safe, but I wanted others to be aware of this. The user has been blocked for now, but he could easily come back with a different IP.

Justin W Smith ^talk/_stalk 06:42, 24 April 2010 (UTC)

If you're really paranoid about these things, you can install NoScript. MER-C 08:35, 24 April 2010 (UTC)

Indeed. MediaWiki will protect you from this. Still this is clearly inappropriate behavior and people who attempt to do this should be indef banned. —TheDJ (talk • contribs) 12:45, 24 April 2010 (UTC)

Sub-page test

Would some kind soul give me Javascript for testing if the current page is a sub-page. That is, I want to be able to distinguish User:Spinningspark and User:Spinningspark/Sandbox for instance. SpinningSpark 09:06, 24 April 2010 (UTC)

Just look for slashes in the title:

wgTitle.indexOf('/')>=0

Technically incorrect in Article, Category, MediaWiki, an File spaces, so you might want to test wgNamespaceNumber, too. Amalthea 09:20, 24 April 2010 (UTC)

Thanks muchly. I was already testing for namespace number, it was the sub-page bit I did not know how to do. SpinningSpark 09:43, 24 April 2010 (UTC)

Does the "Userpace draft" template include NOINDEXing?

I thought the {{Userspace draft}} template prevented a page from being indexed by search engines, but this Google search" for "Hoodywood Records" turns up this user page (seventh item down). JohnCD (talk) 13:33, 24 April 2010 (UTC)

It does. But the page in question existed for a week before the tag was added. Rd232 ^talk 13:51, 24 April 2010 (UTC)

Ah. Thanks. JohnCD (talk) 15:00, 24 April 2010 (UTC)

Skin usage statistics

Are there any statistics available on Wikipedia-Skin usage? I couldn't find anything in a few test searches, but might not be using the right keywords...

(I'm asking partially in regards to this question at VPR, but also out of general interest, and also wondering how hard we should be working to fix bugs and defects in the lesser-used skins). Thanks. -- Quiddity (talk) 19:26, 24 April 2010 (UTC)

Currently the user_properties table is not exposed on the toolsever; I've asked for it to be. I don't think there're any recent accurate stats. Happy‑melon 21:23, 24 April 2010 (UTC)

Claiming edits

My phone keeps logging me off, so I have a sprinkling of IP edits like this one. Is there a way to claim these and replace the IP with my username? Stephen B Streater (talk) 14:57, 19 April 2010 (UTC)

Unfortunately, that is not possible. You could add a note to the User/talk page of the IP address perhaps that those edits are related to your account. —TheDJ (talk • contribs) 15:03, 19 April 2010 (UTC)

Thanks - I thought as much. It's only fair to do this is the edit is controversial, but it is just clutter if it is a minor fix. Stephen B Streater (talk) 15:39, 19 April 2010 (UTC)

It used to be possible, but it was too much work for a very small number of people, so the service was suspended. An idea for an extension to reattribute edits is at bug 2858, but that doesn't seem like it's going anywhere either. Graham87 01:34, 20 April 2010 (UTC)

Thanks. The self-rename option didn't look like any work at all for the developers. And if the IPs must match, it will almost always prevent theft of random IP's edits. Stephen B Streater (talk) 19:36, 20 April 2010 (UTC)

And if there is a concern of those on the same IP address claiming each other's edits, that can be addressed by setting a 1-hour cookie that can also be used for the purpose of vandalism warnings. There is also the possibility of integrating the account login/creation process with the edit form. If editors have a chance to log in after clicking the Save page button, that would definitely stop editing while logged out. PleaseStand ^(talk) 23:53, 20 April 2010 (UTC)

I don’t know a thing about cell-phone editing but I know in a normal browser you could prevent this using a greasemonkey script, something like:

f = document.getElementById("editform");
if(f) f.innerHTML += '\n<input name="assert" value="user" />';

Then the server will reject any edit (and any attempt to preview an edit) not coming from a registered “user”. The same thing would work on a limited scale as part of one’s monobook.js or whatever—that is, only if you are logged-in when the editform first loads. ―AoV² 00:21, 22 April 2010 (UTC)

I have linked to this post from WP:VPR#Ability to edit edit summary and am adding this line to prevent premature archiving. PleaseStand ^(talk) 20:02, 25 April 2010 (UTC)

Wikipedia Logo Obscures Text

The Wikipedia logo is misplaced on my Wikipedia pages (IE 8). It is not aligned with the navigation links column and therefore obscures the text on each page. There is a "Done, but with errors on page" warning in the lower left-hand corner that states as follows:

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; InfoPath.2) Timestamp: Sun, 25 Apr 2010 00:42:17 UTC Message: Not implemented Line: 53 Char: 5 Code: 0 URI: http://bits.wikimedia.org/skins-1.5/common/IEFixes.js

I have checked the "disable script debugging" boxes in my Internet Options/Advanced page to no avail. I have no idea as to the significance of the IEFixes.js file, or how to install this. Would anyone be able to share any assistance on fixing this problem? Thank you very much.  — [Unsigned comment added by Steph333 (talk • contribs) 00:52, 25 April 2010 (UTC).]

It should be enough to use "compatibility view", by clicking the icon next to the address bar that looks like a broken page. Someguy1221 (talk) 01:30, 25 April 2010 (UTC)

Finally some solid info on this problem. Thank you Steph. This is bugzilla:23171. I suspect this happens when you are in compatibility view. The page might enter quirksmode in that case I suspect, triggering code that normally should only be used on IE 5.5 and IE 6. Will try to verify this tomorrow. —TheDJ (talk • contribs) 20:10, 25 April 2010 (UTC)

Links to deleted images use to have links to deletion logs from Wikipedia and Commons?

Up until a week or two ago, whenever I clicked on a deleted image link (i.e. a red link that links to the "File" namespace), it would lead me to WP:UPLOAD as it does now, but below the page's title, there would also be links to deletion logs for the image, on both Wikipedia and the Commons. These links are now gone. Why are they now gone? Gary King (talk) 06:32, 25 April 2010 (UTC)

See bugzilla:23140 —TheDJ (talk • contribs) 20:13, 25 April 2010 (UTC)

“float: right;” farther right

Observed blue quote window about halfway down http://wiki.riteme.site/wiki/Space_Shuttle_Challenger_disaster and formatted (apparently I can’t show you the formatting because it yields the actual quote-box, seen next)

“Scob fought for any and every edge to survive. He flew that ship without wings all the way down....they were alive”

— Robert Overmyer, NASA Lead Investigator

doesn’t line up at the right margin in Firefox Mac, the way the images above and below it, do.

Should it? I think so.

I’m new to this stuff, and Spike Wilbury, who welcomed me and whom I consider sort of a mentor, suggested technical queries of this nature might be directed here.

If you agree the blue box should be “right-margined,” would you please show me how to fix it? I’ve learned how to unbunch images, but this seems like a different task.

Once I’ve learned how, do I have permission to do similar realignments if I see they’re needed, in other articles, or do I need case-by-case permission?

Thanks. Jimeffindandy (talk) 18:34, 25 April 2010 (UTC)

I reformatted it using the {{quote box}} template, and now it is aligned correctly. Svick (talk) 18:59, 25 April 2010 (UTC)

What a mess!

That's where my village pump post got archived: Wikipedia:Village pump (proposals)/Archive 59/Archives/ 48#Effectively warning school IPs. An archive of an archive! Can this be fixed? PleaseStand ^(talk) 23:47, 20 April 2010 (UTC)

Fixed. Problematic diff (warning, it is a big diff). The archive page was set to archive itself. Gary King (talk) 01:03, 21 April 2010 (UTC)

Now the other question is where did the replies to that initial post go, not in either archive page? I recall that there were two before the post was archived. PleaseStand ^(talk) 11:12, 21 April 2010 (UTC)

I also notice that the archive of the PWD debate is incomplete; compare Wikipedia:Village_pump_(proposals)/Archive_59#Pure_wiki_deletion.2C_redux to http://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_%28proposals%29&oldid=353349539#Pure_wiki_deletion.2C_redux . Shall I restore it manually? Tisane (talk) 19:45, 21 April 2010 (UTC)

There are two bots that archive discussions from VPP, hereafter referred to as "this page": MiszaBot II and ClueBot III. It's clear that ClueBot III was malfunctioning. ClueBot III performed a copy and paste of all posts on the Village Pump rather than a proper archive (warning, big diff). That included "Effectively warning school IPs". One hour later, the same bot went to this page and removed three posts, but not the discussions that it archived one hour before. Subsequently, there were three replies ([10][11][12]) to the post on this page that were therefore not in the archive. I made one last post. ClueBot finally properly archived the post I describe, and it added it to the archive. ClueBot III subsequently edited while logged out, archiving to an archive of the archive. This corresponds to this diff of the sub-archive. The complete archive is actually at WP:Village pump (proposals)/Archive 60 after Gary King removed the archival settings from the archive and ClueBot he unarchived the discussions. To have an additional, incomplete archive can mislead editors researching old discussions. What happened with ClueBot III and can this resulting damage be fixed? PleaseStand ^(talk) 21:12, 25 April 2010 (UTC)

Furthermore, I found that threads on that page were duplicated. I have removed the duplicates. Let me know if I have made an error, or if there are more archives for me to fix. I still have to remove the threads that are in Archive 60. PleaseStand ^(talk) 22:09, 26 April 2010 (UTC)

Fixed (changes made, big diff). Erring on the side of caution, I have left a link to the other archive in place of the twelve discussions I removed. I have also corrected the description above of what happened. PleaseStand ^(talk) 23:03, 26 April 2010 (UTC)

Removing spaces within numbers

Hi, is there a template or parser function that can strip spaces from within numbers? For example convert "12 345" into "12345", and "08 1 15 001" into "08115001". Markussep ^Talk 13:32, 21 April 2010 (UTC)

There's {{Str repc}} but it's probably quite buggy and certainly quite slow. And it only looks for the first occurrence; I'm guessing that there isn't an existing template that searches for all occurrences. You can browse the other templates in the same category as that one for similar templates. Gary King (talk) 00:40, 22 April 2010 (UTC)

For something as simple as this it would be best to request that {​{#expr:}​} and such remove spaces from an expression before attempting to evaluate. ―AoV² 03:14, 22 April 2010 (UTC)

I've tried using {{Str repc}} and {{Str rep}}, they can remove one space:

{{str rep|12 3 45 678| |}} = 123 45 678)

But they give strange results when I use them nested:

{{str rep|{{str rep|12 3 45 678| |}}| |}} (not displaying the result here, it messes up the whole page)

I haven't found another useful template in the same category. AoV2, is the change you propose simple, and wouldn't it affect other applications? In the application I'm going to use it for (population of German municipalities, extracted from a database using the municipality code), the spaces are always in the same places. This works:

{{str left|12 3 45 678|2}}{{str sub|12 3 45 678|3|1}}{{str sub|12 3 45 678|5|2}}{{str sub|12 3 45 678|8|3}} = 12345678

but it's not very elegant. Markussep ^Talk 09:00, 22 April 2010 (UTC)

I don't understand, why can't you convert all the numbers to remove the spaces once so it never needs to be done again? Gary King (talk) 15:16, 22 April 2010 (UTC)

Because I'd have to do it for thousands of articles. But maybe a bot can do it, I've never worked with one. Markussep ^Talk 16:32, 22 April 2010 (UTC)

If you let us know just what you want to do, someone might be better able to help you. ---— Gadget850 (Ed) ^talk 19:36, 22 April 2010 (UTC)

German wikipedia has subtemplates for population numbers of municipalities. They use the municipality code (Gemeindeschlüssel in German) as a switch. I want to use these subtemplates in the {{Infobox German location}}. In the subtemplates, the codes are without spaces, but in many of the infoboxes (see e.g. Weeze), the codes have spaces, because German wikipedia used spaces before (when most of the infoboxes were copied). Markussep ^Talk 10:50, 23 April 2010 (UTC)

You want to directly use templates from de.wikipedia in articles here? Amalthea 08:48, 24 April 2010 (UTC)

No, I will copy the templates to English wikipedia. See for instance de:Vorlage:Metadaten Einwohnerzahl DE-SN, which contains all the populations of municipalities and districts in Saxony at 31 December 2008 (referenced inside the template to the Saxon statistics service). Markussep ^Talk 15:01, 24 April 2010 (UTC)

We attempted something like that here on enwiki, but it never got off the ground. Wikipedia:WikiProject Tabular Data.—NMajdan•talk 13:23, 26 April 2010 (UTC)

← Alright, three possibilities I see:

1. You could ask for someone to edit the pages to remove the whitespace from the numbers for you. Place a request at WP:BOTREQ or WP:AWB/Tasks for that.
2. You could use templates to remove the inner whitespace of those numbers. We could even build a dedicated one which would be more robust than cutting specific characters
3. You could modify the metadata templates you are porting to switch on the spaced numbers instead. That would be a trivial modification, and I could help you with that if you want

I'd say it depends on what the actual normalized format of the numbers is. If they are supposed to be unspaced, the input should be unspaced, too. If they are supposed to be spaced, I'd say the switch in the template should compare with the spaced numbers. Amalthea 20:38, 25 April 2010 (UTC)

The Statistisches Bundesamt uses them both with and without spaces. Since the German infoboxes now all have numbers without spaces, I don't expect any new spaced numbers to appear. I also noticed that many articles don't have the "Gemeindeschlüssel" field yet (especially the infoboxes that weren't copied from German wikipedia), so it might be a better idea to have a bot copy (and replace, where applicable) the field from German wikipedia for all municipalities. I'll make a bot request, thanks everybody for your help. Markussep ^Talk 13:09, 26 April 2010 (UTC)

OK. FWIW, I just looked, they use the wicked de:Template:GroupNum to group the key into a 2/1/2/* pattern during rendering. Amalthea 14:34, 26 April 2010 (UTC)

Aligning left and right and photos and TOC's (oh my)

Highway 401 is getting a facelift. One of the things I'm trying to do is space photos evenly left and right aligned. The default TOC creates a nice big empty area since nothing can flow around the bloody thing. I tried to right align it, but found doing so made it impossible to have ANY photos above the bottom of the TOC. Ideally, I want the TOC to align right immediately below the infobox at any screen resolution. However, I also want images to be able to be on the left side where the TOC and infobox is. Is it at all possible to put the infobox and TOC into a floating "frame" on the right, and have the rest of the content of the article (including pictures) flow around it as if it was just one very tall picture? - ʄɭoʏɗiaɲ ^τ _¢ 20:23, 22 April 2010 (UTC)

EDIT: Basically I don't want the TOC to push pictures down the page. I want the pictures to move to the left of the toc when the screen resolution is wide enough to do so. (eg not 1024x768) - ʄɭoʏɗiaɲ ^τ _¢ 20:39, 22 April 2010 (UTC)

See the clear= option of {{TOC right}}. Though I would like to point out that with so many elements right aligned (infobox + TOC) you will likely run into WP:BUNCH issues, and I wonder what the usefulness is in placing a consistent element of an article at a position where readers might not expect it. —TheDJ (talk • contribs) 20:44, 22 April 2010 (UTC)

Also, behavior of this clearing of elements is very browser specific. HTML is a markup language, not a layout language (it's not Adobe InDesign). —TheDJ (talk • contribs) 20:45, 22 April 2010 (UTC)

Well thats the point. I want the images to remain in the correct positions relative to the text, and have the toc/infobox stay to the rightmost position. Instead, the right aligned pictures bunch below the right aligned infobox. - ʄɭoʏɗiaɲ ^τ _¢ 23:24, 22 April 2010 (UTC)

That would use up almost all the width of the page, not a good idea. Why can't you just left-float the TOC at the top? TBH that article is a bit heavy on the pictures anyway, and takes a while to load. My not remove some of them and link to a Commons gallery instead? That would give you more space to sort out the layout. OrangeDog (τ • ε) 11:56, 23 April 2010 (UTC)

Please, pretty please, try to avoid placing the TOC where readers don't expect it. I think that placing it under the infobox is very unintuitive and the best option here is to use the default position of TOC. Yes, you get some empty space that way that can't be used for any purpose, but I don't see that as a bad thing. Svick (talk) 12:21, 23 April 2010 (UTC)

I agree with Svick, I do not like seeing the TOC in a non-expected location. I sympathize with the concern about white space - can someone explain why text can flow around an image, but not a TOC? Is it because the size of the image is known, but the TOC width isn't known until generated?--SPhilbrickT 13:14, 23 April 2010 (UTC)

The TOC is a table wrapped with class toc, defined in monobook/main.css. As a table, text does not flow. You could probably include text in a div with a float class before the TOC, but text wrapping would mess it up unless you set the width. Even then it would not wrap under the TOC. ---— Gadget850 (Ed) ^talk 15:41, 23 April 2010 (UTC)

I point out we have {{TOC left}} as well btw. —TheDJ (talk • contribs) 15:51, 23 April 2010 (UTC)

I also agree with Svick. I looked at the first 10 transclusions of Template:TOC_right and each of them were confusing. I believe Template:TOC_right is bad for usability, and it should be prohibited to use it. Dodoïste (talk) 15:43, 23 April 2010 (UTC)

Actually it probably has some merit outside of articlespace. —TheDJ (talk • contribs) 15:46, 23 April 2010 (UTC)

Looks like {{TOC left}} wraps text. - ʄɭoʏɗiaɲ ^τ _¢ 16:42, 23 April 2010 (UTC)

I would also prefer not to see {{TOC right}} in articles, including this one, about the 401 "parking lot". Gary King (talk) 18:01, 23 April 2010 (UTC)

Yes, {{Toc Left}} does wrap, and I was just about to make some wholesale changes, but luckily, read the documentation, which cautions: "Do not use this template to just force word wrap around the TOC, as this is inappropriate method of achieving this. Instead add a CSS class to your monobook.css file which will apply site wide."

I'm not very experienced with css - can someone tell me what I should add - I like the looks of the wrap.--SPhilbrickT 22:09, 24 April 2010 (UTC)

#toc {
clear:left;
float:left;
margin-right:1em;
}

In your personal skin settings for CSS will do the trick on all toc's for all pages. Note that lists (bulleted or numbered) align poorly next to such an element. —TheDJ (talk • contribs) 20:51, 25 April 2010 (UTC)

Thanks, will try it when I get home.SPhilbrickT 21:25, 26 April 2010 (UTC)

The article looks awful as there is too little space between the toc and the infobox for the second paragraph. The thumbnail images are staggered haphazardly as well, and for no apparent reason. Could you please make each paragraph begin on the left side of my screen? That would make the article less distracting to read. ―AoV² 00:28, 26 April 2010 (UTC)

Merging Contributions of User:Sap.prabhu to User:shok_Prabhu

My earlier user id en:User:Sap.prabhu was renamed through CHU process to en:user:Ashok_Prabhu on 2010-03-21 and older contribs have been renamed. However some of my contributions continued to happen with en:User:Sap.prabhu even after re-naming due to automatic login by my internet explorer. Can some one help and merge the Contribs showing under en:User:Sap.prabhu to en:user:Ashok_Prabhu please..? --Ashok Prabhu (Talk) 10:35, 25 April 2010 (UTC)

Merging contributions isn't possible without help from a developer, and unfortunately I doubt one would be willing to assist you in this situation. Is it really a major problem? — The Earwig ^(talk) 14:41, 25 April 2010 (UTC)

It isn't a problem but I would like to have my contribs under single ID. Can you guide whom I can approach to..? --Ashok Prabhu (Talk) 08:34, 26 April 2010 (UTC)

Sanction log

I've outlined my proposal here at bugzilla.— Dædαlus ^Contribs 06:53, 26 April 2010 (UTC)

Cite error for talk namespace?

The warning about ref tags on a page missing <references /> is very helpful in article space. But I think it would also be halpful for talk pages. I've encountered a situation in which a pair of editors weren't discussing a dispute... all because the talk page had a single missing ">" at the end of a ref tag.[13] The reference thus ate up all the later sections, and the editor ended up thinking the talk page was "broken". Though an experienced editor would catch this when his comments didn't show up, this is not a user error. The syntax of the page was clearly broken before he edited, and the system should have flagged it.

Although previous discussion here [14] described a cite error that specified no closing tag for a ref, the case above instead leads to a warning about a lack of <references /> in article space. The distinction is minor, but in Talk: namespace it might be desirable not to flag a cite error when the reference list is absent, but only the cite error when a closing ref tag is missing. Wnt (talk) 07:36, 26 April 2010 (UTC)

I implemented this through {{broken ref}} about a year ago. Changes in Cite added more error checking that immediately showed up on a multitude of pages. There was quite a bit of discussion and it was resolved to fix all the article pages, but to disable messages on talk and user pages. Later discussion restored messages to user pages so that issues could be resolved with userspace drafts. Each error message is invoked through separate MediaWiki system pages as documented at Help:Cite errors, so I think that what you are asking for can be done, with consensus. Understand that that cite.php does check for missing </ref> tags, but this does not work if the very last tag is missing; this "eats" the rest of the content including {{{reflist}} or <references />. ---— Gadget850 (Ed) ^talk 14:50, 26 April 2010 (UTC)

Thanks for pointing me in the right direction - to build on this a little further, the relevant code seems to be at lines 243-256 in Cite_body.php. This was apparently worked on a bit at Bug 6199, and this problem was left hanging in the last comments there.

The unresolved question there seemed to be whether unclosed tags were sent by the parser to extensions. One poster said that the unclosed final ref tag was never sent, so the extension couldn't possibly spot it; the other said that it was closed "implicitly", but this still is somehow a problem.

While I hope someone works out exactly what information is available to work with, I should note that at least the example I cited here should be catchable even without the final ref tag, as the first mistake involved the lack of a ">", causing a "</ref" to be present within one of the preceding ref tags. Wnt (talk) 18:17, 26 April 2010 (UTC)

And thanks for the bug link— I had looked for that. I added it to Help:Cite errors#Bugs. ---— Gadget850 (Ed) ^talk 19:08, 26 April 2010 (UTC)

Spans within links

In HTML, it is possible to have:

<code><a href="http://example.com>This and <span class="foo">that</span></a></code>

The logical way to do that in Wikicode, for an internal link, would be:

<code>[[This and <span class="foo">that</span>]]</code>

but that breaks the link. Is there a way to do the above, or do I need to raise a bug/ change request? The intention is to do so in complex templates, so regular editors should not come across in-line HTML. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:28, 26 April 2010 (UTC)

The left side of the pipe defines the link target, the right sight the link label, so you'll need to use [[This and that|This and <span class="foo">that</span>]]: This and that.
Amalthea 18:05, 26 April 2010 (UTC)

That's incredibly helpful, thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:55, 26 April 2010 (UTC)

Rollback button .js

I need help. I know I pasted a java script, I'm pretty sure to monobook page that hides my rollback buttons on my watchlist page and diff pages I think ? My problem is I can't tell by looking at my monobook which script it is and DUH I can't remember where I got it. I am hoping someone can indentify it for me, I want to see if it will work in "Vector" or is there a script that will do the same thing that will work in vector. This is the only place I could think to ask. If I'm out of luck so be it, but I had to ask. Thanks to whoever answers. Mlpearc MESSAGE 00:11, 27 April 2010 (UTC)

Everything in User:Mlpearc/monobook.css. It is CSS code, not JavaScript code. Put it in User:Mlpearc/vector.css. PleaseStand ^(talk) 00:36, 27 April 2010 (UTC)

• Thanks, no wonder I couldn't find it. Didn't think to look there I thought that page was empty. What would we do without you tech guys. Thanks again Mlpearc MESSAGE 01:06, 27 April 2010 (UTC)