Wikipedia:Village pump (technical): Difference between revisions

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at the BugZilla.

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

view · edit Frequently asked questions (see also: Wikipedia:Technical FAQ) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

To-do: E · H · W · R Updated 2009-09-19

I'm posting this here to find out if this is plausible...

Highlight a term and then press enter to go to the wiktionary entry on that term.

1. Would this be easy for developers to add to the Wikimedia software?

2. What is the current proposal process for adding new features to the software?

The Transhumanist    23:07, 15 September 2009 (UTC)[reply]

Might be posible through javascript. For instructions on how to submit requests see Wikipedia:Bug reports and feature requests©Geni 23:11, 15 September 2009 (UTC)[reply]

I was sort of thinking about this myself, a while back. Why not simply interwiki-link to important words within body text? If it's an item that is directly relevant/related to the article topic, then a Wikipedia link would be more appropriate. If it's a more unusual word though, I wouldn't have an issue with a Wiktionary link being in the body text.

Putting the above aside and addressing the specific idea here though, the New York Times does this on their web site, and I see no reason why we couldn't either. I just don't see a compelling reason not to create interwiki-links, using the existing tools, is all.
— V = I * R (talk to Ω) 23:17, 15 September 2009 (UTC)[reply]

It is subjective to define "unusual word", as the standard of a native speaker must be different to ESL, and may depend on many other factors. --Quest for Truth (talk) 23:30, 15 September 2009 (UTC)[reply]

I don't quite understand the request; IE8 and FF 3.5 do that already. -- Michael Bednarek (talk) 05:42, 16 September 2009 (UTC)[reply]

What you mean is Internet Explorer 8#Accelerators? How about people not using IE8 and FF 3.5? I suggest you check out http://www.nytimes.com and experience the dictionary yourself. --Quest for Truth (talk) 12:19, 16 September 2009 (UTC)[reply]

Since this feature is useful on all websites, not just Wikipedia, it's better provided by a browser addon (of which several are already available) then by a Mediawiki feature. Algebraist 15:47, 16 September 2009 (UTC)[reply]

I'd guess the best way to implement this would be as a Javascript gadget, something similar to Navigation popups. Then it would be available as an option to the registered users and wouldn't be forced upon everyone. Quibik (talk) 00:28, 17 September 2009 (UTC)[reply]

That's cool, then an optional gadget will be available to those who like this idea. It won't affect those have other solutions or those simply don't want this feature. --Quest for Truth (talk) 15:37, 19 September 2009 (UTC)[reply]

The recent MediaWiki upgrade to the English Wikipedia contained a MediaWiki change that broke templates like {{flag}} that generate images designed to be invisible to the screen readers used by visually impaired people. Formerly, usage like this:

[[Image:Flag of the United States.svg|22x20px|link=]] [[United States]]

generated an image with no alt text, which caused screen readers to silently bypass the image, as intended (because it's just decoration; all the intended info is also in the adjacent text). But now it generates " United States", whose image contains the unwanted alt text "Flag of the United States.svg".

The change was installed by Remember the dot (talk · contribs), so I left a note at User talk:Remember the dot #Repercussions of alt-text handling change, but that user's most recent edit says "I will be leaving very soon for a period of two years" so I'm worried that this will fall through the cracks. Does anybody happen to know who's in charge of that section of code these days? I'd like to see this one fixed. Eubulides (talk) 22:31, 18 September 2009 (UTC)[reply]

What's wrong with using |alt=? Algebraist 22:43, 18 September 2009 (UTC)[reply]

Before, editors could mark purely decorative images with "|link=" but now they must remember "|link=|alt=" (both are now required). More important, English Wikipedia must have hundreds of templates and/or articles that rely on the old behavior, are now broken from a WP:ACCESSIBILITY viewpoint, and will have to be fixed by hand if this software change is permanent. (As an aside, I'm mystified as to why the change was made in the first place; ordinarily a screen reader falls back on the file name if no alt text is specified, so why should MediaWiki clutter up the HTML with another copy of the file name?) Eubulides (talk) 23:01, 18 September 2009 (UTC)[reply]

I requested the change in this discussion at Code Review, which I found through this message on my talk page. JAWS 10 and later don't announce links to images properly if they have no alt text, even if the image has title text. Formerly they said "link graphic filename"; with JAWS 10 and later, they would've said "Link filename", which I found to be more confusing. I thought that rather than relying on the screen reader to automatically say the filename, it should be put in the alt text so screen readers have *something* to work with. Maybe a default alt text of "Missing alt text" or even "Image link" would be appropriate.

I didn't think of the case where the image doesn't contain a link; that behaviour should be reverted back to the way it was previously because the current setup is annoying when images are unlinked. I was going to bring that issue up, but you beat me to it. I'll drop a note at the above-linked Code Review page, as well as Simetrical's talk page, since he works with accessibility issues. Graham87 10:40, 19 September 2009 (UTC)[reply]

This bug report might be related. —TheDJ (talk • contribs) 11:03, 19 September 2009 (UTC)[reply]

I've tried to update File:Long_leg_hair.jpg with a better version but I get an error saying that there is a file with that name on commons but there isn't. I've tried it twice and it does the same thing. Is this just temporary because of the software update? Smartse (talk) 12:36, 17 September 2009 (UTC)[reply]

Probably bugzilla:20677 —TheDJ (talk • contribs) 13:16, 17 September 2009 (UTC)[reply]

I've been having this problem as well for over a day now and it's getting seriously annoying – this has blocked me from uploading quite a few images. Quibik (talk) 14:00, 17 September 2009 (UTC)[reply]

Ok, at least someones is on the case then. Thanks for you help. Smartse (talk) 14:06, 17 September 2009 (UTC)[reply]

Haven't seen the warning about files on commons, but I am seeing a 'failed to calculate hash' warning which was also reported on that bug, which should help us narrow down at least part of it. Michael's poking at it but hasn't been able to reproduce all the problems yet. --brion (talk) 18:59, 17 September 2009 (UTC)[reply]

I'm trying to upload a new image for File:Phantasy Star Portable 2 Cover.jpg, but anyway I try to, I get:

Upload warning

A file with this name exists at the Wikimedia Commons. You can:

*go back and upload this file to Wikipedia using a different name.
*upload it to Commons, if your intent is to replace the image that already exists with a better version.

File:$1
$1

There is no image named this on Commons, and it shouldn't be. Is there something wrong? MrKIA11 (talk) 18:40, 17 September 2009 (UTC)[reply]

See #Image update problem above. ---— Gadget850 (Ed) ^talk 18:55, 17 September 2009 (UTC)[reply]

I was finally able to upload the file. MrKIA11 (talk) 23:31, 21 September 2009 (UTC)[reply]

I noticed File:SuckerShirtFinalFlat.jpg, which is at excessively high resolution for a fair-use logo. So, I download it, reduce resolution, and attempt to re-upload by clicking the "upload a new version of this image" link at the file page. I get an error message telling me "A file with this name exists at the Wikimedia Commons. You can: * go back and upload this file to Wikipedia using a different name. * upload it to Commons, if your intent is to replace the image that already exists with a better version. ". There is no such image at Commons. —Kww(talk) 01:29, 20 September 2009 (UTC)[reply]

See #Image update problem above.
— V = I * R (talk to Ω) 01:35, 20 September 2009 (UTC)[reply]

• This is probably the same as #Image update problem. –Drilnoth (T • C • L) 01:35, 20 September 2009 (UTC)[reply]

• File:Periodic table by article value.PNG
• File:Periodic table by page views.PNG
• File:Element Page Views Distribution.png

I am trying to upload new versions of the above images. When I do so, an error message pops up saying that the files exist on Wikimedia Commons and that I should upload there instead. When I go to Commons, the files never come up in searches, and I'm pretty sure they were never uploaded there in the first place. Any ideas? --Cryptic C62 · Talk 18:50, 20 September 2009 (UTC)[reply]

See #Image_update_problem section above. Ruslik_Zero 19:05, 20 September 2009 (UTC)[reply]

The cite software has been updated to allow definition of references within the reference list. See Wikipedia talk:Footnotes#cite.php update. ---— Gadget850 (Ed) ^talk 13:07, 17 September 2009 (UTC)[reply]

This looks very interesting. I just wish cite.php was less like html/xml and more like wikicode. --Apoc2400 (talk) 15:32, 17 September 2009 (UTC)[reply]

Couldn't a template be made that basically encloses the xhtml tags within a wiki template? So you could use something like {{ref|name=Foo|(content)}} and then have the template itself contain <ref {{#if:{{{name|}}}|name="{{{name}}}"|}}>{{#if:{{{1|}}}|{{{1}}}|}}</ref> ? Heck, it could also enclose citation templates in it, so that instead of the unnamed parameter (which would contain a template like {{cite web}}, you could just use all the parameters of {{citation}} and then this template would pass them through to create a ref. –Drilnoth (T • C • L) 15:41, 17 September 2009 (UTC)[reply]

I'm all for that. The main holdup though is that the {{ref}} template already exists, and is (still!) used for non-cite.php references. There are a lot of people who learned to do citations without cite.php, and they don't seem to want to change.
— V = I * R (talk to Ω) 16:01, 17 September 2009 (UTC)[reply]

Well, yes. 'Twas just a placeholder name. We could always just move the current template and have a bot rename all usages. –Drilnoth (T • C • L) 16:14, 17 September 2009 (UTC)[reply]

There are literally thousands of {{ref}} uses, and I don't see those editors who still use it regularly as being appreciative or supportive of a change. If you want to float a proposal about doing so though, I'll certainly support you (I'm just guessing that it'll float like a lead balloon, is all). One of the main tasks that my bot is (eventually) going to be used for is to clean up and organize refs, so this kind of thing is right in my bailiwick.
— V = I * R (talk to Ω) 16:35, 17 September 2009 (UTC)[reply]

Do you have a better idea for a name? I'm completely open to suggesstions. {{Cite}}, perhaps? That wouldn't be nearly as controversial; a bot would just need to bypass the redirects. –Drilnoth (T • C • L) 16:43, 17 September 2009 (UTC)[reply]

I believe that this new extension of cite.php finally replicates the single most attractive feature of the{{ref}}/{{note}} system - that it keeps the citation information from cluttering the body of the article. But there might remain differences of opinion about other disparities in how the two systems function. Christopher Parham (talk) 18:00, 18 September 2009 (UTC)[reply]

Try {{#tag:ref|Whatever}}. — Werdna • talk 17:23, 17 September 2009 (UTC)[reply]

(e/c)Are there other reasons for doing this other than making ref tags more like templates? Using multiple systems like this breaks consistency between articles here and between other wikis, makes things harder to learn, and will likely also break any script or bot that works with or parses references. References are already one of the biggest bottlenecks in terms of parsing time due to templates like {{citation}} being so complicated and large articles having dozens of refs. Increasing the complexity will just make it even worse. Mr.Z-man 17:25, 17 September 2009 (UTC)[reply]

The problem, I think, is that new users need to figure out two ways of formatting things... HTML-style and wiki-style. Only one should really be used, IMO, although for experience editors it doesn't really matter. It's just trying to get used to it for new users. I know that this is probably never going to happen because of parsing issues, breaking tools, etc.; I just thought I'd toss it out there as something which could be done. –Drilnoth (T • C • L) 17:37, 17 September 2009 (UTC)[reply]

It would be one thing if we switched to a template-based system, and then converted all existing uses to it (though we would still be inconsistent with other wikis), but using multiple systems seems like it would just be more confusing (and more likely to break things) than one "non-standard" system. When I started on Wikipedia, I learned how to do most things by example, from looking at other articles, only referring to guidelines and help pages when examples weren't clear. Mr.Z-man 17:48, 17 September 2009 (UTC)[reply]

Ditto. I think it will take a while before list-defined references take off; heck, a lot of editors are still not aware of the groups feature. We need to document use at Help:Footnotes and include some guidelines. I will do some more testing on this and will update features on the help page as I discover them. ---— Gadget850 (Ed) ^talk 17:58, 17 September 2009 (UTC)[reply]

Exactly. I wanted to mention a couple of relevant points here, however.

• First, cite.php is an extension, and is therefore already non-standard (although, it's use is so widespread now that pointing out that it's "non-standard" admittedly seems strange).
• Prior to the installation of cite.php people used {{ref}}, which is why that template already exists. I'm not sure if it's due to a lack of motivation or actual resistance, but it appears that there is support for retaining the "pre-cite.php" referencing.
• In the vast majority of areas we already prefer templates over xHTML tags, and the main reasons to do so are ease of use, maintainability, and standardization.

Personally, I wouldn't have any issue with folding <ref></ref> tag use into {{ref}} and even {{Citation/core}}, which would require removing the <ref> and </ref> tags from around the majority of existing references. It's a large migration project, but I think that it would be helpful to most people, and it would certainly simplify the source wikitext in the vast majority of articles. As for the learning curve, once the conversion started I think that people would catch on fairly quickly. There would need to be a specific migration period that should last a while (2 weeks would be the minimum, I would think), but it could be done.
— V = I * R (talk to Ω) 18:57, 17 September 2009 (UTC)[reply]

Nothing is stopping us from making the templates and let those who want to try it. I don't think we should organize a mass migration unless the new type is well-proven and well-liked. --Apoc2400 (talk) 19:11, 17 September 2009 (UTC)[reply]

Both {{ref}} and {{Citation}} are already in use, and are in such widespread use that their fully edit protected, so there's no possible way to boldly experiment.
— V = I * R (talk to Ω) 19:45, 17 September 2009 (UTC)[reply]

We could use {{ref2}} or {{cite2}} or come up with something else while testing. --Apoc2400 (talk) 20:04, 17 September 2009 (UTC)[reply]

I updated Arthur Rudolph to use list-defined references as an example. As to {{ref}}— most current uses could be replaced by the groups feature of cite.php. ---— Gadget850 (Ed) ^talk 19:12, 17 September 2009 (UTC)[reply]

Agreed, they could be, and I personally think that they should be, but someone needs to go and create consensus to change them.
— V = I * R (talk to Ω) 19:45, 17 September 2009 (UTC)[reply]

How about we try it for a while before mass-changing? --Apoc2400 (talk) 20:04, 17 September 2009 (UTC)[reply]

It appears that this

I suspect that the xml-like syntax has not been replaced with a template yet because putting the other citation templates inside gets ugly: {{ref|{{cite book|author=...}}}}. With the new list-defined references that is no longer a problem. If we are going to puish for defining references at the end anyway, may I suggest an even shorter syntax in the body text:

• {{ref|Smith2006}}

which would be the same as <ref name="Smith2006" />. This would make article text very readable once again. {{ref}} may have to be replaced with whatever template name we can aquire for this. --Apoc2400 (talk) 20:04, 17 September 2009 (UTC)[reply]

I think list-defined refs will make the body more readable for the casual editor and shorter syntax is always nice if it's understandable. I don't want to jump the gun on implementation, but may I also suggest a script to convert an article's refs into list-defined refs. I can see it becoming very useful if list-defined become the preferred method to cite. —Ost (talk) 20:11, 17 September 2009 (UTC)[reply]

Wow. Apparently I need some education as well. What is the preferred way to do citations? Is Help:Footnotes up-to-date? I'm curious if I'm doing it correctly. I took a bit of a hiatus from editing and just now started again and learned about the group feature yesterday.↔NMajdan•talk 20:05, 17 September 2009 (UTC)[reply]

We are discussing new ways. The method described in Help:Footnotes is the current standard. --Apoc2400 (talk) 20:11, 17 September 2009 (UTC)[reply]

What is would really want is <<Smith2006>>. I think references are important enough to deserve their own wiki syntax. That needs code changes of course. --Apoc2400 (talk) 20:21, 17 September 2009 (UTC)[reply]

I think we need a more centralized discussion page for improvements to the footnotes system with links to the myriad of previous discussions. Much of this seems familiar, and indeed the recent change is due to a series of discussions that I finger at the moment. ---— Gadget850 (Ed) ^talk 20:32, 17 September 2009 (UTC)[reply]

Yes, isn't the usability project working on this too? Perhaps the new format we just got came from there. --Apoc2400 (talk) 20:35, 17 September 2009 (UTC)[reply]

No, I implemented this one. Dragons flight (talk) 21:59, 17 September 2009 (UTC)[reply]

Geez... OK, hang on, let's slow down a bit. The "list-type references" came from a proposal originally made here, if I remember correctly. There have been several proposals to do similar things I'm sure, but someone finally motivated a developer to add in the list-type reference code. Anyway, references already have their own code, which is defined by the cite.php extension, and is (essentially) what we're talking about here. I don't think that creating {{ref2}}, {{Citation2}}, and the like, would be helpful in the long run because it would simply complicate matters even more (we would then be adding a third method rather then simplifying/standardizing on one method). As for a more centralized discusison, I can't imagine a more central place to discuss this. WP:FOOTNOTE is certainly not more central then the Village pump (although, we should move this to Wikipedia:Village Pump (proposals) if we're actually going to make this a change proposal). We could easily add an RFC to this and/or listing it on {{cent}}. It's probably a bit early for that though, since we're not even sure what the proposal is.
— V = I * R (talk to Ω) 20:50, 17 September 2009 (UTC)[reply]

Actually, I meant we need a list of previous discussions— there have been so many that there are a lot of repeated ideas.

The simplest way to do this is to change {{citation/core}} add a parameter, let's call it |refname= that if defined, wraps the citation in <ref name=refname></ref>. Thus it is backward compatible as it only invokes the new feature if the parameter is defined. We could then create a template named redef for the inline cite. Frankly, I don't see any need to update {{ref}}. ---— Gadget850 (Ed) ^talk 02:16, 18 September 2009 (UTC)[reply]

A potential issue with the proposals above to hide the <ref> within a template is that it will make it much more difficult for syntax highlighters and other tools that look at the page's wikitext to determine what is a reference and what is not. Instead of just searching for <ref> and {{#tag:ref}}, they'll also have to keep track of every random template people do this with. Anomie⚔ 13:26, 18 September 2009 (UTC)[reply]

I have been coming towards that point of view as well. Checklinks and refTools don't work with list-defined references— I have alerted their owners and hopefully we can get some updates for these valuable tools. I don't see how any tool could pull a reference if it is buried in a template. I did a proof of concept to show that it works, but I think it is more trouble than it is worth. I did a fix for another editor who was updating an article to LDR and found the problem by searching for the <ref> tag. ---— Gadget850 (Ed) ^talk 13:48, 18 September 2009 (UTC)[reply]

I think the XML-like syntax is much nicer, and much more readable, and much easier to parse, than template syntax. Why do we want to use the horrific template syntax instead?

Advantages of XML syntax:

• Matched opening and closing tags make it easier to see where a particular block ends and begins.
• Familiar to people who are used to programming with the web.
• Only slightly less brief.
• More natural method of specifying arguments.
• Fewer delimiter collisions (no need for ugly stuff like {{!}} and 1=).

Disadvantages:

• Inconsistent with templates.

— Werdna • talk 14:20, 18 September 2009 (UTC)[reply]

For those of us who are familiar with HTML/XML you're absolutely correct. I've talked to several newer editors who aren't, however, and their always slightly confused by it at first. for those editors, the "ugly stuff" seems preferable, simply for consistency/ease of use.

Personally, I'm basically fine with things the way they are. It would be nice to just use {{Cite web|group=Note|name=Example|url=http;//www.foo.com|title=example}} instead of <ref group=Note name=example>{{Cite web|url=http;//www.foo.com|title=example}}</ref>, is all. It looks a lot neater in article source, as well.
— V = I * R (talk to Ω) 15:02, 18 September 2009 (UTC)[reply]

This is a wiki. It should use wikicode. Yes XML is "cool" you can show off your fast typing skills or auto-complete software - but wiki is supposed to be quick. And XML can be horrendously long, because you always end up with another level of enclosing tags. I expect one day to see <character>a</character> nested in <word> tags ...

Loose weight and simplicate. I believe David Chapman of Lotus? Rich Farmbrough, 22:19, 21 September 2009 (UTC).[reply]

RE: "Stuffing this all into templates." If this is a direction you think should be pursued, {{sfn}} already implements some of the functionality you are wishing for. ---- CharlesGillingham (talk) 03:45, 22 September 2009 (UTC)[reply]

Using a template {{ref}} instead of <ref> for a ref with opening and closing tags saves all of 5 characters. For something like <ref name='Foo'/>, template syntax - {{ref|name=Foo}} - saves a whole 1 character. There's simplifying, and then there's excessive optimization, and change for the sake of change. Mr.Z-man 04:11, 22 September 2009 (UTC)[reply]

Could someone please read this thread. I have some tools missing on the history page. I've asked a sys-op to delete all of my custom JS pages. But the tools still aren't there. When I log out they are there on the edit history. Please read this thread. ~~ Dr Dec (Talk) ~~ 20:14, 17 September 2009 (UTC)[reply]

I'm having an epiphany. I'm betting you have selected british english as your en.wp language option. That hides many of the local system message customizations. —TheDJ (talk • contribs) 23:00, 17 September 2009 (UTC)[reply]

You're quite right! I've changed my settings to general English and the links are there. What are the chances of making those tools available regardless of the language setting? ~~ Dr Dec (Talk) ~~ 16:50, 19 September 2009 (UTC)[reply]

Is it possible to add a link to User Contributions in the toolbox on a user's subpage? Deserted Cities (talk) 21:03, 18 September 2009 (UTC)[reply]

Yes, this can be done with Javascript. Algebraist 21:11, 18 September 2009 (UTC)[reply]

That's a pretty unhelpful response; I assume that if the person knew how to write JavaScript code, then they'd already be aware that it could be used to do this. I had written some code before to do this, but it adds a tab at the top of every page rather than in the toolbox; it does appear only on user pages, though, regardless if it's a subpage or not. Simply copy the following code to Special:MyPage/monobook.js:

addOnloadHook(function() 
{
	if (!(wgCanonicalNamespace == 'Special'))
	{
		var username = wgTitle.split('/')[0];
 
		// "User:" tabs
  	if (wgCanonicalNamespace == 'User' || wgCanonicalNamespace == 'User_talk')
		{
			addPortletLink('p-cactions', wgServer + '/wiki/Special:Contributions/' + username, 'contribs', 'ca-contrib', 'User contributions');
  	}
	}
});

Gary King (talk) 06:36, 19 September 2009 (UTC)[reply]

Since the software changes, mediawiki:noarticletextanon (which actually transcludes mediawiki:noarticletext) is no longer displayed to anons when seeing a non-existent page, but instead it is mediawiki:Noarticletext-nopermission, a new mediawiki page (see google for info). I created it to transclude noarticletext to avoid the default, but it could be modified to replace "create this article ..." with elements from mediawiki:Nocreatetext, "log in..." and "submit the content ...". Cenarium (talk) 02:18, 19 September 2009 (UTC)[reply]

All of a sudden I'm getting colored backgrounds everywhere. I want my white backgrounds back! The new background colors make things hard to read. Elphion (talk) 08:12, 19 September 2009 (UTC)[reply]

Monobook did not change, and I see that User:Elphion/monobook.css is empty. Did you perhaps click "Try Beta" or did you change the skin to another option? hmwith☮ 14:35, 19 September 2009 (UTC)[reply]

I did not change the skin. I did click on "Try Beta", but did not click the implementation button there. (Color changes weren't advertised in the "What's improved" blurb there anyway.) I can't swear the colors weren't there before (and I'm not talking dark colors, just dark enough to make the text look muddy), but having noticed them I am now constantly aware of them. I now see them in IE as well (which I don't usually use and never sign in with). How hard would it be to modify the CSS to make the basic tab background white for content, even beyond the main space? I tried * {background-color:white} but of course that wiped out too much (but conversely did not hit elements with more complex combinations of ids and styles). Elphion (talk) 15:18, 19 September 2009 (UTC)[reply]

The local stylesheets on en.wikipedia.org have been putting lightly colored backgrounds on non-main namespaces in Monobook for several years. They are pretty light, though, so you may have not noticed them before -- some LCD monitors for instance won't even show the difference between the light blue and white if you have the brightness and contrast set relatively high.

You'll see the specs for this at the top of MediaWiki:Monobook.css in the "light blue section". You can copy-and-paste those bits back to your personal monobook.css and override them back to white if you like. --brion (talk) 18:49, 21 September 2009 (UTC)[reply]

When looking in users' contributions, the contributions to deleted articles are not shown. This needs to be fixed ASAP. File a bugzilla report or somthing.174.3.110.93 (talk) 08:17, 19 September 2009 (UTC)[reply]

How about being more polite?

And deleted-contribs are only visible to administrators, for privacy and legal reasons. Also, if everyone could see them, the articles wouldn't really be "deleted" – would they? ╟─TreasuryTag►prorogation─╢ 08:43, 19 September 2009 (UTC)[reply]

It would be helpful though to be able to see that an editor made an edit, even if you can't (for good reasons) see the edit itself.Nigel Ish (talk) 08:57, 19 September 2009 (UTC)[reply]

Firstly, I don't think that the MediaWiki software makes that possible (though some external edit-counters do). Secondly, I'm not sure it is that helpful. And thirdly, often the titles of pages, and edit-summaries, contain sensitive/copyrighted information. ╟─TreasuryTag►sheriff─╢ 08:58, 19 September 2009 (UTC)[reply]

You can see oversighted edits in the edit history, though you can't click on them. The same thing could be done with contributions to deleted articles, right? 99.166.95.142 (talk) 16:38, 21 September 2009 (UTC)[reply]

See mediazilla:12667 "User should be able to see the list of his deleted contributions". It was recognized as useful thing, but not useful enough to actually implement it. — AlexSm 20:42, 21 September 2009 (UTC)[reply]

< div style="font-family:Calibri,sans-serif;">

< /div>

I have put these two codes on top and bottom of my userpage to automatically change the font of the whole userpage to Calibri but since it is too small and hard to read, I tried to make it bigger by adding this part to the code,

font-size: 12pt

but unfortunately didn't work. Can someone help me how to fix this?

Also I tried to place two images vertically in my user infobox (two images don't have the same size but I tried to equalize them) but I didn't know how. Can someone help me with this too? Thanks. JuventusGamer (talk) 14:57, 19 September 2009 (UTC)[reply]

Note: my user infobox (shown below) has the same basic code as others.

Village pump (technical)

— Wikipedian ♂ —
Diego, my current favorite bianconeri (left), Alessandro Del Piero, my all time favorite bianconeri (right)
Name	Alex
Born	November 29, 1989
Country	[[|]]
Height	6 ft 2 in
Weight	180 lbs
Blood type	O+
Sexuality	Straight
Education and employment
Occupation	Student, footballer
Hobbies, favourites and beliefs
Religion	Atheism
Politics	Light Greens Environmentalism
Interests
Video games *PlayStation 3

Link color override

Apparently the MW parser considers the <font> tag special, because when a <font> tag directly surrounds an <a> tag they will be turned inside-out so that it changes the color of the link-text. However this is not done for any other presentational tags, only the <font> tag (deprecated since HTML 4.01).

You can try it for various tags and attributes:

wiki-text	rendered html	appearance
<font color="orange">[[Foobar]]</font>	<a href="/wiki/Foobar" title="Foobar"><font color="orange">Foobar</font></a>	Foobar
<span color="orange">[[Foobar]]</span>	<span><a href="/wiki/Foobar" title="Foobar">Foobar</a></span>	Foobar
<font style="color:orange;">[[Foobar]]</font>	<a href="/wiki/Foobar" title="Foobar"><font style="color: orange;">Foobar</font></a>	Foobar
<span style="color:orange;">[[Foobar]]</span>	<span style="color: orange;"><a href="/wiki/Foobar" title="Foobar">Foobar</a></span>	Foobar
[[Foobar|<font style="color:orange;">Foobar</font>]]	<a href="/wiki/Foobar" title="Foobar"><font style="color: orange;">Foobar</font></a>	Foobar
[[Foobar|<span style="color:orange;">Foobar</span>]]	<a href="/wiki/Foobar" title="Foobar"><span style="color: orange;">Foobar</span></a>	Foobar

However since the link itself, the <a> element, is still blue by default, most browsers will still give the orange link text a blue underline (which looks really ugly).

Obviously the clean way to change the link color would be to add attributes directly to <a> tag, something like:

<a style="color:orange;" href="/wiki/Foobar" title="Foobar">Foobar</a>

However no combination of wiki-text will produce this result. — CharlotteWebb 13:10, 19 September 2009 (UTC)[reply]

FireFox is showing orange links for all but samples 2 and 4. Wonder if it is the parser or HTMLTidy? ---— Gadget850 (Ed) ^talk 13:28, 19 September 2009 (UTC)[reply]

It is Tidy. Without tidy you get the <font> on the outside. You can see a similar affect with <span><pre></pre></span> -> <pre><span></span></pre>. --Splarka (rant) 07:18, 20 September 2009 (UTC)[reply]

It is because the <span> tag outside the <a> tag is not sucked into it the way the <font> tag was. Why these should be treated differently is beyond me. Notice on line 2 the color information is completely gone. I guess the parser does sometimes remove deprecated attributes but not deprecated tags. — CharlotteWebb 13:45, 19 September 2009 (UTC)[reply]

The <span> tag doesn't have attribute color (see HTML specification). So it isn't deprecated, it's invalid. Svick (talk) 13:57, 19 September 2009 (UTC)[reply]

But if it did exist, it would be deprecated in favor of style="color:orange;". That's beside the point however as this doesn't work either for changing the color of a link, unless we put it inside the link (which needlessly complicates the bracket notation and still leaves a blue underline, see line six). — CharlotteWebb 14:03, 19 September 2009 (UTC)[reply]

Sample 2 doesn't work for the reason pointed out above: color is not a valid attribute of <span>. Sample 4 doesn't work because the style of <a> overrides that of the enclosing <span>. This is expected HTML behavior, and it's why the parser handles <font> as a special case to generate what the user probably intended: overriding the color style of the <a> tag. This was obviously added to the parser ages ago, before <span> became the accepted way of changing color; and a good case could be made for adding special handling for the <span> enclosing <a> tags. Elphion (talk) 14:44, 19 September 2009 (UTC)[reply]

Could a "good case" be made for adding some direct way to change the attributes of the <a> tag rather than needing to add an extra layer (the hierarchical order of which the parser/tidy functions may or may not quietly invert)? — CharlotteWebb 15:11, 19 September 2009 (UTC)[reply]

Really, a better solution would be to not use custom styling on links at all. Unfortunately navbox has those damn style parameters... — RockMFR 14:51, 19 September 2009 (UTC)[reply]

MiszaBot II is down. No bot archiving at ANI for two days

MiszaBot II has not been running for two days due to a problem with duplicated sections at ANI, in turn caused by Wednesday's update to MediaWiki. Nothing has been bot-archived since 14:35 UTC on 17 September 2009. As a last resort, somebody might consider switching to ClueBot for ANI, at least on a temporary basis. Recent contributions show that ClueBot III was still archiving correctly as lately as 13:39 on 19 September, so it must not have been affected by the MediaWiki update. EdJohnston (talk) 15:14, 19 September 2009 (UTC)[reply]

I suspect the pywikipedia core that powers my bots was somehow affected. But I don't have the time to debug it. Something about XML encoding when trying to save a page (the original, not the archive):

Traceback (most recent call last):
  File "/home/misza13/pywikipedia/archivebot.py", line 606, in main
    Archiver.run()
  File "/home/misza13/pywikipedia/archivebot.py", line 519, in run
    self.archives[a].update(comment)
  File "/home/misza13/pywikipedia/archivebot.py", line 391, in update
    self.Page.put(newtext, minorEdit=True, comment=summary)
  File "/home/misza13/pywikipedia/wikipedia.py", line 1434, in put
    newPage, self.site().getToken(sysop = sysop), sysop = sysop, botflag=botflag, maxTries=maxTries)
  File "/home/misza13/pywikipedia/wikipedia.py", line 1466, in _putPage
    newPage, token, newToken, sysop, captcha, botflag, maxTries)
  File "/home/misza13/pywikipedia/wikipedia.py", line 1813, in _putPageOld
    if self.site().has_mediawiki_message("spamprotectiontitle")\
  File "/home/misza13/pywikipedia/wikipedia.py", line 5449, in has_mediawiki_message
    v = self.mediawiki_message(key)
  File "/home/misza13/pywikipedia/wikipedia.py", line 5417, in mediawiki_message
    tree = XML(decode)
  File "<string>", line 85, in XML
SyntaxError: undefined entity &nbsp;: line 663, column 145

is the typical stack trace. Puzzles me why nbsp would be recognized but until this is resolved, I have stopped my archiving bots. Миша13 16:00, 19 September 2009 (UTC)[reply]

See this thread at pywikipedia-l, which reports 'All bots are broken.' One of the commenters in that thread says:

Fixed in r7267 by alexsh but API must be enabled in user_config.py with use_api = True since xml and php output is no longer supported.

I assume that individual bot operators who use pywikipedia would have to do something to make use of this fix. EdJohnston (talk) 17:06, 19 September 2009 (UTC)[reply]

Ok, I have updated the core, configurations and the bots are coming back up. Thanks to everyone involved. Миша13 18:13, 19 September 2009 (UTC)[reply]

Sinebot down?

I don't see any updates since 16 September. Related to new software?--SPhilbrickT 21:28, 19 September 2009 (UTC)[reply]

Oops, sorry, I even did a search for sinebot, but just now noticed the message that all bots are down--SPhilbrickT 21:37, 19 September 2009 (UTC)[reply]

Yeah, I have no idea what's going on. Someone must have changed something with the API or something. So, until I get a chance to figure it out, it stays broken. I don't have time to play pin-the-tail-on-the-bug. --slakr^\ talk / 20:44, 21 September 2009 (UTC)[reply]

Turning Autoconfirmed into an explicit userright

Please see and comment at Wikipedia:Village pump (proposals)#Turning Autoconfirmed into an explicit userright. Thanks, Cenarium (talk) 01:54, 20 September 2009 (UTC)[reply]

External links no longer showing URL

Probably the same updates to MediaWiki that caused the alt/title tag problem in images, is also responsible for external link no longer showing the URL in hints; in IE, they do not even show up in the status bar anymore. This is quite serious, as I'd like to know where I'm going before I click on an external link. — Edokter • Talk • 16:57, 20 September 2009 (UTC)[reply]

It works fine for me in the Monobook skin. The code looks fine, too; it hasn't even changed. Gary King (talk) 20:20, 20 September 2009 (UTC)[reply]

I can confirm that the external link is no longer duplicated in the title attribute (the tooltip) in all skins. This is bad for full screened users. — Dispenser 01:14, 21 September 2009 (UTC)[reply]

I see that the title attribute is missing, but both IE 8.0 and Firefox 3.5 still show the destination in the status bar. Which browser are you concerned about? Dragons flight (talk) 01:49, 21 September 2009 (UTC)[reply]

IE6. — Edokter • Talk • 00:22, 23 September 2009 (UTC)[reply]

References on userpage

An editor suggested I post my help request here: To whomever can help, I would like the Diderot and Jimmy Wales quotations on my userpage to have their references show up in a reference section at the bottom of my page, but I am for some reason not see them there. Could some please fix that? Thanks! Sincerely, --A Nobody^{My talk} 17:37, 20 September 2009 (UTC)[reply]

The problem was in thank you from Benjiboi about the {{rescue}} tag. More specifically in the twice colapsed table "Articles tagged for deletion and rescue". I removed the table and it's ok now. I hope you don't mind I edited your userpage. Svick (talk) 18:07, 20 September 2009 (UTC)[reply]

No, that is fine and appreciated!  :) Sincerely, --A Nobody^{My talk} 18:13, 20 September 2009 (UTC)[reply]

It seems that after the <categorytree> tag, but only with showcount=on, <references /> doesn't work properly. I created Template:Bug. Svick (talk) 18:30, 20 September 2009 (UTC)[reply]

Cool and thanks for that! Sincerely, --A Nobody^{My talk} 19:07, 20 September 2009 (UTC)[reply]

No problem. I'm glad I could help. Svick (talk) 19:15, 20 September 2009 (UTC)[reply]

References not showing

Can somebody technical have a look at User:A_Nobody page, there are two references at the top(Denis Diderot and Jimmy Wales quotes), but either are shown in the reference list. SunCreator (talk) 17:39, 20 September 2009 (UTC)[reply]

See above! SunCreator (talk) 17:40, 20 September 2009 (UTC)[reply]

Thanks for your time and help! :) Sincerely, --A Nobody^{My talk} 17:43, 20 September 2009 (UTC)[reply]

Policy on checking other editors wikipedia emails

I know it is possible for an editor to check when editors email each other using wikipedia, but where is the policy on this? Ikip (talk) 19:10, 20 September 2009 (UTC)[reply]

I'm not aware of a policy that directly addresses it. The message when you send one lays the important part out: A private log of this action will be retained for the purpose of preventing abuse, and can be viewed by certain privileged users. This log does not identify the recipient, title, or contents of the e-mail. In cases of serious abuse, Wikimedia server administrators can verify the recipient account." By implication, you would have to demonstrate to a checkuser that there was reason to suspect abuse using the e-mail function, and he, in turn, would then have to convince a Wikimedia server operator to reveal the names of the recipients. If the question underlying this is "can editors organizing an RFC/U communicate with each other using the e-mail function?" then the answer is that I'm not aware of any policy or guideline prohibiting that, and believe it to be normal. The policy pump is probably a better place to ask.—Kww(talk) 19:22, 20 September 2009 (UTC)[reply]

thank you kww. Ikip (talk) 19:43, 20 September 2009 (UTC)[reply]

As far as I can tell, it's not possible to tell after the fact the recipient / subject / contents of an e-mail sent through that interface, even for people with shell access to the servers. — Werdna • talk 12:15, 21 September 2009 (UTC)[reply]

New supages

Resolved

 – Config was changed in June

Did more subpages get enabled in this last update, or did I miss it before? Specifically Help and Help talk. There was a request to enable subpages in several namespaces back in April. I didn't see it in the release notes. ---— Gadget850 (Ed) ^talk 19:45, 20 September 2009 (UTC)[reply]

Enabling / disabling subpages is handled by shell users in the local settings, and as such would be uncorrelated with the main software updates. Whether anything has changed, I don't know. Dragons flight (talk) 19:50, 20 September 2009 (UTC)[reply]

Technically it was enable, but there was a MediaWiki bug, see the discussion. Anyway, they are enabled; was just wondering if it was in this update. ---— Gadget850 (Ed) ^talk 00:51, 21 September 2009 (UTC)[reply]

Bugzilla:18437#c1. So what happened was, the customizations on WMF for namespaces with subpages define the entire array, and en.wp's probably has been there since before that namespace existed, so Help_talk was not given subpages since it was overwrit. So on June 1st it seems Rob simply disabled the en.wp line so that it used the defaults (which include both Help_talk and Help). --Splarka (rant) 07:33, 21 September 2009 (UTC)[reply]

floating table of contents

In my User:Lemmiwinks2/monobook.css I have:

1. toc,{
   

float: left;

but the article Four_horsemen_of_the_apocalypse has a table at that position and the table of contents overlaps it. I have no idea what to add to prevent this from happening. Lemmiwinks2 (talk) 20:12, 20 September 2009 (UTC)[reply]

You can add clear:both; but that might cause the toc to move down considerably on many pages. —TheDJ (talk • contribs) 12:29, 21 September 2009 (UTC)[reply]

Thank you. Lemmiwinks2 (talk) 18:59, 21 September 2009 (UTC)[reply]

Blank sequence of pages in an article's history

For some reason the history of Kibbutz between the following points is blank.

from: 11:18, 8 January 2005 to: 21:27, 16 May 2005.

this includes the FA markers in {{ArticleHistory}}. Does anyone else notice this? Does anyone know why the pages are blank? Best, DVD 03:48, 21 September 2009 (UTC)[reply]

I've noticed this sort of thing before, within a similar time frame, on different articles. The obvious speculation is that some sort of database corruption occurred at some point, but I don't know the definitive answer. The actual histories are still there though, so I don't think there's any reason to panic. It's an unfortunate problem, but it shouldn't be Earth shattering.
— V = I * R (talk to Ω) 04:19, 21 September 2009 (UTC)[reply]

This has already been brought up at Wikipedia:Village pump (technical)/Archive 64#Old versions of articles missing. I've just filed bug 20757 to try to get the problem fixed. Graham87 14:33, 21 September 2009 (UTC)[reply]

Has it been fixed already? The old revisions appear (on my screen) not to be blank. — CharlotteWebb 14:40, 21 September 2009 (UTC)[reply]

Those are the bookend revisions and do show; the ones between seem to be the problem. I've assigned the bug to Tim to take a peek at, since we've seem similar things before -- some of our data migration scripts have occasionally gotten confused on old storage methods and mismarked the compression type so they don't load properly. --brion (talk) 18:38, 21 September 2009 (UTC)[reply]

Wrong interwiki link for WP:Sandbox

Resolved

 – Will get an experienced sysop to correct it. decltype (talk) 12:26, 21 September 2009 (UTC)[reply]

The sandbox' iw link to the nn.wikipedia is incorrect (should be "Wikipedia:Sandkasse", not "Wikipedia:Sankasse"). Is there any way to correct this? Thanks, decltype (talk) 10:57, 21 September 2009 (UTC)[reply]

Yup, interwiki links are just added like categories, so the current interwiki link looks like [[nn:Wikipedia:Sankasse]], just change it to [[nn:Wikipedia:Sandkasse]]. Although you should note that the current interwiki links for the the sandbox are in the heading template: Template:Please leave this line alone (sandbox heading), and it is fully protected, which shouldn't be aproblem for you :) - Kingpin¹³ (talk) 11:04, 21 September 2009 (UTC)[reply]

Ahh, but of course! I didn't realize it was in the template, I thought perhaps it was a special case. Thanks! decltype (talk) 12:26, 21 September 2009 (UTC)[reply]

I would argue that the parts containing the interwiki links should not be fully protected. Under normal circumstances, bots would update all interwikis as needed, and generally make fewer spelling errors. It is impractical for us to require admin intervention every time the editors of some new project decide to add a sandbox page.

{{pro-tip}} if we like this idea but are still worried about high-visibility vandalism, we could do something like this:

<div style="display:none;">
{{unprotected sub-template containing interwiki links for the sandbox}}
</div>

The interwiki stuff would still be visible as these links (as with categories) render outside the content area, but plain text like "JOHN SUCKS" would remain hidden. — CharlotteWebb 14:37, 21 September 2009 (UTC)[reply]

Until someone vandalized it with </div>JOHN SUCKS!<div>. Perhaps you mean high-visibility testing. --Splarka (rant) 04:44, 22 September 2009 (UTC)[reply]

An odd disparity

Category:Articles to be merged from October 2007 lists only one article, yet Wikipedia:Proposed mergers/Log/October 2007, which is part of a series of backlogs bot-generated from Category:Merge by month, lists many more. What's the deal with that? @harej 22:13, 21 September 2009 (UTC)[reply]

Probably due to the Help:Job queue. OrangeDog (talk • edits) 22:20, 21 September 2009 (UTC)[reply]

You have a good point. But how recently-tagged are articles which have been labeled with merge tags since 2007? @harej 22:23, 21 September 2009 (UTC)[reply]

I am here to post about the job queue! But is Animal language in the queue? seems unlikely It is still odd though, the upgrade seems to have broken quite a lot. Wikia seemrd to do some upgrades that broke stuff too. ~~

Incidentally, it just got added to the category. I think there is a backlog of stuff that will be added now that I fixed a quirk in {{merge}}. @harej 22:28, 21 September 2009 (UTC)[reply]

Yes and no. I null edited that page. But the {{Merge}} thing took them out and now they will have to queue to get back in. Thanks for fixing that. Rich Farmbrough, 22:29, 21 September 2009 (UTC).[reply]

To clarify, are you being sarcastic? (It's okay if you are). @harej 23:53, 21 September 2009 (UTC)[reply]

No I thought you fixed my bug. Rich Farmbrough, 10:43, 22 September 2009 (UTC).[reply]

Ah, that's right. In other words, you're saying your change to the template kicked the articles out of the category. You're welcome! @harej 11:20, 22 September 2009 (UTC)[reply]

Jobqueue

Is it broken? Stuff seems to never update its cats till it's edited. Rich Farmbrough, 22:25, 21 September 2009 (UTC).[reply]

Special:Statistics seems to show a massive backlog for the job queue; I've been checking it on and of all day, and I haven't seen it below 20,000. I'm guessing that it has everything in the backlog, but just hasn't gotten to it yet. –Drilnoth (T • C • L) 23:11, 21 September 2009 (UTC)[reply]

well it used to go over a million without any bother.It was just a few hours then. Oh well. we will see tomorrow. Rich Farmbrough, 02:21, 22 September 2009 (UTC).[reply]

Image move re-enabled

Resolved

 – For already-affected files, edit the redirect (not null-edit) or wait 24 hrs for cache to expire

For those who had not yet noted. As of today, it is again possible for sysops/administrators to move files and their corresponding pages, without having to reupload the images. Hopefully this time no bugs will pop up, but if you see any weird or unexpected behavior, please report it. —TheDJ (talk • contribs) 23:02, 21 September 2009 (UTC)[reply]

Awesome! –Drilnoth (T • C • L) 23:10, 21 September 2009 (UTC)[reply]

It didn't work. :( I tried moving File:00000362.jpg to File:Flowers of Shanghai film cover.jpg... the image was moved OK, but the redirect didn't work and I had to manually change the on-page link to the image. –Drilnoth (T • C • L) 23:17, 21 September 2009 (UTC)[reply]

Brion is looking into it. —TheDJ (talk • contribs) 23:52, 21 September 2009 (UTC)[reply]

It's a bug where the redirect information gets cached incorrectly immediately after the rename. As a temporary workaround, you can edit the redirect page -- not a null edit, but add some text afterwards. This'll rebuild the image redirect cache entry for the page and the redirected image will start working again.

Michael Dale and I are taking a peek to see if we can figure out how the bad entries are getting in... it seems consistent here but isn't happening on our offline test environments yet. --brion (talk) 00:26, 22 September 2009 (UTC)[reply]

Ok, I've installed a temporary quick fix to re-clear the bad entry from the cache at the end of Special:Movepage. The cache was being polluted during the display of the post-move success text, which on en.wikipedia is pulling in a direct link to the original title... which then reads the redirect state from slave servers which have not been updated with the rename yet. Any remaining bad cache entries will expire within 24 hours (pages using them can then be re-rendered successfully), or you can do the edit-the-redirect trick to clear them sooner. --brion (talk) 00:48, 22 September 2009 (UTC)[reply]

Great. Do we have a guideline on dealing with the resulting redirects? Cause that make it a pain to figure where the image is used and if the backlinks are valid. ---— Gadget850 (Ed) ^talk 01:09, 22 September 2009 (UTC)[reply]

P.S. For those who want to work on this. See Category:Image_renaming and I there is this userscript by Splarka, that makes it easier to do the work, because it removes the {{rename media}} template for you. —TheDJ (talk • contribs) 14:50, 22 September 2009 (UTC)[reply]

Interesting effect

This is a case of a Commons image with a local en.wp page. The local page contains a category, but this could also be a Featured image tag or something of course. After the file on Commons is moved, the following problems arise

• bugzilla:20770 When going to the page description using the original link File:01123.jpg, there is no "redirected from" notice.
• Due to the lack of the redirected from notice, the en.wp page is unreachable. You have to use a handcrafted url [1]
• The en.wp page still adds the image to the category Category:Shinto_shrines_in_Taiwan, but the description page does not list this category.
• bugzilla:18017 The description page misses the image backlinks, even though the image is on use in Taiwan_Grand_Shrine and List_of_Shinto_shrines_in_Taiwan.
• The en.wp page with the category or the featured image tag is not moved, nor rendered.

These are important side effects that we will have to deal with. Some can be fixed, but others probably will require botwork to cleanup. —TheDJ (talk • contribs) 15:28, 22 September 2009 (UTC)[reply]

All these issues are bugs in the File redirects code apparently. They also exist independent of wether or not there the local page is still there. The other issues that is left, is that Commons moves will cause featured article and DYK banners to go broken. We might want to have a bot that checks for this sort of problem. —TheDJ (talk • contribs) 15:50, 22 September 2009 (UTC)[reply]

Help Generating List

Hello. I was trying to generate a list of all the edits that preceded VoaBOTII's Edits. I can't find any easy way to do this. Can someone help me? Tim1357 (talk) 00:08, 22 September 2009 (UTC)[reply]

I don't know of an easy way to do it on the site, but it can be done with a query on the Toolserver database. tools:~alexz/voabot.htm is the edits immediately before VoABot's last 500 edits, excluding user talk edits. Let me know if you want a longer list, more information, different format, etc. Mr.Z-man 02:34, 22 September 2009 (UTC)[reply]

Thanks! I was going to offer this list to User:Crispy1989 for use in training his new Cluebot (which needs a LOT of examples of vandalism). Im going to parse the list for edits that User:VoaBOTII made against vandalism (it doesn't just do vandalism, therefore i need to remove the non-vandalism reverts). I think 500 is good to start off. But if it turns out that User:Crispy1989 wants them, then I might have to ask you to give me more. Thanks for your help! Tim1357 (talk) 03:04, 22 September 2009 (UTC)[reply]

Repetitions in edit screen

As many probably noticed, the current version of edit screen repeats a part of the Terms of Use: the notification about editing, usage and redistribution is mentioned twice in small letters and under the bold hat below, as well as the link to the Terms. I think this should be fixed in the nearest future by having just a single relevant grasp from TuU. The present tautology of notifications seems quite onerous, if not annoying. Brand[t] 00:33, 22 September 2009 (UTC)[reply]

When will flagged revisions be turned on?

I already looked on the project page, there's nothing there.— Preceding unsigned comment added by 99.241.211.159 (talk) 01:37, 22 September 2009 (UTC)[reply]

According to WP:FLPPR, the trial should start in a few weeks. Svick (talk) 01:56, 22 September 2009 (UTC)[reply]

Considering the advancement of the testing [2], it will probably take much longer. Cenarium (talk) 16:02, 22 September 2009 (UTC)[reply]

If we can get a per-page opt-in going it'll be much sooner rather than later. --brion (talk) 16:57, 22 September 2009 (UTC)[reply]

Cologne Blue User Script failure

Cologneblue.js processing of user scripts has recently broken for me in Firefox 3.5. Specifically, addOnloadHook(func) no longer works in a user script for Cologne Blue, though it continues to work for Monobook. The hook function is never called.

The failure point traces to the onloadFuncts array, which contains entries loaded from addOnloadHook(), and has as its first function entry the function liveClock(). Unfortunately, liveClock() errors out under Cologne Blue for my machine and always has, due to liveClock.node being a null value. This liveClock() failure didn't used to be a problem. Now it is, since it stops further JavaScript processing, including my script's hook function (which here lives at the tenth subscript in the onloadFuncts array).

I can hack around the problem in a user script by forcing a valid function where the liveClock() hook lived by adding the line:

onloadFuncts[0] = function() { return; }

to the user script, but this is a crude and rude hack. Any idea of a better workaround or a fix? -- Michael Devore (talk) 04:27, 22 September 2009 (UTC)[reply]

Remove whatever userscript is adding the liveClock() function? I don't think that's part of any of the global scripts. Mr.Z-man 04:45, 22 September 2009 (UTC)[reply]

Hmm, I only use one script so it's not coming from me. And it's loaded at [0], so it's loaded earliest. -- Michael Devore (talk) 04:47, 22 September 2009 (UTC)[reply]

(Also, MonoBook has a live clock, while Cologne Blue does not, so I'm pretty sure it's WP functionality.) -- Michael Devore (talk) 05:00, 22 September 2009 (UTC)[reply]

There's a live clock in the gadgets section of your preferences. Is that the one you're talking about? Graham87 08:54, 22 September 2009 (UTC)[reply]

I have fixed the gadget to no longer generate errors, but it still doesn't work for the cologneblue skin (but there are many scripts that don't work in cologneblue). —TheDJ (talk • contribs) 09:55, 22 September 2009 (UTC)[reply]

Ahh, it's a gadget issue, I didn't think about that. I don't care if that particular gadget works when Cologne Blue skin is selected, but don't want the gadget breaking script processing if enabled for the user, since it's a universal setting separate from skin setting. Thanks. -- Michael Devore (talk) 18:08, 22 September 2009 (UTC)[reply]

Custom css

Any way to get extra links on, say, the navigation toolbar? In particular I'm wanting to put in one for RandomRedirect, but if there's a general way to do it for any link that would be nice. —thedarklordtrombonator 05:17, 22 September 2009 (UTC)[reply]

Use this: Wikipedia:Tools/Navigation shortcuts Gary King (talk) 05:47, 22 September 2009 (UTC)[reply]

Amazing. —thedarklordtrombonator 23:26, 22 September 2009 (UTC)[reply]

Detecting redirect pages

Is there a way to determine if a page is a redirect page from within a template? Is there a parser function for example?

{{#ifexists: . . .}} lets one check if a page exists (and, for example, avoid unnecessary red links), but when having templates link to existing pages I would pefere to avoid linking to a redirect page. I would rather link to the actual page.

Alternatively, is there a way of asking, for example, for the resolved redirect, that is, for example {{#resolve: 'name of page'}} returning the redirected-to page if the 'name of page' is a redirect page?

Peet Ern (talk) 08:23, 22 September 2009 (UTC)[reply]

Currently there is no way to do this. Ruslik_Zero 16:12, 22 September 2009 (UTC)[reply]

Thanks. Peet Ern (talk) 09:03, 23 September 2009 (UTC)[reply]

One big issue to keep in mind here would be WP:NOTBROKEN, which probably explains the lack of such a parser function. Of course, it depends on what links are being discussed, as links in navigational templates should show up as bold on the pages that they link to.
— V = I * R (talk to Ω) 17:41, 22 September 2009 (UTC)[reply]

WP:NOTBROKEN does not really apply because I have the choice of defining and picking the better link in each case. So if the context is not improved by the redirect it would bebtter for me to pick the non redirect. But thanks anyway. I had not come across this wikitip before. Peet Ern (talk) 09:03, 23 September 2009 (UTC)[reply]

Upload MIDI

I raised this at Commons, but only got one baffling response.

My question: "I'm trying to upload a MIDI file I made. In IE8 and FF 3.5 this ends with the message "This file contains HTML or script code that may be erroneously interpreted by a web browser." I have searched commons.wikimedia.org and en.wikipedia.org for that string and only found it regarding instances of SVG files. How can I find out what causes that message with a MIDI file, and how can I avoid it?"

Response: :It probably has html embedded in a comment. Platonides (talk) 22:33, 21 September 2009 (UTC)[reply]

My response: I've never heard of any such thing. A MIDI file is a binary file and content should not be interpreted, not as HTML or anything else, other than as MIDI instructions. There are some text elements in a MIDI file, like track names and composition title, but that's well within the MIDI specifications, and none of them contain anything resembling HTML. Previous MIDI files I uploaded contained those text elements, too. The file can currently be inspected at http://mbednarek.com/temp/maidensprayer.mid (13,635 byes, 3:05 minutes). For me, it opens and plays from there as expected in IE8 and FF 3.5.

I have also attempted to upload that file here at en.wikipedia.org, with the same result, i.e. the above error message. Where do I go from here? -- Michael Bednarek (talk) 14:07, 22 September 2009 (UTC)[reply]

Whenever a file is uploaded, a scan is done to try to guess if the file contains code that might be executed by web browsers. Some sort of test like this is necessary to prevent uploaded images from being used to attack people's computers. Your file is, unfortunately, coming up as a false positive under this scan. I looked briefly but I don't have time to find out exactly which part of the scan (in UploadBase.php) is being tripped. You should file a bug report at bugzilla.mediawiki.org, so that a developer can investigate the situation and fix the scan. — Carl (CBM · talk) 16:19, 22 September 2009 (UTC)[reply]

It is because it contains "<A" in the first 1024 bytes. At least I think so, changing it to "<B" let it upload fine (and corrupted it of course): testwiki:File:Maid.mid. --Splarka (rant) 18:53, 22 September 2009 (UTC)[reply]

Yes, I checked the code, and that will do it. — Carl (CBM · talk) 19:08, 22 September 2009 (UTC)[reply]

Thank you very much for that nice piece of detective work. BTW, the piece didn't get corrupted by your change, just slightly modified: you changed a "note off" event for an F5 note late in bar 2 to F♯5 (for which there was no previous "note on" event), so a F5 kept sounding until another "note off" event for that note occorred in bar 7; given the decay for a piano sound (and the flurry of notes anyway), that didn't matter much. One could also change the preceding value of 3C_x (<) to 3D_x (=) which would stretch the piece at that point by 1 MIDI tick.

Off to learn how to submit a bug report. -- Michael Bednarek (talk) 06:52, 23 September 2009 (UTC)[reply]

Eh, I did what now? It's all greek to me (music that is). --Splarka (rant) 07:56, 23 September 2009 (UTC)[reply]

Trying to insert content into BBC article

Moved to Wikipedia:Help desk

Or more specifically, to Wikipedia:Help desk#Trying to insert content into BBC article, which will eventually be archived at Wikipedia:Help desk/Archives/2009 September 22#Trying to insert content into BBC article. Graham87 06:18, 23 September 2009 (UTC)[reply]

Contributions text clash

At reduced window widths, the text "Javascript-enhanced contributions... " from MediaWiki:Gadget-contribsrange.js is getting mangled underneath MediaWiki:Sp-contributions-explain. Anyone know how to fix without destroying the world? OrangeDog (talk • edits) 05:26, 23 September 2009 (UTC)[reply]

Color of visited links

I have recently reinstalled Firefox 3.5.3 on my computer. Now the links within Wikipedia are changing color after I visit the linked page. I am using the "Classic" skin and in Firefox>Tools>Options>Content>Colors, I have checked "allow pages to choose their own color". Is there any setting within Wikipedia were are can turn this feature off? I would like websites in general to choose their own color, but would not like to have the links change color within Wikipedia. Is that feasable? Thanks a lot in advance! olivier (talk) 06:17, 23 September 2009 (UTC)[reply]

It doesn't look like the classic skin sets a color for a:link, just for a:visited. But you can simply set one for both to make them the same. Add something like a:link, a:visited {color: #0000EC;} to User:Olivier/standard.css. --Splarka (rant) 08:08, 23 September 2009 (UTC)[reply]

Wikipedia:Link colors. --MZMcBride (talk) 08:10, 23 September 2009 (UTC)[reply]

Those colors don't apply to the "Classic" skin. --Splarka (rant) 08:35, 23 September 2009 (UTC)[reply]

Thank you. Splarka's method is working fine with my "Classic skin". olivier (talk) 08:50, 23 September 2009 (UTC)[reply]