Wikipedia:Village pump (technical)/Archive 58

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

Toolserver error

Hi, don't know if this is the right place to post but don't know where else to report it...basically the edit counters I use at Toolserver are down, reporting an "Page not found (404)" error message. This refers to the edit and action counter and the list of articles created, which are the only ones I use...regards, Giant Snowman 03:01, 8 March 2009 (UTC)

See #Articles created above for someone with the same problem. SQL's tools have been taken down due to abuse. Graham87 05:53, 8 March 2009 (UTC)

Many thanks. Any idea if/when the tools will be re-enabled? Giant Snowman 14:05, 8 March 2009 (UTC)

I assume from the message that says "temporarily" that they will be enabled some day. I have no idea when though. Graham87 14:15, 8 March 2009 (UTC)

OK, thanks for your help anyways. Regards, Giant Snowman 14:16, 8 March 2009 (UTC)

The above-mentioned discussion has been archived at Wikipedia:Village pump (technical)/Archive 57#Articles created. Graham87 09:03, 11 March 2009 (UTC)

Help:Transclusion in HTML

How can I transclude the content of a webpage? Please help me. Thank you. --Amit (Talk | Contribs) 16:43, 9 March 2009 (UTC)

An external webpage? You can't. Why would that be useful for an encyclopaedia (not mentioning the spam problems that this would enable)? --Amalthea 16:53, 9 March 2009 (UTC)

What a very interesting account: Myrecovery (aka Amit) has spent the last 1000 or so edits (I didn't look back further) playing around with color coding and other page formatting; I found exactly one edit actually related to improving Wikipedia as an encyclopedia. -- John Broughton (♫♫) 19:50, 11 March 2009 (UTC)

Ifd -> FfD

Wikipedia:Images and media for deletion/2009 January 1 - why are there still subpages under IfD, when the process was moved to FfD? This makes searches annoying. ▫ JohnnyMrNinja 13:36, 10 March 2009 (UTC)

It looks to me like someone started moving them and then stopped. Don't ask me why, though I suspect a bot would be needed to handle this efficiently were you to want to actually move them. --Izno (talk) 13:42, 10 March 2009 (UTC)
- Actually, 100 pages were moved. This looks like an admin who requested to move the subpages along with the page, but that only moves 100 pages, not all of them. עוד מישהו Od Mishehu 15:21, 10 March 2009 (UTC)
  - Is there an easy way to finish? ▫ JohnnyMrNinja 23:39, 10 March 2009 (UTC)
IIRC, no one thought it was important enough to go to the bother of actually moving all those subpages. Anomie⚔ 23:41, 10 March 2009 (UTC)
- The "move subpages" feature for admins is limited to 100 subpages to prevent WP:PERF issues, crats have a limit of 1,000 pages according to my memory, but other than that, no way to move more than 100 pages at a time easily. MBisanz ^talk 23:44, 10 March 2009 (UTC)
  - A bot could easily handle it, right? ▫ JohnnyMrNinja 11:35, 11 March 2009 (UTC)
    - At least one 'bot, namely User:Uncle G's major work 'bot, has handled exactly this sort of thing in the past, and moved far larger mountains than this. Show me the discussion of and the consensus for this move, and place a notice linking to and directing people to this discussion here on Wikipedia:Bot requests. Uncle G (talk) 12:03, 11 March 2009 (UTC)
      WT:FFD#Process name change proposal. Anomie ⚔ 12:56, 11 March 2009 (UTC)
  - I'm hoping this is because bureaucrats might need to rename somebody who has 101–1000 user-space pages, not because we anyone believes bureaucrat accounts are magically less likely to be hacked or go rogue. I'm sure this will happen at least a couple times as the ranks grow another order of magnitude. Seriously I don't see why there should be a limit in either case. If it's a "too many database changes at once" issue we should have the job queue handle the pagemoves one at a time. For all practical purposes it would resemble an internal bot, as it would want to do an "am I blocked yet?" check every several steps. As long as it's just as easy to revert I don't see what the big deal is. — CharlotteWebb 16:06, 11 March 2009 (UTC)
    - If it was a database issue wouldn't it also be an issue with 'crats? ▫ JohnnyMrNinja 16:19, 11 March 2009 (UTC)
      - Yes, but it would come up less often. Maybe I got side-tracked but what I meant to say was there's no real reason to trust crats more than "regular admins" to decide when and when not to move all the sub-pages from VFD to AFD or IFD to FFD or whatever. Hell, Ed Poor was a bureaucrat when he spontaneously decided to delete VFD. Plus this isn't exactly something anyone would screen anyone for at RFB, not if they wanted to continue being seen as a reasonable person. — CharlotteWebb 17:16, 11 March 2009 (UTC)
        My only point was, it would have to be a "trust" issue, but I can't see what situation this would avoid. The damage done from 100 page moves is about the same as 1000 or 5000; either another admin moves them back or a bot does. How could something like this be changed? ▫ JohnnyMrNinja 17:23, 11 March 2009 (UTC)

The 'bot is busy renaming the 2006 sub-pages as I type this. Uncle G (talk) 00:04, 12 March 2009 (UTC)

Disambiguation using popups

Resolved

I regularly use navigation popups to disambigaue links, and it's brilliantly efficient tool for the job.

However, today it has stopped loading the "show changes" view after it has made its changes. Viewing the changes is essential when using it on anything except a very short stub articles to check that the correct links have been disambiguated, so the remocal of automatic preview requires an editor to sscroll down, find the "show chnages" button, and click it. This adds several unnecessary steps to the process, and slows down the important work of disambiguation. Does anyone know why this has been done, and whether it can be undone?

BTW, I now use POPUPs through the gadgets setting at Special:Preferences, rather than loading Lupin's version into my monobook.js ... so I presume that as a gadget, this change is the work of a Wikimedia developer. --BrownHairedGirl (talk) • (contribs) 22:45, 10 March 2009 (UTC)

I don't know. It doesn't seem like a change in Popups - I have just did a disambiguation link, and got the "show changes" view. עוד מישהו Od Mishehu 14:44, 11 March 2009 (UTC)

Enabling it that way will use this version MediaWiki:Gadget-popups.js, but it doesn't seem to have changed recently either. — CharlotteWebb 15:44, 11 March 2009 (UTC)

Thanks for the comments. Now resolved, as explained at Wikipedia talk:Tools/Navigation popups#Show_changes_after_disambiguation. Must have been some oddity in my browser, but now all fixed after clearing cache, etc. Still odd, though: I never had this happen before in over 3 years of using popups, and dab-via-popups must account for several thousand of my horribly high edit count. --BrownHairedGirl (talk) • (contribs) 16:19, 11 March 2009 (UTC)

Heh, well if you want to go twice as fast you can make it automatically "save page" instead of showing the preview/diff, easy to change this. — CharlotteWebb 16:37, 11 March 2009 (UTC)

No, I don't want that! I think it's really important to check that I haven't inadvertently disambiguated another similar link to a different person. If there's John Smith (or similar highly ambiguous name) link in a long list, it's horribly easy to wrongly dab another JohnSmith, and IMO the only thing worse than an undisambiguated link is a wrongly disambiguated link. :) --BrownHairedGirl (talk) • (contribs) 16:56, 11 March 2009 (UTC)

John Charles Dodson, 3rd Baron Monk Bretton

Why is the John Charles Dodson, 3rd Baron Monk Bretton saying there is no references tag, when there is one? Who then was a gentleman? (talk) 23:57, 10 March 2009 (UTC)

As documented at Help:Cite error (which unfortunately cannot be linked from that message due to a software problem), that message also displays if the article contains a reference after the reference list. In this case the reference does not appear in the list. It's in the succession box. Algebraist 00:12, 11 March 2009 (UTC)

(ec) It's because of the ref in the succession box. All refs must be above the references tag. Moving the succession box up will fix it. — jwillbur 00:14, 11 March 2009 (UTC)

Which breaches the guidance in WP:LAYOUT#Standard_appendices. Guidelines are not a straitjacket, and this seems like a good reason to breach one ... but since I'm sure I'm not the only editor who habitually does a minor edit to reorder the std appendices sections if they are out of sequence, it would be a good idea in situations like this to include a hidden commnet in the references ection explaining the reason for its non-standard location.

Alternatively, just put a second {{reflist}} below the succession box. --BrownHairedGirl (talk) • (contribs) 00:40, 11 March 2009 (UTC)

Unfortunately, that causes another problem: the footnote in the succession box is using a named ref defined earlier, and named refs don't work across multiple reflists. Algebraist 01:43, 11 March 2009 (UTC)

Change <ref name="ww" /> to

<ref group="note">MONK BRETTON, John Charles Dodson. (2008). In ''Who's Who 2008''. Retrieved February 26, 2008, from http://www.credoreference.com/entry/7441825</ref>

Add {{reflist|group="note"}} immediately after the sucession box. --—— Gadget850 (Ed) ^talk - 15:45, 11 March 2009 (UTC)

This is one of my 101 pet peeves. I swear there are some editors would put the references section 30 feet beyond the end of the page if they knew how. The best solution here would be to state this information somewhere in the main prose (this should be done with any important navbox/infobox/successionbox info, regardless) and add a ref to it in that position. In addition to or lieu of that you could create/link-to the article about this man's heir, and provide a reference for the other guy's heir status in that article. — CharlotteWebb 18:42, 11 March 2009 (UTC)

Well, I've removed the ref in the succession box, and that fixed that problem. Who then was a gentleman? (talk) 23:01, 11 March 2009 (UTC)

Proper process for Article scope / name change while under AfD?

Hello,

This is about Wikipedia:Articles for deletion/Amaranth Games (2nd nomination): the developing consensus is that the article (about a CORP) doesn't pass the inclusion bar however some of its production does. I have started working on salvaging elements which can be split out here, the intent being to migrate the salvaged content to Aveyond (Game Series). Since this is reusing content contributed by other editors, the edit history should certainly be kept. I am however unsure about the proper process:

Trimming down and then moving would completely change the scope of the article (currently still under AfD), which upon reflection doesn't seem a "clean" way of doing this, in particular since the AfD is running on the original scope
Creating a new page and redirecting if the final consensus is to delete loses the edit history, which doesn't sound like it should happen either.
Proper splitting seems not practical since the consensus to delete the original article appears likely, thus also losing the edit history.

As I'm obviously still quite new, I'd appreciate any guidance on how best to proceed. Thanks. MLauba (talk) 11:31, 11 March 2009 (UTC)

Read Wikipedia:Guide to deletion#You may edit the article during the discussion. AFD is not an election. There's no freezing of articles for polling day. It's a discussion. And this is not a technical issue, and does not belong on this part of the Village Pump. The only (fairly) technical issue with this was something that we solved years ago: We fixed the AFD notice templates so that the link from article to discussion didn't break if someone renamed the article whilst it was listed at AFD. Clearly, we didn't do that just in order to tell people that doing that wasn't allowed. ☺ If you want the advice and help of (other) experienced hands at article rescue, Wikipedia:Article Rescue Squadron is the place. Uncle G (talk) 11:55, 11 March 2009 (UTC)

missing categories Military of Morocco

The categories are wikifed and show when editing the article Military of Morocco, but I can't seem to make them show when the article is saved. There's no broken references, or anything like that. Could I get some help? Thanks! cOrneLlrOckEy (talk) 12:01, 11 March 2009 (UTC)

I don't see any categories, only interlanguage links, which show on the left sidebar under languages. --—— Gadget850 (Ed) ^talk - 18:20, 11 March 2009 (UTC)

The categories were removed by an anon in November last year. I've restored them.-gadfium 20:26, 11 March 2009 (UTC)

[edit] links appear in printable version when copied into a document

I've already submitted this to bugzilla:17810 but maybe I'm just missing something.

When I go to any article and click the printable version via the link on the sidebar, I can see the printable version without the [edit] links. But if I copy-paste the text to a document, the edit links appear again. This is quite annoying, but is this a known bug? -- penubag (talk) 23:09, 5 March 2009 (UTC)

The content is still all there, it's just being hidden with special CSS. So naturally if you take it into an environment where CSS is not applied, the content will not be hidden. Happy‑melon 23:13, 5 March 2009 (UTC)

I've duped the bug to the older bugzilla:11213, which was closed some time ago as 'wontfix'. It seems like a legit enough issue and it's come up a number of times, so I've reopened it; I'm tossing it over to our new Usability Project crew, as they're asking me for some bugs to cut their teeth on until they get the bigger project plans going. :) --brion (talk) 06:23, 6 March 2009 (UTC)

I dread to think what a "fix" might involve. This is CSS used properly, but browsers not handling it intelligently. A "fix" to this is likley to involve either using some ugly hack or removing other functionality. --BrownHairedGirl (talk) • (contribs) 08:17, 9 March 2009 (UTC)

currently, edit links are there in the text, unless the user can't edit the page, or they disabled that in their user preferences, or there's a magic word in the page text. The fix would probably involve adding another case to that list. -Steve Sanbeg (talk) 18:43, 12 March 2009 (UTC)

sandbox history

I just saw a question over on Wikipedia talk:vandalism about people posting obscene things in the sandboxes. nothing to be done about that directly, I don't suppose, but it got me wondering whether the sandbox history could be purged periodically (deleting everything over 6 hours old, say...) I can't imagine a reason why wikipedia would need to keep old revisions of the sandboxes around; this would remove a lot of crap and free up some space on the servers that could be put to better use. would that be possible, even? --Ludwigs2 00:00, 10 March 2009 (UTC)

In my humble opinion, it would be nice to have a "Special:Sandbox" that clears (i.e. completely discards) revisions once they're reasonably old but otherwise acts like a normal sandbox page. This would solve the problem you mention. {{Nihiltres|talk|log}} 02:59, 10 March 2009 (UTC)
- Or that, like many Special pages, is specific to that user, so that no-one else can see it? ▫ JohnnyMrNinja 13:34, 10 March 2009 (UTC)
  - That would solve the "obscene things in the sandboxes" problem, but I haven't thought about the possible side effects of such an implementation—one possible problem is that you'd need a "traditional" sandbox page to be able to collaborate on something sandboxed. Granted, that's not much of an issue for replacing the main Sandbox, which is pretty much a black hole of test edits. {{Nihiltres|talk|log}} 14:38, 10 March 2009 (UTC)
Considering the number of edits to the Sandbox, wouldn't repeated deletion of its history bring Wikipedia to its knees? There's a reason why there's a throttle on deletion of article histories with large numbers of edits. Who then was a gentleman? (talk) 19:45, 10 March 2009 (UTC)
- Indeed, considering the large number of edits to the sandbox, even if there is some grossly offensive material in the history, finding such edits would be like finding a needle in a haystack, thereby making the history deletion unnecessary. If one revision is truly problematic, that's a job for oversights. -- Blanchardb -^{Me•MyEars•MyMouth}- timed 20:39, 10 March 2009 (UTC)
  - well, interesting. I hadn't really thought that deletion of article histories would have that much overhead (I just assumed it was static data that could be eliminated from the database at will). so why not just make the main sandbox a historyless page? few people use it for anything other than quick tests or garbage, anyway, so I don't see any real reason for retaining anything other than the current revision. --Ludwigs2 23:17, 10 March 2009 (UTC)
    - If the Sandbox had no history, then it would be a copyright violation most of the time (since it would not be complying with the terms of the GFDL with regards to GFDL-licensed content). This would be a bad thing. Algebraist 23:20, 10 March 2009 (UTC)
    - There is Special:ExpandTemplates if all you want to do is experiment with wiki text, but I think the idea of the sandbox is to put across the unusual concept of anyone being able to go to a webpage and edit it, without anyone needing to authorise it. If we start making it not behave like any other wiki page, newcomers will be confused as to how exactly Wikipedia works. Tra (Talk) 23:33, 10 March 2009 (UTC)
      - For content we've deleted?? We only need to keep history for the content we keep. Otherwise how could we justify deleting articles? — Blue-Haired Lawyer 23:36, 10 March 2009 (UTC)
        I'm not talking about deleted content, but about content from previous revisions which has not yet been removed, but would not be properly attributed in the history if Ludwigs' suggestion were carried out. Algebraist 23:41, 10 March 2009 (UTC)
Deletion increases database size. Deletion does not shrink the database, nor does it remove things from the database. (Removal occurs when developers purge the deleted revisions table, which they stopped doing in 2004, or when different tools, other than the deletion tool, to which only a very few people have access, are used.) Wikis are not filesystems. Don't think of pages in wikis as files on the hard disc of your personal computer. Uncle G (talk) 12:26, 11 March 2009 (UTC)

Regardless of whether it would do any good to delete (in any sense of the word) old revisions of the public sandbox, the idea of a private "Special:Mysandbox" feature is certainly interesting. It would probably be the only feasible way to provide an editable, history-less page for deeply personal test edits, drafts, evidence storage, or other notes-to-self. Sure, one could set up their own private wiki for this, but it would be a pain to copy over (and continuously update) every template and meta-template and meta-meta-template needed to guarantee proper rendering of the page. Not sure whether you'd want to think of this as "notepad.exe but supporting wikitext markup and remote transclusion" or "Special:Expandtemplates but with a 'save' button", or just "a big text field added to the `user` table but which the parser treats just like any other", but I think a lot of us would find it quite useful. — CharlotteWebb 15:04, 12 March 2009 (UTC)

Is there (should there be) a limit on the size of a GIF file in an article?

I had this interesting discussion with an anon here, about the size of a 3 MB GIF file. I thought it was no big deal, but the anon complains that this makes their small Nokia browser very slow and therefore they want to eliminate the GIF from the article. Is there a policy that covers this? Thanks. Dr.K. logos 03:28, 12 March 2009 (UTC)

There's no policy that I know of, but the problem is that server-side GIF thumbnailing is disabled for performance reasons. While a reduced thumbnail is automatically created for other images, this is disabled for GIFs, because of problems with animated ones. I've uploaded a reduced version scaled to the same size used in the article using what should be the same program and options that would be used by Wikipedia if it wasn't disabled. The image is at File:Fiat500Presented250x167.gif; I've already replaced the one in the article with it. The reduced file is only 385 KB. Mr.Z-man 04:03, 12 March 2009 (UTC)

Wikipedia:Image use policy#Animated images recommends using a static image with a link to the GIF unless the file is "very small." Without, of course, defining the term. Someguy1221 (talk) 04:14, 12 March 2009 (UTC)

Thank you very much Someguy1221. Also thank you Mr.Z-man for your fast reply and for solving the technical problem. Your GIF renders very nicely in my browser. Take care. Dr.K. logos 04:30, 12 March 2009 (UTC)

bugzilla:16451 --Splarka (rant) 07:33, 12 March 2009 (UTC)

Db-pagemove

I used the twinkle "csd" function in an attempt to request a redirect-page delete to make way for a move, and twinkle added template {{Db-pagemove}} to the page. However, that template redirects to {{Db-g3}} which is for "pure vandalism" pages. Not quite the expected result. -- Tcncv (talk) 05:10, 12 March 2009 (UTC)

That was meant to refer to redirects left over as a result of page-move vandalism. The correct template is: {{db-move}}. Someguy1221 (talk) 05:24, 12 March 2009 (UTC)

Please also note that {{db-move}} should specify the page which should be moved, and the reason for the move. עוד מישהו Od Mishehu 06:56, 12 March 2009 (UTC)

Scripts to move pages???

Here's a thread I started on Sj's talk page. I'm copying it to here to relay the question to you tech-heads. Your input would be appreciated.

You mentioned that "You can manage renames quite effectively with a script, and have it take minutes, not hours". Please teach me how to do this (please post such help to my talk page).

I would love to take a look at scripts that do this. Can you point them out or email them to me?

Thank you.

The Transhumanist 22:52, 10 March 2009 (UTC)

P.S.: There are several people I know of besides me who would be very interested in how to do this. I've CC'd this message to them (Juliancolton, thehelpfulone, Robert Skyhawk, and NuclearWarfare). I will pass along to them any know-how you provide. You have yourself an audience. :) -TT
- You...can...rename...pages...with a script? NuclearWarfare dies of shock. Please tell me how, oh wise one :) NuclearWarfare _(Talk) 23:44, 10 March 2009 (UTC)
  - It might be listed at Wikipedia:WikiProject User scripts/Scripts, but I didn't find anything at a quick glance. –Juliancolton ^Tropical ^Cyclone 00:16, 11 March 2009 (UTC)
    - I guess I should mention the python script of pywikipedia - movepages.py. This will probably be script that can be used so long as you have installed python and pywikipedia, although it will require a bot task, if it can reach such speeds as it can run automatically. Sorry I didn't mention this earlier ;) The Helpful One 18:10, 11 March 2009 (UTC)

There are several ways of doing this. I, personally, simply wrote a program called WIKIMOVE.exe. To rename pages in a script, I simply write a script that invokes that program. My new IFD-TO-FFD.btm script, that I have just written for Uncle G's major work 'bot, is one such script that invokes it, for example. You appear to be looking for some JavaScript. A script is not necessarily, or even usually, JavaScript, and doesn't run in a WWW browser. Shell scripts, in particular, do not. Uncle G (talk) 23:26, 11 March 2009 (UTC)

Such a javascript is probably easy with the new API write features available (like some batch delete scripts I've written), but I'd have moral qualms about it. Not so much because of vandalism, but because it might make it too accessable to editors who might be a bit clueless about such things. --Splarka (rant) 07:38, 12 March 2009 (UTC)

I dont see what you mean by a script to rename the page. Isn't moving the page the easiest thing to do? Where is the complication?ManishEarth^{Talk • Stalk} 09:32, 12 March 2009 (UTC)
- Then you haven't read carefully enough. Note that everyone above is using the plural: "pages", "renames". See also the original discussion, and the work that the 'bot is doing. Uncle G (talk) 12:16, 12 March 2009 (UTC)

Then why not use AJAX. There probably is an AJAX tool for renaming, so if I can find it, it wouldn't be hard for me to write a script for multiple page moves. ManishEarth^{Talk • Stalk} 15:17, 13 March 2009 (UTC)

Found it here (Search 'action=move' in the page and you'll find the section.) It's not AJAX, but i think it can be used in AJAX. I'm an amateur at AJAX and I'll have to see the AJAX documentation. ManishEarth^{Talk • Stalk} 15:25, 13 March 2009 (UTC)

Well, if you're set on making it exist anyway, here: User:Splarka/ajaxbatchmove.js. Adapted from two existing scripts I had, a batch delete script and an ajax delete script. This is not tested yet, or rather it hasn't been successfully tested, as API moves are broken on test.wikipedia and any wiki with AbuseFilter (to be fixed shortly), and I didn't feel like moving too many pages on en.wp! --Splarka (rant) 00:43, 14 March 2009 (UTC)

Messed up multiple columns

I asked my question here

Wikipedia:Village pump (technical)/Archive 57#Messed up multiple columns

It didn't look perfect when I finished then, but it does now. I found the solution for my problem under Internet radio#See also, after clicking on "edit". I needed to read more carefully, because it took a couple of tries. There was more than what I had seen.

This is what I had to fix.

Adult standards#Adult standards artists

Is the information about how to do this somewhere?Vchimpanzee · talk · contributions · 20:13, 12 March 2009 (UTC)

I made a slight change to use {{col-3}} templates to gived the columns equal widths. Does this look better? -- Tcncv (talk) 02:59, 13 March 2009 (UTC)
Yes, in the formatting section of Wikipedia:Template messages. Looking things up in the Wikipedia:Editor's index to Wikipedia, which points to Wikipedia:Template messages, is where one starts when one has problems like this. Uncle G (talk) 13:16, 13 March 2009 (UTC)

Large volume media additions to WikiSource and/or Commons

First off, I'm making the assumption that this is the correct location for discussions on Wikisouce and Commons, which might not be correct. I've also posted this text at the Help Desk.

Question: is there Wiki software available to allow Wikipedia users to view image files (of books/magazines/journals) on the left side of the user's display, with the matching digital article on the right side of the screen? That seems to me to be the ideal: viewing the original document/book/journal/newsclipping complete with illustrations and photos on the left side, while having the digital article (with all its advantages) displayed on the right side of the user's screen.

I've noticed in Wikisource only a few issues of National Geographic Magazine had been uploaded, and of those many were only indexed while only a few had been proofed and were readable as digital articles. To me that seems to ignore the huge stores of desirable articles available from quality magazines/journals that are no longer under copyright protections, prob. a hundred issues of National Geographic alone prior to 1923 as well as tens of thousands of journals. It also seems that an easy way to provide significant benefit to Wikipedia editors and the general public would be to make those public domain magazines and journals available as quickly as possible (via uploaded scanned .Jpeg image files), followed with very simple article indexing with subject tags. Digital conversions, proofing and meta-data could follow afterwards on a time-available basis. If Wiki viewing software (as noted earlier) were used and the scanned article's digital text were not yet available, a message stating so would be added to the blank view on the right side of the screen, opposite to the page image on the left side. Other messages on the right side could indicate the absence or completeness of proofing and meta tags.

For your consideration if this has not yet been discussed -thanks.....

HarryZilber (talk) 21:22, 13 March 2009 (UTC)

Initial assumption is wrong. Please check out commons:Commons:Village pump. Commons also hosts images (scans of books mainly) for WikiSource. So that is where you should ask. view image files (of books/magazines/journals) on the left side of the user's display, with the matching digital article on the right: this is implemented on Wikisource. As for the lack of proofread articles: WikiSource needs manpower! --Dschwen 21:56, 13 March 2009 (UTC)

Wikipedia.org is more popular than...

I updated the new three month ranking of 7[1], but I'm not sure how to find the exact date for the "Wikipedia's Alexa ranking milestones (3 month average)" section. Anyone know? - Peregrine Fisher (talk) (contribs) 17:55, 12 March 2009 (UTC)

From Alexa's graphs, which only go back about 16 months. So it's not possible to check the figures from before that time.--Father Goose (talk) 20:15, 14 March 2009 (UTC)

Oh, I think I understand your question better now. As far as I can tell, people were basically checking every day and updating the page when a new milestone was hit. So it's really on a "first noticed" basis, not "first occurred".--Father Goose (talk) 20:52, 14 March 2009 (UTC)

access to wikipedia access_logs

I've heard that there is a large Wikipedia access_log sample available for download. Does anyone know where I can obtain this file? I am interested in analyzing how Wikipedia users browse Wikipedia (for example, what sequences of articles). So looking at summarized stats is not sufficient, I would like to see the actual web server logs. Jawed (talk) 02:03, 14 March 2009 (UTC)

These data are not, and never will be, publically available, and you will never be allowed to see them unless you are employed by the Foundation. Basically. Sorry to rain on your parade. Happy‑melon 09:10, 14 March 2009 (UTC)

There is interest in this kind of thing, but we're not interested enough to actually dedicate resources to anonymising logs, and risk the user data exposure (e.g. see the AOL search record controversy in which logs were anonymised, but it was still possible to track down users). — Werdna • talk 12:04, 14 March 2009 (UTC)

Disappearing banner

This is a problem I've noticed with several WikiProject banners. Take {{WPCHINA}} at Talk:A Xiang for example; when I first load the page the banner appears as intended:

but as soon as I move the cursor the collapsible section vanishes:

Any ideas? (I use IE7). PC78 (talk) 19:38, 14 March 2009 (UTC)

At least it's not my fault, for a change :D Have you tried clearing your personal .css and .js? Happy‑melon 20:12, 14 March 2009 (UTC)

My .css is empty; I don't have a .js. PC78 (talk) 20:25, 14 March 2009 (UTC)

discospinster message

I have received the following (Below) upon sending a question to my MAC dictionary/wikipedia APP. I have no idea why. I, until now, had no wikipedia account and have not knowingly lent my laptop to anyone. Until this day, I had no idea who Adam Copeland was.

I am sure this is not where such enquiries go, but it was impossible to figure out and I am sure that one or many of you mavens out there do and will forward and respond appropriately.

Thank you.

The following: <<<Sava (disambiguation) You have new messages (last change). Sava may refer to:>>>

Links to: <<<User talk:68.46.7.39 From Wikipedia, the free encyclopedia

[edit] February 2009 Welcome to Wikipedia. The recent edit you made to the page Adam Copeland has been reverted, as it appears to be unconstructive. Use the sandbox for testing; if you believe the edit was constructive, please ensure that you provide an informative edit summary. You may also wish to read the introduction to editing. Thank you. ... discospinster talk 00:21, 19 February 2009 (UTC)>>>

RBwhy (talk) 19:53, 14 March 2009 (UTC)

If you were using an IP, then someone else on that IP did the edit and the warning was issued to that IP. Feel free to disregard messages that clearly do not apply to you. -Jeremy ^{(v^_^v Cardmaker)} 20:22, 14 March 2009 (UTC)

And since you now have a registered account that won't be happening again to you. Cheers, Amalthea 20:27, 14 March 2009 (UTC)

To be a little more clear, the IP address 68.46.7.39 is one of a block of 32768 addresses used by Comcast (I'm sure they also have many other blocks of varying sizes). Normally, no IP address is reserved for any particular customer (if someone wants that, Comcast would probably charge them more for the privilege); Comcast just assigns the "next" free address whenever a customer comes online (or their DHCP lease expires).

What probably happened here is that a month ago someone else had the IP address and used it to vandalize Wikipedia. Then Comcast gave them a different IP, and then recently Comcast randomly gave you that IP address and therefore Wikipedia notified you that there was a message for the IP address you were now using. Anomie ⚔ 21:22, 14 March 2009 (UTC)

~~~~ doesn't give me any links

I have Raw signature checked in Special:Preferences. Per Wikipedia:Signatures#Using four tildes, that should give me "TerraFrost (talk) 22:14, 14 March 2009 (UTC)", but it doesn't - it gives me "TerraFrost 22:14, 14 March 2009 (UTC)". Any ideas as to why? TerraFrost 22:34, 14 March 2009 (UTC)

If you have "Raw signature" checked, you have to write the links into it. That's what the "raw" part means. If you want it auto-linked, un-check "Raw signature". rspεεr (talk) 22:36, 14 March 2009 (UTC)
- That worked - I guess I got caught up on the "the box above will be treated as your nickname" bit. The box is, by default, empty, so I thought that that'd mean that it'd act as though you didn't have a nickname or something. Guess I was wrong. Thanks! TerraFrost (talk) 22:46, 14 March 2009 (UTC)

Column Breaks in Numbered Lists

I posted a "Help Me" on my Talk Page ... and I was referred to this page. I hope this is the right page where I can ask my question and get a resolution. Can anyone help with this question? Thanks in advance. Please take a look at the list below. You can also take a look at the Wikipedia "code" that generates this list below, if you'd like, by hitting the "edit" link to the right above. My question is this. Is there any way to make the second column of the list simply continue the numerical count, without starting over at "1"? If so, what is the way to accomplish that? In other words, I would like the second half of the list, on the right hand side, to begin with the numbers 19, 20, 21, and so on. Any advice? Thanks. (Joseph A. Spadaro (talk) 23:14, 8 March 2009 (UTC))

Lists:

You can do it with html, as I have done. I don't know if there's a cleaner, more wikitext-based way to do this. Algebraist 23:19, 8 March 2009 (UTC)

Thanks. I looked at your code. Your solution requires that I know that the left column has 18 items ... correct? (Thus, dictating that the right hand column begin at 19). But, in a Wikipedia article, things will be added/subtracted all the time (from lists). Isn't there just a generic code that does not require that I know the exact number on the left side? Thanks. (Joseph A. Spadaro (talk) 23:47, 8 March 2009 (UTC))

{{div_col}} and {{Columns-list}} will do this, but it may not work in Internet Explorer or Opera (unless those browsers have come up to W3 standards since the template docs were written). It might be possible to write a template to do it explcitly. --Ludwigs2 00:12, 9 March 2009 (UTC)

Thanks. I don't follow, though. What is the exact code that needs to be typed (as in the above example)? I checked those links, but I was not able to figure it out. Thanks. (Joseph A. Spadaro (talk) 01:40, 9 March 2009 (UTC))

Like this:

Algebraist 01:50, 9 March 2009 (UTC)

{{div_col}} and {{Columns-list}} use CSS3 column elements and will not work with IE, which accounts for about 75% of use. --—— Gadget850 (Ed) ^talk - 03:11, 9 March 2009 (UTC)

See Help:List#Multi-column_numbered_list. This page says that you must use html, or you can use the template at meta: m:Template:multi-column numbered list. The meta template actually requires html as a param, so it is better to just use html ore the example given by Algebraist above. ManishEarth^{Talk • Stalk} 11:05, 9 March 2009 (UTC)

Something in this section is doing something wierd with my FF-3.0.5; when hitting the 'back' button, everything below this section ceases to exist. Clicking on any link, even section links, brings it back again... Wierd. Happy‑melon 17:06, 13 March 2009 (UTC)

Please never use multi-column layout -- it interferes with small screens, large fonts for visual issues, printing, and general legibility. --brion (talk) 16:51, 16 March 2009 (UTC)

It's bad for article space, but what if people want it for something in their userspace that is mainly for personal use? That shouldn't be a problem, and Ludwigs2 or someone else can update the {{col-list}} documentation to specify not to use it in mainspace. rʨanaɢ ^talk/_contribs 16:59, 16 March 2009 (UTC)

In addition, {{Colbegin}} offers CSS columns that work with colwidth (on some browsers), which should be OK for all devices. Not sure if fixed css styled columns can easily be turned off if need be, probably not. --Amalthea 17:26, 16 March 2009 (UTC)

problem updating wikipedia from IE with windows XP

From my computer using IE 7.0.5730.11CO and win XP 2002 SP 3 I get a time out error when I load an image or edit a long page of wikipedia. IE just stays waiting from the reply from the server for a long time. From another computer everything is ok. Is there any special requirement on IE options or drivers or java ? —Preceding unsigned comment added by MSacerdoti (talk • contribs) 17:43, 13 March 2009 (UTC)

See the FAQ at http://www.ie7.com/ — CharlotteWebb 08:19, 14 March 2009 (UTC)

this website is firefox website, not internet explorer FAQ —Preceding unsigned comment added by MSacerdoti (talk • contribs) 11:16, 14 March 2009 (UTC)

Um, no. Who then was a gentleman? (talk) 18:07, 16 March 2009 (UTC)

Ethnio banner

Like this user I encountered that ad but Firefox doesn't do anything when I click on the link (yes, javascript is enabled). See also this. --Ma Baker (talk) 18:57, 16 March 2009 (UTC)

Magic word "CURRENTMONTHDAY"

I have made a template {{Currentmonthday}}, rendering: December 30.

So far I have used it successfully in {{Day+1}} and {{Day-1}}. I propose to add it to the magic words in Magic words#Date & time. Every time I look at that list this suggestion comes to my mind. Now that I've made the template maybe the time is ripe. Debresser (talk) 14:34, 15 March 2009 (UTC)

If it is an en-wiki local template, we can't add it to the mediawiki documentation? It won't work on other wiki installations. --Amalthea 14:50, 15 March 2009 (UTC)

After reading the Template talk:Currentmonthday, I understand you want to add a new magic word that replaces the template. I personally see neither need nor harm with it. Doing it as Lawyer suggested below seems easy enough to me, and you'd at the very least also need to add a CURRENTDAYMONTH magic word for the more widespread d yyyy style of writing a date. --Amalthea 15:20, 15 March 2009 (UTC)

What's wrong with just using {{CURRENTMONTHNAME}} {{CURRENTDAY}} ? — Blue-Haired Lawyer 15:06, 15 March 2009 (UTC)

Oh that's great, but now figure out some way to format it based on user-prefs without linking to it

. — CharlotteWebb 15:16, 15 March 2009 (UTC)

What is it you mean, CharlotteWebb? Debresser (talk) 15:28, 15 March 2009 (UTC)

Use the upcoming formatdate parser function?

Anomie ⚔ 16:06, 15 March 2009 (UTC)

What? No {{Currentdaymonth}} for us Europeans? — Edokter • Talk • 23:42, 16 March 2009 (UTC)

Nicely done Edokter! I was thinking much the same myself. Only the US use the "March 17" format. On enwiki we use both and most other wikis use "17 March" format. But frankly it just raises my first point of "why bother" again. Neither of these templates do anything particularly complicated. Why do we need them at all? — Blue-Haired Lawyer 00:06, 17 March 2009 (UTC)

A templete's primary function is not to do anything complicated, but to save editors typing. I think this qualifies. — Edokter • Talk • 01:03, 17 March 2009 (UTC)

My opinion precisely. I completely agree with a "European" {{Currentdaymonth}}. I am European myself. It is just that Wikipedia uses the other order of month-day. Debresser (talk) 12:33, 17 March 2009 (UTC)

Bug in #time:?

The first three example work as expected, but the fourth gives an error:
{{Day+1|{{Currentmonthday}}}} = December 31
{{Day-1|{{Currentmonthday}}}} = December 29
{{Day+1|{{Currentdaymonth}}}} = December 31
{{Day-1|{{Currentdaymonth}}}} = December 29
— Edokter • Talk • 01:42, 17 March 2009 (UTC)

Because the Day+-1 template looks for the date at the end, as in the American format, probably. I'm more surprised that {{Day+1|{{Currentdaymonth}}}} works. Debresser (talk) 12:40, 17 March 2009 (UTC)

The #time: function should be able to accept any format that PHP accepts. After manual expanding the template's output, it turns out the template if fine, and that the bug occurs in #time: parser function itself:

{{#time: F j|March 17 +1 day}} = March 18

{{#time: F j|17 March +1 day}} = March 18

{{#time: F j|March 17 -1 day}} = March 16

{{#time: F j|17 March -1 day}} = Error: Invalid time.

What's even more strange, inserting a comma or the year does work:

{{#time: F j|17 March, -1 day}} = March 16

{{#time: F j|17 March 2009 -1 day}} = March 16

— Edokter • Talk • 13:46, 17 March 2009 (UTC)

Weirdniss gets better, but allows for a fix:

{{#time: F j|17 March +-1 day}} = March 16

— Edokter • Talk • 17:12, 17 March 2009 (UTC)

That seems to have fixed the problem. — Edokter • Talk • 17:17, 17 March 2009 (UTC)

I'm (unfortunately) not familiar with the way complex templates or magic words work. A few months ago I wasn't familiar with Wikipedia either, and now I write, edit, and manage to fix templates sometimes, so who knows what I'll be able to do in time. Do you plan to fix the bug? Could you make the magic words {{CURRENTMONTHDAY}} and {{CURRENTDAYMONTH}}? Debresser (talk) 14:25, 17 March 2009 (UTC)

I can't make magic words; only devs can do that. — Edokter • Talk • 14:38, 17 March 2009 (UTC)

notice copywriter's name

GFDL 1.2
4. MODIFICATIONS
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

I found a copy and pasted wikipedia article at other commercial site.

I make that article by myself.

But commercial site's user, Michael, don't notice my name at copied article.

Michael(pseudonym) only notice, wikipeda URL and GFDL.

But, Wikipedia is not copyright holder. copyright holder is me. principal author is also me, not wikipedia.

I request the copy-paste feature that auto-include my name to wikipedia articles. -- WonRyong (talk) 02:00, 16 March 2009 (UTC)

If you are requesting that you get copyright over your work, it is not possible in Wikipedia. Whatever you write is released to the public, and they can use it if they cite Wikipedia. Whoever uses it need not cite your name, as the content is not yours anymore. If you have something that you want to stay as your property, do not put in on the 'pedia.ee WP:OWN ManishEarth^{Talk • Stalk} 04:10, 16 March 2009 (UTC)

Manishearth, I'm afraid that's completely wrong. Wikipedia contributors retain copyright over all of their contributions. As a consequence of posting that material here, editors agree to grant Wikipedia an irrevocable license (currently GFDL1.2, as WonRyong notes. Because it's a license, and not a transfer or assignment of copyright, contributors retain all rights except the right to terminate their grant of license to Wikipedia. I'm sorry to be harsh, but please do not give legal opinions if there's any chance you may not be sufficiently informed on the subject, as it can be harmful to our good-faith contributors. Meanwhile, anyone who reads the above should also read Wikipedia:Legal disclaimer, which clarifies whether the above constitutes legal advice (short answer: no).

WonRyong, it absolutely sucks that people steal your (and my, and every editor's) work. It sucks just as much when they misappropriate it through ignorance. Unfortunately, it's not really practical to force mirrors into copying and displaying a list of authors, because any mirror could just omit the list. Also, Wikipedia has a long tradition of presenting articles as a communal effort, deliberately omitting editor credits from the main article page. I wish there were a good solution for this, but there isn't one. As I said, it pisses me off just as much. — Gavia immer (talk) 04:43, 16 March 2009 (UTC)

If they link back to the article on here, anyone can just follow that link to get the history of the article, so they'll see who wrote it. If they omitted that link, WP:Mirror is a better place to discuss it. -Steve Sanbeg (talk) 22:54, 16 March 2009 (UTC)

I'd follow Steve Sanbeg's suggestion. It's the easiest way to get them to comply in one way or another. - Mgm|^(talk) 10:32, 17 March 2009 (UTC)

Template talk pages

I'm not sure if it's just me, but I've noticed that there are suddenly a lot of templates in articles who's talk-page is now a redlink. Has there been a purge on talkpage deletion on templates, or have I simply not noticed this before?! Lugnuts (talk) 08:11, 16 March 2009 (UTC)

I purged about 500 blanked template talk pages about 4 months ago, other than that, I don't know. MBisanz ^talk 08:55, 16 March 2009 (UTC)

Are you noticing this in V-D-E links e.g. in navboxes? It's because previously {{Tnavbar}} always colored talk page links blue, even when the talk page didn't exist. It was recently updated with new code, and one of the changes was the removal of this masking. 「ダイノガイ千？！」^{(Dinoguy1000)} 04:10, 17 March 2009 (UTC)

Yes! That's it. Cheers! Lugnuts (talk) 09:47, 17 March 2009 (UTC)

A strange file

I was going through CSD backlog and I came across File:DigitalUK logo.png. I've deleted a file, but in case a non-administrator wants to know what it was, here is the page history:

(diff) 05:17, 8 March 2009 . . BJBot (talk | contribs | block) (1,439 bytes) (BJBot, orphaned fair use image tagging)
(diff) 22:18, 11 December 2008 . . 718 Bot (talk | contribs | block) (1,396 bytes) (== Summary == This is the logo of Digital UK ("the Company"). The copyright to the image is owned by the Company. This image is provided under the Fair Use (Logo) licensing Category as the company believes it is an important illustration for the Wikipedia)

...and here is the file history:

22:18, 11 December 2008 . . 718 Bot (talk | contribs | block) 263×74 (18,123 bytes) (== Summary == This is the logo of Digital UK ("the Company"). The copyright to the image is owned by the Company. This image is provided under the Fair Use (Logo) licensing Category as the company believes it is an important illustration for the Wikipedia)

The strange thing is the fact that the page history was intact, but the file history was already deleted when I came and the deletion log does not mention it [2]. Admiral Norton ^(talk) 18:45, 16 March 2009 (UTC)

Follow up: I've found more such images in Category:Orphaned non-free use Wikipedia files as of 8 March 2009 and I've left them non-deleted. Admiral Norton ^(talk) 19:26, 16 March 2009 (UTC)

I think you should ask the operator of User:718 Bot, which converts images into png format. Ruslik (talk) 19:57, 16 March 2009 (UTC)

OrphanBot's reported two images like that to me: File:1abvDolly 2008.jpg and File:SonarVideo3.jpg. Neither was uploaded by 718 Bot. --Carnildo (talk) 07:36, 17 March 2009 (UTC)

never received a new password

I sent for a new password some 10 or so hours ago, but I have yet to receive one. cannot seem to find the old one or I'd use it. seems I did remember my username, Wiki does list that in the username space, but none of the passwords I thought I may have used are accepted. what happened to my new password? or does it take a full 24 hours to get one? that would be pretty bad turn around time for an automated system. —Preceding unsigned comment added by 75.95.160.69 (talk) 06:28, 17 March 2009 (UTC)

It should be instantaneous. Make sure you spelled your username correctly, capitalization does matter. Also, you need to make sure the email you are checking is the email you registered with. MBisanz ^talk 07:50, 17 March 2009 (UTC)

I did use the right eddress, and it didn't require a username that I recall, but if it did, then maybe I have the wrong one. so I can't work in Wiki, can't reply to a comment. it's just a tech. murphy's law for me today. not just Wikki. —Preceding unsigned comment added by 75.95.160.69 (talk) 08:05, 17 March 2009 (UTC)

Did you provide your address when you signed up? You could be using a valid email address but when the system can't link it to your account, it won't give you a new password. - Mgm|^(talk) 10:28, 17 March 2009 (UTC)

Template formating help

Resolved

– Template fixed, a round of virtual cocktails for all. -- Banjeboi 06:14, 18 March 2009 (UTC)

I'm not figuring out how to make {{Top 50 U.S. City Mayors}} automatically defaulted to collapsed. Can someone be my hero and fix it? -- Banjeboi 12:40, 17 March 2009 (UTC)

Gnevin fixed it. In the future, you can use the |state= parameter; state = collapsed or state = autocollapse should do it. rʨanaɢ ^talk/_contribs 13:54, 17 March 2009 (UTC)

My wee brain is not likely to remember but I will try. -- Banjeboi 14:22, 17 March 2009 (UTC)

Haha, no worries. It's also in the documentation for {{Navbox with columns}}, if you ever forget. rʨanaɢ ^talk/_contribs 14:39, 17 March 2009 (UTC)

Okay .... same issue different information. Danger Will Rogers, arms flailing, need cocktail! -- Banjeboi 14:53, 17 March 2009 (UTC)

Updated statistics

Yea, I know this is getting old, but here are some updated statistics on the velocity of edits being made to Wikipedia. Have fun! MBisanz ^talk 06:34, 18 March 2009 (UTC)

Edit tools/drop down weirdness

This one has been annoying me for a couple of days now. I recently upgraded to Firefox 3.0.7 from 2.something. Before the upgrade, when editing I always had the drop down tool list thingy below the edit box (I am not sure what the correct name is, but it's the drop down where you can select Insert, Wiki markup etc). Since the upgrade it seems to be hit and miss as to whether I get it or the far less useful copy and paste table (the one without the dropdown). I assume that this is a javascript issue. Is there some way I can force the use of drop down list every time I edit? Thanks. – ukexpat (talk) 14:07, 18 March 2009 (UTC)

Does Tools/Error Console have anything interesting? Have you checked whether the problem persists with your monobook.js blanked? Algebraist 14:12, 18 March 2009 (UTC)

What should I be looking for in the error console? Thanks. – ukexpat (talk) 15:11, 18 March 2009 (UTC)

Problem for me in IE6 as well; it's hit-and-miss most of the times. — Edokter • Talk • 14:20, 18 March 2009 (UTC)

I've been using User:Ilmari Karonen's edittoolstest script since the new edittools were first being written, without problem, on various versions of Firefox. Recently, I tried removing the script from my monobook.js, since the new edittools have been officially deployed, only to find that they are, indeed, hit-and-miss (needless to say, I promptly added the test script back in). I didn't think to look at the error console, though. 「ダイノガイ千？！」^{(Dinoguy1000)} 18:57, 18 March 2009 (UTC)

Wikipedia text editor "word doubling" bug?

I've encountered a curious circumstance a dozen or so times during several years of Wikipedia editing. It seems to me that the text editor will take a word that is at the end of a line, and duplicate it unexpectedly, probably during SAVE. When i look at the output, that word appears twice.

The problem is, this happens so rarely that i don't know how to reproduce it. But i have also seen words doubled in articles that wouldn't normally be doubled, and so i expect that this phenomena has affected others as well.

One possibly complicating factor, it might be a browser bug, or an interaction between the Wikipedia text editor and a particular browser. I use Firefox, and have used Firefox for most of the time that i've been editing. I always use the latest version. (My current OS is Windows Vista, but i encountered the problem while editing under Windows 2000 as well.)

Has anyone else experienced this?

thanks, Richard Myers (talk) 14:45, 18 March 2009 (UTC)

php syntax trees

Circeus just showed me phpSyntaxTree, which auto-generates syntax trees (as .png images) out of some code. It's an external application, so the only way to use it with WP is to make a tree over there and then save the image and upload it here as a file; but I was wondering if it's possible to add something to MediaWiki that allows you to embed the code directly in an article (like how we can embed LaTeX with <math></math>). Would that sort of thing be a huge pain, or is it relatively simple? And if it is simple, where would one go about submitting a suggestion like that? rʨanaɢ ^talk/_contribs 15:01, 16 March 2009 (UTC)

By the way, I think the source code for phpSyntaxTree is available at Google Code: [3]. rʨanaɢ ^talk/_contribs 15:02, 16 March 2009 (UTC)

The short answer is yes. External application are a no-no, but the source code is available under the same licence as MediaWiki (Wikipedia's software) and it's even written in php. You'd need to make an extension request. You could try here although the warning at the top of the page is rather off putting. — Blue-Haired Lawyer 14:00, 19 March 2009 (UTC)

Footnotes AND References?

The article Social Security debate (United States) ends with a list of Footnotes and a list of References, with more than 40 entries in each. Both look like the style of list produced by the <ref> ... </ref> ... <references/> style that I am familiar with. Is this some new and even more complicated version of that style, or is the article just botched? If the first, where do I read about it? --70.48.231.39 (talk) 19:39, 17 March 2009 (UTC)

It's caused, it seems, by a hideous mixture of <ref></ref> tags and {{ref}} templates. I can't see the value of keeping them separate but I am not feeling bold enough to tackle it at the moment. – ukexpat (talk) 19:44, 17 March 2009 (UTC)

Nowadays it's also possible to use the 'group="foo"' parameter in ref templates to produce separate note groups - see WP:REFGROUP for details. This is probably a better solution than mixing reference styles. — Gavia immer (talk) 21:07, 17 March 2009 (UTC)

I think the mixup in that particular is possibly due to the fact that ref group hasn't always been an option... --Izno (talk) 14:20, 19 March 2009 (UTC)

Announcing the Abuse Filter

Hi all,

After about six months' waiting, I've finally activated the AbuseFilter extension on enwiki!

In brief, the Abuse Filter allows automated heuristics to be run against every edit. It's designed as an anti-vandalism tool for very simple and/or pattern based vandalism.

PLEASE do not activate a filter with any action other than flagging without testing it first with just flagging enabled. — Werdna • talk 23:36, 17 March 2009 (UTC)

Woohoo. Dragons flight (talk) 23:53, 17 March 2009 (UTC)

And the very first filter ignores your injunction... perhaps that "PLEASE" should've been even bigger. On a more serious note, where is the correct place to discuss new filters, and shouldn't said place be linked from the special page? Algebraist 23:59, 17 March 2009 (UTC)

I can't edit them, and one of the filter has already warned inappropriately. They need to be disabled. Cenarium (talk) 00:14, 18 March 2009 (UTC)

Give yourself the 'Abuse Filter editors' right. Algebraist 00:15, 18 March 2009 (UTC)

Fellow Wikipedians, please read the manual on your new toy and don't use it irresponsibly. It is shiny, new, and fun, but there is lots of time to use it properly. Discuss and test first, then deploy. Chillum 00:24, 18 March 2009 (UTC)

Thanks. I think we should test live and discuss before enabling a filter... Cenarium (talk) 00:25, 18 March 2009 (UTC)

Which is what Wernda said. If only we had a more responsible bunch of admins, or a way to get rid of the irresponsible ones. Algebraist 00:29, 18 March 2009 (UTC)

Just be aware that everyone (except Dragonsflight) who has created a filter thus far has been talking to Werdna in real time as they do it, over IRC. So everyone is checking and double and triple checking everything. Prodego ^talk 01:57, 18 March 2009 (UTC)

Showing the IP address on blocked createaccount actions seems like a bad idea. This probably goes against the WMF privacy policy. --- RockMFR 02:44, 18 March 2009 (UTC)

I'm pretty sure "investigating abuse" is covered by the privacy policy as an exception, and I don't think it's entirely a bad idea iff the action is "disallow". If it were "warn", say, that would be a different issue. {{Nihiltres|talk|log}} 03:07, 18 March 2009 (UTC)

Not a huge deal yet, but I agree that it might be best not to show the IPs. Still thinking about the best way to do this, technically speaking. — Werdna • talk 03:27, 18 March 2009 (UTC)

Werdna, I find discussing the specific filters a bit cumbersome at the moment, since the "Notes" textbox has to be (ab)used for it, and for private filters it's the only place where they can be discussed.
I'd like it if the notes section could be shown and edited just like any other wikitext page. Since I'm assuming that this would be rather difficult, maybe just displaying the parsed output of the wikitext notes, enhanced with some javascript to hide the textbox and only show it by clicking an "edit" link, might be a doable middle ground. --Amalthea 13:50, 18 March 2009 (UTC)
- Maybe there could be a link to a talk page instead. Like Special:AbuseFilter/2 linking to Wikipedia talk:AbuseFilter/2. --Conti|✉ 13:52, 18 March 2009 (UTC)
  - That's OK for public filters, but discussions of the specifics of private filters shouldn't be held on a public page. --Amalthea 14:14, 18 March 2009 (UTC)

Does the Abuse Filter do short-circuit evaluation? --- RockMFR 01:45, 19 March 2009 (UTC)

This should be a great tool... could diff buttons be added to it, though? The AbuseLog could be used for vandalism fighting even if it isn't fully automated. –Drilnoth (T • C) 02:03, 19 March 2009 (UTC)

Werdna, for IP blocks you need to use something similar to the autoblock numbers (see Special:Ipblocklist):

21:27, 19 March 2009, Black Kite (talk | contribs) blocked #1361759 (expires 21:27, 20 March 2009, account creation blocked) (Autoblocked because your IP address was recently used by "Abbarocks"...)

etc. — CharlotteWebb 21:53, 19 March 2009 (UTC)

Check Wikipedia

Every time that I've tried to update Wikipedia:WikiProject Check Wikipedia with the content from the toolserver page, Wikimedia says that there's an error and I need to try back later. I haven't noticed any problems editing other articles today... is there a way to update this? I'm not sure if it would matter, but Wikipedia:WikiProject Check Wikipedia/Translation was just created a few days ago. –Drilnoth (T • C) 00:25, 19 March 2009 (UTC)

Probably has something to do with the Abuse Filter. See #Not allowing editing to AN & ANI. --- RockMFR 01:36, 19 March 2009 (UTC)

Okay; thanks for pointing that out. –Drilnoth (T • C) 01:41, 19 March 2009 (UTC)

It's actually still not working right. Any other ideas? Or could it still be that? –Drilnoth (T • C) 01:46, 19 March 2009 (UTC)

What's the exact error message you're getting? --Carnildo (talk) 07:22, 19 March 2009 (UTC)

It's just the generic Wikimedia Foundation error message when I try to save... "Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes.
You may be able to get further information in the #wikipedia channel on the Freenode IRC network.
The Wikimedia Foundation is a non-profit organisation which hosts some of the most popular sites on the Internet, including Wikipedia. It has a constant need to purchase new hardware. If you would like to help, please donate."
It shows up fine in preview mode, but just won't save and that error pops up. I've seen it before on various pages, although not much, and usually just backing up a few pages and resaving fixes it. –Drilnoth (T • C) 13:27, 19 March 2009 (UTC)

Yes, probably. Something to do with the abuse filter choking on his 800kB diff. Most of the filters only operate on new users or mainspace pages, so I'm not sure which one is causing the issue. As a rule of thumb, if you can preview successfully but not save, then the problem is probably with an abuse filter rule (or sometimes another filter such as the spam blacklist). Dragons flight (talk) 07:44, 19 March 2009 (UTC)

Watchlisting sections?

Is there any script or some such that would allow users to watchlist only a section of a page? As it currently stands, it is essentially pointless to watchlist talk pages which receive lots of traffic and have multiple active discussions; if you watch the page and an edit occurs, you have to manually check if your section was edited. Watchlisting sections would solve this quite nicely! --Cryptic C62 · Talk 15:51, 19 March 2009 (UTC)

Actually, you don't have to manually check if your section was edited, as the displayed change in the watchlist shows the edited section in the edit summary(in most cases, sometimes editors remove this). But I agree that the watchlist should be renovated. Some more filters should be added (not just the minor edit, bot, anon, not-anon, and your edit which are already there) Maybe by looking at the mw code for watchlists, you could figure it out.

ManishEarth^{Talk • Stalk} 16:07, 19 March 2009 (UTC)

No such tool exists at present, and no-one's thought of a good way to make one yet. See Wikipedia:Perennial proposals#Allow watchlisting individual sections of a page. Algebraist 16:37, 19 March 2009 (UTC)

Sections aren't really well-defined at the software level. Let's say you are only "watching" one section and I click "[edit]" on the next section after it. My only change to is to remove the section heading from the latter section, which causes the two sections to become one. Should this show up in your hypothetical "section watchlist" (remember, I never edited your section)? — CharlotteWebb 22:00, 19 March 2009 (UTC)

Dynamic evaluation

I'm not sure how to phrase this. Is there a way, either by magic words or by site JS, to get the name of the user who clicks a wiki-link?

For instance, our instructions on how to create a sub-page in user space are simple enough once you understand how to do it, but they're far beyond what a new editor can fathom, so it would be nice to have a static article where the editor could click on "make a subpage" and for me, it would edit User:Franamax/Subpage and for Jimbo it would be User:Jimbo Wales/Subpage. Even better would be a thingy where I could click it and it would ask me for the subpage name.

The context here is to create a simple method for new editors who have made a new article that has been CSD'ed to have an easy path for userfication. The CSD notice could have a link to a page like this one - point 2., I'm trying to fill in the "[instructions here]" part of it with a one-click link.

Does any of that make sense? :) Franamax (talk) 19:47, 19 March 2009 (UTC)

Special:Mypage lets you go to certain pages in your userspace (for example, Special:Mypage/monobook.js would take you to your own monobook subpage). So, using that, you could create a Special:Mypage/Subpage link, but it couldn't be renamed without moving the page. I'm stumped about changing the name. –Drilnoth (T • C) 19:55, 19 March 2009 (UTC)

Instead of a link, just use it as the default value in an InputBox, so the user can change it prior to creation. -Steve Sanbeg (talk) 20:20, 19 March 2009 (UTC)

Oh yes, thanks both! Those are valuable clues. I could maybe use the CreateArticle extension, using prefix=, subpage=, preload= in combination with Special:Mypage. Hmm - maybe I should try this on my own localwiki first so I don't asplode anything :) Looks like I have the ingredients though, I just have to figure out how to cook the dish. Thanx! Franamax (talk) 21:49, 19 March 2009 (UTC)

I know this has been a perennial proposal. It should probably be added to the FAQ section. I can't find it but I know there's a request on bugzilla for a CURRENTUSER variable which is closed as WONTFIX. Rightly so as I know I wouldn't want to accidentally click on a link like this.

The wgUserName variable is not so bad as users at least have the option of disabling javascript or otherwise not opting into whatever parlour-game rquires this feature. Plus malicious code exploiting this variable would have at least some chance of being reverted before one's cache expires, and a malscript can always ascertain the user's identity anyway without needing this variable (by looking at the <li id="pt-userpage"> element, for example). — CharlotteWebb 22:21, 19 March 2009 (UTC)

Fyi on per-article edit notices

Just noticed mw:Special:Code/MediaWiki/48276. Just wanted to give enwiki a head's as these are pretty heavily used here. (Should this be somewhere else like WP:VPT? Apologies if so) ^demon^{[omg plz]} 20:18, 10 March 2009 (UTC)

And for those of us who are code-challenged, this would mean...? ➲ redvers ^{see my arsenal} 20:33, 10 March 2009 (UTC)

"remove per-page editnotice functionality, message files and message cache are supposed to be global data". Make of that what you will. - Jarry1250 ^{(t, c)} 20:38, 10 March 2009 (UTC)

That per-page edit notices are being removed. ^demon^{[omg plz]} 21:48, 10 March 2009 (UTC)

That's very useful. Not. Black Kite 22:40, 10 March 2009 (UTC)

Have we asked why yet? (That cryptic explanation means nothing to me) –xeno (talk) 22:42, 10 March 2009 (UTC)

I'm with the Kite here. That seems like a weird and dumb move, to remove 'em. //roux 22:52, 10 March 2009 (UTC)

The reason why is someone was foolish enough to bite a developer. ;) Okay now to figure out the real reason... FunPika 23:00, 10 March 2009 (UTC)

I emailed Domas a request for clarification. Dragons flight (talk) 18:10, 11 March 2009 (UTC)

It means they forgot to update line 427:

- # Optional notices on a per-namespace and per-page basis

+ # Optional notices on a per-namespace basis

Is there some reason it wouldn't be better to just make the latter feature optional and disable it in the configuration of our wikis? Other sites may find this useful and be less concerned about cache issues. — CharlotteWebb 15:34, 11 March 2009 (UTC)

It wasn't removed "nicely" because it was a live hack (which means, a quick edit and immediate scap) by Domas to remove a very bad feature, when he noticed the horrible bloat and overhead it caused to the message cache. Domas generally doesn't care about MediaWiki features, he cares about server performance on Wikimedia. It had nothing to do with biting the developer, it was removed before the actual biting occured (said biting applied by the original feature requestor, see bugzilla:15102). Some other developer can re-add the feature, enable it by default and disable it on WMF. Domas simply acted fast to reduce the bloat and improve performace. You can talk until you're blue in the face about how much we "need" a feature, but if it threatens to bring the servers down, it goes bye-bye. Wikimedia runs on a tiny fraction of the cost it takes to run a typical cluster of websites of similar popularity, so efficiency is paramount.

I had argued strenuously and (I thought) persuasively against this feature, with MZMcBride and Krimpet (see 20080810.txt, starting at [07:02:38]) saying it was a bad idea and would most definitely get removed. It was only sad that I was ignored at the time and that the removal took 6 months, spanning a release, and causing a dependence on the feature to grow in the interm. --Cassandra (rant). P.S. I (and Werdna, and a few others) made the same argument against the horrible padleft hack and these things. If reliance is given to them and the feature is later removed in 6 months, I told you so (looking at you brion ^_^). 19:38, 11 March 2009 (UTC)

I believe you are mistaken about the immediate scap. (The functionality appears to still be live here.) In six months only about 130 edit notices were created here. I'm not sure what the threshold for harm is, but I doubt it reached the level of being an emergency. That said, the functionality is desired and I would say desirable, do you have a suggestion for implementation that would keep the messages out of the Mediawiki space? Dragons flight (talk) 20:51, 11 March 2009 (UTC)

Nope, I watched him make the edit and then scap (sync common all php) includes/EditPage.php a few seconds later. And en.wp is far from the worst offender (see [4] for example). I have no such suggestion for implementation, do I need one in order to point out an idea is bad and shouldn't be implemented (at the time, before it even was implemented) until such a solution is possible? Lack of viable alternative does not invalidate the basis of my objection ^_^. Say for example, someone wants to go swimming in shark-infested waters, and I suggest they do not. If when asked for an alterntative I am left speechless, that they ignore my advice and swim anyways is not a fault of my warning. --Splarka (rant) 07:25, 12 March 2009 (UTC)

P.S. Regarding "those things", I fully expect the padleft hack to ultimately die a horrible death (and wouldn't have given a reprieve if I was Brion), but since it does work, I am hoping that if hackish string functions are shown to be useful then it increases the probability of addressing the 2+ year old requests for actual string support. Dragons flight (talk) 20:51, 11 March 2009 (UTC)

Note that per-page editnotices are not completely disabled in that revision, just per-page editnotices in the article, File, MediaWiki, Help, Help talk, Category, and Category talk namespaces (i.e. the ones where subpages are disabled). When I tried to ask why,[5] that question was ignored. And the only reason given for removing it at all was "this feature introduced bad practices", no mention of performance issues. Anomie ⚔ 22:10, 11 March 2009 (UTC)

Dumb question: what's a per-article edit notice? Thanks, --A. B. ^{(talk • contribs)} 13:34, 12 March 2009 (UTC)

It's the display of e.g. MediaWiki:Editnotice-5-Signatures at the top of WT:Signatures when you edit the page, compared to per-namespace edit notices like MediaWiki:Editnotice-7. --Amalthea 13:50, 12 March 2009 (UTC)

Thanks for the explanation. --A. B. ^{(talk • contribs)}

The Editnotice Plan

I propose the following solution that will preserve per page editnotices but move them out of the Mediawiki space and stop annoying Domas.

Move every per page editnotice from Mediawiki space to a "/Editnotice" subpage of its corresponding page.
Add a parser function loader to the end of every per namespace editnotice that will check for the page's corresponding "/Editnotice" and load it if it exists.
Add ".*/Editnotice <noedit|autoconfirmed>" to the Titleblacklist which will effectively semiprotect all editnotice pages (we could also full protect them, but I'd like to see if semi is enough).

Dragons flight (talk) 04:26, 12 March 2009 (UTC)

If the discussion above is correct, editnotices are only being disabled for namespaces without subpages enabled (e.g., the very ones where this won't quite work as you intended). Moreover, putting article editnotices in article space, as this proposal would do, is not a good idea - search engines (our own, Google, etc.) would index all of them. A better idea is to put them in the corresponding talk namespace, and put talk page editnotices at [[/Talk-Editnotice]] or some similar location that could be distinguished from the editnotice for the main namespace. Just a minor tweak, but I thought I'd better point it out lest Domas simply get mad in a new and different way. — Gavia immer (talk) 05:37, 12 March 2009 (UTC)

Putting parser functions in widely used messages is a bad idea. It would almost certainly get reverted (see MediaWiki:nstab-main's history). ^demon^{[omg plz]} 12:18, 12 March 2009 (UTC)

nstab-main is visible on every page view, editnotices only when editing a page. --Amalthea 13:14, 12 March 2009 (UTC)

Personally, I'd go for storing the editnotice for a page at something like Wikipedia:Editnotice/for/{{FULLPAGENAME}} (and I guess title-blacklist "Wikipedia:Editnotice/for/.*"). As for using parser functions, Domas stated in the revision comments "if you need, you can put editnotices in some subpage of project namespace, etc, and include them via template." No promise he wouldn't go back on that statement, but for now it's what we have. Anomie ⚔ 16:22, 12 March 2009 (UTC)

I'd drop the "for" as a superfluous, and might consider Template: rather than Wikipedia: (they do feel like templates, even if they aren't being used in the normal way). However, I can see advantages of giving them all a common stem. It would also allow us to Robots.txt them all into oblivion which would address one of the concerns raised above. Dragons flight (talk) 16:47, 12 March 2009 (UTC)

I put the "for" in there so there wouldn't be conflicts with the existing subpages of Wikipedia:Editnotice. If you pick some prefix that isn't already in use with subpages (unlike Template:Editnotice, unfortunately), then the "for" could be done away with. Anomie ⚔ 17:43, 12 March 2009 (UTC)

Though it is potentially confusing, neither of those would create direct conflicts as long as we insist that page names start with uppercase letters. Dragons flight (talk) 18:00, 12 March 2009 (UTC)

We could also consider using "Editnotices" (plural) as a stem in Wikipedia or Template space. Dragons flight (talk) 18:57, 12 March 2009 (UTC)

I'd perhaps recommend pondering a general solution for out of band notices; some of these belong on the article view in addition to the edit page. --brion (talk) 16:28, 12 March 2009 (UTC)

(edit conflict) My understanding, relayed through a third party, is that Domas is primarily worried about polluting the message cache and is okay with using parser functions to simulate the same behavior. Also, 7 of the 18 per namespaces editnotices have already had limited use of parser functions for months. Dragons flight (talk) 16:29, 12 March 2009 (UTC)

Personally, I don't understand why "polluting the message cache" requires "immediate removal and scap and no one who knows what's going on willing to explain it". If the real reason was "the message cache was overflowing because of this crap", that would have been a much more informative reason to give. Anomie ⚔ 17:43, 12 March 2009 (UTC)

Notify talk pages now

Unless they come back two hours ago, someone really needs to run a bot to notify every talk page of articles with editnotices in them. I just checked the one that I know of and it's been disabled, but anyone not watching this page won't know. This isn't some "oh well whatever" case -- usually the notices are an important help in curving unuseful edits. ♫ Melodia Chaconne ♫ (talk) 11:28, 12 March 2009 (UTC)

I've made a list of the pages with a non-empty editnotice in the affected namespaces. Do with it what you will. Anomie ⚔ 17:55, 12 March 2009 (UTC)

List of affected pages

List of pages that will be affected if they finish the job

I just had a thought, as far as fixing the immediate problem until we finish the discussion: Create MediaWiki:Editnotice-0 as {{#ifexist:MediaWiki:Editnotice-0-{{PAGENAME}}|{{MediaWiki:Editnotice-0-{{PAGENAME}}}}}}, and append {{#ifexist:MediaWiki:Editnotice-8-{{PAGENAME}}|{{MediaWiki:Editnotice-8-{{PAGENAME}}}}}} to MediaWiki:Editnotice-8. Once we decide where to move the per-page editnotices to in order to get them out of the MediaWiki namespace, those can be revised as needed. Anomie ⚔ 18:46, 12 March 2009 (UTC)

I would rather not. I'm afraid that continuing to rely on Mediawiki space message would look antagonistic and I don't think it will take that long to come to an agreement here. Dragons flight (talk) 18:59, 12 March 2009 (UTC)

Melodia made it sound quite urgent. Anomie ⚔ 01:15, 13 March 2009 (UTC)

Well it just seems to me that if there's an edit notice, it's to, ya know, notify editors about something important on the page. So taking it away without notifying them so they can fix it (probably by adding the comments that were taken out when the editnotice was put up) makes it kinda risk-worthy, IMO. ♫ Melodia Chaconne ♫ (talk) 02:12, 13 March 2009 (UTC)

Alternatives

Ajax maybe? We might consider something similar to the edittools fix. Then we could add a user preference (gadget) to disable it for people who find it obnoxious. — CharlotteWebb 14:28, 12 March 2009 (UTC)

We could do a preference with the current system (I think) by wrapping the custom notices in some CSS and making a Gadget to hide it. Mr.Z-man 17:19, 12 March 2009 (UTC)

Indeed. Since their implementation all editnotices have been wrapped in id="editnotice" or some such to allow people to hide them in their CSS subpages. (Some of the user talk ones especially can be overbearing and excessive.) --MZMcBride (talk) 18:29, 12 March 2009 (UTC)

I thought the discussion about edittools and the donation banner made clear the difference between "hide" and "disable". — CharlotteWebb 20:34, 12 March 2009 (UTC)

If its done via the transclusion method then there's no real reason to make the distinction, as the amount of overhead is minimized by putting it in the same request as the edit page. An option to disable it would only really be necessary if it was done via AJAX as the content would have to be loaded from a second HTTP request. Mr.Z-man 21:26, 12 March 2009 (UTC)

Edit Notices Plan 2.0

In consideration of the above comments, and in the interest of boldy doing something, I suggest the following revised plan:

Move every per page editnotice from Mediawiki space to a corresponding subpage of "Template:Editnotices", such as "Template:Editnotices/Sarah Palin" and "Template:Editnotices/Wikipedia talk:Deletion Review". Template:Editnotices itself could hold some kind of overview description, or just redirect to Wikipedia:Editnotice.
Add a parser function loader to the end of every per namespace editnotice that will check for the page's corresponding page in this Editnotices psuedospace and load it if it exists.
Add "Template:Editnotices/.* <noedit|autoconfirmed>" to the Titleblacklist which will effectively semiprotect all editnotice pages (we could also full protect them, but I'd like to see if semi is enough).
Add "/wiki/Template:Editnotices/" to the Mediawiki:Robots.txt exclusions to keep out search engines.

Dragons flight (talk) 22:30, 12 March 2009 (UTC)

P.S. Since this is a wiki, we can still go back and change things latter if someone has a better solution. :-) Dragons flight (talk) 22:32, 12 March 2009 (UTC)

Numbers 1-4 refer to Dragons flight's message above.

4: Yes, I think I agree that editnotices should be excluded from the external search engines.

2: What you are talking about is the same thing as the {{editnotice loader}} that I coded up in October 2008. So I am happy to report that we have already tested this approach and it works very well. And I coded many of the other editnotice related templates, so I have some knowledge in this area.

But let me start from the beginning:

5: I tested and it seems to be true that per page editnotices are disabled for some namespaces.

6: I don't know if the global per namespace editnotices still work for all namespaces, I have to test that to know. If they still work then we can use the template based editnotice loader approach, like what Dragons flight describe above and what I coded as the {{editnotice loader}} last year.

7: The problem seems to be that the devs don't want editnotices to be placed in the MediaWiki space. And if I remember right there are some specific caching issues with that namespace which means it is a bad thing to put too many pages into that namespace.

8: However putting the editnotices in some other namespace should probably be okay, at least from a server load point of view. And editnotices are anyway only loaded when people edit pages, which probably is only a small part of the Wikipedia server load. And template space seems like a logical choice since editnotices kind of are templates.

So back to the editnotice loader:

1: We should not use any colons ":" in the names of the editnotices. Since that means we can not use template coding to pick apart the name. And thus not do nifty things like having the editnotice's pages automatically create links back to the page they belong to. So we should not place an editnotice at "Template:Editnotices/Wikipedia talk:Example", instead we should place it at "Template:Editnotices/Wikipedia talk/Example". (That would be the editnotice for the page Wikipedia talk:Example.)

9: To avoid name collisions we should name the editnotices for the main (article) space like this: "Template:Editnotices/Main/Example". (For the article Example.)

10: We can make "group editnotices", that is an editnotice that shows on a page and all its subpages. They could be named like this: "Template:Editnotices-group/Wikipedia/Example" That would be the editnotice for Wikipedia:Example and all its subpages, but not for their talk pages.

3.1: I think that editnotices for most namespaces need to be fully protected. I think only user space and perhaps template space editnotices can be open for regular users (semi-protected). Last year when we discussed the security aspects of editnotices then most other editors who understand editnotices thought that we only could open user space. (There are some pretty nasty things you can do if the editnotices are not protected.)

3.2: I am happy to hear about the MediaWiki:Titleblacklist, it seems to mean we can choose to protect ranges of pages, so we still can make protected editnotices without using MediaWiki space.

3.3: We have already tested a feature for the {{editnotice loader}} that makes it so a user himself can block editnotices in his own user space. That is, only admins would be able to add and edit the editnotices for that user.

11: The features and possible features and security implications etc. of the {{editnotice loader}} were discussed at Wikipedia talk:Editnotice#Slash style editnotices last year. But we were ordered by the developers to not deploy it. But I think they had misunderstood what it was doing, or they were concerned about something that they didn't explain (like filling up MediaWiki space).

12: If you take a look at the code of the {{editnotice loader}} don't be too scared, we can make it much simpler. That one has a lot of code since it has a lot of bells and whistles to make editnotices a very user-friendly system.

13: I think that further technical discussions should be done over at Wikipedia talk:Editnotice. I just wanted to give a quick overview here. And yes, this is complex stuff, this really just was a quick overview...

--David Göthberg (talk) 00:17, 13 March 2009 (UTC)

I don't understand your point #1.

{{#titleparts:Template:Editnotices/Wikipedia talk:Foo | 1 | 2 }} = Wikipedia talk:Foo
{{NAMESPACE:Wikipedia talk:Foo}} = Wikipedia talk
{{PAGENAME:Wikipedia talk:Foo}} = Foo

With regards to 5/6, per page notices are disabled in some namespaces and probably will be disabled in all namespaces soon enough. The namespace level notices are active everywhere and should stay that way.

With respect to 10, that is a future issue. I'd like to address restoring the previous functionality before we get into extending it.

On the question of protection, there is relatively little that one can do to abuse an edit notice that one couldn't accomplish by editing other kinds of templates, and yet we don't protect all templates everywhere. In keeping with the wiki spirit, I think it is better to start at semi and see if there is actually significant abuse. Irrespective of what's done with the titleblacklist, one could still choose to full protect individual examples in the event of isolated problems.

Dragons flight (talk) 04:03, 13 March 2009 (UTC)

1: Eh? I didn't know that those magic words could take parameters like that. So since you pointed it out I went checking: It is a new feature from January 2009. So that wasn't available when we coded the old editnotice loaders. Thanks for telling us about that new feature, MediaWiki is getting better every day! :)) Since we now can handle the colons, then I think I agree with you, it seems nicer to use the page names unchanged. It perhaps doesn't simplify the code, but those names will be more human-readable.

10: Hehe, it's actually the other way around. The old editnotices that MediaWiki supplied never were "per page" editnotices. They all were group notices. An editnotice for the page "Wikipedia:Example" also was visible on all subpages of that page such as "Wikipedia:Example/sub/sub". And that worked on all levels, so if there also were an editnotice for "Wikipedia:Example/sub" then "Wikipedia:Example/sub/sub" would show both those notices. But "per page" notices are more user-friendly for everyday use, and they are what almost all users expect. I too was surprised when my editnotices also turned up on my subpages. Although the old group-notices are much more flexible for us who know advanced template programming. Thankfully it isn't much more work to make an editnotice loader that supplies both functions.

3.1: I don't want to get into lengthy discussions here on the Village pump. Among other things because they disappear deep into the archives here too fast. But there are some good reasons why we should not let everyone edit the editnotices for instance for articles. We already have had problems with the editnotices. But as I said, you are welcome to Wikipedia talk:Editnotice to read about some of it and discuss it.

11: Ouch, this reminds me why I didn't keep lobbying to be allowed to install the old user-friendly editnotice loader last year. (I stopped just some day after the devs said no.) I realised that if too many users get to make and edit the editnotices then the editnotice system will do more harm than good. If I don't remember wrongly we have already had edit wars over editnotices, and editnotices that were longer than the article, and editnotices that broke the page. And that was caused by well meaning editors, that wasn't even attacks. That is, editnotices provide just a very small benefit, but they cost a lot of problems. Thus a too user-friendly and open editnotice system is probably a bad thing. But it took some time for me to realise that, since I was blinded by all the nifty functions and cool programming we could do with it. We could make it so very user-friendly...

--David Göthberg (talk) 11:17, 13 March 2009 (UTC)

(ec) Point #1 was valid at the time when the magic words NAMESPACE and PAGENAME didn't work as parser functions (rev:46630). FWIW though, titleparts needs to be invoked like
{{#titleparts:Template:Editnotices/Wikipedia talk:Foo/Bar/Foo | 0 | 2 }} = Wikipedia talk:Foo/Bar/Foo
to work with subpages
Amalthea 11:21, 13 March 2009 (UTC)

Regarding the protection question question, just consider if someone put this garbage in an editnotice.

Correct me if I'm wrong, but it looks like {{editnotice loader}} would allow an edit notice for WP:AN+subpages, and one for just WP:AN/I, but not (directly) one for WP:AN/I+subpages.

David Göthberg, you mentioned a few times that the devs said not to implement your editnotice loader; do you have a history link for that? Anomie ⚔ 12:11, 13 March 2009 (UTC)

Anomie: Right, that attack is just one of several possible attacks. There are some sneaky attacks that make tools like Twinkle crash when those tools try to edit a page, in spite the page looking very normal and innocent.

I don't remember all the details, and I am not in the mood to reread the code of {{editnotice loader}}, but from what I remember and from what I wrote in the loader's documentation: Yes, I think you are correct. That loader only have one level of group notices, thus could not load a group editnotice for a Wikipedia:Example/sub page and all its subpages. But we could of course easily add that feature if needed, but at the time I coded that I didn't think it would be needed. And that template anyway is only an early beta version, it was not meant to be deployed before a lot more discussion and testing of its functions had been done.

Actually, my plan was to break it up into several templates, sort of one for each namespace. (But many namespaces could use the exact same version, thus perhaps only 4 or so templates really needed). That would make it easier on the servers, instead of having all the code and logic for all namespaces in one single large template.

Sorry, I have not had the time yet to spend some hours digging through the archives to find the old discussion where the devs very strongly asked me to not deploy the editnotice loader.

--David Göthberg (talk) 18:30, 15 March 2009 (UTC)

It seems to me that 4 would be the max needed, and only 2 needed if we want to forgo the idea of "user-editable" notices (which IMO would be a good place to start; it can always be added later).

I'm interested in seeing what the devs said, whenever you do get time. Anomie ⚔ 22:57, 15 March 2009 (UTC)

Is the conversation where devs said no Wikipedia:Village pump (technical)/Archive 49#User-friendly editnotice system? If that was it, the objections there don't seem to apply anymore: the devs are now removing features from the editnotice system rather than considering adding them, and it's now about more than just "slash-style" page names. Anomie ⚔ 23:20, 15 March 2009 (UTC)

Progress

I've gone ahead and done steps 1-4 in plan part 2 above for the Article and Talk space edit notices. I'll try to work through the rest later. I am currently using {{editnotice load}} as the loader, which checks for only a single corresponding page at Template:Editnotices/{{FULLPAGENAME}}. This is a lot lighter than {{editnotice loader}} and I wanted to get the edit notices back as quickly as possible without getting hung up on that extra complexity. I would expect features to be added as we go forward.

I went ahead and semi-ed the Editnotices pseudospace. I am aware that both of the people above to comment on protection seem to think all edit notices should be full protected. We can of course change this later if that is what the consensus ends up being. For the moment I left it at semi both because I think that is a better option, and because it will make things easier if there is clean up needed in the immediate aftermath of this migration. Dragons flight (talk) 19:36, 14 March 2009 (UTC)

Dragons flight: Who do you think you are?

I see that you have now deployed your {{editnotice load}} to the entire article and article talk space. (See MediaWiki:Editnotice-0 and MediaWiki:Editnotice-1.) That means you have deployed functionality that affects all articles and their talk pages on the entire English Wikipedia.

Have you had anyone check your code and test it before such a site wide deployment? I see no evidence of anyone testing it.

You have not achieved consensus for such a deployment. On the contrary, we have explained above that there are security problems with your approach. And you have failed to come to the talk page I invited you to discuss those issues. And no, I am not going to discuss here on the Village pump how editnotices can be used to hack Wikipedia. And no, that talk page doesn't list all the security and technical problems with editnotices, there is much more to it.

I have told you that the devs very strongly said no last time we wanted to deploy an editnotice loader of this kind. I have not had the time yet to spend some hours digging through archives to try to find the page where that was discussed. (I have had other more pressing things to do.)

I suggest you immediately revert yourself, or that someone else reverts this deployment for you.

And again, I suggest the details of a deployment like this should be discussed at Wikipedia talk:Editnotice, not here on the Village pump where it quickly disappears deep into the archives.

--David Göthberg (talk) 18:09, 15 March 2009 (UTC)

This is a wiki. We are allowed, even encouraged, to be bold. I welcome further discussion to address the issues you raise, but edit notices make a material difference and I'm not prepared to be paralyzed by talk. The Wikipedia talk page you point to has no ongoing discussion. Further, I believe that a site-wide deployment, is better discussed in the open rather than at an obscure talk page. We can of course copy this discussion anywhere you'd like to provide an archive. Domas Mituzas, the developer and WMF board member who disabled the per page notices encouraged this approach. That is enough of an developer endorsement for me. I also have experience working with Mediawiki on the developer side. I am prepared to trust my judgment and Domas's that a solution like this will not bring down the house, and by observation it has not done so thus far. You mentioned that developers had complaints about your prior approach, but there is no discussion of that on any page I could find and you haven't said what they are. Without something specific, I can't tell if they are still relevant.

Since primarily my goal is to restore the prior functionality, I went ahead and switched the space to full protection. I continue to believe that this is unnecessary. The damage that a vandal can do by inserting a template on one edit page at a time (i.e. per-page notices) is relatively minor, and in my opinion overshadowed by the good that could come from encouraging the broader community to make use of these tools. I would agree with full protection for notices that affect groups of pages, but the very limited install I created has no group functionality. Dragons flight (talk) 19:40, 15 March 2009 (UTC)

There's a huge difference between being bold when editing an article, and being bold when changing the functionality for 6,932,209 articles and their talk pages. That you don't understand that difference is very worrying.

--David Göthberg (talk) 21:23, 15 March 2009 (UTC)

Keep in mind that I am restoring functionality, with the relevant developer's encouragement. It takes some boldness to make that happen, but at a functional level the restoration of edit notices is neither a bold change in site behavior nor particularly controversial. Dragons flight (talk) 21:38, 15 March 2009 (UTC)

Note that there is (currently) no need to do it for the Talk namespace, as Domas only disabled the per-page editnotices for namespaces without subpages enabled and seems uninterested in "finishing the job" at this time. Anomie ⚔ 22:59, 15 March 2009 (UTC)

I'm placing a little note here to hold off archiving. There is still the question of whether we want to deploy this one system globally or have two opposing systems (i.e. Mediawiki for some namespaces and Templates for the other). Personally I think it makes sense to only have one, but the devs seem in no rush over the other namespaces. Dragons flight (talk) 06:51, 19 March 2009 (UTC)

Also, since we're on editnotices, is there a way to hide them in a way similar to the banners, just by clicking on [hide] ? I'm more concerned of hiding because I think it would be interesting to have per-category editnotices, but there should be a way to hide them (and not one by one, but all at once of course), or it would be too intrusive for regulars. Do we have a magic word that allows to know if the current page is in a given category ? With that, we could create per-category editnotices through mediawiki:editnotice-0. Cenarium (talk) 01:42, 21 March 2009 (UTC)

Too long didn't read?

Is there a shorter version of all this information? --DFS454 (talk) 20:09, 17 March 2009 (UTC)

File renaming error

I was trying to rename File:DSCN7043.JPG to File:Vermont Street (San Francisco).jpg. First it moved the image description page, but not the image, to the new name. I tried moving things back and forth and now get the following error when I try to undelete the file.

Undelete failed; someone else may have undeleted the page first.

<p></p>

Error undeleting file: Unable to write to file "public/archive/a/a4/20070717110943!DSCN7043.JPG": file exists

I'm going to download the deleted image and then re-upload it, but this does mean we need to be careful when renaming things. MBisanz ^talk 09:01, 18 March 2009 (UTC)

It has happened a couple more times, so I filed bugzilla:18033. MBisanz ^talk 10:38, 18 March 2009 (UTC)

Is file moving now disabled? I'm getting "Cannot move pages in namespace 'File'". --—— Gadget850 (Ed) ^talk - 13:23, 20 March 2009 (UTC)

To quote from the above listed bugreport: "Image renaming is disabled pending resolution." --TheDJ (talk • contribs) 13:41, 20 March 2009 (UTC)

Not allowing editing to AN & ANI

I have been unable to submit edits to WP:AN or WP:ANI for the past 1/2 hour; instead receive the "Error - Wikimedia Foundation" page (no the pages are not sprot'd). Looking at the respective page histories, [6] [7], no edits have been made in over 30 minutes (not likely coincidental). Anyone else having this problem? --64.85.220.189 (talk) 18:24, 18 March 2009 (UTC)

I am having the exact same problem editing another page, Template talk:Did you know. Having been trying various edits to if for at least half an hour. —Mattisse (Talk) 18:28, 18 March 2009 (UTC)

It seems to be allowing editing now, but what was that all about??? --64.85.220.189 (talk) 18:37, 18 March 2009 (UTC)

Someone wrote an abusefilter rule that was so computationally burdensome that the server was timing out trying to process it whenever anyone submitted a large page. This has been fixed now. Dragons flight (talk) 18:38, 18 March 2009 (UTC)

I was just about to report success null-editing ANI, but since that's been resolved, let me just say: You (=admins writing abuse filter rules) do understand that's exploitable, right? — Gavia immer (talk) 18:48, 18 March 2009 (UTC)

It isn't really exploitable, because you could also write a filter to just block everyone from editing ANI. But it is something to be careful not to make mistakes with. Prodego ^talk 02:14, 21 March 2009 (UTC)

Without going into too many details, my main worry is that, so long as the abuse filter is implemented so that it can DOS the servers, it might be possible to write a page that will trigger the DOS - where by "might", I mean that I know I could do so against some of the filters that have been tried, and by "write a page", I mean "write lots of pages until all of the socks get blocked". Needless to say, it would be bad if this actually happened, so I hope it is prevented from happening. — Gavia immer (talk) 02:43, 21 March 2009 (UTC)

I suppose this is part of the reason we have private filters. Algebraist 02:44, 21 March 2009 (UTC)

They are a help in that regard, yes. — Gavia immer (talk) 03:07, 21 March 2009 (UTC)

Two diverging template styles

I'm seeing two discussions that are coming to seemingly opposite conclusions on two different pages. One one hand you see Wikipedia_talk:Template_messages/Cleanup#Standardisation_of_template_styling which wants all template banners (amboxes) to look the same, and then we have Template_talk:Expand-section#More_subtle_style which wants section amboxes to look smaller. How can these two movements be reconciled? Online discussions can become disjointed (see meatball:ForestFire), but two discussions coming to opposite conclusions can be a disaster in the making.--Ipatrol (talk) 21:29, 18 March 2009 (UTC)

The former is quite an old discussion, and more concerned with the content of the box. The latter is an extension to ambox to allow for a mini version. I don't see how they conflict, especially since the first discussion didn't go anywhere. — Edokter • Talk • 22:55, 18 March 2009 (UTC)

No, the former discussion was partly about standardizing the box size. The idea's implementation actually went much farther than the discussion and many templates were standardized. This new idea now destandardizes the box size, in fact, what exposure was there for this mini-template implementation? All I see is an obfuscation of practices for no good reason. Why are we fixing unbroken things?--Ipatrol (talk) 23:54, 20 March 2009 (UTC)

How to find number of downloads of a spoken article?

Hi,

I'm active on WP:SPOKEN & WP:BIRD. I am trying to find the number of times a spoken article is downloaded. I tried 'http://stats.grok.se/' for getting the page views of a spoken article. The page works if I input 'File:American_Black_Vulture.ogg' in the search box. It gives me an answer of 95 article views. But if I type 'Image:American_Black_Vulture.ogg', then I get 19 views.

Why is this so? Secondly, can I take it these are the number of downloads or just page views? How can I know the number of downloads?

AshLin (talk) 16:05, 20 March 2009 (UTC)

The difference between "Image" and "File" views is probably in that 19 people viewed the page before the Wikimedia software shifted over to using "File:" instead of "Image:". I don't know about the second bit. -- RattleMan 20:13, 20 March 2009 (UTC)

The difference between a download and a view is browser trivia—whether it writes a file or not. I don't think there is any indication in the transaction type. —EncMstr (talk) 22:14, 20 March 2009 (UTC)

File renaming enabled

It seems that brion has enabled file renaming. All admins should now be able to move files. Redirects are created. This is a great new feature that was one of the most longstanding requests. I say many cookies for the devs are in order ! :D --TheDJ (talk • contribs) 03:09, 17 March 2009 (UTC)

Renaming? Image redirects? I don't know that my little heart can take it... ▫ JohnnyMrNinja 03:15, 17 March 2009 (UTC)

Cool, this will be a nice feature... just out of question, where would a peasant (non-admin) like myself request files for renaming if needed? chan dler · 03:16, 17 March 2009 (UTC)

We probably need a template and category, if there are any template-minded folks about. ▫ JohnnyMrNinja 03:18, 17 March 2009 (UTC)

Such requests should probably be directed to Wikipedia:Requested moves (and the scope modified)? --Splarka (rant) 07:17, 17 March 2009 (UTC)

{{Rename media}} has been in use for quite a while in anticipation of this feature. Category:Image renaming is the associated category. It would appear that a large number of files have already been moved per the template. --—— Gadget850 (Ed) ^talk - 11:50, 17 March 2009 (UTC)

BetacommandBot was also doing file renaming previously (trough reuploading). But the entire process will need some attention, because the files and cats are a bit disorganized atm. --TheDJ (talk • contribs) 12:46, 17 March 2009 (UTC)

I don't suppose anyone knows whether there is a mechanism in place to potentially warn those moving if a file is going to usurp an image from commons? Nanonic (talk) 13:42, 17 March 2009 (UTC)

{{#ifexist:Media:Copyright CD.svg | {{#ifexist:Image:Copyright CD.svg|local file|commons file}} | file doesn't exist}} → local file

{{#ifexist:File:Circus- Album.png | {{#ifexist:Image:Circus- Album.png|local file|commons file}} | file doesn't exist}} → local file

{{#ifexist:Media:Foo.bar | {{#ifexist:Image:Foo.bar|local file|commons file}} | file doesn't exist}} → file doesn't exist

Amalthea 14:54, 17 March 2009 (UTC)

Made a feature request to integrate this into mediwiki. bugzilla:18019 --TheDJ (talk • contribs) 17:51, 17 March 2009 (UTC)

Does Mediawiki allow you to move or upload a file to the same name as a Commons file? That seems like a bad idea. ▫ JohnnyMrNinja 00:12, 22 March 2009 (UTC)

Yes but I think it warns you first. Hell, try it. — CharlotteWebb 00:16, 22 March 2009 (UTC)

Major admin backlog :)

This has now created a major admin backlog (well... it was always a backlog, but now that moving images is an admin function, I'm saying it's now an admin backlog :) See Category:Media renaming requests and Category:Media requiring renaming. If you want to test out moving image pages, there are some files there that you could use to test out the feature. I guess ideally, this would be really simple for a bot to handle now. But I figured I'd mention it so anyone who wants to take the feature on a test drive and help clear a backlog, can do so. -Andrew c ^[talk] 16:31, 17 March 2009 (UTC)

Hmm, I just moved a few images to test the new feature, and it seems that the "File links" section won't work once an image is moved (since all the articles link to the redirect then. Here's an example). Won't that cause problems with our bots who look for orphan fair use images? --Conti|✉ 16:57, 17 March 2009 (UTC)
- This issue is already filed as bugzilla:18017 --TheDJ (talk • contribs) 17:36, 17 March 2009 (UTC)
  - BTW, "what links here" does work. The api doesn't register the usage of the file either. I'd say that it definitely has the potential to mess up some bots. --TheDJ (talk • contribs) 18:04, 17 March 2009 (UTC)

Please remember to remove the template afterwards, Andrew ;)
I've added a small move link to the template, which helps if there's a target filename already in the template (or a reason).
Is there, by the way, a naming convention for files? :) --Amalthea 17:30, 17 March 2009 (UTC)

Wikipedia:Image file names --—— Gadget850 (Ed) ^talk - 19:57, 17 March 2009 (UTC)

There's also whole sections of files that are not currently tagged that could probably do with renaming as well. e.g. [8] -- WOSlinker (talk) 23:44, 17 March 2009 (UTC)

MBisanz is now putting a dent in them with this spooky thing. --Splarka (rant) 07:47, 18 March 2009 (UTC)

Me like this new script. I will take a look once I did my daily CSD sweep. But Category:Media requiring renaming could be cared for by a bot though, they should all have suggested better names. I put up a request for it at Wikipedia:Bot requests/Archive 26#File auto renaming bot. Regards So Why 08:07, 18 March 2009 (UTC)

Is Wikipedia:Image renaming related to this feature in some way? It looks rather old... ▫ JohnnyMrNinja 00:14, 22 March 2009 (UTC)

War on white-space, contd.

Could somebody tell me how to get rid of broad white gutter at the top of Alexander Hamilton-Gordon (1859–1939)? I tried previewing it without the {{use dmy dates}} template and it looked normal. I tried adding an html comment to that template, thinking that it would help "eat" a line that contained only an html comment, but that doesn't work from within a template. Why shouldn't it? — CharlotteWebb 22:03, 20 March 2009 (UTC)

I believe the parser strips all comments from transcluded templates before rendering the page, so comments in templates never change anything. Removing the superfluous newline from the start of {{Infobox Military Person}} should solve the specific problem with that article. Algebraist 22:09, 20 March 2009 (UTC)

Yeah but, we ought not have to make edits like this all over the place. — CharlotteWebb 22:13, 20 March 2009 (UTC)

Algebraist is right, I removed the superfluous linebreak from the infobox, so that I could undo that stupid edit you quoted. :) --Amalthea 22:15, 20 March 2009 (UTC)

This seems like a non-obvious solution as removing the dmy template also solves the problem. Perhaps it is a combination of factors, however these should not be combining. Seems like the parser should strip white-space from both ends of the template before transcluding it into the other markup. — CharlotteWebb 22:19, 20 March 2009 (UTC)

I'm not sure the newline at the end of {{dmy}} is at all relevant. I think the problem was just that there was a newline at the start of the infobox template, and a newline in the article itself between the two templates, and that two newlines adds up to ugly whitespace. Algebraist 22:24, 20 March 2009 (UTC)

(ec) Well, the actual reason is that the dyk template transcludes no content, but since it is placed on its own line it is equivalent to having an empty line in the article. Similarily, the infobox started out with an empty line, and since the MediaWiki parser converts two consecutive linebreaks into a new paragraph ...
If you'd placed to dyk templates (or similar marker templates that don't transclude any content) on two seperate lines you'll still get a new paragraph. The only way around it is to either remove the linebreak between them, or hide the linebreak in a comment.
Or, but that might change at any point, place those marker templates right above the categories, since IIRC the categories eat all empty lines that are placed right above them. :)
Amalthea 22:29, 20 March 2009 (UTC)

One of my earlier points was that even if you add a bunch of instructions like this to the top of an article:

<!-- use dmy dates -->
<!-- use metric units -->
<!-- use british spellings -->
<!-- drink tea -->
<!-- call crackers "biscuits" -->
<!-- drive on the left -->
{{Infobox somethin'-r-other
| ... = ...

There is no extra white-space visible as it gets "eaten" whenever a comment occupies an entire line. However this doesn't happen when blank templates are used to convey the same messages. — CharlotteWebb 22:46, 20 March 2009 (UTC)

Ah, I see. I totally agree that a template that transcludes no content at all should behave the same way. It's often a pain that it doesn't. --Amalthea 23:26, 20 March 2009 (UTC)

Is this serious enough to consider it a bug? "Magic words" like __NOTOC__ also behave like an empty template. If you put a blank line before and after to improve readability you get excessive spacing like you would if you had three blank lines. Except it is okay to do this with most templates. Let's say X is a banner template of some kind which displays a block element (table, div, etc.)—the following will all render the same:

Foo.

{{X}}

Bar.

Foo.
{{X}}
Bar.

Foo.{{X}}Bar.

<p>Foo.</p>
<table id="template-X" ... ...>
<tr>... ... ...</tr>
</table>
<p>Bar.</p>

Funny eh? — CharlotteWebb 10:38, 21 March 2009 (UTC)

Servers - a vague suspicion

This is only anecdotal, but has anyone else noticed anything weird happening with page history in the last few days? I could swear that a vandal-revert of mine completely dropped out of pagehist, but I shrugged it off at the time. Now I've just had a comment from elsewhere about pagehist getting screwed up so just wondering if anyone else has noticed alien objects in the sky...

I suspect a flaky server but I'll defer to "everything's fine" if that's the overwhelming opinion. Yes, I have no specifics. Just a premonition. Thanks! Franamax (talk) 00:23, 21 March 2009 (UTC)

User:Buster7 said on my talk page day before yesterday:

How did you do that???? I just left you a messagte a few minutes ago and it dissappeared...even from my watchlist. Are you a Magician???? [9]

Ikip (talk) 12:56, 21 March 2009 (UTC)

Wikipedia:Date formatting and linking poll

The above link leads to a community poll regarding date linking on Wikipedia. The poll has not yet opened, but the community is invited to review the format and make suggestions/comments on the talk page. We need as many neutral comments as we can get so the poll run as smoothly as possible and is able to give a good idea of the communities expectations regarding date linking on the project—from User:Ryan Postlethwaite. Dabomb87 (talk) 20:36, 21 March 2009 (UTC)

{{PAGESINCAT:Articles for deletion}} lists 663 which is completly and widely inaccurate, how can I fix this? Ikip (talk) 14:32, 20 March 2009 (UTC)

Category:Articles for deletion shows an almost identical number... are you sure that there's an error? –Drilnoth (T • C) 14:39, 20 March 2009 (UTC)

Oh now that is interesting. The category lists the number as being over 10,000, but there are only three pages actually in it. I'd say it's most likely some sort of problem with the cat, not the magic word, but I can't be sure. –Drilnoth (T • C) 14:44, 20 March 2009 (UTC)

So the actual number is "only" 566. any ideas how to fix this? Ikip (talk) 19:44, 20 March 2009 (UTC)

No clue. –Drilnoth (T • C) 19:48, 20 March 2009 (UTC)

Category tree also shows over 10,000 pages:

<categorytree mode=pages showcount=on>Articles for deletion</categorytree>

This is a recent problem too:

archive.org for August 2007, Shows only 198 articles.

It could be a problem with {{AfDM}}, since removing all the information on the category page makes no difference, even after I purge the page, using ?action=purge

Ikip (talk) 19:50, 20 March 2009 (UTC)

The underlying problem has been fixed for some time now (category count not being decremented on deletion) but the actual counts will not update unless the category is renamed or some maintenance script is run by the devs. MER-C 01:44, 21 March 2009 (UTC)

Thank you. I am attempting to create a new category at Template_talk:Afd#Please_add_a_new_category_or_rename_the_old_one.3F, Category:AfDc, which will not solve the original problem, but will create a category which will update. Ikip (talk) 12:39, 21 March 2009 (UTC)

Ikip, for your purpose you can probably use the Category:AfD debates category, which lists all open AfD debates. --Amalthea 13:13, 21 March 2009 (UTC)

What a wonderful idea! Thank you! Ikip (talk) 22:20, 21 March 2009 (UTC)

It's still out by 10%, but hey at least you've got it to the right order of magnitude! MER-C 12:17, 22 March 2009 (UTC)

Way to resize template documentation on template page?

Is there a way to resize template documentation, so that when it is transcluded onto the template page, it only takes up 75% of the page and displays to the left of a sidebar template, instead of at the bottom, several scroll pages down? (See Template:Style/doc) In that case, the sidebar template is so long that the doc info ends up 2 pages down. Your help is appreciated! --Funandtrvl (talk) 23:38, 21 March 2009 (UTC)

we'd have to modify the template. fairly simple, I think - just add an optional 'width' style element to the main DIV (didn't look that close, though) - but it's such a major template you should get some consensus on whether that's desirable. --Ludwigs2 23:56, 21 March 2009 (UTC)

Rather than changing the documentation template just put a includeonly around it (the template itself) and include {{Style}} in the documentation, that will save space. chan dler · 00:00, 22 March 2009 (UTC)

Well, this particular template requires no documentation, as it has no parameters. That is, there's only one way to use it. In any case you should not assume that 200px (actually 215px if you count the margin-left:15px;, possibly more in practice) will always be less than 25% of available space (for me, it wouldn't be). Really I think the best possible solution would be to get rid of the ugly blue background div of the {{documentation}} template, so that all of the contents will wrap around anything hanging down from above the docs material. — CharlotteWebb 00:04, 22 March 2009 (UTC)

Easily done. I suppose, but it would lose some clarity. the (not as ugly as all that) blue background does make it really clear what's part of the template and what's not. --Ludwigs2 00:38, 22 March 2009 (UTC)

Ah so now that we have the documentation-subpage-bloat and the background color, we assume nobody could figure out what portion of the template is instructions without it. That makes a lot of sense

. Actually I'd argue that the doc-pages should be in a custom namespace and correspond to templates via a tab at the top of the page (somewhere between "template" and "talk") rather than the esoteric way it is currently done. — CharlotteWebb 09:38, 22 March 2009 (UTC)

Note that the output of {{documentation}} explicitly doesn't wrap around floated boxes: the CSS class it uses contains "clear:both". If you really want it to be to the side of a floated template, something like this should do it (although it'll be squashed for those of us not using maximized browsers on high-resolution widescreen monitors):

<table border="0" width="100%">
<tr valign="top"><td>{{documentation}}</td>
<td>
<onlyinclude>(template goes here)</onlyinclude>
</td>
</table>

Example display

OTOH, chandler's suggestion is even better. Anomie ⚔ 02:55, 22 March 2009 (UTC)

--Thank you again!! Chandler gets the "A" for the day! It worked!! --Funandtrvl (talk) 16:40, 22 March 2009 (UTC)

Issue with Wikimedia software not reporting image use, so don't delete images without checking

In TV Tokyo (for example), you can clearly see File:Tv-tokyo-logo.png being used (I clicked the image to make sure I was viewing the right image page), but the "File links" section on that image page is blank. So, it appears something weird is happening and we need to be careful about deleting images which are allegedly not being used. I looked in Bugzilla, but didn't find anything which addressed this issue. Anyone know what might be the problem? ···日本穣^{? · Talk to Nihonjoe} 05:51, 22 March 2009 (UTC)

Hmm...I wonder if it was just some sort of hiccup in the software? I cleared my cache and everything, but couldn't get it to show up for over 10 minutes. Now it's working fine. Weird. ···日本穣^{? · Talk to Nihonjoe} 05:53, 22 March 2009 (UTC)

Probably somebody did a null edit to the article. — CharlotteWebb 09:41, 22 March 2009 (UTC)

Not all page edits are updating the file links immediately. Notably if these file links are dynamically generated using conditional templates whose behavior is modified: in this case it will take between 3 and 10 days (on this Wikipedia, depending on the load) before all pages referencing the modified template have been completely parsed again. A null edit on a page using a template that includes some image will effectively update the file links immediately, but pages that were using an image and that were not modified at all but were modified only indirectly by one of the templates they depend on, will take long before they get parsed and regenerated, notably if the template has lots of references (apparently, the count of references for template is significant: only the first few references, generally the oldest ones, are parsed rapidly, but above some low threshold, the other pages are updated more slowly, by inserting the template's usage in a update job queue that MedaWiki will process with low priority (there's higher priority to update only those pages that are requested by users, but apparently MediaWiki cannot always see that a requested page is in the job queue for being refreshed)

As a consequence, a deletion request for unused medias should not be honored immediately: at least 15 days should be given for images stored locally on an unshared wiki (except Commons, see below), to make sure that all pages using a file have been listed. The deletion reason should indicate that the request is made because of absence of usage.

But the situation is more complex if images are stored in Commons: checking file usages requires scanning lots of wikis, not just Commons itself. The correct policy for Commons is to make sure that all related images are properly categorized and can be found and compared to other similar images. Then, equivalent images need to be kept for long with a "deprecation" request that should be kept for at least a couple of months, during which all wikis can be checked.

Beware: the CheckUsage tool used in Commons is currently not functional, due to lack of database dumps for many wikis, including many of the most important ones; I've seen recently some images being incorrectly deleted from Commons, just because they were apparently not used on English or German wikis, and in no other of a few tested Wikipedias, but that were used in several Wiktionnaries or Wikibooks or Wikiversities or even on Meta ! Restoration requests could not even be honored as there remained no backup anywhere (so the images had to be recreated, loosing most of its history of changes for better quality, or other images had to be selected). The file deletion log on Commons does not always give a reason, even if there was no copyright issue, some images disappear at unknown dates and for unknown reasons, as if they had never existed, this is very bad.

Something should be done to allow Commons to inform other "client" wikis that a deletion request is pending: each wiki would then insert its own check in its own database, that would complete after all its current job queue has been processed. At that time, the file usage will be checked, and the client wiki will post back the result to Commons. Commons will monitor the responses from all its registered client wikis and will manage these results in a queue page shoing the results of investigation. This deletion request status should be visible directly in the file's description page. If any wiki tries to import an image that has some deletion request pending, each request source (the referer's URL?) should be logged and counted over the deletion request period. After some maximum time has elapsed without any referal (is two months enogh for all client wikis?) the deletion request could be honored by admins, but if there are too many logged referals during that period, the deletion request should be canceled automatically (instead of this deletion log, there would remain an history line listing only a few of the referer locations discovered during the deletion request period). 79.94.111.15 (talk) 12:11, 22 March 2009 (UTC)

This particular image is not on commons, and it has been in the article for months (if not years). It's not an issue of it not showing up right away as it was there the whole time, but the software wasn't showing it was being used so a bot tagged it for deletion in seven days. ···日本穣^{? · Talk to Nihonjoe} 17:43, 22 March 2009 (UTC)

no indexing

I don't think it's possible but is there a way to make mirror sites no index some (or all) of my user pages? -- penubag (talk) 06:30, 23 March 2009 (UTC)

Nope, mirror sites will still index it, but you can take it off of Google searches by addming {{NOINDEX}} to each page. MBisanz ^talk 06:35, 23 March 2009 (UTC)

Yeah, didn't think so. I know how to make Wikipedia no index, but not the mirrors. They'd have to do that from their site, which means my page still shows up on Google. -- penubag (talk) 06:37, 23 March 2009 (UTC)

Is there a bot which can remove sections for a page when a certain template tag is removed?

User:ARSBot adds articles tagged for rescue to the talk page of WP:ARS, the problem is that they are never removed. For example, there are 86 articles listed, but only 33 articles which actually have the template currently. Is there a bot which can remove sections for a page when a certain template tag is removed from the pages? Ikip (talk) 03:24, 22 March 2009 (UTC)

You should ask User:ST47 to have User:ARSBot also remove them, if that is what ARS desires. IMO, it's usually better if the same bot does both halves of something like that. Anomie ⚔ 05:34, 22 March 2009 (UTC)

Thank you for the response. So it is possible? Ikip (talk) 14:43, 23 March 2009 (UTC)

Yes it is possible. There is a bot User:ARSBot that can do it. Ask User:ST47. Chillum 14:49, 23 March 2009 (UTC)

For what it's worth: the rescue tag could also be turned into a parameter of the various deletion tags. This would mean that they are always removed along with the template, but tagging them for rescue would be a bit harder. --Amalthea 15:23, 23 March 2009 (UTC)

Main page cascading protection not working

The cascading protection for the Main page doesn't seem to be functioning. This picture was uploaded to En from Commons, for DYK, but I was still able to edit it while the image was on the Main Page. I'll have to go to sleep now, but it would be good if someone could look into this. Shubinator (talk) 06:39, 22 March 2009 (UTC) (Please move this to the correct page if this isn't where it should be)

Perhaps the nature of "cascading protection" for images is such that you can still edit the description page but not change the uploaded image. That would certainly make more sense. If that's how it actually works there is no need for this. — CharlotteWebb 09:47, 22 March 2009 (UTC)

I've tested cascading protection other times in the past, that's not how it works. I would get a pink screen to warn me that something is protected. I tested on the following image in the DYK group, and the image was not protected. I added protection just to be safe. Royal broil 12:30, 22 March 2009 (UTC)

I just had to null edit the main page in order to get cascade protection working on the images. Usually only purging is necessary. --- RockMFR 21:21, 22 March 2009 (UTC)

Hmm, I'd definitely argue that the description page of an image used on a "cascade-protected" article should remain editable unless it is directly protected for an unrelated reason (because unlike with a template such edits cannot affect the article using the image). I think this would first require us to have a separate protection setting which allows images to be specifically protected only against replacement uploads. This would be useful on commons too as it would allow people to improve the image description and add various tags and translations etc. but still avoid upload vandalism on certain heavily used images whose appearance would very rarely need a legitimate change (flags would be a prime example). Has this already been requested somewhere? — CharlotteWebb 14:29, 23 March 2009 (UTC)

Extending XHTML with DTD

Can someone provide some pointers to docs that would explain how to extend XHTML (as used on en.Wikipedia) to include additional tags such as <mw:date>April 1 2009</mw:date>? Either I'm too tired or I'm just coming across the most complicated examples on Google, but I'd like to think this would be simple to do. =)

As an aside: are most browsers compatible with sites that extend XHTML as I'm pursuing? I'm fairly confident about IE7 and Firefox, but if anyone has any compatibility issues they're aware of I'd be curious. Thanks! —Locke Cole • t • c 11:34, 22 March 2009 (UTC)

You don't necessarily need a DTD to extend XHML. All you need is to declare the namespace used, and bind it to a unique URL (that does not necessarily load a document: the URL is just symbolic and used as an opaque identifier).

In your example, just add: xmlns:mw="some unique url" in the <html> element to bind the "mw:" namespace prefix; in that case your "mw:date" element will not be part of the XHTML DTD and will not have to be validated by it. Note however that XHTML's containment data model need to be updated as well to allow the additional element within the contents of a standard XHTML element (This requires adding your own "<!ELEMENT>" redeclaration for the XHTML element containment model, in addition to the declaration of the new custom element itself). If you don't do this, then the document will not parsse as valid XHTML and will necessarily be parsed using legacy HTML processing, using various "quirks" compatibility mode (which could affect the rendering across various browsers that will work without "strict" validation). 79.94.111.15 (talk) 12:24, 22 March 2009 (UTC)

Note: en.Wikipedia does not seem to extend XHTML as you indicate; it uses the standard XHTML1 model (the transitional version, not the strict one). So it does not use the additonal tags you indicate in the generated HTML code (may be there's a MediaWiki extension that uses a custom tag usable in the MediaWiki's parsed Wiki syntax, but it is not used here; even if it was, I don't think that uch extension would be used as it would invalidate the support for standard rendering and could affect lots of CSS rules for specific browsers, something that is really not wanted here, where we want to minimize this dependency).

Can you point a page on en.Wikipedia that demonstrates where your custom tag is effectively used? Look at the signature here: it shows that your tag is not recognized 79.94.111.15 (talk) 12:33, <mw:date>22 March 2009</mw:date> (UTC)

It's not yet in use, I'm working on a proposal that would use it however. If there's a reason not to pursue this please let me know. The idea is to use a custom tag to mark off dates within article text, then use Javascript to modify those dates depending on what a client chooses for a format. I suppose I could just as easily avoid the custom tag and use a CSS class to mark off such dates (<span class="date">April 1 2009</span>), but I felt extending it would make more sense (and allow for further extensions as time goes on). I'm not married to the idea at this stage, but it seemed "cleaner" than using a CSS class or marking off the dates some other way. —Locke Cole • t • c 12:47, 22 March 2009 (UTC)

You don't really need to think of it as an extension to anything. Wikitext has plenty of tags which look like html but aren't. You could propose a new tag that's as simple as <date>April 29, 1992</date> and have it do whatever the heck you want. — CharlotteWebb 14:44, 23 March 2009 (UTC)

Italics in article name

Currently the page Fannia scalaris (about a species of fly) displays with its article title in italics. That is suitable for a biological name; but I can find nothing in its text that would make the title come in italics. How does this happen? (I am familiar with the template {{Lowercase}} to make the article title show wirh a lowercase first letter.) Anthony Appleyard (talk) 10:44, 23 March 2009 (UTC)

I imagine that it effected by a template similar to {{lowercase}} transcluded from the infobox. Skomorokh 10:46, 23 March 2009 (UTC)

Specifically, {{taxobox name}}, which is conditionally transcluded in {{taxobox}}. — TKD::{talk} 10:52, 23 March 2009 (UTC)

Ehm, is this what we want ? Cause there is a whole lot of other stuff we can apply this kind of formatting to. I'm thinking of names of books, and names of songs etc etc. Also, i'm somewhat worried about expectations of this "feature" surviving the future. This is one of those things that can break at any time. If a dev needs to break this to fix something or implement a new feature, they will. --TheDJ (talk • contribs) 13:28, 23 March 2009 (UTC)

The same could be said of just about any MediaWiki feature: the devs have shown themselves quite willing to take drastic and unilateral action on occasion to maintain performance or prevent abuses of the software, and quite rightly so. Does that mean we shouldn't have ever used editnotices because they might have been disabled? According to our style conventions, some phrases should be italicised, therefore we should use whatever features we have available to make that convention as consistent as possible. So yes, I think we should consider deploying this on titles, etc. Happy‑melon 14:23, 23 March 2009 (UTC)

If it's ok on the technical side, perhaps the question of the use italics in article titles is for MOS:ITALICS/MOS:TITLE to address? Skomorokh 14:31, 23 March 2009 (UTC)

In any case, doing this with {{Wrongtitle}} and javascript should be quite robust. If anything ever happens to break the javascript, we'll still have perfectly good hatnotes in place. Algebraist 15:07, 23 March 2009 (UTC)

I remember this being brought up before, and many people were against any implmentation of it -- one main problem is thw all or nothing facotr of it would cause any disambig parts of the title to also be italicized, which makes no sense. ♫ Melodia Chaconne ♫ (talk) 14:52, 23 March 2009 (UTC)

But the current javascript (in MediaWiki:Common.js, search for 'RealTitle') isn't all-or-nothing. Algebraist 15:03, 23 March 2009 (UTC)

Could someone clarify whether, for example, Rage (novel) can display as Rage (novel), and whether or not this can be effected by {{Infobox Book}}? Muchas gracias, Skomorokh 17:06, 23 March 2009 (UTC)

Yes it could, but how to implement that in {{infobox book}} is a bit more tricky. If you could come up with a reasonably complete list of possible disambiguations ("book", "novel", etc), then it could be done from the |name= parameter. Happy‑melon 17:31, 23 March 2009 (UTC)

Thanks very much, that's helpful. Would it not be possible to have the template ignore anything that is parenthesised, and then use a manual override (e.g. |fullitalics=yes) for articles like Agrippa (a book of the dead) where the actual title includes brackets? Any editor-generated list would miss too much, I fear. Skomorokh 17:37, 23 March 2009 (UTC)

I think that, without mw:Extension:StringFunctions, that would be difficult with the string-manipulating tools Mediawiki has. You might be able to hack something together, but it would be complicated and ugly and might well make the devs hate you. I would favour a system where {{infobox book}} by default italicizes the whole title, with exceptions for obvious disambig terms like (book) and (novel), and with an optional |displaytitle= parameter if the default needs to be overridden. Algebraist 17:56, 23 March 2009 (UTC)

Your suggestion may be an improvement over the status quo, but why is it easier to not italicise (book) and (novel) specifically rather than (anything)? Skomorokh 18:00, 23 March 2009 (UTC)

Because the infobox template already has a {{{name}}} parameter, and it can easily check whether {{PAGENAME}} equals '{{{name}}} (book)' or '{{{name}}} (novel)' using {{#ifeq:}}, but can't (AFAIK) easily check whether {{PAGENAME}} equals '{{{name}}} (anything)'. Algebraist 18:08, 23 March 2009 (UTC)

Indeed; to check for "(anything)" requires string functions, which we don't properly have. We do have some hacks which have been put together, which do the job fairly well... just DON'T LOOK AT THEIR CODE! IT'S EVIL!! But aside from some length limitations, they work ok. Happy‑melon 18:19, 23 March 2009 (UTC)

LOL :-) Dragons flight (talk) 19:43, 23 March 2009 (UTC)

Something is coming together at {{italictitle}}. No documentation as yet, but watch this space... Happy‑melon 18:19, 23 March 2009 (UTC)

That looks good. My only request is a parameter which, if set, overrides everything else and sets the RealTitle to the value of that parameter (unless you can think of a better way of handling exceptions, of course). Algebraist 18:58, 23 March 2009 (UTC)

The JavaScript will only allow RealTitles that can be copied-and-pasted to be the same as the proper title of the page. So the only useful override is to force the whole title to be italic (or not italic, of course). The |force= parameter does that here. Happy‑melon 19:14, 23 March 2009 (UTC)

I was envisaging a situation where {{infobox book}} calls {{italictitle|{{{name|PAGENAME}}}|book|novel}} or something similar. In that case, titles such as Crash (1973 novel) would be rendered incorrectly if no override was available. Algebraist 19:22, 23 March 2009 (UTC)

Uuuuh ... since when does that work? Well that'll open a can of worms ... --Amalthea 19:28, 23 March 2009 (UTC)

Cool! We have a lot of flexibility here, just use it wisely. —Remember the dot ^(talk) 19:39, 23 March 2009 (UTC)

That's actually a lot less horrible than similar things I've seen done with CSS. At least the image is in exactly the right place. Algebraist 19:44, 23 March 2009 (UTC)

With the string manipulation hacks it can actually be done for all titles: User:Amalthea/Italictitle/test, which uses User:Amalthea/Italictitle. Only a proof of concept, needs of course the proper checks and the correct div and span, and the exception flag where the paranthese is part of the title, but it would work. --Amalthea 21:07, 23 March 2009 (UTC)

Yes, but don't forget that {{str left}} coughs and dies after 80 characters, and {{str find}} dies after 50 characters. Making it fail gracefully in these circumstances is the most difficult part, and the part that would be remedied with StringFunctions. Happy‑melon 21:37, 23 March 2009 (UTC)

I certainly wasn't arguing against string extensions! I just noticed that you started the template to work with specific qualifiers only, and didn't know whether you were planning to add functionality to work with arbitrary ones. --Amalthea 22:31, 23 March 2009 (UTC)

I'm still failing to see why the title needs italics at all. It is merely an identifier of where we decide to place a particular subject. Usual style rules should not apply. --- RockMFR 21:59, 23 March 2009 (UTC)

I disagree, I'd say it's the most important place to be consistent with our styles; it is after all both the most prominent and the first-seen use of the subject's title in the article. Certainly the world is not going to end just because a film title is italicised in the lead but not in the article title (it hasn't ended over the past seven years) but that's not a reason to avoid fixing it. We can improve the professional appearance of our articles with this feature, so we should do so. Happy‑melon 22:22, 23 March 2009 (UTC)

Talk Page

Resolved

Hi I seem to be having some problems with my talk page in that it is not displaying correctly. It is only displaying half the page as if it has zoomed in to the bottom section were the comments are, the scroll bar on the right moves the wiki globe and the search box on the left up and down and the page remains static. Also you can't see the links on the left Main Page, Contents etc, any ideas thanks. I use Opera as my browser. BigDunc^Talk 18:32, 23 March 2009 (UTC)

yeah, well, you CSS bombed yourself. I went ahead and removed the position elements from the span and div at the top of your page; you can't use 'fixed' and 'absolute' in quite the way you did without really mucking things up.

I will AGF with the edit made by this IP here but I think that is what caused it. I tend to attract a lot of vandals due to recent changes patrol so IMO that is what happened. BigDunc^Talk 18:50, 23 March 2009 (UTC)

Input needed

Hi! I was wondering if someone with some more technical knowledge of Wikipedia could take a look at Category talk:Wikipedia backlog#Automatic backlogs and reorganizing this cat and clarify how the category additions could be done... there seems to be some confusion about how things work, and some more input would be much appreciated. Thanks! –Drilnoth (T • C) 19:57, 23 March 2009 (UTC)

wikipedia.us?

I have noticed that for example, going to wikipedia.us/wiki/USA redirects to en.wiki.x.io/wiki/Main_Page/wiki/USA. Surely this is not intended behavior. I think at least a beurucrat is needed to fix this. Am I correct that this is a mistake? -Zeus-^u|c 03:23, 24 March 2009 (UTC)

Most likely a developer. I don't know that a bureaucrat could do that. ···日本穣^{? · Talk to Nihonjoe} 03:29, 24 March 2009 (UTC)

It's not necessarily even owned by the Wikimedia Foundation. In any event, a WHOIS lookup returned the following backwards contact email: moc.sispilos@guod . Try sending a message there. {{Nihiltres|talk|log}} 03:33, 24 March 2009 (UTC)

problem with Uncategorized Pages list on Turkish Wikipedia

I have a technical problem related to the Turkish Wikipedia. I know this is the English Wikipedia, but I am hoping that developers read this page and may assist me. If there is a better page to post this please let me know. The problem is that on the special page for uncategorized pages (http://tr.wiki.x.io/wiki/Özel:KategorisizSayfalar), the list includes redirects, such as tr:Annie Hall (film). If this is not fixed, soon the list will consist of nothing but redirects and we will not be able to see the real pages needing categorization. Thanks for any help. --İnfoCan (talk) 14:39, 19 March 2009 (UTC)

You could make a category just for redirects. ~user:orngjce223 ☺ how am I typing? 15:06, 22 March 2009 (UTC)

And (I assume) you'd need to have a bot that would check pages in that category to see if they are redirects; if so, then add the category that says that they are redirects. -- John Broughton (♫♫) 00:48, 25 March 2009 (UTC)

Favicon

Favicon of English Wikipedia, is displayed incorrectly. It is same to Yahoo's! Maybe it could be my own problem, and would somebody check on other computer? 59.7.73.178 (talk) 07:22, 24 March 2009 (UTC)

They seem to be displaying fine to me. But it would help to know specifically what looks off, and also what browser, OS, and screen resolution you are using. Someguy1221 (talk) 07:26, 24 March 2009 (UTC)

Thank you. I use Windows XP Professional SP3 and Internet Explorer 7. I can upload screenshot but it's against Wikipedia's copyright policy… 59.7.73.178 (talk) 07:31, 24 March 2009 (UTC)

Try clearing your cache and restarting your browser. wodup 07:37, 24 March 2009 (UTC)

It works! Maybe it was just an temporary error. Thank you. 59.7.73.178 (talk) 07:49, 24 March 2009 (UTC)

Yeah, it happens. I'll have the Wikipedia favicon on my wordpress bookmark, and the myspace favicon on my Facebook... etc. It'll go away. --Izno (talk) 14:20, 24 March 2009 (UTC)

Hello. I'm having a similar problem. The English Wikipedia site is displaying the NBC logo as the favicon. But the Simple English version of Wikipedia as well as the Spanish version are displaying correctly. I've cleared the cache several times and restarted the browser, even rebooting. It's interesting to note that when I enter en/wikipedia.org/favicon.ico in the address bar to verify what the favicon should be, the correct one is displayed on the webpage but not on web tab nor in the address bar region. I'm running Vista Home Premium SP1 and Internet Explorer 8. I suspected it was a problem with IE8, but apparently it's happening with IE7 also. Any guesses as to what may be happening?Techjourney (talk) 15:28, 24 March 2009 (UTC)

Its probably because IE has never fully suppoerted them....... IE's going to the dogs if you as me rdunn PLIB 15:33, 24 March 2009 (UTC)

IT happens in firefox also. The Favorite links bar shows all of the icons to be of Wikipedia. Once, I went to testwiki, and all the icons changed to the black testwiki icon. Looks like WP is trying to take over my favorites bar.ManishEarth^{Talk • Stalk} 02:09, 25 March 2009 (UTC)

Watchlists

Can an option for the watchlist be added to show/hide edits made by AWB? Lugnuts (talk) 08:15, 24 March 2009 (UTC)

Does AWB mark its edits in any way? You can't magically tell what was done by AWB and what by hand, you'd need to put 'AWB' in the edit summary or something. Then you could do it with javascript. Algebraist 12:58, 24 March 2009 (UTC)

Depends on the user, but the edit summary usually contains the link to the AWB page. Some are also flagged a minor edit too, but not all. Lugnuts (talk) 19:07, 24 March 2009 (UTC)

It might be useful to have another code (to go along with 'b' for bot edits and 'm' for minor edits) that marks an edit as bot-assisted. that would help distinguish page-specific content edits from large-scale (usually fixes or cleanup) edits. of course, setting that up would be a fairly involved process... --Ludwigs2 13:50, 24 March 2009 (UTC)

indented lists: just checking my eyes...

I was looking at the way Wikipedia constructs indents (using a : at the beginning of the line) to try to figure out spacing for CSS use on a template, and I discovered that (apparently) indents are nested HTML definition lists? that struck me as odd enough that I wanted to confirm it was true, and not a strange artifact of being a Mac user, or something like that. can someone confirm? --Ludwigs2 18:17, 24 March 2009 (UTC)

Yes, they are, and yes, it is odd. Algebraist 18:19, 24 March 2009 (UTC)

lol - well, there you go. ok, thanks.

--Ludwigs2 18:33, 24 March 2009 (UTC)

Or rather, we abuse definition lists for indentation. :) --Amalthea 18:40, 24 March 2009 (UTC)

New article template

On top of all new articles is the following:

Before creating an article, please read Wikipedia:Your first article, or search for an existing article to which you can redirect this title.
To experiment, please use the sandbox.
When creating an article, provide references to reliable published sources. An article without references will likely be deleted quickly.

Where can I comment about possible additions to template above new articles? Ikip (talk) 12:56, 21 March 2009 (UTC)

At MediaWiki talk:Newarticletext. --Amalthea 13:18, 21 March 2009 (UTC)

Thank you again Amalthea, you are always such a huge help. Ikip (talk) 20:10, 25 March 2009 (UTC)

GIF image thumbnailing

Why hasn't true GIF image scaling been turned back on? GIF thumbnails in Commons categories are grinding some computers to a halt.

If certain types of animated GIFs are screwing up the MediaWiki software when it tries to scale them down, or to thumbnail them, then let's just ban or quarantine those particular animated gifs for awhile. I believe that is why true GIF thumbnailing was turned off.

Many images on the Commons were originally created in the GIF format, and we don't want to discourage people from uploading GIF graphics. Converting them to PNG would be a huge waste of time, too. There is no advantage to it because converting already-finalized images to other formats does not increase their quality. --Timeshifter (talk) 14:02, 21 March 2009 (UTC)

I think this would require teaching the MediaWiki software how to determine whether a gif is animated. That is unless there is some kind of -rejectifanimated command line option in ImageMagick or whatever they are actually using for the thumbnailing. Somehow I doubt it's that simple. — CharlotteWebb 19:12, 21 March 2009 (UTC)

Yes it is a problem with animated GIFs. Quarantining them requires teaching Mediawiki how to detect an animated GIF. It is on someone's to do list, bugzilla:16451, but it hasn't been gotten to yet. Dragons flight (talk) 19:52, 21 March 2009 (UTC)

Something about the way it's described feels inefficient. Maybe it would be better to store this animated? true/false data somewhere in the database rather checking it than every time somebody tries to obtain a thumbnail. For new images this should be checked at upload time. This would also allow false positives and negatives to be corrected manually, at least until the next upload. — CharlotteWebb 21:52, 21 March 2009 (UTC)

Thanks for the bug link, Dragons flight. It looks like they have a partial solution. I suggest they go with that for now, and if a better solution comes up, then they can implement that then. Let's not sacrifice current usefulness for future perfection. A lot of resized GIFs in articles are looking really bad due to the lack of true scaling and resampling.

Also, it can take much more time for dialup users to load Wikipedia pages if they contain GIFs that require many kilobytes at their original sizes. A resized GIF currently requires downloading the full-size GIF image (and all the kilobytes) before being resized by the browser. Browser resizing makes many images look bad compared to images scaled by the server. --Timeshifter (talk) 04:15, 22 March 2009 (UTC)

Maybe there is a way to stop an attempt to scale or thumbnail a particular animated gif if the server time surpasses a set limit. I have no clue about how this would work, and I am just throwing the idea out there. --Timeshifter (talk) 11:32, 23 March 2009 (UTC)

We've written the code to detect animated GIFs, so now it's just a matter polishing things up a bit; hopefully, it will get resolved fairly soon. -Steve Sanbeg (talk) 18:38, 25 March 2009 (UTC)

Code updates coming live

Ok, we've finally caught up with MediaWiki development code review and I'm pushing out an update to the live sites. This fixes a lot of little bugs, and hopefully doesn't cause introduce too many new ones. :)

Change logs

As usual in addition to lots of offline and individual testing, we've done a quick environmental shakedown on http://test.wiki.x.io/ -- and as usual we can fully expect a few more issues to have cropped up. Don't be alarmed; just let us know here, in our bug tracker or on the tech IRC channels and we'll make sure they get diagnosed and fixed.

I'd also like to announce that we've started a blog for Wikimedia tech activity & MediaWiki development, in part because I want to make sure community members can easily follow what we're working on and give feedback before we push things out:

http://techblog.wikimedia.org/

I'd very much like to make sure that we've got regular contacts among the various project communities who can help coordinate with us on features, bugs, and general thoughts which might affect some projects distinctly from others. --brion (talk) 13:11, 25 March 2009 (UTC)

"Provide preference-based autoformatting of unlinked dates with the dateformat parser function." hmm is this what everyone is complaining about? ViperSnake151 15:03, 25 March 2009 (UTC)

Today is 2009-03-25 ({{#formatdate:2009-03-25}}). Interesting. --- RockMFR 18:22, 25 March 2009 (UTC)

Even more so:

{{#formatdate:2009-03-25|mdy}} → March 25, 2009
{{#formatdate:2009-03-25|dmy}} → 25 March 2009
{{#formatdate:March 25, 2009|ymd}} → 2009 March 25
{{#formatdate:March 25, 2009|ISO 8601}} → 2009-03-25

Amalthea 19:14, 25 March 2009 (UTC)

To expand: you see that all four of those display the same to logged-in users; but all of them display as defined to logged-out users. Try viewing the examples logged in and logged out to see what's what.

Next week's Signpost tech report is going to be a monster :D Happy‑melon 21:29, 25 March 2009 (UTC)

Note there's also bugzilla:17905 to get a magic word to set a default for all #formatdate calls on a page that don't specify a format specifically (i.e. the one in RockMFR's example, but not the ones in Amalthea's). Anomie ⚔ 00:26, 26 March 2009 (UTC)

'Confirmed' usergroup

Please see Wikipedia:Village_pump_(proposals)#.27Confirmed.27_usergroup. Cenarium (talk) 17:57, 25 March 2009 (UTC)

Per-category editnotices

Now that Template:Editnotice load is transcluded in MediaWiki:Editnotice-0, after this discussion, if we had a magic word returning if the current page is in a given category, we could have per-category editnotices. But even if the magic word could be created, per-category editnotices may annoy users, would it be possible to have the option to hide it (simultaneously for all pages in the category) using an id, similarly to notices ? Cenarium (talk) 18:54, 25 March 2009 (UTC)

Wrote a script that allows you to hide pages from your watchlist (such as Talk pages)

I have written a script (in response to this thread at the Help Desk) that allows you to hide pages from your watchlist. From the script's documentation that I just wrote, at Wikipedia:Hide Pages in Watchlist, what can do is: "For example, if you watch an article but do not want to see any of the edits made to the article's Talk page on your Watchlist, then you can hide just the Talk page without unwatching the article. To best understand how this script works, you should install it and try it out by following the instructions." So, feel free to check it out, and post on the documentation's talk page if you find any bugs. I'm guessing there are some people out there who might find this useful. I'm still working on it and making some tweaks, too, so it'll continue improving. Gary King (talk) 22:03, 21 March 2009 (UTC)

That wouldn't do me much good because it would still involve waiting a couple minutes for the entire watchlist to load before hiding half of it. It would be much better to introduce watchlist features and improvements in the actual mediawiki software. — CharlotteWebb 22:33, 21 March 2009 (UTC)

If your watchlist takes a few minutes to load, then that's probably something that should be resolved before using this script. I think my Watchlist takes at most three seconds. Gary King (talk) 22:57, 21 March 2009 (UTC)

Really, mw should have a way to uncheck talk pages in the 'view and edit watchlist' section. I would make things a lot easier ManishEarth^{Talk • Stalk} 13:18, 22 March 2009 (UTC)

You'd have to first introduce some way to watch an article but not its talk page, or vice versa (without watching both). Right now that's not possible. — CharlotteWebb 02:35, 23 March 2009 (UTC)

And why not? I, for one, would love to watch WP:RFA without having to watch WT:RFA. –xeno (talk) 16:58, 26 March 2009 (UTC)

Google Chrome Beta

Just a warning, I 'upgraded' to the Beta and have lost the edit summary field. I'll have to figure out how to roll back now! dougweller (talk) 09:35, 25 March 2009 (UTC)

I use Chrome (The full version has come out), and the summary field is there for me. I can't recall it being missing when I was using Beta. Try purging your cache ManishEarth^{Talk • Stalk} 12:59, 25 March 2009 (UTC)

It's a new Beta [10] - I already had the latest stable release. dougweller (talk) 14:01, 25 March 2009 (UTC)

I still have an edit summary field with the new beta. Does the problem persist when logged out? Algebraist 17:49, 25 March 2009 (UTC)

Evidently not. :-) I don't understand this, it's ok when logged out, not when logged in, although I could swear that when I first tried it again just now while logged in I could see the edit summary field until I scrolled out of the edit window altogether, and when I scrolled back to the edit window the summary field had gone again. Actually all I see seems to be the word Edit on a line by itself. 81.105.226.60 (talk) 21:52, 25 March 2009 (UTC) aka Dougweller (talk · contribs)

Could it be something you ate? --Splarka (rant) 07:11, 26 March 2009 (UTC)

Quite likely. I deleted that, I still have the problem. I have determined however that what actually happens is when I run the Beta (logged in, doesn't happen logged out) the first time I edit I see, for a second, the edit summary box. Then everything suddenly vanishes except for the words 'Edit summary' - even the briefly describe bit. So it must be something like Twinkle, etc. I guess I shall just have to test them all. 81.105.226.60 (talk) 08:53, 26 March 2009 (UTC)

Ok, after deleting my js stuff didn't change anything, I went into preferences and set gadgets to default. No problems with edit summaries. Ticked gradually on the ones I wanted, no problems. So I've got my gadgets back, so far as I can see everything is like it was before but I have my edit summary field back. Go figure. Dougweller (talk) 09:26, 26 March 2009 (UTC)

credits not given !

your assessment of "the Prisoners Dilemma "does not give due credit to Wm D Hamilton pioneer in this field!

Please post suggestions for improvements to that article to the page Talk:Prisoner's dilemma. And when you do, it would be very helpful to mention a source (book, article, whatever), since those supposed to be the basis for the contents of articles. -- John Broughton (♫♫) 17:02, 26 March 2009 (UTC)

Pipe character between page name and timestamp in watchlist

Resolved

– Original behavior has been restored

Call me crazy, but is this new?

(diff) (hist) . . Glenn Quagmire‎ | 17:29 . . (+18) . . 86.20.232.82 (talk | block) [rollback]

See that pipe character between "Glenn Quagmire" and "17:29" ? I coulda sworn that wasn't there before. I will be first to stand up and say...DO NOT WANT ! –xeno (talk) 21:30, 25 March 2009 (UTC)

I was wondering that - I think it is new, and it does look wrong, though I suspect we'll get used to it in time. I assume it's a mediawiki page somewhere, unless it's a software change. Can anyone shed any light on this? — Tivedshambo (t/c) 21:36, 25 March 2009 (UTC)

See MediaWiki:Semicolon-separator. I don't like it much, either. --Conti|✉ 21:33, 25 March 2009 (UTC)

It's been restored to its default value of ; . Algebraist 21:37, 25 March 2009 (UTC)

(edit conflict) I've just deleted it. Consensus should be in place before implementing site-wide appearance changes. –xeno (talk) 21:37, 25 March 2009 (UTC)

Oh what a mess. Try enabling "enhanced recent changes": now you get this:

20:52  Wicked (musical)‎ (diff; hist) . . (-14) . . And1987 (talk | contribs | block) (→Productions) [rollback]

Note that the pipe between "diff" and "hist" has now become a semicolon: they're the same interface message!! Hence my change; I was in fact trying to restore the appearance that was in place before the recent code changes. Happy‑melon 21:48, 25 March 2009 (UTC)

So this is A Bad Thing™? All I know is I don't like that pipe in my watchlist. I fear change. But if I've fucked up something else, by unfucking the watchlist, feel free to re-implement it. I'm sure someone can write me a bit of css code to keep it the way it was before. –xeno (talk) 21:51, 25 March 2009 (UTC)

I think it's an unresolvable Bad Thing, indeed: leaving the semicolon-separator as it is makes those "diff hist" links look awful; but I agree that the pipe looks pretty bad too; and semantically the semicolon should be a semicolon - god knows where else it's being used. The 'correct' solution is to change MediaWiki so that the diff hist links in the watchlist with ERC use the correct separator; I'll file that as a bug. Happy‑melon 22:01, 25 March 2009 (UTC)

cheers. I'll be offline for now. as I said, feel free to reverse my deletion if it's necessary. –xeno (talk) 22:03, 25 March 2009 (UTC)

It's rather weird to have a message "Semicolon-separator" in the first place: What else is this ever supposed to contain but a semicolon, in particular if it is used in different contexts? Messages should be defined by function. --Amalthea 11:09, 26 March 2009 (UTC)

It's there to be localized for languages which would use a different character in this context. --brion (talk) 16:42, 26 March 2009 (UTC)

... while context is simply a semicolon-, dot- or pipe-seperate list. Fair enough. --Amalthea 17:30, 26 March 2009 (UTC)

T20161 Happy‑melon 12:10, 26 March 2009 (UTC)

I've resolved this as invalid, since there's been no change in behavior from previous versions of MediaWiki -- enhanced RC has always used a semicolon there. --brion (talk) 16:49, 26 March 2009 (UTC)

And I reopened it as an enhancement, because it's still inconsistent with other toolbar links. It's a one-line patch: hard to find, trivial to fix. Happy‑melon 18:49, 26 March 2009 (UTC)

{{Gnosticism}} template help please

Resolved

– Moved request. -- Banjeboi 03:27, 27 March 2009 (UTC)

{{Gnosticism}}, a template I have never edited (and I can not stress this enough), is fundamentally in need of redecorating. My feeble tests have all failed even though I think simply switching a few style bits or something would help exponentially. Would someone please add a border and maybe some contrasting background. I'm also concerned the print is rather small but maybe Gnostics and their supporters all have exceptional vision, so to speak. Any takers? -- Banjeboi 12:21, 26 March 2009 (UTC)

Requests like this probably should go to Wikipedia:Requested templates, which is (despite its name) for both improvements to existing templates and for new templates. (This suggestion isn't just a bureaucratic run-around; the template guys hang out at that page.) -- John Broughton (♫♫) 16:56, 26 March 2009 (UTC)

Cheers, I'll likely forget that exists so feel free to readjust anytime. -- Banjeboi 03:27, 27 March 2009 (UTC)

Addition to {{Welcome}}

I ask that the following nullet be added to the welcome templstes:

Intuitive guide to Wikipedia

--Ipatrol (talk) 20:13, 26 March 2009 (UTC)

That page could do with an introduction. You know, for new users. Skomorokh 02:00, 27 March 2009 (UTC)

A proposal to de-table Wikipedia infoboxes

Please see Håkon Wium Lie's latest post in the thread at WikiEN-l. This is a potentially wonderful upgrade to our html-table infoboxes.

(cross-posted from Wikipedia talk:WikiProject Infoboxes, where it might be best to coordinate action/discussion (or reply to the mailing list thread itself). Anywhere else I should crosspost/notify?) Thanks. -- Quiddity (talk) 21:29, 26 March 2009 (UTC)

Reminds me of a monastery or the nomadic lifestyle: clean, elegant, pure as a babbling spring... but of absolutely no use whatsoever in the dirty, confused, standards-uncompliant world in which we live. Makes a great paper. Would make an inferior Wikipedia. Happy‑melon 21:45, 26 March 2009 (UTC)

I stop to wonder why someone hasn't built an infobox extension yet... --Izno (talk) 22:58, 26 March 2009 (UTC)

How do you suggest that would work to be an advance on the infrastructure we have already? Happy‑melon 23:10, 26 March 2009 (UTC)

(e/c)Part of Semantic MediaWiki includes semantic forms that can work similar to infoboxes, but SMW is huge, and evaluating it for use on Wikimedia sites will take a long time. The other issue is that, since some infoboxes are so complicated, that implementing them in an extension without losing significant functionality would be rather difficult. Mr.Z-man 23:14, 26 March 2009 (UTC)

Happy-melon: It was more of a wondering than a "you, go fix" thing. It seems intuitive to me that someone would have put together a better method of infoboxing. For example, there is template:infobox for meta-template purposes, since it has become a wiki-standard (you can find infobox all over Wikia for one, and they can probably be found elsewhere). An extension "version" which would be able to generate smaller code via less (or no) tabling and more semantic HTML seems like it would be a good [great!] idea (and obviously in the direction of the essay, though Gothberg below makes a few points about going too far along in that direction). Something with the syntax of <inputbox> possibly, or even something more like the syntax of the infobox metatemplate. The only real advance on infrastructure is then semantics and individual page size, but I think the latter is a very good idea to strive toward, as I'm positive that would have a non-negligible improvement on page service, even with page caching. Then, if it's an extension, it can probably (more easily?) be coded for graceful failure (I'm not sure if that idea is legitimate...). A second template that could probably benefit from being an extension would be Navbox, as the current tables they are now should decidedly be div and list elements styled with CSS, though I know that they aren't that way for some reason I don't recall.

Mr.Z-man: I'm waiting for someone to get SMW up to snuff, but SMW obviously doesn't focus on the same things as the essay (or even basic web semantics; never mind the complex meta-data usable with SMW). I'm not sure that your point about complication applies with what I've just said, though feel free to tell me wrong. :) That said, not every template would need to use the infobox extension; while it obviously isn't beneficial to have two forms to make infoboxes with, extreme cases like your example could remain templated until the functionality could be built into the extension. --Izno (talk) 20:37, 27 March 2009 (UTC)

I took a look at that page that Håkon Wium Lie has written. The boxes that he is suggesting (and showing at that page) breaks in all browsers I have except my Opera 9.02. And Håkon is the CTO of Opera Software, so of course he would love if we would change all our infoboxes to a system that breaks in all browsers except the browser his company produces.

There is an old rule of thumb when making web pages: Users should use the latest standards compliant browsers, while web masters should use and test in several older browsers and code so it works in them too.

Experience has shown that the only thing that really works when you put several boxes on a page in complex ways is to use HTML tables. Not even DIVs work properly in most modern browsers.

--David Göthberg (talk) 00:07, 27 March 2009 (UTC)

FWIW, it works for me in firefox 3.0.7. I don't think we should adopt it, though, as too many people still use IE6. Anomie ⚔ 03:35, 27 March 2009 (UTC)

Also worked just fine in Safari for me. Nevertheless. Even with {{infobox}} now, I dread the day we have to do ANY conversion. The amount of infobox code that is dependant on it being a table is gigantic. --TheDJ (talk • contribs) 20:59, 27 March 2009 (UTC)

Link meddling (redlink=1)

A change seems to have been made in the last day or two to the MediaWiki software which has had the following effect when trying to send a command to edit a page which is *not* a redlink:

Previous behaviour: title=Talk:Castletown,_Western_Australia&action=edit&redlink=1 -> title=Talk:Castletown,_Western_Australia&action=edit (edits page)
Current behaviour: title=Talk:Castletown,_Western_Australia&action=edit&redlink=1 -> title=Talk:Castletown,_Western_Australia (displays page)

This is utterly frustrating for me as I create a lot of pages which are based on other pages, and now have to manually remove the "redlink=1" from the link in order to jump from one page to another easily using the "address" bar in my Firefox (same would apply in IE). Is there any way this could be minorly tweaked so that if redlink=1 is attempted on a non-redlink page, that it is simply ignored, as it was before? Thanks Orderinchaos 23:44, 26 March 2009 (UTC)

This is T17242. I don't quite follow your description of what you're doing to run afoul of this behavior: could you clarify please? Happy‑melon 00:04, 27 March 2009 (UTC)

Ah OK. What I'm doing is changing the address in the Mozilla Firefox address bar. For example at the moment it says: "... title=Wikipedia:Village_pump_(technical)&action=edit&section=23". I'll give you an example - let's say I'm editing a member list, such as Members of the Queensland Legislative Assembly, 1974–1977. It's a new article, I'm just creating it, the url at the top says "&redlink=1". I suddenly realise a person I want to put in the list is in the 1989–1992 list, so I change 1974-1977 in the address bar to 1989-1992, and hit Enter. Previously, that would open up the 89-92 article in edit mode, so I could copy out the name, then go back to the article I was editing, paste it in, and then continue on. Now, it just opens up the article itself in display mode and I have to click edit. When you've got about 4 or 5 of these in chain, the risk of losing the content in 1974-1977 is much higher as the browser has to retain more in memory (unless I remember each time to remove the additional parameter). Hope this helps. Orderinchaos 01:07, 27 March 2009 (UTC)

Just hit another example - project rating. I'm at Talk:West_Beach,_Western_Australia&action=edit&redlink=1, for an article I've just created. I want to use the exact same rating I used for Nulsen, so I go to Talk:Nulsen,_Western_Australia&action=edit&redlink=1 ... which then only displays the page. Click edit, copy, back, back, paste, hope it works. Orderinchaos 01:18, 27 March 2009 (UTC)

This is definitely a bug - I've used the same technique myself to make quick edits in more than one place. Mediawiki shouldn't be putting up artificial barriers to this kind of edit. — Gavia immer (talk) 01:29, 27 March 2009 (UTC)

How is this a bug? It improves behaviour for normal users clicking on redlinks, and only hurts a few people doing very specific things with the address bar. Algebraist 01:31, 27 March 2009 (UTC)

It's a bug becuase it changed previous behavior that some people rely on to edit, probably without intending to do so, and because it could have been implemented in a way that didn't change that behavior. Mind you, I'm not saying it's a major bug. However, see Happy-melon's post below for what should happen - an explicit action=edit in the url should have precedence, because it's generally going to indicate an experienced editor trying to get right to editing. — Gavia immer (talk) 16:57, 27 March 2009 (UTC)

I think the correct behavior should be that links with only redlink=1 should go to view if the page exists, and edit if it doesn't. Redlinks wiki-wide should only contain "redlink=1", not an explicit "action=edit" parameter; and all urls with the "action=edit" should always go to the editpage. Thoughts? Happy‑melon 10:52, 27 March 2009 (UTC)

That seems like a totally reasonable solution to me. Orderinchaos 02:34, 28 March 2009 (UTC)

Unified Login

I have unified my login. I was under the impression that once I login to one wiki site I would automatically be logged into all other wiki sites. The Special:MergeAccount feature indicates that my login was successful and indeed unified for all the supported wiki sites. However, I'm having to actually login to each site. I'm using Windows Vista Home Premium SP1 and Internet Explorer 8. Has anyone using Vista and IE8 got this working properly?--Techjourney (talk) 05:22, 27 March 2009 (UTC)

That is what is supposed to happen but it can be a bit buggy sometimes. If you haven't already tried it, logout of your main account and log back in. This should reset the global cookies and hopefully allow you to move seemlessly between wikis. Dragons flight (talk) 05:39, 27 March 2009 (UTC)

The automatic login to all other sites feature was enabled and disabled several times and indeed seems quite unreliable in general. Never works for me either, and i'm not really sure how it is supposed to work at this moment. I might also be something very browser dependant perhaps (is use safari). --TheDJ (talk • contribs) 15:08, 27 March 2009 (UTC)

I believe automatic login only works if you go from one wiki to another, i.e. via an interwiki link, thats always worked for me, I've somehow ended up logged into 45 different projects--Jac16888 ^Talk 15:21, 27 March 2009 (UTC)repl

Should work fine unless you've disabled third-party cookies (some browsers may default to that configuration) in which case we don't currently have a good way to set a login cookie for the other domains when you log in. --brion (talk) 16:00, 27 March 2009 (UTC)

~~It's definitely buggy somewhere, Brion~~. I've gotten a welcome message over at ar.wikipedia without having ever logged in there, because I had an account autocreated at some point without visiting it - but visiting Commons or Meta from enwiki, it's essentially a 50/50 crapshoot whether I'll have to log in again or not. I'm using Firefox 3, and I do have some cookie-cleaning stuff, but I've whitelisted all the Wikimedia domains that I care about. It's not a huge deal for me, but it is annoying. — Gavia immer (talk) 17:09, 27 March 2009 (UTC) On second thought, TheDJ's comments below crystalized this for me. It's my browser settings (and the "definite" bug is clearly in my brain somewhere). — Gavia immer (talk) 02:18, 28 March 2009 (UTC)

Unified login works fine for me. And have worked fine all the time since I merged my account some months ago. (I use Firefox 2.0.) But just to make sure since you guys mentioned problems when not first logging in to your main account: I just tested to close and then restart my browser, and then went to Wikipedia in some languages I have never before visited. And I didn't need to log in, the pages showed my user name at the top as usual.

Of course, you have to set your cookie permissions right. I have set my browser to allow and keep any cookies from "wikipedia.org", "wikimedia.org" and "mediawiki.org". And that means it accepts all subdomains too, so it accepts and keeps cookies from "anything.wiki.x.io" and so on. (While I have set my browser default so that for other websites that I have not especially added an "exception" the cookies get deleted when I close my browser.)

Note that it is not enough to allow cookies for just say "en.wiki.x.io", since from what I can see in the cookie list in my browser the central authorisation cookies are stored directly under "wikipedia.org".

--David Göthberg (talk) 17:03, 27 March 2009 (UTC)

Good point. Safari defaults for cookies: "accept only from sites i visit: Block cookies from 3rd parties and advertisers" . That explain why it works going from en.wp->de.wp but not from en.wp->commons. --TheDJ (talk • contribs) 21:20, 27 March 2009 (UTC)

BetacommandBot Warnings

Hi.

There is something i would like you to help me with. There is this bot that put warnings about fair use violations on images, surely you all have crossed ways with one of his warnings sometime; The bot has been out of service for a while now and a lot of the thousands of warnings he put are about images that have already been erased and should be erased as well.

I asked one of the admins that participated in the block of the user that operated the bot about a way to find and/or delete these warnings, other that the manual way at least, and this section came up, so what do you think?. Could some bot or something take care of that, either erase the warnings that are no longer useful either because the image has been erased or because the proper fair use rationale has been added or just generate a list so i could do it manually.

I know is a little too much to ask but i`ll await an answer either here or in my talk page. Thanks in advance. Zidane tribal (talk) 06:32, 27 March 2009 (UTC)

Why should they be removed? Why not leave it to users to decide what to do with their own talk page? Algebraist 08:47, 27 March 2009 (UTC)

They're on article talk pages too. --NE2 10:37, 27 March 2009 (UTC)

But they represent part of the history of the article. Why would they need to be removed? Happy‑melon 10:54, 27 March 2009 (UTC)

Because the "history of the article" belongs in the history tab? I remove them whenever I see them and make another edit to the talk page. --NE2 11:47, 27 March 2009 (UTC)

Which is fine, as would be moving them to the talk page's archive; but I agree with the others that a bot going around just to remove them would be pointless. Anomie ⚔ 12:03, 27 March 2009 (UTC)

I agree that a bot removing them could be too much, but a list of article talk pages that contain them would be ok, i don`t mind removing them manually, but without a list it would take forever, could a list be generated somehow? Zidane tribal (talk) 17:31, 27 March 2009 (UTC)

Special:Contributions/BetacommandBot. All 930,000 of them. Good luck with that :D Happy‑melon 17:41, 27 March 2009 (UTC)

I have been removing them as a matter of course when tagging articles for relevant wikiprojects - I suspect others will do the same. Can't see the effort of searching them out to be of any benefit though and using a bot would just clog up the watchlists of many people. Agathoclea (talk) 19:15, 27 March 2009 (UTC)

I also remove them whenever I see them. I've seen 30kb+ article talk pages which have literally consisted solely of betacommandbot warnings. Crazy. PC78 (talk) 21:44, 27 March 2009 (UTC)

(Sign) Well, at least now i see the magnitude of the task, i guess i`ll have to live with it and just remove them everytime i se them. At least now i `ll be able to hate the warnings more any time i see them. Thanks. Zidane tribal (talk) 23:17, 27 March 2009 (UTC)

Problems to expand secondary subcategories

In category pages, I cann't see the buttons ("[+]") to expand secondary subcategories. These buttons appear beside primary subcategories, but when I expande the primary subcategories these buttons don't appear beside the secondary categories. For example, in Category:Algebra, if I click the button "[+]" that appears beside "Abstract algebra", then it expands and shows subcategories of Category:Abstract algebra, but without "[+]" buttons next to the secondary subcategories, as "Algebraic number theory", "Algebraic topology", etc. I cann't it either when I use "CategorytTree". Example:

I use Windows, with Internet Explorer and Mozilla Firefox. I have the same problem in other Wikimedia projects. Any idea to solve it? Thanks. HUB (talk) 12:00, 27 March 2009 (UTC)

Doesn't work for me either. Chrome, Vista. ManishEarth^{Talk • Stalk} 13:29, 27 March 2009 (UTC)

Doesn't work on testwiki, either. if it was a bug they introduced, the fix would have been there by now testwiki:Category:Treetest ManishEarth^{Talk • Stalk} 13:38, 27 March 2009 (UTC)

They show when you set the depth attribute greater than 2, but the same problem persists if you try to delve deeper. Ofcourcse, this is not practicat.:

Algebra

Theorems in linear algebra

Theorems about polynomials

Theorems in abstract algebra

Algebra journals

Algebraic geometry journals

Computer algebra journals

Algebraic graph theory

Cayley graphs

Regular graphs

Computer algebra

Computer algebra journals

Computer algebra systems

no subcategories

Fractions (mathematics)

Quotients

Unary operations

History of algebra

no subcategories

Mathematical identities

Homogeneous polynomials

Orthogonal polynomials

Polynomial factorization algorithms

Rational functions

Series expansions

Symmetric functions

Theorems about polynomials

Polynomial stubs

Series expansions

no subcategories

Symmetric functions

no subcategories

Variables (mathematics)

Hidden variables

Variable (computer science)

Algebra stubs

Abstract algebra stubs

Linear algebra stubs

Polynomial stubs

ManishEarth^{Talk • Stalk} 13:44, 27 March 2009 (UTC)

Looks like this was broken by rev:48101. --- RockMFR 19:00, 27 March 2009 (UTC)

Reported at bugzilla:18203. --- RockMFR 19:12, 27 March 2009 (UTC)

Template:Wi message appears different before and after log in

As I was wandering around Wikipedia I found the article Miscellaneous on which {{Wi}} was put. The message of the template looks as expected after I log in, but if I log out it becomes like this:

“

Wikipedia does not have an encyclopedia article for Miscellaneous. You may wish to read Wiktionary's entry on "[[Wiktionary:Special:Search/{{{1}}}|{{{1}}}]]" instead.

”

I think the message should not change even for user who choose not to log in. Is it some kind of technical problem or I am just the only one got this problem? --Quest for Truth (talk) 17:54, 27 March 2009 (UTC)

That isn't intended behaviour; I think it was a minor glitch in how the page was rendered. Purging the page (by going to the edit form and clicking save without making any changes) seemed to fix it for me. Tra (Talk) 18:03, 27 March 2009 (UTC)

Special:PrefixIndex broken

Special:PrefixIndex seems to be partly broken. It now behaves more like Special:AllPages.

To get the old kind of PrefixIndex search, where you only see the pages that start with what you search for, then you still can manually do a link like this: Special:PrefixIndex/User:Example

But if you use the search box at Special:PrefixIndex then it also lists pages later in the alphabetical order, more like Special:AllPages. Try going to Special:PrefixIndex/User:Example and then click the [Go] button there and you'll see.

And when using the [Go] button it blanks the search field. Thus making it hard to then also search for instance for the "User talk:" pages with the same name.

--David Göthberg (talk) 20:15, 27 March 2009 (UTC)

Caused by rev:47984 and fixed in rev:48845. --- RockMFR 20:44, 27 March 2009 (UTC)

Ah! Thanks for finding that. Yes, seems to be the fix we need. So since we at the time I write this are at revision 48811, then all we have to do is to wait until they update Wikipedia to run revision 48845 or higher.

For reference, the version and revision at the time you view this page is 1.44.0-wmf.8 (f08e6b3). (Or more correctly: The last time this page was re-rendered. But since this page is edited so often it means "now".)

--David Göthberg (talk) 21:32, 27 March 2009 (UTC)

remove autoconfirmed

Is it possible to remove the autoconfirmed flag? I know the abuse filter is in a position to do so - so I was wondering if that was possible as an admin. In one particular case I am looking at someone who has a load of deleted/reverted contributions which consist of testedits and minor graffiti - not bad enough to warrant a block but due to the break since the first editing s/he could fall under the radar if restarting activity for a third time. Agathoclea (talk) 19:10, 27 March 2009 (UTC)

Autoconfirmation is an implicit group, it can't be "removed". Every time someone makes a request to mediawiki, their autoconfirmed status is potentially recalculated. For example, the threshhold (account age, editcount) for it when using tor is higher than when not, so the same user can be autoconfirmed when editing normally, and not autoconfirmed when using tor. The AbuseFilter extension most likely just adds another condition for such status and withholds it for a timeperiod to simulate "removal". Another similar extension could probably do the same. --Splarka (rant) 07:36, 28 March 2009 (UTC)

So an "alternate startdate" field in the db would do the trick. Agathoclea (talk) 22:38, 28 March 2009 (UTC)

We can, for example by replacing it with a usergroup with autopromotion. Autopromotion is not installed in the core (yet, I'd say), but certain extensions like FlaggedRevs have a built-in autopromotion. There are other ways to remove autoconfirmed without an autopromotion, but not so efficient. Anyway, there is currently a poll on being able to add and remove (auto)confirmed here. Cenarium (talk) 01:27, 29 March 2009 (UTC)

Column option in {{reflist}} breaking stuff

Resolved

– — neuro^{(talk)(review)} 11:52, 28 March 2009 (UTC)

I just noticed a very long reference section on 4 Minutes (Madonna song) and went ahead and split it into two columns. However, this had the unexpected effect of causing the infoboxes and categories from below the reflist template to be omitted from the article, as evident in the old version of the article (note, same diff-link as before). The version before my edit did not have this problem, and since all I changed was adding the two-column option to the reflist template, this must be what caused the problem. The problem is only present in Firefox, but not in Internet Explorer (which doesn't show the two columns, though, but that is described in the template's infobox, so not surprising. -Lilac Soul ^{(talk • contribs • count)} 07:33, 28 March 2009 (UTC)

Works for me perfectly in firefox (reflist|2 doesn't work in Chrome). Try purging your cache.ManishEarth^{Talk • Stalk} 10:53, 28 March 2009 (UTC)

Purging worked. Wonder what went wrong, perhaps just some data transmission thing. -Lilac Soul ^{(talk • contribs • count)} 10:56, 28 March 2009 (UTC)

Special:LongPages

I have asked a question at Wikipedia talk:Special:LongPages#All namespaces. -- IRP ☎ 20:38, 27 March 2009 (UTC)

You have a list of all long pages at Wikipedia:Database reports/Long pages. I think that it's technically difficult to filter those types of special pages by namespace, and it's not currently available. Cenarium (talk) 18:46, 28 March 2009 (UTC)

Switch from soft redirects to hard redirects

In discussing the benefits of doing hard redirects vs. soft redirects with a co-worker, it occurred to me that Wikipedia's (squid) cache servers are potentially wasting space in memory for what are essentially duplicate copies of pages. With soft redirects, for example, the squid servers need to keep a ~300K copy of http://en.wiki.x.io/wiki/University_of_California,_Berkeley and a ~300K copy of http://en.wiki.x.io/wiki/UC_Berkeley in memory (as well as other ~300K copies each of the other 47 redirects) whereas with hard redirects it would only need to keep one ~300K of the article and 48 much much smaller (hard) redirect URLs. Presumably the traffic to the "real" articles is higher than the "soft redirect" versions, and so not all of the "soft redirect" versions will end up being cached... but still, it seems like the ~~performance~~ capacity of the squid servers could be dramatically improved by switching from soft redirects to hard redirects. Thoughts? --UC_Bill (talk) 18:45, 17 March 2009 (UTC)

I'm assuming that by "hard redirect" you mean "HTTP redirect". Take it up with the developers; there's nothing we can do about it here. —Remember the dot ^(talk) 18:48, 17 March 2009 (UTC)

Yes, that's what I mean. I'm bringing it up here first, because it would represent a change to the behavior of redirects on the site, and that would presumably be of interest to many (non-developer) editors. Also, I was under the (apparently mistaken) impression that the technical folk who run the site sometimes read the technical discussion on the site. --UC_Bill (talk) 18:52, 17 March 2009 (UTC)

This exact topic was discussed not too long ago. Don't remember which pump though. ♫ Melodia Chaconne ♫ (talk) 19:14, 17 March 2009 (UTC)

I think you're referring to WP:Village pump (technical)/Archive 56#Moved Page - technical redirect considerations. --Amalthea 21:36, 17 March 2009 (UTC)

You're not mistaken Bill, the dev's do read this page, they just don't necessarily respond to every thread. And on one or two occasions, I've found that shortly after I've asked about technical issues here, a magic fix appears in the MediaWiki code base. :) Don't lose heart...

That's a pretty major change though. How do you propose to inject the "Redirected from [[source]]" message at the top of the target page? Franamax (talk) 21:36, 17 March 2009 (UTC)

I propose we don't inject any such message. It could be done (for 99% of cases) by looking at the HTTP_REFERER (sic) environment variable... but since the whole point is to have the squid cache servers be able to handle the requests themselves (and since they're not able to inject messages into pages) it would end up being skipped in favor of the cached-with-no-injected-message version. That's a minor loss in functionality (some would consider it an improvement since the URL itself would change to the "correct" version.. something that has always annoyed me about the current setup) that results in a HUGE gain in server capacity (and thus performance, given fixed hardware resources.) --UC_Bill (talk) 23:06, 17 March 2009 (UTC)

Because it's reasonable to look at the HTTP_REFERER variable, and then manually type in the URL with redirect=no, just to edit a redirect? --NE2 23:47, 17 March 2009 (UTC)

Admittedly, I don't have intimite knowledge about the squid servers, but surely they are smart enough not to store the same content more then once based on redirects? That would mean redirects aren't cheap after all. — Edokter • Talk • 23:56, 17 March 2009 (UTC)

Ah, I hadn't thought about the usefulness of the "redirected from xxx" links in terms of easy access to the redirect itself. You wouldn't need to know the HTTP_REFERER variable (or rather, you should already know it because it's what you just typed into the browser, before being redirected) but you would need to know to put redirect=no in there, which is a pain.

As for the functionality of the squid cache servers, they would keep duplicate copies of each (regularly visited) redirect page... unless the Wikipedia sysadmins made some custom changes to the code (which they may very well have done.) As for the "cheapness" of non-HTTP redirects, they're cheap from the perspective of the PHP (Apache) servers, but are just as expensive as an actual article from the perspective of the Squid cache servers. Since some really high percentage of requests (over 3/4, last time I read anything about it) are handled by the squid cache servers and never even reach the PHP/Apache servers, I'd argue that it's the cache expense that matters — again, unless the devs have modified the code for the squid software. --UC_Bill (talk) 15:17, 18 March 2009 (UTC)

Disk space is cheap. Just from a quick search, a 15000 RPM SAS disk is going for about $1.06 (USD) per GB (and that's far from the cheapest if all you want is storage capacity). So for $1, you can store about 3500 copies of a 300 KB page, assuming the content isn't compressed in any way. Mr.Z-man 16:33, 18 March 2009 (UTC)

It's RAM, not disk space, and there are a lot more constraints on the amount of RAM that can be put into use in a physical server running the Squid cache software (not to mention the number of actual physical servers available, which are considerably more expensive than adding more disk.) I don't think there's any question (unless I'm wrong about how the squids handle non-HTTP redirects) that replacing non-HTTP redirects with HTTP redirects will result in a dramatic increase in cache capacity (and thus performance.) The question is how to resolve the various side effects of doing so (such as the extra hoops people would need to jump through to edit redirect pages themselves.) --UC_Bill (talk) 17:18, 18 March 2009 (UTC)

I feel that this is a solution to the problem. Use 'hard' redirects, and then simply use the document.referrer javascript variable to find out what the previous page was. The page should have a list of pages redirecting to it, and it should cross-check the document.referrer, and then show 'redirected from' if the referrer page was a redirect. ManishEarth^{Talk • Stalk} 07:29, 19 March 2009 (UTC)

That's an interesting possible client-side solution. It would need a change to - I dunno, wikibits.js? And parsing out the referring page (if it's a same-wiki page) and popping it in at the article top, how would that be done? Could likely be done though. Manish, can you present some specific code? If we don't have a solid solution, there's no use discussing possibilities here. But I'll test your code on my own wiki, and so will many others here. Also, where would your proposed solution fail? Franamax (talk) 07:54, 19 March 2009 (UTC)

Every time a redirect to an article is created, modified, or deleted, the server should, in the background, update the list on the page. (The list could just be some XML on the page). Now, every time the page is opened, it should check if a referrer is there: if(document.referrer){... Then, it should get the XML content, and put it in a convenient array (Should be simple, i'm not writing the code here). Next, use a for loop to cross-reference:

if(document.referrer){
if(document.referrer.split("http://en.wiki.x.io/wiki/").length==2){ //Just making sure that referrer is valid wiki page
//remove the main part of the url from the referrer var, making it easier to compare:
var refer=document.referrer.split("http:\/\/en.wiki.x.io\/wiki\/")[1]//Just getting the name of the page without the stuff around the url. When actually implementing, it would be better to use wgServer instead of http:\/\/en.wiki.x.io
var nameOfReferrer=""
for(i=0;i<redirArray.length;i++){
if(refer==redirArray[i]){//Cross-referencing
nameOfReferrer=redirArray[i]//If match, store name, and break out of loop
break;
}//endif
}//endfor
if(nameOfReferrer!=""){ //If the referrer is a redirecting page
document.write("Redirected from" + nameOfReferrer)//I didnt make this a link to the page, but it wouldn't be hard to
}//endif
}//endif
}//endif

ManishEarth^{Talk • Stalk} 08:28, 19 March 2009 (UTC)

I could write the code for this, but i'm not an admin and i cant put it on wikibits. Also, I'll need to finds a way to do the server-side edit which adds to the XML list. (AJAX wont work because it isn't supported everywhere).

Maybe there is already a list of redirects stored with the page. I suggest seeing the code of Special:WhatLinksHere, as it can distinguish between redirects. If the same code is implemented here, then you can see if document.referrer is a redirect or not. ManishEarth^{Talk • Stalk} 10:04, 19 March 2009 (UTC)

Redirects are stored in the database, but if you have to check that, then any performance gain in memory usage on the squid servers is going to be mostly or completely negated by the extra HTTP request on every page load and the extra database query. Also, can squid "know" that a page is supposed to be a hard redirect? Right now, redirects are implemented in MediaWiki. If you have to start up MediaWiki or do a database query on every page load to check if a page is a redirect, its not really going to save anything. Mr.Z-man 18:23, 19 March 2009 (UTC)

Yes, squid servers understand "hard" (HTTP) redirects just fine, and only need to store the URL that's being redirected to rather than a full copy of the page like they do now. It might be reasonable to include a list of redirects somewhere within some hidden form variables in a page, so they'd be easily accessible to client-side javascript without having to make a second request to get that information. Another nice side-effect of using HTTP redirects is that search engines are (usually) pretty smart about how they index redirects, so that you won't end up with multiple hits for the same page because of the variations in the article/redirect title. Of course, given the prominence of Wikipedia, the major search enginges should already be removing the duplicate entries resulting from Wikipedia's "internal" redirects... but they don't, and HTTP redirects are the standard way of dealing with that anyway, so it's probably still better to take that approach. --UC_Bill (talk) 21:43, 19 March 2009 (UTC)

(Reply to Mr.Z-man) No, there won't be a HTTP request on each page load. The page will contain some XML, hidden fields, or something of the like, which will contain the names of all the redirect pages. The parsing will be client-side. When the page is loaded, local javascript can find the XML and crosscheck it with the document.referrer variable. The only time there is a server request is when you make, remove or modify a redirect page. This doesn't give any extra load, as you are submitting the page at the time, anyway.

To implement this, a change needs to made to index.php, in which if it finds a #REDIRECT tag in the diff, then it can take suitable action (Add an XML tag to the target page if a redirect tag was added, remove the XML if the tag was removed, and remove XML and put it on a different page if the target was changed)ManishEarth^{Talk • Stalk} 06:39, 20 March 2009 (UTC)

So pages with over 900 redirects will have to include all of them as a list in the page text, plus any additional XML or JS markup to make it parseable? (While that's an extreme example, there are 234 pages with 100 or more redirects to them, and over 1000 with 50 or more). People with low-end computers would have to turn JS off when they browse Wikipedia, or never click any links to avoid having a referrer. Mr.Z-man 01:29, 25 March 2009 (UTC)

It just occurred to me that a simpler solution might be to just preserve the current behavior (non-HTTP "internal" redirects) for logged-in users, and to only switch to HTTP redirects for anonymous users. Logged-in users always hit the Apache/PHP servers anyway, since the page is always custom (at the very least it contains their username in the top right) so they wouldn't benefit from Squid optimization in any case. This would make it harder for anons to edit redirects — but is that really a problem? If you're advanced enough of an editor that you want to edit a redirect, is it that big a deal to require you to login, or to put "&redirect=no" in the URL if you can't/won't login for some reason? --UC_Bill (talk) 15:27, 20 March 2009 (UTC)

Actually, no, logged in users don't hit h=the server for their userbar. Its JS generated. The only thing extra we download is our monobook js and css pages. But we are digressing here. The main problem is that if there are 12 or so redirects to a 300K page, the space taken up is 3.6 MB. The point is to reduce that to about 310K (I dunno how much space a nearly empty page takes). Basically, we want to change from redirect pages which are a copy of the article to HTTP redirects, but the snag we are coming up against is that it is a bit tedious (and annoying) to find out where you were redirected from. The reduction of load on the server is just a side-effect. —Preceding unsigned comment added by Manishearth (talk • contribs) 08:24, 21 March 2009 (UTC)

It's not generated by client side javascript. Also, logged-out users will still get a personalized frame, showing their IP, talk page link, and possibly the new messages bar. The same mechanism could possibly be used to place the redirect link. --Amalthea 12:53, 21 March 2009 (UTC)

I've just realized that tis could be solved (and some more things) with IFRAME like behavior. The page could be in an iframe, and so would templates and other transcluded things. That will reduce space for not only redirects, but template usage. Only thing is, I'm not sure if IFRAMEs are supported by most browsers (other than IE.) If they are universal W3C allowed tages, then we could use them easily. 13:24, 22 March 2009 —Preceding unsigned comment added by Manishearth (talk • contribs)

Note that the personalized frame for anons is disabled on Wikimedia sites, specifically because it breaks with squid caching. The new messages bar uses some black magic that tends to not work very well. As for iframes, I don't see how we could use them "easily." Replacing templates with iframes would probably require rewriting large chunks of the parser. Mr.Z-man 01:29, 25 March 2009 (UTC)

Iframes aren't in the w3c recommendation for xhtml 1.1 or the html 5.0 draft and they're not likely to be included, for the reasons located at the link. --Izno (talk) 02:48, 25 March 2009 (UTC)

They aren't? Anomie ⚔ 11:51, 25 March 2009 (UTC)

Hmph. --Izno (talk) 12:45, 25 March 2009 (UTC)

Fixed. Anomie ⚔ 15:10, 25 March 2009 (UTC)

Then forget IFRAMEs. Why not try to implement my original idea, which was to just use hard redirects, and add a bit of XML to the page. The only extra server load it generated is when you are editing a redirect page, and anyways some load is already being created, when you submit. There's nothing to lose. ManishEarth^{Talk • Stalk} 13:02, 25 March 2009 (UTC)

As I said above, many pages have dozens, in some cases hundreds, of incoming redirects. What's more is that the pages with lots of redirects are likely going to be the pages that are more popular and more well-developed (i.e. longer), so that 300 K page may now be a 305 K page, increasing bandwidth usage, and it adds even more JS on pageloads, slowing load time (possibly significantly on pages with lots of redirects). Mr.Z-man 16:45, 25 March 2009 (UTC)

Yes, but the change from 300 to 305 is insignificant as compared to the change from 30000 to 300. Remember, we are removing those redirect pages containing an exact copy. JS doesn't take much time to read and equate 100 XML/HTML tags. Also, the 'redirected from' can be removed for anons, who don't really care about redirects. In fact, the entire redirect list for a page could be stored on a js subpage (protected, of course), so that when an anon views the page, the js won't be loaded, but it will be for users. A checkbox could be added in the user prefs, for removing the 'redirected from'.ManishEarth^{Talk • Stalk} 07:02, 29 March 2009 (UTC)

User rights management?

I just observed that, when I'm looking at a user's contributions, I have a tab labelled "User rights management" after the links for the user's userpage, talk page, etc., up in the top left corner just under "From Wikipedia, the free encyclopedia". I've been an admin since November 2007, but I'm confident that this wasn't available earlier today; do people who have been admins for a certain period of time get a few more rights? Or is this a new feature for all admins? I typed "user rights management" into the search feature (with quotes), telling it to look only at Wikipedia: pages, and I got absolutely nothing. Nyttend (talk) 21:56, 25 March 2009 (UTC)

Don't worry, it's new (#Code updates coming live). :) Cheers, Amalthea 22:04, 25 March 2009 (UTC)

That link is new but all admins have been able to handle requests at Wikipedia:Requests for permissions for a long time. PrimeHunter (talk) 22:23, 25 March 2009 (UTC)

This has been happening at en.wikinews as well for the past few days, I think it is simply a update in the wiki-software. ♪Tempo di Valse ♪ 16:57, 27 March 2009 (UTC)

Interestingly the link shows on contributions but not on deleted contributions which disturbs my sense of symmetry. Agathoclea (talk) 19:21, 27 March 2009 (UTC)

For the symmetry lovers, watch bugzilla:18144 for updates. :) --brion (talk) 20:10, 29 March 2009 (UTC)

Line breaks in page source

If you look at the HTML source of this template, you'll see that whitespace has been inserted between the "NavHead" DIV element and its children. This whitespace is rendered to the page (see here) and should be removed. SharkD (talk) 00:40, 27 March 2009 (UTC)

Can someone take a look at this please? SharkD (talk) 01:06, 29 March 2009 (UTC)

You'll need to be more clear about what's wrong, and how you want it to be instead. I don't see any problem with whitespace. Do you mean the areas between "Sub-genres" and "Topics" where the (almost) white table background is showing through? --Amalthea 21:14, 29 March 2009 (UTC)

Something up with section edits and edit conflicts?

I just got edit conflicts 3 times in a row doing section edits on wp:Requested templates, when someone added something to a different section. not supposed to be the way that works, yah? did I just hit the jackpot on flukes, or is something odd going on? --Ludwigs2 21:03, 27 March 2009 (UTC)

It does not matter what section your edit. You will get an edit conflict, when someone edits the article simultaneously with you, even if it is a different section. Ruslik (talk) 21:18, 27 March 2009 (UTC)

Actually, you only get an edit conflict if the software can't automatically merge the two edits, which it always can if they're in different sections (it can merge edits to two separate paragraphs ok). So no, this is wierd behaviour. Happy‑melon 21:38, 27 March 2009 (UTC)

Hehe, funny, I just did get an edit conflict with Happy-melon above. :))

Ruslik: No, Ludwigs2 is right. Often when two users edit different sections Wikipedia accepts that without an edit conflict. That is often very visible at pages like this page. But I am not sure under which circumstances it works and when it fails. I think one thing that causes an edit conflict is if someone adds a new section or subsection before the section you are editing. Since that screws up the section numbering used to tell where to save your text. So Wikipedia has to cause an edit conflict then.

--David Göthberg (talk) 21:44, 27 March 2009 (UTC)

hmmm... well, what I was doing was adding 'resolved' templates, right under the section headers. maybe there's an issue that crops up when you edit right next to the headers like that? that might cause the software to re-evaluate the section numbers, even if the sections haven't actually changed. or maybe it has something to do with the template itself (though there's nothing particularly special about that template that I can see.) --Ludwigs2 23:40, 27 March 2009 (UTC)

Section numbering should not actually affect edit conflict merging, since merging is done on the complete page text. If an edit was *adjacent* to yours (say, someone changed the couple of lines right above or below the line you changed) then the merge is more likely to get confused and throw it back to you for manual merging. --brion (talk) 00:11, 28 March 2009 (UTC)

So I guess that's why we get crap-flooded with two revisions in their entirety, when we're only trying to make a section edit? Seems like there should be a better way except in the rare case where somebody renamed or destroyed the section you were trying to edit. — CharlotteWebb 16:09, 28 March 2009 (UTC)

Likely we could make the merging a little smarter for this case, yes. :) --brion (talk) 19:52, 29 March 2009 (UTC)

Interwiki mail

OK, I know that we now log on to all the wikis we have accounts with a single logon. But is there any way we can arrange the system so that we are notified of any new mail we might have in any of the wikis at the same time, passibly through the "you have new mail" bar, rather than having to bounce between them to see if anything new has happened? John Carter (talk) 19:22, 28 March 2009 (UTC)

That would be new messages, not new mail, right? In any case, I can suggest two workarounds: (1) other Wikimedia Foundation wikis allow you (in "my preferences") to specify that you want to be notified by email whenever your user talk page changes [I say "other" because this option is not available here, at the English Wikipedia], and (2) you could post a note on your other user talk pages asking that editors post on your English Wikipedia user talk page rather than on those pages. -- John Broughton (♫♫) 00:42, 29 March 2009 (UTC)

Yeah, messages, sorry. Thanks. :) John Carter (talk) 00:46, 29 March 2009 (UTC)

And to answer your question directly: no, there is no way, currently, for notification to be cross-wiki. You could suggest this at bugzilla, as a feature request, but I very much doubt that the developers would be interested. (It wasn't trivial to implement single logon, because the each wiki - I believe - runs as a different instance; that allows, for example, a phased-in approach for new features, as well as for different wikis to have different parameters, messages, etc.) -- John Broughton (♫♫) 01:15, 30 March 2009 (UTC)

An extra-wiki solution might be to use RSS to track changes to each of one's talk pages. I don't know if all of the projects in which you participate have implemented RSS, but it facilitates a unified page view, albeit not on any one wiki. --AndrewHowse (talk) 03:30, 30 March 2009 (UTC)

Inline image maps?

Resolved

I'm trying to create a series of inline image maps. However, successive image maps always appear on a new line. See here. Anyone know of a workaround? SharkD (talk) 05:25, 29 March 2009 (UTC)

If you would just be using the default [[example]] setup for the link (a clickable image), just use a normal inline image and specify the |link=example parameter that the devs bestowed upon us. If you actually want an image map inline, then you need to mess around with really hackish CSS involving mainly putting the entire paragraph within a special element. {{Nihiltres|talk|log}} 05:56, 29 March 2009 (UTC)

Actually I am trying to do the opposite: I am tying to make the images "unclickable". Normally, specifying an image map with no dimensions does the trick. But in this case I also need the images to be rendered inline. SharkD (talk) 07:07, 29 March 2009 (UTC)

Hmmm

hmm. --Splarka (rant) 13:12, 29 March 2009 (UTC)

[[Image:Wiki.png|link=]] <- if that wasn't clear. :) --brion (talk) 19:48, 29 March 2009 (UTC)

ass pus?

on wikiquote, there is an ad for ass pus productions. its visible here and i have upped a screenshot here. badmachine (talk) 08:50, 29 March 2009 (UTC)

That's wikibooks actually, and the edit was made and reverted back in October. Why are you mentioning it now? — CharlotteWebb 11:08, 29 March 2009 (UTC)

have a look at the screenshot before its gone. the ass pus as is on wikiquote and wikibooks. the diff came from a google search, the screenshot was after i edited something at wikiquote. badmachine (talk) 11:22, 29 March 2009 (UTC)

It's just some clever css, not a hack. — Blue-Haired Lawyer 12:10, 29 March 2009 (UTC)

background-image in table markup

I have been playing with tables :Duration of Copyright (UK), and want to replace the lilac background-color (sic) of a single cell, with a background-image. Does anyone know how to do it? --ClemRutter (talk) 09:59, 29 March 2009 (UTC)

Background images aren't allowed in inline mediawiki markup, you'd have to request it at MediaWiki:Common.css but you'd need a very good reason. --Splarka (rant) 13:14, 29 March 2009 (UTC)

Dremelspitze

This would only be okay for general use if there is some way to limit it to free images hosted on Commons. Floating text labels over a blank map would be one realistic example, though I know there are already more complicated ways to do this with z-index, etc. Perhaps we could come up with some kind of in-house syntax for using a background image in a div or table cell, which would be converted to

background-image: url(http://up.wiki.x.io/wikipedia/commons/thumb/6/61/Austria_location_map.svg/250px-Austria_location_map.svg.png)

for example. Seems like that would be simpler than mucking around with several super-imposed divs. — CharlotteWebb 18:09, 29 March 2009 (UTC)

Rollback

Did someone remove the [rollabck] links from the watchlist or these links weren't there in the first place? —SV 12:36, 29 March 2009 (UTC)

Yeah it's gone. Good ridence. ♫ Melodia Chaconne ♫ (talk) 13:09, 29 March 2009 (UTC)

Domas broke it while live-optimizing, but he fixed it after in rev:49002. --Splarka (rant) 14:44, 29 March 2009 (UTC)

Categorytree extension

I am using the categorytree extension at WP:DERM:CAT (see expandable tree on the left). However, although there have been no changes to the categorytree tag on that page recently, the tree now no longer expands past one level (see how the second level categories have no [+] next to them). What is the problem? kilbad (talk) 13:19, 29 March 2009 (UTC)

See #Problems to expand secondary subcategories above. --—— Gadget850 (Ed) ^talk - 13:44, 29 March 2009 (UTC)

Ping from MediaWiki talk:Newarticletext

See talk page entry. --Yecril (talk) 19:47, 29 March 2009 (UTC)

Done - Fixed.

--David Göthberg (talk) 22:41, 29 March 2009 (UTC)

Invisible text on talk page

At Talk:Historicity of Jesus, the last few edits are invisible. Specifically, this set [11]. I can't figure out how to fix it, I managed to get a small bit to show but with my sig, so that was no good. Thanks. Dougweller (talk) 21:20, 29 March 2009 (UTC)

It was fixed in [12] by closing a comment which was messed up in [13]. PrimeHunter (talk) 22:28, 29 March 2009 (UTC)

Wikipedia:Date formatting and linking poll now open

The date linking and formatting poll is now open. All users are invited to participate. Ryan Postlethwaite^{See the mess I've created or let's have banter} 23:00, 29 March 2009 (UTC)

Stub

Resolved

– Answered elsewhere rʨanaɢ ^talk/_contribs 13:08, 30 March 2009 (UTC)

Please could someone define the Wikipedia meaning of "stub article"? I created Fledgling Jason Steed yesterday and marked it as "start class," before nominating it at DYK. (It isn't massively long, but it does have 25 refs etc). However, another editor removed the start tag and marked it is a stub. I always thought a stub was just a few lines, or a couple of paragraphs at most...--Beehold (talk) 11:39, 30 March 2009 (UTC) (PS, I've also posted this at DYK discussion - as I wasn't sure which page to use).

Did you try asking on the user's talk page, or the talk page of the relevant WikiProject? This is certainly not the right place, and I doubt DYK is either. Anomie ⚔ 12:31, 30 March 2009 (UTC)

I've answered this question at DYK. rʨanaɢ ^talk/_contribs 13:08, 30 March 2009 (UTC)

English Wikipedia brief outage

Memory condition crashed the database master for English Wikipedia; we were down for about 25 minutes. All restarted and recovered now; others sites not affected. --brion (talk) 23:43, 30 March 2009 (UTC)

Save draft

Looks like a feature for saving as a draft (It won't be shown on the page, but while editing you have the choice to load from different drafts) is coming soon. It's been loaded onto testwiki: (1.15alpha (r48811)), where MW updates usually come a bit earlier.ManishEarth^{Talk • Stalk} 04:56, 31 March 2009 (UTC)

Proposed new admin tool

Sometimes people use a public terminal, or they have mischievous over at their house. Some way or another the account of an otherwise good contributor falls into the hands of a childish vandal. More often than not the password is not compromised, but rather the user just left themselves logged in on an unattended computer.

I suggest a simple tool that will allow an admin to log out a user that is suddenly acting strange. The user can then simply log back in if they are the true user, but the usurper is left looking at a log in prompt. I am sure it would not be too difficult for the developers to create. What do people think? Chillum 17:36, 25 March 2009 (UTC)

Define "strange". --—— Gadget850 (Ed) ^talk - 20:07, 25 March 2009 (UTC)

I would define it as when an otherwise great contributor suddenly acts in a way that would get him/her blocked in a manner inconsistent with their personality. Pretty much in those situations where you say to your self "I don't think this is the same person". In such cases our only choice is to block, even when we suspect the account is compromised. Another option than blocking would be nice. Chillum 20:46, 25 March 2009 (UTC)

But how many people have their browser remember their password, so the illicit user would find the login form pre-filled for them? Anomie ⚔ 02:04, 26 March 2009 (UTC)

Yes, it is not perfect, but it is better than nothing. If the account logs back in and acts disruptively then we block it. Chillum 02:19, 26 March 2009 (UTC)

One possible (minor) issue I can see is that because this is of such limited utility, will people actually remember to use it? 1) It would be new, so more experienced users may not even know about it when a use for it arrives, and 2) for the given use, its "competing" with one of the core admin tools, blocking. I mean, how many admins when (or if) they ever have to do a mass rollback remember that they can add &bot=1 to the URL when loading Special:Contributions to hide the rollbacks from recentchanges? Mr.Z-man 02:54, 26 March 2009 (UTC)

Another problem is that when this is used, it will often just be a waste of time. If the person running amok is the user themself, or someone who's acquired their password, or someone with access to their computer and they have password remembering switched on, then the time spent trying this new tool and seeing that it hasn't worked is more time in which the account is causing damage. Sure, this is quite a small downside, but the gains are also minimal (i.e. people in the situation in the original post wouldn't have to request unblocking when they come back). Algebraist 02:46, 26 March 2009 (UTC)

So it will not always work, people will not always use it. So? If it is useful to some and causes no harm then why not? There is such a tendency here to seek any reason not to do something new. Perhaps this is not to be, but not for lack of merit. Chillum 02:52, 26 March 2009 (UTC)

I have just explained that it will cause harm: if used, it will cause a slight increase in vandalism from compromised accounts. Algebraist 03:00, 26 March 2009 (UTC)

Only about as much as issuing a user warning. Really, I don't think that harm is significant enough to consider. I would rather prevent a block than prevent the need for another revert. Chillum 03:05, 26 March 2009 (UTC)

I see how this could be beneficial, but the cases in which it would work are extremely limited I imagine. I doubt it would get more than a few correct uses a year. A block is a perfectly good option for 'strange acting' accounts. If the account was really left in they can come back and get unblocked. No problem to fix here. Icewedge (talk) 03:05, 26 March 2009 (UTC)

Its not seeking "any reason not to do something new" but requiring a good reason to do something new. We have limited developer resources, so unless you're volunteering to write this, software tasks are prioritized based on 1) How much developers want to do it (most devs are volunteers), 2) How useful it is or how serious a bug it is, and 3) How much people actually want it. Yes there's very little downsides to having it, but there's also very little upsides too. Mr.Z-man 03:16, 26 March 2009 (UTC)

Fair enough, I suppose I was out of line with that comment. Sorry. Perhaps I will just go and write this one day. Chillum 22:55, 26 March 2009 (UTC)

The major utility that I see in the proposed feature would be the ability to reduce the likelihood of someone changing the legtitimate account holder's password and e-mail address. (The sooner the illicit user is logged out, the better.) But this needn't be an alternative to blocking. Instead, I think that the best implementation would be the addition of a "log out this account" checkbox in the block dialogue. That way, assuming that the password hasn't been changed, the legitimate account holder could simply log in and plead his/her case (via his/her talk page or e-mail). This would be far from perfect (because of the illicit user's ability to change the account's password before getting caught and the possibility that the password is in his/her possession or the computer's memory), but I see no potential harm. As Mr.Z-man notes, however, we'd need to see whether this is technically feasible and worth coding. —David Levy 03:26, 26 March 2009 (UTC)

It just occurred to me that an account's password cannot be changed without entering the current password (unless it's stored by the browser, in which case it will be pre-filled). So for this feature to make sense, it also would have to prevent the account's password from being changed by anyone for the duration of the block. —David Levy 03:45, 26 March 2009 (UTC)

That's another good feature to add... password conformation while changing the password. The browser autofill won't know if the field is the password field requiring the same password as login, so there is no way the password can be changed by someone else.

To answer the original discussion, why not have a 'sleep' mode, in which you are logged in to all of the pages, and any unsaved work is kept frozen, but to resume you have to enter your password again. ManishEarth^{Talk • Stalk} 13:26, 27 March 2009 (UTC)

You might be able to implement that as a user script; depends on the availability of hashing functions (I'm not familiar with JavaScript). --Thin boy 00 @876, i.e. 20:01, 31 March 2009 (UTC)

For the record you can change the e-mail address of an account without knowing the old password, then request a temporary password, then change the password with that. It only takes time. I am not sure but I think it can be done while blocked, you sure can't do it while logged off. Chillum 14:29, 27 March 2009 (UTC)

Of course this means that anyone who compromises your e-mail account (which is most likely easier to crack) can easily get hold of your Wikipedia account by sending a temporary password to it. Then they can log in and remove your e-mail address from Special:Preferences to ensure that regaining access to your e-mail account (if possible) won't do you any good. — CharlotteWebb 16:29, 28 March 2009 (UTC)

Stopping media clips

When I start a clip, stop it, go to another page and then return, the clip re-starts without being asked. This is not a serious or even noticeable problem with silent movies like the one at Cnidaria, but is quite annoying with sound clips such as those at Grindcore - especially as there are 2 on the page and they both re-start. --Philcha (talk) 15:32, 28 March 2009 (UTC)

Grindcore eh? Well if there ever was a time to be glad I can't get these to play at all, this is it. On a less personal note I really doubt fair use policy was ever meant to cover this. — CharlotteWebb 16:00, 28 March 2009 (UTC)

Works for me. Tell me the player that you are using (You can find out by clicking "more..." under the clip after you press the blue playbutton)

I'm able to reproduce it. Go to the Grindcore page. Scroll down to the first media clip and click the play button, so that it plays in the Java applet. Then click the stop button before it finishes. Then scroll down to the second clip and click the play button, followed by the stop button. Now click on a hyperlink, to take you to another page. When you click back, you hear both of the clips being played. I'm using the Cortado (Java) player in FireFox. Tra (Talk) 09:41, 29 March 2009 (UTC)

Be happy you're not going to Marathi_phonology#Consonants That page has about 60 clips.ManishEarth^{Talk • Stalk} 02:50, 29 March 2009 (UTC)

This behavior is likely different between different browsers and different underlying players, but we'll want to look into it. :) --brion (talk) 19:51, 29 March 2009 (UTC)

It works perfectly for me on Firefox 3.0.8. Check the Java version. I use Java 6 update 10ManishEarth^{Talk • Stalk} 10:28, 31 March 2009 (UTC)

Submitted bug report at bugzilla. Number 18281. Plleases add yourself to the CC list and improve my description.

Image/File deletion issue

Something I've run into recently and I'm not too sure where to take it up...

I've been having problems with file deletion for images. The upshot is that I cannot delete individual versions of the file. If I try to remove the next newest or older version, the entire page is deleted.

Any ideas what this may be or where I should be taking this up?

Thanks,

- J Greb (talk) 18:11, 28 March 2009 (UTC)

Have also run into the exact same problem - unable to delete 'old' revisions of files Skier Dude (talk) 23:42, 28 March 2009 (UTC)

To everyone else that read this: Only admins can delete pages. J Greb and Skier Dude are both admins.

Do you mean deleting the image itself or the image description page?

1: For the description page (just like any other page) if you want to delete some old version but not the latest version then do like this: First delete the entire page, then restore the versions you want to keep. If it is an image page then don't forget to restore the image too.

2: If it is the actual image you mean, then look at the "File history" section on the image description page. There are [delete] links in the left column there, they delete the specific version of the image shown in that table row.

So are you saying that those delete links in the left column doesn't work anymore?

--David Göthberg (talk) 19:53, 29 March 2009 (UTC)

Yup, situation 2 - in working with an image that had 6 up loads showing in the "File history", using the "[delete]" link for numbers 2, 4, and 6 each resulted in the entire page going. I had assumed a miss-click on my end the first time (removing the "newest" of the old), so it was a case of fully restoring the page in between tries. But in trying the older versions and getting the same result I realized it didn't seem to matter - all pf the "[delete]" links seem to be reading as "[delete all]".

- J Greb (talk) 20:24, 29 March 2009 (UTC)

Just reporting that the image reversion deletion is still broken - all that is allowed is to delete the entire image and then restoring just the wanted image and appropriate page(s). This is extremely tedious compared to the correct 'delete revision'! There is a bit backlog here Category:Rescaled fairuse images more than 7 days old (c. 400 images) where this feature is extremely useful. Skier Dude (talk) 17:00, 31 March 2009 (UTC)

Confirming this bug. The individual "delete" links all go to the regular deletion page, rather than deleting the individual revision. Does anyone know if this has been reported as a MediaWiki bug? Papa November (talk) 17:27, 31 March 2009 (UTC)

It has been reported here Papa November (talk) 17:30, 31 March 2009 (UTC)

Can I change style of footnote numbers

I am authoring a list of mainstream topics where dissenting opinions appear in the footnotes. Do I have any control over the footnote indices appearing in the main text? I would like to have all the footnote numbers of one dissentor appear in the same color. Any other change such as size, shape, or numeric range could also be used. Phil_burnstein (talk) 20:59, 30 March 2009 (UTC)

I don;t think that is the best way to do this. We have to consider those with color vision problems as well as print rendering. If there is a good reason to split references, I suggest using reference groups: see {{reflist}}. --—— Gadget850 (Ed) ^talk - 11:09, 31 March 2009 (UTC)

Why does this appear in a user talk page's history?

Mysterious "comment removed" entry

Why does it show "comment removed" in a user talk page? (See screenshot; I forgot which page it was.) Kimchi.sg (talk) 08:32, 31 March 2009 (UTC)

Its an Oversighted edit. —SV 08:34, 31 March 2009 (UTC)

But I thought oversighted edits don't show up in histories at all? We've had oversight for years (since 2006 IIRC) and I only began seeing this type of entry recently. Kimchi.sg (talk) 08:45, 31 March 2009 (UTC)

It's part of the new RevisionDelete extension. Graham87 09:19, 31 March 2009 (UTC)