Wikipedia:Village pump (technical)/Archive 74

• Village pump
  • Policy
  • Technical
  • Proposals
  • 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, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230

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 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 en.wikipedia.org, 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://en.wikipedia.org/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://en.wikipedia.org/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 . ―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 , 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:

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_74&oldid=1147981513"