Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 1,185: Line 1,185:


Thank you in advance for any input. --[[User:Pixelface|Pixelface]] ([[User talk:Pixelface|talk]]) 03:03, 5 December 2007 (UTC)
Thank you in advance for any input. --[[User:Pixelface|Pixelface]] ([[User talk:Pixelface|talk]]) 03:03, 5 December 2007 (UTC)

# Everyone.
# No, but this would:
<source lang="css".spoiler {
display: block;
}</source>

~~~~

Revision as of 04:46, 5 December 2007

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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 because there is no guarantee developers will read this page. Problems with user scripts should not be reported here, but rather to their developers (unless the bug is exigent).

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.

A little help with javascript

What's a way to execute a function on page load? Thanks, — Bob • (talk) • 07:41, July 31, 2007 (UTC)

Nevermind, I googled it. — Bob • (talk) • 08:01, July 31, 2007 (UTC)

English spelling/dialect code

I think that we should have some new code in the next revision of MediaWiki that modifys English spellings based on your IP address. That would mask my all-time pet peeve about Wikipedia, and prevent these stupid spelling debates. C'mon, it would only be a few kilobytes! Canada-kawaii 15:01, 3 December 2007 (UTC)[reply]

I would think it's rather more complicated than that, there are many cases where the appropriate translation is only clear from the context: from my own area of interest, what the British call a 'straight' on a race track, Americans call a 'straightaway'. But obviously 'straight' does not translate to 'straightaway' in other contexts. How to you automatically make these decisions? In many ways I think life would have been easier if Wikipedia had just said 'All articles to be written in US English' and those of us based elsewhere would just have to live with it!. I am not however proposing to open another debate! 4u1e 13:28, 4 December 2007 (UTC)[reply]

Help with parser functions

Could someone please check out {{Infobox Martial artist}}? The test case that's being used right now does not pass any kickboxing-related parameters. The behavior I desire is that if parameters are passed, it will add up {{{kickboxingwins}}}, {{{kickboxinglosses}}}, {{{kickboxingdraws}}}, and {{{kickboxingncs}}}, and place them in the total line (already implemented). However, if neither of these four parameters are passed, the entire kickboxing section should not appear. If you can fix it for just this one section, I can implement in the other three myself. Thanks in advance! east.718 at 05:00, 10/24/2007

OK, never mind. I figured out that I can just use #switch like I did at {{MMArecordbox}}. east.718 at 05:31, 10/24/2007

Give ClueBot rollback?

I propose that we give ClueBot the rollback privilege. This not only is nicer on the servers and on ClueBot, but it is also faster, and it would all happen in one transaction so there is less of a chance for anything to go wrong. This would not mean making ClueBot a sysop, but the developers can give a single user rollback if consensus is demonstrated. Thanks. -- Cobi(t|c|b|cn) 01:19, 11 November 2007 (UTC)[reply]

Discussion

My intial reaction is yes, but am not sure if this is fair (possibly opens floodgates). GDonato (talk) 01:22, 11 November 2007 (UTC)[reply]

I don't think this would be possible without making the bot an administrator, or creating a new user group for bots with rollback. —{admin} Pathoschild 01:35:31, 11 November 2007 (UTC)

I think you are right but such a task should not be too difficult. GDonato (talk) 01:38, 11 November 2007 (UTC)[reply]
  • Deserves it with all the work he does. --Charitwo talk 01:40, 11 November 2007 (UTC) 01:22, 11 November 2007 (UTC)[reply]
  • If the developers can give ClueBot rollback without making it a sysop, I can't see the harm - it saves bandwidth and doesn't really change ClueBot's function. ClueBot will just beat me more often this way. :D Nihiltres(t.l) 01:25, 11 November 2007 (UTC)[reply]
  • Support, if the devs can make it happen. (I'd also support this for Cluebot's friends) I agree with Gracenotes that we desperately need a process to give any user rollback without the other buttons, but opposing for that reason doesn't seem constructive to me. Considering the vast amount of contribs Cluebot (and it's friends) make, using rollback will be much nicer on the servers and will render the bots themselves more effective by speeding them up. Mike.lifeguard | @en.wb 02:24, 11 November 2007 (UTC)[reply]
    In my defense, creating a user group for only one user to be in has little point... GracenotesT § 04:20, 11 November 2007 (UTC)[reply]
  • If Cluebot gains rollback it could be the poster child for future requests for rollback. There are a lot of dedicated vandal fighters that could really use rollback but don't want ot become full fledged admins. –Crazytales talk/desk 04:48, 11 November 2007 (UTC)[reply]
    I said this exact statement in IRC lastnight. --Charitwo talk 20:59, 11 November 2007 (UTC)[reply]
  • Not until Wikipedia:Requests for rollback privileges (or a similar process) gains consensus, which will provide a standard process for ClueBot (or anyone trustworthy) to gain rollback privileges, instead of this straw poll. No point making vandalism cleanup nicer for servers if only one user contributes to that effect. I do not like the idea of going out of our way to give them to a bot without some standard process that reduces error and bandwidth for everyone else. In summary, I have no major objections to ClueBot getting rollback, but object strongly to this means of doing so. GracenotesT § 01:42, 11 November 2007 (UTC)[reply]
  • If the devs say that it's possible, I reckon that there's no reason for us not to do it. I'm sure that other antivandalism bots would convert to this method of operation, so the "only one user" idea is a non-flier with me. Martinp23 19:01, 11 November 2007 (UTC)[reply]
    • We shouldn't be giving it out willy-nilly, but ClueBot has a pretty long history of being very reliable, I think. Probably another discussion, but we could look into giving rollback out to human users, as well. My main concern with giving these particular bots the priviledge, at least off the top of my head, is actually going to be rollback's default edit summary, which isn't nearly as useful as the summaries currently used by these bots -- unless we can somehow give our anti-vandal bots custom summaries? – Luna Santin (talk) 21:02, 11 November 2007 (UTC)[reply]
      • Are you joking? This bot has a history of being unreliable from what I've seen of it. I can't give diffs, but it's often reverted back to vandalised versions of pages, so I think rollback will be a poor idea. Not to forget that rollback can't mention "This is a bot, please report my errors". Majorly (talk) 14:39, 18 November 2007 (UTC)[reply]
        • It seems that not many are aware that the default rollback summary can be changed on a case-by-case bases. If someone takes the rollback url and appends &summary= followed by the edit summary, that is used instead of the default rollback edit summary. And, of course, ClueBot will take full advantage of this ability. Thanks. -- Cobi(t|c|b|cn) 19:06, 18 November 2007 (UTC)[reply]
          • To Cobi: Huh, I hadn't known that. Handy! To Majorly: Certainly the bot's made mistakes, any bot will (hell, I make my own share), but I do think the bot's done a whole lot more good than harm, all things considered. As for the edit summary, I suppose that's been addressed. – Luna Santin (talk) 11:07, 20 November 2007 (UTC)[reply]

Polling is evil. If you'd like to have a rational discussion about the pros, cons, and if there even is a possibility of giving the bot rollback, then let us do so. Bringing the matter to a vote does nothing but discourage rational discussion and instead encourages this mindlessness of jumping on the support or oppose bandwagon. At present time there is no way to give a user -- be it bot or human -- rollback without sysopping them. Previous efforts to try to create a special "rollback" usergroup have failed, as it adds yet another level of bureaucracy to a project already laden with a tremendous amount of bureaucracy. If your intention is to get the bot sysopped, take him to WP:RFA. If you're intention is to get a new rollback usergroup, then please say so. If you have some other solution not mentioned, then please say so as well. But for the love of god, no more voting! Thanks :) AmiDaniel (talk) 08:11, 11 November 2007 (UTC)[reply]

I went and asked in #wikimedia-tech if it were possible before starting this. They said it was. That is where I am getting my information. As for polling, I guess I should have been a bit more clear it was supposed to be a discussion to gain consensus instead of a vote. Thanks. -- Cobi(t|c|b|cn) 13:11, 11 November 2007 (UTC)[reply]
I've done something which someone will probably not like - I've reverted the archival and refactored the comments so that they no longer resemble a vote. Hopefully rational discussion can now continue. Martinp23 19:00, 11 November 2007 (UTC)[reply]
  • The question does not seem to be so much of should we give rollback functionality or not as much as how to do it. The simpliest way is to grant admin status to the bot which would make it the second bot with admin status. But as stated by others, it would probably make better sense to create a new user group, or add on group, that only adds the roll back feature; which would then make it easier to also allow other proven users to apply for and obtain rollback functionality without also gaining full admin status. Dbiel (Talk) 21:25, 11 November 2007 (UTC)[reply]
  • A separate user group for rollback seems like it would be both the easiest way, and the most versatile way (give it to the anti-vandalism bots for sure, but then we could potentially give it to, as has been stated, solid editors who don't want to become full admins). EVula // talk // // 07:26, 12 November 2007 (UTC)[reply]
Well, you would get about 30 options under Special:Listusers, multiply the processes to get these permissions, so not just Admin, Crat, Bot, Oversight, Checkuser, but protect, delete, block, range block, IP-exempt, hide-revision, oversight, create account by email, edit interface, checkuser, bot, undelete, etc. Messy messy! Prodego talk 21:36, 12 November 2007 (UTC)[reply]
Given the relative handiness of breaking out some of the features, that'd be really nice; having numerous options show up on that page is hardly a high cost. It'd be especially nice for bots, as they could be given only the features that they need and none of the others (though I don't think anyone was too concerned in that bot RfA of the bot going rouge and blocking or protecting). Maybe not break all the features out, but a handful would certainly be nice. EVula // talk // // 02:16, 13 November 2007 (UTC)[reply]
I don't necessarily see each different tool being added to the dropdown list, if I am not mistaken, even if there is a group added, it doesn't have to be displayed in the list. --Charitwo talk 02:12, 14 November 2007 (UTC)[reply]

Brief fundraiser notice glitch

I just happened to glance at the fundraiser notice and found it somewhat odd. The bug seems to have been fixed already, or it may have been a local issue that fixed itself, but since I already went to the trouble of taking a screenshot and uploading it, I figured I might as well share it — maybe someone else finds it amusing, too... —Ilmari Karonen (talk) 19:14, 24 November 2007 (UTC)[reply]

I'd contact $Brion. --$Deskana ($talk) 19:16, 24 November 2007 (UTC)[reply]
Yeah, this happens on meta occasionally. Apparently just a short delay that occurs when things are updated. As I've only ever seen it happen on meta, however, I wouldn't be particularly concerned about it. AmiDaniel (talk) 01:44, 25 November 2007 (UTC)[reply]
I too have seen it on meta twice. I've never seen it here, just a minor glitch, no biggie. - Rjd0060 (talk) 01:46, 25 November 2007 (UTC)[reply]
The one I saw and took a screenshot of was right here on Wikipedia — even though it says "Meta" on the notice! Apparently whatever caused the other parts of the notice to go missing also made it default to Meta for the project name. —Ilmari Karonen (talk) 00:05, 26 November 2007 (UTC)[reply]
Oh? Hm .. I've not noticed the glitch on any wiki other than meta, but can see how it would be possible for it to occur here too. The reason the sitename appeared as "Meta" is because the text is actually generated on Meta (m:Special:NoticeText); under normal conditions, it's run through a separate processor that substitutes $counter, etc., as well as {{SITENAME}} with values relevant to the referring wiki. AmiDaniel (talk) 16:48, 26 November 2007 (UTC)[reply]
For the record, I've seen it glitch a couple times on en, as well as once on meta. Dragons flight (talk) 16:59, 26 November 2007 (UTC)[reply]
This would likely be caused by a machine floating in the server pool with an out-of-date copy of the code, either on disk or in memory. I've shut off one server which was half-crashed and may have been responsible; I'll do another sweep for bad caching options in the PHP config just to be sure. --brion 16:27, 27 November 2007 (UTC)[reply]
Fixed a server that had bad cache setting. --brion 21:44, 28 November 2007 (UTC)[reply]

category creation problem

I've attempted to create Category:Pretenders to the Libyan throne and Category:Thomas Henry Wyatt buildings (deleted old mis-capitalized/titled categories) for 2 days, to no avail. Can someone check into this, or try creating the categories?! Thanks... SkierRMH (talk) 00:10, 26 November 2007 (UTC)[reply]

You have to create category pages like other pages and save them. The page is not autocreated by placing pages in the category, although the pages are displayed before the category page is created. I have created Category:Thomas Henry Wyatt buildings. PrimeHunter (talk) 00:22, 26 November 2007 (UTC)[reply]
Thanks for that - the problem is that I am attempting to create the pages as categories, but for some reason it isn't working. I just tried to create the 1st 1 again (Libyan) and it continues to come back with "Wikipedia does not have a category with this exact name." I've probably created dozens of categories, & never had this oddity happen :-? It gets odder - I was able to create the talk page for the category Category talk:Pretenders to the Libyan throne but not the category itself! SkierRMH (talk) 03:13, 26 November 2007 (UTC)[reply]
I have also created Category:Pretenders to the Libyan throne now. Your message sounds like you tried to create it as a blank page. I created it with a parent category. PrimeHunter (talk) 03:25, 26 November 2007 (UTC)[reply]
Thanks again - I tried it both ways, to no avail :( Both times I got the same bizarre message! SkierRMH (talk) 03:46, 26 November 2007 (UTC)[reply]
A parent category isn't required: see, for example, Category:Mayors of Osaka, Japan, which was just created. (It should have a parent category, but that's another matter.) -- John Broughton (♫♫) 22:56, 27 November 2007 (UTC)[reply]
It wasn't created with a parent but it did have content which was my point. When I tried to create Category:Pretenders to the Libyan throne as a blank page, it failed and I got a message like SkierRMH. PrimeHunter (talk) 21:42, 28 November 2007 (UTC)[reply]

SQL functions and lists (or as we call them disambiguation pages

Hi, I'm editing the article MS. Actually, it's more of a disambiguation page or a list. There is a little debate there about how we could format the list. I couldn't help but think of my good old database programming class. There we could pick and chose how we wanted the information to be displayed. I think it would be really handy to be able to make a table and sort it in various ways and have it display on wikipedia the way that the final user would like. For example, the article could sort the list by MS, mS, Ms, M.S., etc... or By category: medical, Aviation, etc..., then by alphabetical, etc...? I can't place 2 and 2 toghether on how SQL and a regular articles (wikipedia's database) technologies could be implemented together. --CyclePat (talk) 03:33, 26 November 2007 (UTC)[reply]

Sortable tables already exist in MediaWiki. I'm not sure how they'd work in your case though. Graham87 23:09, 26 November 2007 (UTC)[reply]
It looks like there is agreement on the talk/discussion page for this disambiguation page. Let's not go down the path of trying to format dab pages as sortable tables, please. -- John Broughton (♫♫) 22:51, 27 November 2007 (UTC)[reply]

URGENT: Special:Recentchanges is down

It's only showing the CSS code file for it now... Nwwaew (Talk Page) (Contribs) (E-mail me) 14:45, 26 November 2007 (UTC)[reply]

Showing normal for me... EdokterTalk 14:48, 26 November 2007 (UTC)[reply]
Looks fine to me too. Try bypassing your cache when viewing it. --ais523 14:49, 26 November 2007 (UTC)
Yeah, normally I'd do that, but I forgot about it... *dopeslap* Nwwaew (Talk Page) (Contribs) (E-mail me)(public computer) 17:30, 26 November 2007 (UTC)[reply]

Blockquote text size

Somehow the text size of blockquote segments has changed. Why is that, and where can we discuss it (here, perhaps)? Blockquote is sometimes used for rather long quotes - quotes that are meant to be carefully read (see Stalin's antisemitism for instance), and it is annoying to either have the normal text too large to be comfortable or the quoted text too small to be comfortable. /SvNH 02:42, 27 November 2007 (UTC)[reply]

The font size of blockquotes is 93.75% of that of the surrounding text. The size difference helps distinguish quoted text from encyclopedic prose. I don't believe the font size of a quote would cause anyone to read it less carefully, but I may be wrong. You can add the code #content blockquote { font-size: 106.67%; } to your monobook.css page to see the blockquotes in a normal font size. GracenotesT § 04:45, 27 November 2007 (UTC)[reply]
Hm, this is what it looks like (I use a rather well-known browser with a rather well-known operating system, text size set to "normal").

I wasn't implying it would cause anyone to read it less carefully - but the way it is displayed makes it harder to read it careful unless you change the text display size (which you shouldn't have to do to be able to read comfortably the contents of an article). IMHO the left margin indent serves the need to set the text apart from its surroundings well enough. /SvNH 14:10, 27 November 2007 (UTC) (Sorry for choosing a sample text with such depressing content, I didn't think of it until now).[reply]
I agree. The reduction in font size is unnecessary and causes unnecessary strain on the reader. If the intention is simply to differentiate the quoted text from that of the encyclopedia article, I think this is accomplished more effectively through changing the font type, perhaps to a Sans instead of a Serif, than through changing the font size. Personally, I find that, as SvNH said, simply indenting the text likely makes it clear that the text is quoted rather than a part of the prose. AmiDaniel (talk) 19:48, 27 November 2007 (UTC)[reply]

Hm, that doesn't look too pretty. You might find {{cquote}} to be a good (and aesthetically pleasing) alternative. As far as I can tell, there's no consensus regarding whether cquotes or blockquotes should be uniformly used for large quotations, but both appear to be acceptable. GracenotesT § 22:40, 28 November 2007 (UTC)[reply]

Not really weighing in one way or the other, but I will say that <blockquote> has been at the smaller font size for well over a year. It's an expected behavior for the font to be smaller and editors have made conscious choices based on that fact as to whether or not to use the blockquote tag. Changing it would be a significant change. --MZMcBride (talk) 00:50, 29 November 2007 (UTC)[reply]

Non-breaking spaces for dates

Is it possible to force dates to stay on one line? Trying to force my signature to stay on one line made me think of the idea, but after some further thought I can't think of any situation where I would want a date to wrap to the next line. Ideally this would be a date preference in my preferences. Is this doable/desirable? Am I missing something? Would it be possible to just force this for signatures? ~ PaulC/T+ 17:30, 27 November 2007 (UTC)[reply]

The regular expression used to detect signatures assumes there are spaces in the date; everything that parses dates from talk pages would have to be updated to handle a change like this. But I don't see much benefit to the work; it's not a big deal if a date is split across a line. — Carl (CBM · talk) 17:40, 27 November 2007 (UTC)[reply]
The css code white-space: nowrap; causes spaces to be non-breaking. The only problem with this is that it has to go around the date, so you'd have to sign with ~~~~</span>. This solution won't break regexen, but it's cumbersome, and not too much benefit results from it. GracenotesT § 17:55, 27 November 2007 (UTC)[reply]
Ah, that would be terribly involved. I was hoping for something simple like just adding a "}}" at the end of the last character for dates in signatures and prepending "{{nowrap|" at the beginning of all signatures (or the underlying wikicode in lieu of using the template). Thanks for the response. (Edit: yes, exactly what I was thinking... too cumbersome to work out.) ~ Paul (psantoraC/T+) 18:02, 27 November 2007 (UTC)[reply]

You could add ~~~~~ to your raw signature where the date goes and sign with ~~~.—Random832 18:55, 27 November 2007 (UTC)[reply]

~~~~~ in raw signatures doesn't work. One could imitate the timestamp using substituted magic words, however. GracenotesT § 01:59, 28 November 2007 (UTC)[reply]
That's what I do, anyway. I don't use nbsps, though. --ais523 11:42, 28 November 2007 (UTC)
I'm certain I've had that in my sig before - it was as a parameter to a (subst'ed) template, though, so that may have made a difference. —Random832 13:16, 28 November 2007 (UTC)[reply]

WPCITE Mozilla add-on generates footnote reference code

We have created a Firefox add-on that automatically generates footnote reference code for whatever web page you are looking at. All you have to do is right click on the web page and select WPCITE. This can save a lot of time when citing sources. The add-on beta test, wpcite.xpi, is now available for download from Mozdev. This is a beta test version that works in Firefox 2. It will be modified later today to also work in Firefox 3. If any developers would like to join the project, please visit the WPCITE project page at Mozdev and add your name to the mailing list. Thank you. - Jehochman Talk 18:35, 27 November 2007 (UTC)[reply]

Very nice. I would like to see an option to have it display in a single line format. When inserting cite templates into the body of an article, having the template stretch out to one entry per line can really throw off a page. In my opinion at least. I would rather have it in a single line format: {{cite news|title=|url=|accessdate=...}}NMajdantalk 16:27, 28 November 2007 (UTC)[reply]
Ditto. Very nice idea, and single-line-format seconded (with spaces between entries would be good, similar to ottobib's output, as it allows for overflow linewrap in the edit window (otherwise you're more likely to get the horizontal scrollbar)). -- Quiddity (talk) 22:37, 1 December 2007 (UTC)[reply]

Deletion error?

I can't delete (copyvio, if anyone cares) the second version of Image:Image3.JPG. It says "There is no archived version of Image3.JPG with the specified attributes." —Random832 21:07, 27 November 2007 (UTC)[reply]

No luck here, either. —Cryptic 21:23, 27 November 2007 (UTC)[reply]
deleting the whole thing and restoring the others worked; though I'm curious as to what could have caused the error.—Random832 21:33, 27 November 2007 (UTC)[reply]

This change established a link from Autism to the Latin page for Autism, la:Autismus. But there is no Latin page; when I follow that link I get a missing-page diagnostic (in Latin). Wikipedia:Interlanguage links #Links to pages that do not exist suggests that I can remove the link by hand, but in the past, whenever I've edited interlanguage links, some bot soon comes along and reverts my edits. What's the best thing to do here? Eubulides (talk) 22:36, 27 November 2007 (UTC)[reply]

You can remove the link by hand, but you also need to remove the link from all other Wikipedias that contain the offending link. I checked up to Japanese and couldn't find a version of Wikipedia with that link - asking the editor who added the link as you have done is another good idea. I didn't notice the discussion at Talk:Autism before removing the link. Graham87 10:39, 28 November 2007 (UTC)[reply]
See User talk:Yurik/Interwiki Bot FAQ for more information about interwiki links - I believe most of the interwiki bots are based on similar principles. Graham87 10:47, 28 November 2007 (UTC)[reply]

Partial transclusion?

Is there a way to directly transclude part of a page, say, the first 20 lines?

I'm trying to bypass the need to place excerpts on separate pages.

(A scrollbox won't do, because the whole page is transcluded into the scrollbox, which introduces a size/load-time concern).

The Transhumanist    23:01, 27 November 2007 (UTC) [reply]

You could put the part of the page that you don't want included inside a <noinclude> tag. Would that work? —Remember the dot (talk) 23:27, 27 November 2007 (UTC)[reply]
It's for a list of the day project for displaying a featured list daily. It would be an uphill battle getting something like that approved for use on 450 lists. It would be better if it was controlled from the other end. Is that possible? The Transhumanist    10:55, 28 November 2007 (UTC)[reply]
Not with the present software. --ais523 11:41, 28 November 2007 (UTC)

Help With My Monobook.js

Whenever I put any script in my monobook.js file, the scripts never take effect. I tried purging the server's cache and bypassing my browser's cache but nothing works. My browser has JavaScript enabled and everything else enabled for Wikipedia. Is there something wrong with the scripts in my file or what? Somebody help. Parent5446(Murder me for my actions) 02:04, 28 November 2007 (UTC)[reply]

I notice you are trying to use Twinkle. Are you using Firefox? Note that Twinkle doesn't work with Internet Explorer. or any other browsers except for Mozilla Firefox. - Rjd0060 (talk) 05:55, 28 November 2007 (UTC)[reply]
Actually it will also work on Opera and Safari. —Remember the dot (talk) 06:25, 28 November 2007 (UTC)[reply]
And Camino. -Rjd0060 (talk) 07:05, 28 November 2007 (UTC)[reply]
Oh, really? I did not know that. - Rjd0060 (talk) 07:04, 28 November 2007 (UTC)[reply]
I use Firefox (don't worry, I already checked Twinkle's compatibility before I put it in, along with every other script). Parent5446(Murder me for my actions) 21:47, 28 November 2007 (UTC)[reply]

New-page-patrolled edit oddity

I had Special:Newpages open from yesterday, unrefreshed, and followed a couple of the links for yellow highlighted article. In all cases I saw a "[Mark this page as patrolled]" link on the article. That included several articles that had already been deleted. In other words, I got a "[Mark this page as patrolled]" link on a page that says "This article can't be found".

I'm guessing this was intended as a feature, not a bug. If the software checked before displaying that link, and (say) you were working from a five minute old list, you might get frustrated hunting for the "Mark this page" link which wasn't there because someone else cleared it a minute ago. After all, there isn't any harm if multiple people "mark" a page as patrolled - so (I guess the logic goes) just show it so people can clear it, rather than frustrating them - the more eyes, the better.

But with a day-old list, as I was using, I wouldn't expect to find the "Mark this page" link in most cases; this now seems more like a bug than a feature. So - would it make sense to modify the software (if I understand how it works, and the logic) to check the date/time stamp for when a page was patrolled, if that does exist, and if it's more than (say) an hour old, NOT display the "Mark this page" link? -- John Broughton (♫♫) 14:00, 28 November 2007 (UTC)[reply]

Newpages should not be showing deleted pages. It's query straight joins on page, so only slave lag would cause anything deleted to show. Deleted pages are not really useful to patrol given that. I'd leave a bugzilla report. Voice-of-All 17:40, 28 November 2007 (UTC)[reply]

bugzilla:12143. Sorry I munged the markup (guess we need a how-to somewhere). MER-C 05:15, 29 November 2007 (UTC)[reply]

Fixed with r27941, but isn't live yet. MER-C 12:40, 29 November 2007 (UTC)[reply]

Can we start numbered list with number other than 1?

Look at Portal:Poland/Poland-related_Wikipedia_notice_board#Participants_list and you will see what I mean. There are two columns numbered via #, but the second one starts at 1 instead of 25. Can this be changed other than by converting # symbols into plain numbers?-- Piotr Konieczny aka Prokonsul Piotrus | talk 21:24, 28 November 2007 (UTC)[reply]

It's possible to do so in HTML (wide browser support):
  1. One
  2. Two
  1. Three
  2. Four
It's also possible to do using CSS (slim browser support):
  1. 1
  2. 2
  3. 3
  4. 4
However, there isn't a way to do so using wikimarkup. Cheers. --MZMcBride (talk) 22:01, 28 November 2007 (UTC)[reply]

Problem with the position of coordinates with fund raising header

I finally located the problem code that is creating the conflict with the fund raising header and the position of the coordinates template. That code is:

<span id="coordinates">Test</span>


Where can one find the code used by id=coordinates? and can it be altered, or a new copy created for the coordinaate template so we can finally get rid of the conflict with the fund raising header?

It should be noted that this code works very differently over in Meta. Dbiel (Talk) 04:06, 29 November 2007 (UTC)[reply]

It isn't code, just skin specific styling on the English Wikipedia, defined in MediaWiki:Monobook.css:
#coordinates {  
    position:absolute;
    z-index:1;
    border:none;
    background:none;
    right:30px;
    top:3.7em;
    float:right;
    margin:0.0em;
    padding:0.0em;
    line-height:1.5em;
    text-align:right;
    text-indent:0;
    font-size:85%;
    text-transform:none;
    white-space:nowrap;
}
--Splarka (rant) 08:27, 29 November 2007 (UTC)[reply]
As noted at Wikipedia_talk:WikiProject Geographical coordinates#Coord loc on VP due to previous mention in VP, the coordinates are positioned with absolute coordinates. The fundraising and other notices shift the article position under the coordinates. The original position in the article moves to a different location for the expanded notice, the brief notice, and no notice (in addition to whatever other messages someone decides to create). I haven't checked if CSS allows positioning based upon an anchoring marker. (SEWilco (talk) 16:31, 29 November 2007 (UTC))[reply]

The next question would be: How is the position of the article title defined? That may give some insight into how best to alter the coordinates positioning. Dbiel (Talk) 05:25, 1 December 2007 (UTC)[reply]

The minimum tag hierarchy to reduplicate its position would look something like this:
<body  class="mediawiki ns-4 ltr page-Wikipedia_WikiProject_User_scripts_Requests">
 <div id="globalWrapper">
  <div id="column-content">
   <div id="content">
    <a name="top" id="top"></a>
    <div id="siteNotice"></div>
    <h1 class="firstHeading">Editing Wikipedia:WikiProject User scripts/Requests (section)</h1>
   </div>
  </div>
 </div>
</body>
Nothing outside <div id="content"> (other than its direct parent tags, listed above) should affect its position, nor anything below it, so the conditions of its position are dependant on the stylings if these elements, the styling of <a name="top" id="top"></a> and the styling and content of <div id="siteNotice"></div>. The content of the sitenotice is extremely variable, and not very predictable. This means no absolute-positioning css trick can ever really exactly place an object on a page relative to the title, if the site has a sitenotice. A relative-position trick might be more feasable, but anything at the top between the title and contents (such as on a preview or diff page) would screw that up too.
BTW, if you want to see the stylings in effect, see monobook/main.css and look for the following definitions: body ; #globalWrapper ; #column-content ; #content ; #content ; h1, h2, h3, h4, h5, h6 ; h1 ; #bodyContent h1, #bodyContent h2 ; #bodyContent h3, #bodyContent h4, #bodyContent h5 ; .firstHeading ; a . --Splarka (rant) 09:43, 1 December 2007 (UTC)[reply]
Thanks for the reply. It is way over my head. I was hoping that someone with a good html background might be able to solve the problem as long as the variables were available; so thanks for posting them. It is a shame that a site with as much exposure as en.Wikipedia is unable to correct this display problem. Dbiel (Talk) 05:42, 2 December 2007 (UTC)[reply]

Editing own talk page while being blocked

Is there anyone who knows what's the code or script that, if we are blocked, we can still edit our own talk page so that we can request for unblock, or answer someone's question? I'm an admin in the Malay Wikipedia, when I blocked myself there, I couldn't edit my own talk page! So I'd like to change this there. Is there anyone who can help? Thanks! --Edmund the King of the Woods! (talk) 09:43, 29 November 2007 (UTC)[reply]

It's $wgBlockAllowsUTEdit, that needs to be setup by someone with access to the configuration file (LocalSettings.php). -- lucasbfr talk 11:12, 29 November 2007 (UTC)[reply]

Thanks. But, erm... how to use that configuration file? Is there any instruction of how to use the code into the file? --Edmund the King of the Woods! (talk) 11:15, 29 November 2007 (UTC)[reply]

Open a bug on bugzilla. — Werdna talk 11:49, 29 November 2007 (UTC)[reply]

Yep, a developer needs to update the file for your Wikipedia. I assume they will need to check that there is a local consensus to allow users to edit their talk pages. More info on bugzilla can be found at mw:bugzilla -- lucasbfr talk 12:42, 29 November 2007 (UTC)[reply]

Abuse of #ifexist parser function

I've just cleaned up some templates that were causing upwards of 2000 database queries per page-load ({{usercheck}}, the one responsible being {{highrfc-loop}}. To ensure that this does not happen again, I've introduced some changes to ParserFunctions in r27946 which make it impossible to use #ifexist more than 100 times per page-load starting from the next time the code is taken live. You may find that some templates no longer work, which used to use {{highrfa}}, {{highrfb}}, and their relatives, will no longer work.

Thanks, — Werdna talk 10:51, 29 November 2007 (UTC)[reply]

Would it be possible to make substituted {{#ifexist:}} statements not count towards this limit, since they are one-time database loads? This is useful for simplifying statistics pages (for example, using regex patterns to remove all deleted pages from an existing statistics page, or allowing an external script to skip page checking which is more complicated offsite than using MediaWiki). —{admin} Pathoschild 15:39:36, 29 November 2007 (UTC)
My understanding is that this would still present a denial of service vulnerability (think submitting a page filled with ifexist statements to the article size limit. Each one takes 3ms, it's 19 characters per check, this could fill an article up to 2MB, so we get a finished article of something like 100,000 requests. This would tie up one quarter of one of our ten $12,000 database servers for five minutes. — Werdna talk 00:26, 30 November 2007 (UTC)[reply]

This change will probably break the Wikipedia:Protected titles system. --- RockMFR 18:00, 29 November 2007 (UTC)[reply]

Three solutions might exist for this: 1. Limit entries to 50 per page, or 100 if the second #ifexist in {{protected title}} can be removed. Replace * with #. 2. The template can be edited to leave out #ifexist: actually transclude the page if it exists. 3. Implement a better solution than an unintuitive hack. Wikipedians have a knack for finding those, though :< GracenotesT § 18:15, 29 November 2007 (UTC)[reply]
4. Change the implementation of #ifexist (could the queries it's causing be batched up somehow?) —Random832 21:49, 29 November 2007 (UTC)[reply]
Incidentally, "transclude it anyway" could work well if protected titles were on a page that acts like a css/js file: those don't actually paste in the content for display purposes, but they do "count" as transcluding, see User:Random832/test.css and User:Random832/testprottitle for proof of concept. (Or we could just count on them never being created without being removed from the lists)—Random832 21:55, 29 November 2007 (UTC)[reply]
Actually, that might be wrong. They do cause scripts to show up in categories, so it might be fully parsed/transcluded behind the scenes.—Random832 21:59, 29 November 2007 (UTC)[reply]

Then fix the Wikipedia:Protected titles system. I don't know how this page works, but I have added the technical restriction with good reason, and it needs to be in place. — Werdna talk 00:26, 30 November 2007 (UTC)[reply]

Why not fix the implementation of #ifexist so that it doesn't generate 2000 database queries? (certainly it's reasonable to have the technical restriction in place until that is done, but as a permanent solution?)—Random832 06:04, 30 November 2007 (UTC)[reply]
I wonder why people need to check if 2000 pages exist anyway. — Werdna talk 10:11, 30 November 2007 (UTC)[reply]
The use of #ifexist on WP:PT subpages is to prevent the pages being transcluded there (and therefore protected) if they do exist. The page uses cascading protection as a method of preventing various non-existing pages being created, as a method of working around the lack of protection for nonexistent pages. --ais523 13:25, 30 November 2007 (UTC)
I wonder why checking 2000 pages for existence alone (not pulling up their contents) is such a huge burden on the servers. Why does it need to make a separate query for each page that is being checked? I _agree_ with this as a temporary fix, but a better solution should be used in the long run. And calling it "abuse" is out of line.—Random832 14:53, 30 November 2007 (UTC)[reply]
Let's all stay calm. From a perspective of a user who just expects things to work, and expects that it's impossible to mount a DOS attack, it was not abuse. Once it was realized that the implementation was costly, it became clear that having numerous queries of that form does present a burden to the servers. There are solutions being discussed on the wikitech mailing list to reimplement the parser function so that it is not so costly, but these require some complex code, so they certainly will not be in place soon. For the time being, perhaps we write a script to handle updates to the the protected titles page? — Carl (CBM · talk) 14:59, 30 November 2007 (UTC)[reply]
"Then fix the Wikipedia:Protected titles system."
You acknowledge in the following sentence that you "don't know how this page works," so the above nonchalant instruction is rather rude. So is your claim that good-faith use of the #ifexist function constitutes "abuse." Brion Vibber has told us that the developers will handle any necessary technical restrictions directly (as you're doing now), so we shouldn't worry about server load or bother enacting limitations beyond those in MediaWiki. Now you're suddenly blaming us for failing to do exactly that (despite the fact that no one even informed us of the issue until now).
Incidentally, the Wikipedia:Protected titles system exists because MediaWiki includes no alternative means of protecting nonexistent pages. (Perhaps you could consider adding one.) Back in April, I discussed the setup with Voice of All (who didn't complain of any problems, and actually assisted me by tracking down a minor bug that had recently been introduced), so please don't act as though we haven't sought developer feedback. —David Levy 19:00, 1 December 2007 (UTC)[reply]
I'm not interested in getting into a holy war over word choices in what I've said here: Change the word 'abuse' to 'overuse' if it helps you sleep better. Anyway, I was hoping to do some work on the blocking system that would have allowed this sort of restriction, but unfortunately, I'm flat out for the next year or so (I'm in my final year of High School, and they lay it on pretty thick here), and so I probably won't have time to implement it (despite the fact that I've wanted to since something like the start of the year). — Werdna talk 12:55, 4 December 2007 (UTC)[reply]

It is quite a feat to re-jig the parser to do it all in one go (from a programming perspective — we'd need to add placeholders, and replace them after the end of parsing, and all that jazz. A few messages on the mailing list has made it clear that it is not as simple as "just use a LinkBatch". Those proposing an alternative implementation of the parser function may be interested to read Tim Starling's comments on the matter:

... I
think you're getting the idea of how complicated it is. I told the guy in
#mediawiki who wanted to do 4000 #ifexist calls on a page that optimising
this case would take days, and that he should just forget it and find some
other way to do what he was doing. Unless someone comes up with some
really, really valuable applications that can't be done any other way, I'm
happier with just having a limit. If you have days to spend on
optimisation work, I have some other ideas for where you should be
spending them.

-- Tim Starling

Werdna talk 22:35, 30 November 2007 (UTC)[reply]

Do I understand the above correctly? There's a much better solution, but it won't be implemented because it "would take days"? Please tell me that I've misunderstood. —David Levy 19:00, 1 December 2007 (UTC)[reply]
That's not fair. Tim's been incredibly busy with work on an updated parser, a new file repo system, and the Ogg Handler. All files related to MediaWiki are publicly available for anyone to download and modify at http://svn.wikimedia.org/. Unless you are going to begin coding something better, you'll simply have to wait until someone else gets around to it. --MZMcBride 19:14, 1 December 2007 (UTC)[reply]
I'm not questioning Tim's work ethic or demanding that he (or anyone else) do anything. I'm questioning his belief that this issue is so unimportant that he would actually discourage others from spending "days" to develop a better solution. (If I possessed the knowhow, I would do so myself.) —David Levy 19:41, 1 December 2007 (UTC)[reply]
As for WP:PT, there is an extension that would allow a MediaWiki page much like MediaWiki:Bad image list that would block the creation of protected titles and would even allow regex to do so. The extension is mw:Extension:Title Blacklist. Hopefully either that system or a better one can be implemented to fix this particular problem. As for the broader #ifexist issues, if there were an easy fix, someone would have committed it already. --MZMcBride 19:14, 1 December 2007 (UTC)[reply]
Do you know why has this extension has not been implemented at the Wikimedia wikis? Are you aware of any negative effects? —David Levy 19:41, 1 December 2007 (UTC)[reply]
Well, the extension was created pretty recently, I believe. It's also still in beta. The code would need to be reviewed by Tim or Brion or one of the other devs to look for any possible security implications. There's also the issue of performance issues and whether or not an extension like that may cause any of those. The extension itself exempts sysops from any of the title blocks, but does so without any warning or indication; that could be problematic. Also, it appears to block editing if a regex is written poorly and covers pages that it shouldn't. --MZMcBride 20:01, 1 December 2007 (UTC)[reply]
I see. Well, it's nice to know that there's some progress on that front. Thanks for the info! —David Levy 20:08, 1 December 2007 (UTC)[reply]

It also abuses the localisation system for configuration. — Werdna talk 07:35, 2 December 2007 (UTC)[reply]

Can somebody help me understand this? I saw this discussion last week and I just read about it again on the Signpost. I was going through the list of affected articles and came across one I edit a log, 2007 NCAA Division I FBS football rankings. Both the log and the generated HTML say there are 948 ifexists in the code. I'm looking at the code to the page, and the code to the template being used and I see no ifexist statements. Am I missing something?↔NMajdantalk 14:20, 4 December 2007 (UTC)[reply]

The issue is {{Cfb link}}. — Carl (CBM · talk) 14:29, 4 December 2007 (UTC)[reply]
Ok thanks. Is the issue resolved if I subst it?↔NMajdantalk 14:33, 4 December 2007 (UTC)[reply]
Ok, still confused. Take a look at 2007 Buffalo Bulls football team. There are 10 uses of the {{cfb link}} template which makes six #ifexist calls. That's 60, but the page is saying there are 138. I looked at every other template in the page and cannot find where the difference is coming from.↔NMajdantalk 14:38, 4 December 2007 (UTC)[reply]
Nevermind, figured it out.↔NMajdantalk 14:58, 4 December 2007 (UTC)[reply]

Glitch

File:Wiki Glitch.jpg

I got this glitch often, even on this page! —Coastergeekperson04's talk@11/29/2007 15:36

What's the glitch? The extra toolbar? Or the image not appearing? EdokterTalk 15:54, 29 November 2007 (UTC)[reply]
I studied this for 5 minutes, and don't see what the problem is. I hope this isn't a "gotcha"... Rjd0060 (talk) 17:41, 29 November 2007 (UTC)[reply]
It is a script that adds another toolbar, and it is leaving the old one in place. (hint: look at the top of the image). Something in your monobook.js is doing it, clearing it will fix it, otherwise... Prodego talk 21:10, 29 November 2007 (UTC)[reply]
The extra toolber is wikEd, but the bottom part is not where it should be. —Coastergeekperson04's talk@11/29/2007 23:30

"Test" on page heading

File:Tech vp with test.JPG

Am I the only one who sees the word "Test" at the top of the page (just to the right of the page title). Why is it there? Here's an image incase I'm the only one... Rjd0060 (talk) 17:59, 29 November 2007 (UTC)[reply]

It was caused by the code <span id="coordinates">Test</span> (both written inside and outside nowiki tags) in #Problem with the position of coordinates with fund raising header. I have commented out the version without nowiki tags. PrimeHunter (talk) 18:45, 29 November 2007 (UTC)[reply]
Thanks, - Rjd0060 (talk) 19:42, 29 November 2007 (UTC)[reply]

Database error: conflicting read lock

Lately I've been getting quite a few errors like this (I think this is the third I've seen within a few days):

Database error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted query was:

(SQL query hidden)

from within function "Block::purgeExpired". MySQL returned error "1223: Can't execute the query because you have a conflicting read lock (10.0.0.237)".

This one happened while I was blocking a user; the previous ones happened while saving edits (and occurred within "Revision::insertOn", IIRC). Reloading fixes the problem. I don't recall seeing this particular error message before, so I assume it's a relatively new issue, but I have no idea what could be causing it. Posting here in case someone does know, or might find this report useful. —Ilmari Karonen (talk) 18:52, 29 November 2007 (UTC)[reply]

Corruption with cite.php

Just happened when I was editing an article: [1], attempt to fix fails. I have seen a few times before, although rarely (last time maybe half a year ago or longer). Any ideas what's causing it - and how to fix it? -- Piotr Konieczny aka Prokonsul Piotrus | talk 19:25, 29 November 2007 (UTC)[reply]

Answered in the section right under this one. :) Acalamari 19:44, 29 November 2007 (UTC)[reply]

ref tag broken?

I just updated some formatting on Thomas Rogers (locomotive builder) to current MOS practice, but when I saved it, the <ref> rendered as ?UNIQ1218c283548c5658-ref-00000001-QINU? instead of a footnote number, and the footnote did not appear in the {{reflist}} output. Slambo (Speak) 19:27, 29 November 2007 (UTC)[reply]

I've just noticed the same thing. — Frecklefσσt | Talk 19:27, 29 November 2007 (UTC)[reply]
I just had the same thing happen when notifying an IP that they were blocked.[2] EVula // talk // // 19:30, 29 November 2007 (UTC)[reply]
Me three. howcheng {chat} 19:30, 29 November 2007 (UTC)[reply]
I noticed the same thing on this talk page (hence my rollback) right here, yet I never edited that part of the page. It's odd. Acalamari 19:41, 29 November 2007 (UTC)[reply]
Ditto that :-( A few of us have reported the same thing at Wikipedia_talk:Footnotes#Something_is_wrong_with_footnotes.21 ǝɹʎℲxoɯ (contrib) 19:50, 29 November 2007 (UTC)[reply]

Scroll up (and I mean through the entire page). She's dead Jim. Anyone want to go tell the devs on IRC to lock the database before this corruption runs rampant? Dragons flight (talk) 19:40, 29 November 2007 (UTC)[reply]

There was just a lock right now that took place for about five minutes. Acalamari 19:42, 29 November 2007 (UTC)[reply]
Yeah, and that lock was probably associated with the software update that broke everything. Now it would be nice to lock the database again and fix it. Dragons flight (talk) 19:43, 29 November 2007 (UTC)[reply]
That lock was to undo the update, according to the text that accompanied it. And editing works fine again since the lock, so all is good. --Dreaded Walrus t c 19:46, 29 November 2007 (UTC)[reply]
The thing appears to have been fixed a few minutes ago. I had this same issue, and thought it was just me, but it appears not. Anyway, it's fixed now, we can edit safely. :P --Dreaded Walrus t c 19:43, 29 November 2007 (UTC)[reply]

Ah, thanks for the updates. The weird text replaced the reference text completely, so I had to go back and update it again to fix my corrupted edit. Slambo (Speak) 19:52, 29 November 2007 (UTC)[reply]

As far as I know, this is fixed, but an unknown number of diffs will need to be checked for errors. See User:Splarka/UNIQ_list. – Luna Santin (talk) 00:45, 30 November 2007 (UTC)[reply]

Templates going crazy

Not sure what's up, but there appears to be something gone wrong with some basic feature of the Wikipedia template system. In the last fifteen minutes, suddenly communities with Template:Infobox Settlement have begun displaying a warning that the coördinates are wrong and showing an empty link for the communities' seals, although the template itself hasn't been edited in two days. Meanwhile, other templates are being affected, as you can see with Template:Ohio, which hasn't been edited in a month and a half:

Until a little while ago, the Counties line was the bottom line; there was nothing of the group6 and group7 lines.

I don't know what's going on, but it's making a mess of geography pages (the infoboxes are far wider with the "ERROR in ?UNIQ60248b0f24db3956-nowiki-00000002-QINU? invocation" warning), and I suspect that it's vandalism or unintentional damage to some sort of basic template. Nyttend (talk) 19:29, 29 November 2007 (UTC)[reply]

There was an upgrade that messed up. All hail Brion for fixing it. east.718 at 19:42, November 29, 2007
Hail, Brion! — Frecklefσσt | Talk 19:51, 29 November 2007 (UTC)[reply]
Personally, I don't praise them for causing only a little mess, when it was their update that created the problem in the first place. How many pages were corrupted and still need to be fixed? Dragons flight (talk) 19:54, 29 November 2007 (UTC)[reply]

This appears to be a system wide issue. Have we confirmed this is a little mess and not a grandiose mess? Check this out as well. spryde | talk 19:56, 29 November 2007 (UTC)[reply]

I think it is a big mess. I've spotted several pages on my watchlist that were corrupted. Anything edited within a certain time frame may have errors embeded into it. NoSeptember 20:00, 29 November 2007 (UTC)
To be more specific; any edit involving a substed template in that timeframe has ended up corrupted permanently. Transcluded templates only showed a temporary corruption. EdokterTalk 20:15, 29 November 2007 (UTC)[reply]
It also affected data included inside of <nowiki> tags. If we know the exact time frame of this situation, can a list of all edits made in that period be made available for us to check each one out? I think it lasted several minutes. NoSeptember 20:24, 29 November 2007 (UTC)
This appears to happen around the 19:24 UTC time. I am going to see if I can't get a list of potential issues together. spryde | talk 20:21, 29 November 2007 (UTC)[reply]
Yeah, I see that it messed up the nowiki problems; that's why there's gibberish in my first comment, as I was trying to copy a line of text that included template coding. The place where I found the main problem is communities in Craven County, North Carolina, but I'm now noticing that places such as Havelock, North Carolina are displaying properly without any edits having been made to the page since I noticed the problem in the first place. Nyttend (talk) 20:29, 29 November 2007 (UTC)[reply]
Earliest I have seen is 19:16 and the latest is 19:30. spryde | talk 20:31, 29 November 2007 (UTC)[reply]

Additional corrupted edit here, occured at 19:16 (8 minutes earlier) on the much used update template. /Blaxthos ( t / c ) 20:42, 29 November 2007 (UTC)[reply]

Updated. spryde | talk 20:47, 29 November 2007 (UTC)[reply]
I have fixed this page manually by editing the last good version and copying later edits into it:[3] (I accidentally duplicated the last section after an edit conflict and removed the duplicate later) Is there a chance of getting an automated fix or should we just go over affected pages manually? PrimeHunter (talk) 21:38, 29 November 2007 (UTC)[reply]

I would like to suggest this google search, in order to catch any that were missed as they show up in the search index over the next few days. (This is less than useful at the moment because a lot of temporary problems are showing up in the search - give it a couple days)—Random832 21:40, 29 November 2007 (UTC)[reply]

Splarka and I are currently whipping together a couple scripts to reverse faulty revisions introduced during the 14 minute period that the broken code was live. There are around 3,000 revisions that were potentially affected; of those (at present time) about 6-7% appear to actually be problematic. We will hopefully have them all corrected today. AmiDaniel (talk) 22:36, 29 November 2007 (UTC)[reply]
Thanks. Then I will not make additional complicated fixes. PrimeHunter (talk) 00:01, 30 November 2007 (UTC)[reply]
After some initial investigation by myself and MZMcBride, it appears there is not really any feasable way to automate the cleanup, as it is. I'm building a list of revisions which introduced the string 'UNIQ' during the timeframe at User:Splarka/UNIQ_list. List is not quite complete (and there is a &title issue we've got to hammer out before it is useable yet, heh). --Splarka (rant) 00:30, 30 November 2007 (UTC)[reply]
Okay, User:Splarka/UNIQ_list is up and running for any people with too much time on their hands. Each revision I guess needs to be checked manually, and if the UNIQ is no longer in the top edit, then the history should be checked to make sure it was reverted correctly, I guess. Fun fun! --Splarka (rant) 01:40, 30 November 2007 (UTC)[reply]

Need Help

This is the second time I am posting this. None of the scripts in my monobook.js file work. I have Firefox so the TWINKLE script will work and there is nothing disable for Wikipedia in my browser. Parent5446(Murder me for my actions) 21:10, 29 November 2007 (UTC)[reply]

There is an uncommented line at the end of your monobook.js (END WIKIBREAK SCRIPT */) which might cause javascript to abort. Put a /* in front of it. EdokterTalk 00:23, 30 November 2007 (UTC)[reply]

site css proposal (line-height on sup, sub)

I would like to propose adding the following rule to the site css:

sup, sub { line-height: 0 }

Proof of concept follows.

This div has a line-height of 1.5, the default, in case any of your stylesheets are overriding it. There are some superscripts throughout. Superscripts in red have no other CSS applied to them, other superscripts have a line-height of 1.Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis xy nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est xyz laborum. Suspendisse porta, leo id pellentesque imperdiet, justo nunc posuere felis, vitae viverra dolor pede et wisi. Ut metus augue, rutrum pharetra, elementum nec, porta et, mauris. Praesent auctor cursus sem. Proin ut orci. Maecenas orci. Integer tempor hendrerit nulla. In massa orci, placerat sed, sagittis in, varius at, est. Ut xy erat. Proin at sapien quis ipsum imperdiet pulvinar. Donec vehicula metus ac sapien. In eu urna. Suspendisse dapibus, ante ut facilisis dignissim, velit mauris congue odio, xyz nec suscipit sapien eros quis nisl. Aenean est. Etiam pharetra metus vitae est. And, as you can see with the staggering xyztetc, a line-height of 0 will not result in the content failing to get space when it is needed.

Random832 21:23, 29 November 2007 (UTC)[reply]

GAH. fails in IE. changing to the less ambitious value of 0.8. —Random832 21:28, 29 November 2007 (UTC)[reply]

IE seems to break regardless on use of nested superscripts.—Random832 21:30, 29 November 2007 (UTC)[reply]
Works in Safari 3. And I like it !!! Can't we make this browser specific ? We have plenty of that already, so. --TheDJ (talkcontribs) 22:34, 30 November 2007 (UTC)[reply]

Defining new CSS classes or IDs?

Previously asked but unanswered at Wikipedia:Help desk

Is there any way to create a new CSS class or ID in a single page, but have it apply to all viewers? The only thing I can find is to modify my own monobook.js, which would apply only to me, or a site-wide change to MediaWiki:Common.css which is obviously not an option. I tried using <style></style> tags but MediaWiki seems to escape them out. I can't just use inline CSS style="" attribs because common classes are overriding it. —dgiestc 23:21, 29 November 2007 (UTC)[reply]

No, there is no other way. Use inline CSS - it should override classes (care to give us an example where it doesn't?) ∴ AlexSm 00:05, 30 November 2007 (UTC)[reply]
I believe there are separate css files for each of the seven skins, in the MediaWiki namespace. I hope that we're not talking about some unilateral change that noticeably affects everyone. -- John Broughton (♫♫) 00:42, 30 November 2007 (UTC)[reply]
I absolutely am not asking for a unilateral change, but can someone figure out how to override list-style-image for bulleted lists (class li)? —dgiestc 03:52, 30 November 2007 (UTC)[reply]
You could, I think, use inline styles, but you would have to fully use html - no wikimarkup using * or anything. So, raw <ul> and <li> tags. Because if you use *, that comes with its own (entirely plain) <ul> tag. —Random832 04:21, 30 November 2007 (UTC)[reply]
Also, you can't actually change the image with a manual <li style="">. The mediawiki xml whitelist doesn't allow image stylings in wikicode because it would allow you to bypass [[image]] syntax and even hotlink, it gets censored right out. What you *can* do is something like:

<ul><li style="list-style-type: circle; list-style-image: none;">Bar</li></ul>

  • Bar
See this thingy for more info. --Splarka (rant) 08:36, 30 November 2007 (UTC)[reply]
Ah, good point about security. I figured there must be a good reason. Thanks. —dgiestc 16:50, 30 November 2007 (UTC)[reply]
Any chance of a feature being added to allow CSS image references to wikipedia images? e.g. list-style-image: wiki_image_url("example.png",10) —Random832 14:55, 30 November 2007 (UTC)[reply]
That's not legal CSS. To support something like that we'd need some sort of JavaScript hook to examine CSS properties and rewrite them as proper URLs. —dgiestc 16:50, 30 November 2007 (UTC)[reply]
Neither is <br> valid XHTML, but the parser takes care of it. MediaWiki could replace wiki_image_url() with url(), just as it replaces Image:Example.png with an <img> tag with this src. GracenotesT § 18:20, 30 November 2007 (UTC)[reply]

(Talk) on your talk page

Recently we had the default signatures switched to display talk page links at the end. On a person's own talk page it displays as boldfaced rather than as a link. Is there any way to make it so that it automatically won't be appended when signing to one's own talk page, but remains for all other pages?--Fuhghettaboutit (talk) 23:57, 29 November 2007 (UTC)[reply]

No, not possible. Sigs act as substituted templates and cannot be filtered. The bolding is done by the link parser, and it affects all sigs. Look at any user talkpage and you'll see bold non-links of that user. EdokterTalk 00:15, 30 November 2007 (UTC)[reply]
What I do is I link to a redirect to my talk page, so it always appears as a link and allows me to track where I have made signed comments. Another option is to use {{subst:#ifeq:{{SUBST:FULLPAGENAME}}|User talk:YourName||([[User talk:YourName|talk]])}} replacing YourName with your username which will make the talk page link appear everywhere apart from on your own talk page. Tra (Talk) 00:29, 30 November 2007 (UTC)[reply]
The default signature format is now something that any admin can change. I think the code shown (as I understand it) would be a big improvement, removing the (black) talk page link when an editor (one without a personalized signature) posts to his/her own user talk page. Do we need a poll to move forward with this? -- John Broughton (♫♫) 00:38, 30 November 2007 (UTC)[reply]
I had actually intended that code to be put in the box in the preferences for an individual user. I guess it might work for in the system message for everyone. It depends if that message supports ParserFunctions. Tra (Talk) 00:45, 30 November 2007 (UTC)[reply]
Thanks for the responses. So if I understand correctly, this may be feasible site wide, but until implemented, if I want to make this change myself I would place the code Tra provided in the signature field in my preferences? I think this would be a nice feature site wide—slightly trivial, purely esthetic, but an improvement.--Fuhghettaboutit (talk) 01:30, 30 November 2007 (UTC)[reply]

I suspect it supports parserfunctions - the bigger problem is that it seems at least semi-likely that if subst: is put in, it will subst when saving the message.—Random832 04:18, 30 November 2007 (UTC)[reply]

Fuhghettaboutit - yes, you can put the code into your signature field and it will work fine - I just tested it with IE7. Also, note that the code provided is only for the "talk" part of the signature; you'd need to add the front part as well, if you want a link to your user page. That's probably pretty obvious, but since I missed it the first time reading the code, I thought I'd mention it just in case.
Random832 - you're saying that you think that when an admin makes the change, the subst might kick in immediately, yes? Is there some way to test this, say at the test wiki that the Wikimedia Foundation has? -- John Broughton (♫♫) 13:51, 30 November 2007 (UTC)[reply]
Random832 is right, as far as I know. It's very hard to save a page which literally contains subst: after a pair of opening braces, and none of the methods I know for doing it will work in this case, especially as it's a MediaWiki message that's being created and not a template. It's also worth checking to make sure that bug 5678 won't interfere with this; I don't think it will, but it'll definitely be worth checking what happens if a sig is used as a template parameter, and as a parameter to a nested template, after the new changes have been made. --ais523 13:56, 30 November 2007 (UTC)

I have a solution for users' monobook.css:

body.ns-3 strong.selflink { font-weight: normal }

This rule simply removes bold - apply whatever styles you want. Can't get rid of it entirely though, because then you'd have empty parentheses. —Random832 16:46, 30 November 2007 (UTC) [reply]

Continued at #Talk page links included in default signatures -- John Broughton (♫♫) 19:57, 4 December 2007 (UTC)[reply]

Weirdness on Talk:Saeb Erekat

Hey, do y'all have any idea what the first change on [4] is all about? It looks like "====" somehow got changed to "UNIQ6894a2d17c86f176-nowiki-00000002-QINU". I don't think Jaakobou did this, although I guess it could be some weird bug in his browser / external text editor. Does that UNIQ-xxx-blah-yyy-QINU notation mean anything to the Mediawiki software? <eleland/talkedits> 02:24, 30 November 2007 (UTC)[reply]

There's a discussion about this, above.--Fuhghettaboutit (talk) 02:47, 30 November 2007 (UTC)[reply]

Issue with API and bots

There is some issue this morning where bot queries to the API are limited to 500 records instead of 5000. The developers know about it. VeblenBot 14:27, 30 November 2007 (UTC)[reply]

Fixed in revision 27975. VeblenBot 14:43, 30 November 2007 (UTC)[reply]

Relapse

In edit mode, [[relapse]] occurs after this colon:relapse In un-edit mode, I can't see it. Can you? If not, should we fix the bug or rename the "Relapse" article? Art LaPella 16:34, 30 November 2007 (UTC)[reply]

The #Disappearing links? section below is the same problem. Art LaPella 16:37, 30 November 2007 (UTC)[reply]

Disappearing links?

Suddenly this morning I notice that some links are disappearing in my browser. For example, the word vulnerable is invisible on my screen (if you just saw "the word is invisible," then you have the same bug -- it should say "the word [[vulnerable]] is invisible"), and there is no link to click on for that word. I am using IE 7; I can't test with another browser until later on. I can't at the moment figure out which links are disappearing and which aren't; for example, "[[browser]]" above shows up just fine. I've checked my preferences and flushed my browser cache. Any other suggestions would be most welcome! --Russ (talk) 16:16, 30 November 2007 (UTC)[reply]

Update: I did figure out part of the issue -- vulnerable is a short article, and I had my stub link preference set at 250. When I changed it to 25, the link reappeared, so obviously the problem is with the formatting of stub links. Why these links disappear, however, is still a mystery to me. --Russ (talk) 16:22, 30 November 2007 (UTC)[reply]

I'm able to reproduce this bug by fiddling with my stub prefs. It's not a browser bug or CSS thing, though. The link is not present in the HTML at all. --- RockMFR 16:29, 30 November 2007 (UTC)[reply]

I've got the same problem. I have my preferences set so that I can tell stubs, and don't really want to lose that ... but I guess if that's what fixes it, I'll have to. Pastordavid 16:35, 30 November 2007 (UTC)[reply]
Bug #12165 created on Bugzilla. --Russ (talk) 16:38, 30 November 2007 (UTC)[reply]
me too.</aol> - at least this one's not mangling actual wikimarkup.—Random832 16:41, 30 November 2007 (UTC)[reply]
It should be fixed now; try reloading the page and the link to vulnerable should appear in this sentence. You may need to clear your browser's cache (shift-reload etc). If the problem reappears, post here. — Carl (CBM · talk) 16:55, 30 November 2007 (UTC)[reply]
Good. It has been fixed for me. PrimeHunter 17:20, 30 November 2007 (UTC)[reply]

Changes to unwatched pages showing up on my watchlist

This is not a big deal, and I apologize if it's been reported already, but changes by User:BOTijo (comments on capitalization redirects) to pages I don't watch have been showing up on my watchlist. At the moment I can see the following (skipping pages that I do watch).

   *( diff) (hist) . . mb  Carbonated Sierra-Finch‎; 09:34 . . (+32) . . BOTijo (Talk | contribs) ({{R from other capitalisation}})
    * (diff) (hist) . . mb Brown-capped Tit-Spinetail‎; 09:12 . . (+32) . . BOTijo (Talk | contribs) ({{R from other capitalisation}})



29 November 2007

    * (diff) (hist) . . mb Blue-billed Black-Tyrant‎; 21:22 . . (+32) . . BOTijo (Talk | contribs) ({{R from other capitalisation}})
    * (diff) (hist) . . mb Black-throated Shrike-Tanager‎; 20:14 . . (+32) . . BOTijo (Talk | contribs) ({{R from other capitalisation}})

    * (diff) (hist) . . mb Black-backed Water-Tyrant‎; 20:11 . . (+32) . . BOTijo (Talk | contribs) ({{R from other capitalisation}})

    * (diff) (hist) . . mb Bay-capped Wren-Spinetail‎; 16:49 . . (+32) . . BOTijo (Talk | contribs) ({{R from other capitalisation}})
    * (diff) (hist) . . mb Araucaria Tit-Spinetail‎;

I do watch a number of bird articles, but not these. I'm just mentioning it in case it's a symptom of a bigger problem. —JerryFriedman 19:49, 30 November 2007 (UTC)[reply]

If soembody moves a page you're watching to another name, then the new name will show up in your Watchlist. Corvus cornixtalk 19:54, 30 November 2007 (UTC)[reply]
Oh, thanks, I see what's happening. They're redirects that I created and then forgot about. Never mind. ——JerryFriedman (Talk) 21:06, 30 November 2007 (UTC)[reply]

SVG

How can I change the default size of an SVG in a gallery?

BetacommandBot

On http://en.wikipedia.org/wiki/User_talk:BetacommandBot there are several recent entries about this bot mistakenly identifying images as orphaned. What's the history of this bot, and why is it seemingly broken? - Bevo 02:45, 1 December 2007 (UTC)[reply]

yes there was a problem with the API that caused BCBot to tag some images by mistake as orphan. βcommand 03:09, 1 December 2007 (UTC)[reply]
Is there any residual effect of that mistake? Can we just disregard the notices that it put out once we affirm that they are not orphaned, and are proper to use within the articles that include them? - Bevo 03:51, 1 December 2007 (UTC)[reply]
you can ignore the notices that said the image is orphaned, but in regard to any other notices those are valid. and are proper to use within the articles that include them? cannot be judged by a bot. when ever you include a non-free image in a article make sure that you have a good rationale βcommand 03:57, 1 December 2007 (UTC)[reply]
Well, this will be a good test of whether admins deleting BCBot-tagged images actually review them, eh? =] GracenotesT § 04:15, 1 December 2007 (UTC)[reply]
all of the image tags have been reverted, from the bot errors. βcommand 04:16, 1 December 2007 (UTC)[reply]
Ah, great; thanks. WP:BOT does recommend such reversion. GracenotesT § 04:22, 1 December 2007 (UTC)[reply]
Would you mind elaborating upon exactly what problem with the API caused the malfunction? A "problem with the API" is rather nondescript, and I would like to ensure that the problem has indeed been corrected and will not repeat itself. AmiDaniel (talk) 09:32, 1 December 2007 (UTC)[reply]

C:CSD bug?

Talk:///, which was recently speedy deleted, isn't disappearing from the C:CSD list (although there, it appears as [[Talk:///.]] -- notice that it currently shows up as a valid link). Anybody know how to take care of this, or should it go to Bugzilla? Tijuana Brass 04:32, 1 December 2007 (UTC)[reply]

The job queue is moderately high at the moment: 681,030 items. Removing Talk:/// from display in CAT:CSD is probably one of those items; nothing to worry about, I don't think. GracenotesT § 04:39, 1 December 2007 (UTC)[reply]

It is a bit odd that the page listed on the category reads Talk:///. (notice the period), yet when you click it you go to Talk:/// (without a period) but [[Talk:///.]] (with period) doesn't exist either (but somehow when you click the one with the period, you are redirected to the other one). - Rjd0060 04:55, 1 December 2007 (UTC)[reply]

Actually, disregard my last comment. You're right, it's a MediaWiki bug: [[Talk:///.]] links to Talk:///. Perhaps it's a problem with subpages in the talk namespace? An admin wishing to delete the page may go here. GracenotesT § 05:01, 1 December 2007 (UTC)[reply]
I had just figured this out too. It's not just in talk that a period after a slash is removed. Seems to happen in any namespace. Gimmetrow 05:07, 1 December 2007 (UTC)[reply]
Also happens in any link ending in "/.": see User:Gracenotes/Bug. I have a feeling it's Tidy's fault. (The third theory in 30 minutes =]) GracenotesT § 05:19, 1 December 2007 (UTC)[reply]
Do you know if this is on BugZilla? - Rjd0060 05:24, 1 December 2007 (UTC)[reply]
Actually, on the test page, the source code reads:
<a href="/wiki/User:Gracenotes/." title="User:Gracenotes/.">User:Gracenotes/.</a>
So now it's a Firefox bug, it seems. O_O (now 4 theories) GracenotesT § 05:34, 1 December 2007 (UTC)[reply]
That's right. Just checked with IE and no problem. The links go to where they're supposed to be. Good catch... Rjd0060 05:37, 1 December 2007 (UTC)[reply]
Really? It looks like the behavior exists in both IE 7 and Opera as well. Despite the fact that the link's href is "/wiki/User:Gracenotes/.", it points to "/wiki/User:Gracenotes/" in all three browsers. For me, at least. GracenotesT § 05:39, 1 December 2007 (UTC)[reply]
I only tried the talk///. and talk/// links. I'm using IE6 and both links took me to the correct place, opposed to my 2.0.0.11 firefox ... - Rjd0060 05:47, 1 December 2007 (UTC)[reply]
Firefox bug or not (I'm using Camino, which uses the same engine), I'm not sure how that would explain it remaining on the actual C:CSD page. In any case, it's gone now, so... something happened. Might've just been the lag as originally suggested. Tijuana Brass 06:04, 1 December 2007 (UTC)[reply]
No, the version with the period remained in the C:CSD page because many admins clicked on it and went to the version without the period. Gimmetrow 06:21, 1 December 2007 (UTC)[reply]

If you're checking this, make sure you check the article and not just the edit window from a redlink. In Mozilla firefox:

  • [5] (works)
  • [6] (does not work as expected)
  • [7] (does not work as expected)

In fact, the latter two even preview without a period. Gimmetrow 06:17, 1 December 2007 (UTC)[reply]

Sure is odd. Like you said, the preview (the bar at the bottom of the window) does not show the period, but while hovering over it, there is a period...- Rjd0060 06:33, 1 December 2007 (UTC)[reply]
See also non-MediaWiki test page. GracenotesT § 07:11, 1 December 2007 (UTC)[reply]

Slaps head. Why didn't I think of these examples with existing pages: [8] goes to slashdot in Safari, but slash in Mozilla, [9] and [[:/.]] goes to slash in both. Gimmetrow 07:49, 1 December 2007 (UTC)[reply]

#ifexist limit

This announcement was also posted to wikitech-l, archived here.

Werdna's #ifexist limit feature is now live. In response to complaints of template breakage, I have increased the limit on Wikimedia wikis temporarily, from 100 to 2000. Barring a coup, it will stay at 2000 for about a week, and then we'll lower it to 100.

Please use this one-week period to check pages and templates that use #ifexist heavily. Look in the HTML source of the preview or page view. There will be a "limit report" that looks like this:

<!--
Pre-expand include size: 617515/2048000 bytes
Post-expand include size: 360530/2048000 bytes
Template argument size: 51168/2048000 bytes
#ifexist count: 1887/2000
-->

This is the limit report from commons:Template:Potd/2007-12, one of the pages that will break. Another example of a page that will break is this very page (WP:VPT), with a #ifexist count of 202.

At the end of the week, any pages which have a #ifexist count of over 100 will cease to be rendered correctly (after the next edit or cache clear). All #ifexist calls after the hundredth will be treated as if the target does not exist.

In some cases it may be possible to rewrite your templates so that they still do the same thing, but with less #ifexist calls. In other cases, you will need to remove template features. Removing features is always sad, as a sofware developer I know that, but sometimes it is necessary for the good of the project. This is one of those times.

-- Tim Starling 08:13, 1 December 2007 (UTC)[reply]

Could developers draft a list of pages (e.g., as a Special page) that, when run through by Parser.php, have #ifexist calls that exceed the 100 limit? One would be very useful at this point. GracenotesT § 08:39, 1 December 2007 (UTC)[reply]
Some of these are fairly well hidden. On this page, 100 ifexists come from {{Archive list}}. Where do the rest come from? Gimmetrow 08:48, 1 December 2007 (UTC)[reply]
I'll see what I can do. -- Tim Starling 09:17, 1 December 2007 (UTC)[reply]
One of the issues here is that current template/expression processing is fully recursive. This has the effect that on #if and #switch constructions the parser fully expands all branches, and not just the relevant forks. This is one of the effects that significantly increases the number of calls being made. Unfortunately, since the recursion is part of the parser, I don't see anyway to change that from within the ParserFunctions extension, such branching logic would have to be incorporated into the Parser itself. Dragons flight 09:32, 1 December 2007 (UTC)[reply]
The new preprocessor expands only followed branches of #if and #ifeq. #switch and #ifexist will hopefully follow at some stage. So when we finish working the bugs out of it and deploy it, the #ifexist counts will drop, in certain cases. This will hopefully be in the next day or two. -- Tim Starling 10:10, 1 December 2007 (UTC)[reply]
No fair reading my mind and getting out in front.  :-) Dragons flight 21:33, 1 December 2007 (UTC)[reply]
In some fraction of the cases, #ifexist is used solely to hide redlinks. In other words, constructions like {#ifexist:foo | foo | }. This limited functionality can be implemented with a CSS class, e.g.
.hidden-redlink A.new { display: none; }
Which would remove any redlinks appearing within a hidden-redlink class from being shown to the visitor. In other words, the functionally equivalent code would be <span class="hidden-redlink">foo</span>. Computationally this isn't a huge improvement over using ifexist, but there is caching for link processing and there isn't any caching for ifexist processing. So, I am proposing we add the above class to Mediawiki:Common.css. Of course, it doesn't help with the many more complex ifexist constructions that are also used. Dragons flight 22:00, 1 December 2007 (UTC)[reply]
PS. The same construction can also be used to hide missing images since a missing image is simply another redlink. Dragons flight 22:11, 1 December 2007 (UTC)[reply]
That is just HiddenStructure all over again. It won't hide links for everyone, particularly Google caches and it will break the transfer of wikimarkup into other wikis that don't have that CSS class enabled. The problems with HiddenStructure, along with the server resources used by templates like {{qif}}, were the exact reason why parser functions were created. Graham87 03:56, 2 December 2007 (UTC)[reply]
Is it enough to just hide the links? Or would you want to hide the separators as well? -- Tim Starling 07:09, 2 December 2007 (UTC)[reply]

A request was made at Template:Archive list to reduce the # of calls from 101 to 10 in light of this discussion. Should that wait until the week's over or should it be done now? SkierRMH (talk) 23:57, 1 December 2007 (UTC)[reply]

The point of the week is to make changes now, before the limit is fully implemented and breaks everything. Dragons flight 00:03, 2 December 2007 (UTC)[reply]

Suggestion: how about adding something to the site notice, so that when templates do break, there is a centralized reporting page for registered users and IPs alike? GracenotesT § 02:22, 2 December 2007 (UTC)[reply]

It should go in the watchlist notice, if anywhere. Readers don't need to know about these problems, editors do. --MZMcBride 02:37, 2 December 2007 (UTC)[reply]
Readers will know about the problem if they see an article messed up from too many #ifexist calls. And they will report the problem to many places: here, other village pumps, the help desk, Talk:Main Page, to the article's talk page, in the article itself, and a host of other decentralized places. If the site notice says "Due to a recent software change, articles may not be formatted correctly. Please report problems to Wikipedia:Insert relevant title", this bug becomes shallow, fast. I do not suspect that many pages in mainspace will be affected, though. GracenotesT § 02:55, 2 December 2007 (UTC)[reply]
On second thought, the above wording is somewhat vague. But something like this seems like a good idea – at least to me :) GracenotesT § 03:00, 2 December 2007 (UTC)[reply]
Actually, the Watchlist notice should possibly be written now to encourage people to reduce the use of #ifexist before things break. Dragons flight 03:05, 2 December 2007 (UTC)[reply]
Good idea – here's the notice page. GracenotesT § 03:16, 2 December 2007 (UTC)[reply]

A list of pages with a #ifexist count over 100 is here. Pages are added on parse, and there's no duplicate filtering, so it might get big in a day or two. Pages with a #ifexist count over 2000 are already broken. -- Tim Starling 05:07, 2 December 2007 (UTC)[reply]

OK, so I see one source of problems is {{archive box}} and {{archive box collapsible}}, which use {{archive list}} and {{archive list long}}. However, these are inside an if, and above it's claimed that soon if branches will not be expanded unless followed. So does this need to be fixed? If so, what's the best approach: fork the template into auto and non-auto, or disable the auto feature entirely, or something else? Gimmetrow 05:32, 2 December 2007 (UTC)[reply]
Another source is {{TemplatePAGENAME}}, which is used in the complex system of {{precision1}} and {{coord}}. These will break articles. Gimmetrow 06:11, 2 December 2007 (UTC)[reply]

I've disabled {{Backlognav}}. This is unfortunate, since it was a useful system, but it's loaded with #ifexist calls =[ GracenotesT § 05:38, 2 December 2007 (UTC)[reply]

Any news on the status of the preprocessor update mentioned above? I'm trying to beat down the number of #ifexist calls on WP:LOCE/R, and I don't think it's going to be possible without this update. Happymelon 15:00, 3 December 2007 (UTC)[reply]

To be fixed

Is it Secure?

I'm wanting to place a code on the Monobook, but I'm wanting to double check to see if it's secure and safe and won't compromise my account first. SKYNET X1000 10:08, 1 December 2007 (UTC)[reply]

Which script in particular? Can you provide a link to the page where it is hosted? MER-C 11:54, 1 December 2007 (UTC)[reply]

In response to your question [10] this is the link to the script page

Yes, it's fine. MER-C 12:33, 1 December 2007 (UTC)[reply]

Message received and understood, thanks for confirming that it's safe to use. SKYNET X1000 13:01, 1 December 2007 (UTC)[reply]

Donation counter

So when I alternatively click on "show more" "hide this" on the donation counter, the two views give me numbers of donators that differ by the thousands. Anyone know why? Someguy1221 11:48, 1 December 2007 (UTC)[reply]

32,117 (expanded version) as opposed to 35,088 (small version). Some difference. :-) Stwalkerster talk 00:05, 2 December 2007 (UTC)[reply]
Each number is generated by different processes at different intervals, and they are cached (both server-side and client-side) differently. It's not unusual for there to be a discrepancy. AmiDaniel (talk) 06:17, 2 December 2007 (UTC)[reply]

Policy protection based on {{policy}}

There's a discussion at the policy pump about making it standard to protect policy pages. Since all pages that are recognised as policy are tagged with {{policy}}, I was wondering if there is a type of protection that automatically protects all pages on which {{policy}} is transcluded. --Porcupine (prickle me! · contribs · status) 17:19, 1 December 2007 (UTC)[reply]

That would be the opposite of cascading protection, but such a mechanism does not exist. EdokterTalk 18:23, 1 December 2007 (UTC)[reply]
It would be permission escalation:
  1. Admin A transclude protects {{policy}}
  2. User B transcludes {{policy}} on page C
  3. User B just protected page C
Prodego talk 22:55, 1 December 2007 (UTC)[reply]
This wouldn't be feasible unless you couldn't transclude a transclude-protected template unless you had permission protections. Otherwise, we'd start seeing vandals replace pages with "{{PAGENAME}} is gay. {{policy}}" so that only admins could revert. —Cryptic 23:13, 1 December 2007 (UTC)[reply]
Considering that there are something like 40 to 50 policy pages, an automated solution doesn't seem necessary. -- John Broughton (♫♫) 20:17, 4 December 2007 (UTC)[reply]

Pages never finish loading

Pages are not completely loading. Status is "Waiting for upload.wikimedia.org". -- SEWilco 03:40, 2 December 2007 (UTC)[reply]

Can you be more specific? - Rjd0060 05:03, 2 December 2007 (UTC)[reply]
It was happening at that time but stopped. IRC opinion is "lag". -- SEWilco 05:21, 2 December 2007 (UTC)[reply]

This is a common problem, I've been having the same experience, with my browser when pages aren't loading, however most of the times pages don't load at all. This is happening with both of my browsers Mozilla and the standard IE 7, most of the times i have to reload the entire browser SKYNET X1000 14:40, 2 December 2007 (UTC)[reply]

What would it take to change the master default search setting?

(I.e., change the program so that the main namespace and portal namespace are the defaults for new users who haven't used "my preferences").

What would be entailed in physically changing the master default search setting, to include both the main namespace and the portal namespace?

Is it just a setting that an admin could change? Or would it require a developer to modify the program?

I'd like to know the logistics of this before submitting a proposal for discussion to change the master default search settings.

The Transhumanist 05:28, 2 December 2007 (UTC)[reply]

It is a simple change that would need to be done by a sytems admin. Before requesting such a change, you will need to demonstrate that there is consensus for such a change here on the English Wikipedia, which I frankly doubt you will be able to obtain. AmiDaniel (talk) 06:15, 2 December 2007 (UTC)[reply]
This sort of thing is a routine change for a shell-access developer; however, they won't make it unless you get consensus first. --ais523 12:11, 2 December 2007 (UTC)
Which is the purpose of submitting a proposal for discussion. Thank you. See ya at WP:VPR.  ;-) The Transhumanist 12:55, 2 December 2007 (UTC)[reply]

Minor edits except for new articles option.

I'd like an option in preferences to default mark my edits as "minor" except for new article creation (which would default to not being marked as minor). I would particularly like to have this on Wiktionary, but am requesting it here because this is where it will get read. Cheers! bd2412 T 06:37, 2 December 2007 (UTC)[reply]

Try this user script:

addOnloadHook(function() {
    var form = document.getElementById("editform");
    if (!form)
        return;
    if (wgArticleId > 0)
        form["wpMinoredit"].checked = true;
})

(Not the same thing as a user preference, I know, but that's what scripts are here for =]) GracenotesT § 06:43, 2 December 2007 (UTC)[reply]

An article I am working on, Riverina, is a featured article candidate. One of the reviewers has noted a problem with the edit link in one section appearing in the middle of a paragraph. He suggests it may be his browser or OS. I have the same problem. I use Firefox and XP. Is there anything I can do to fix this? Cheers, Mattinbgn\talk 07:40, 2 December 2007 (UTC)[reply]

See WP:BUNCH for how to fix this.-gadfium 08:09, 2 December 2007 (UTC)[reply]

Master search default setting

Are there specific reasons why the search box doesn't include portal space in searches by default?

The Transhumanist 14:44, 2 December 2007 (UTC)[reply]

Sure is. Go to your Preferences and click on the Search tab. Then check/uncheck the appropriate boxes in the section titled Search in these namespaces by default:. When you are done, click Save, and after that, don't forget to bypass your cache for the settings to take effect. - Rjd0060 15:16, 2 December 2007 (UTC)[reply]
Sorry. Guess I read your question wrong. You probably already know how to change the search options. - Rjd0060 18:41, 2 December 2007 (UTC)[reply]

There's something wrong with LOL (^^,) page. (I use Firefox on Windows XP; I didn't check other OSs and browsers yet.) --­ 19:37, 2 December 2007 (UTC)[reply]

It looks OK to me. If you're wondering about the difference between the title bar and the article title displayed at the top of the page, this is because the title shown at the top of the page (but not the title bar) needs to be able to be copied and pasted to form a valid wiki link. For example, the link LOL (^^,) works but not [[LOL <(^^,)>]]. Tra (Talk) 21:02, 2 December 2007 (UTC)[reply]
I was talking about the extra title. However, User:RockMFR fixed it and it's fixed (gone) now. --­ 00:40, 3 December 2007 (UTC)[reply]

Templates broken

For a short time, some templates were broken in articles, notably {{Infobox Musical artist}}. One of the examples in the template docs is still broken (it could be fixed with a purge). What happened? Gimmetrow 06:09, 3 December 2007 (UTC)[reply]

Maybe the above discussion ##ifexist limit is relevant. -- SEWilco 06:37, 3 December 2007 (UTC)[reply]

Editing page in Nederlands

To whom ita may concern;

I can't save my page in Nederlands. I set up my page in all the portals, but I can't conclude in Nederlands. I don't know why.

I know German, but they speak another language that I can understand quite a bit, but I can't write yet, then I am asking for help here.

My search name is Luciana Bene/ Lucianabene/ Lubene, anybody has my own name in that country, there is no reason, that I can't save my information.

Please reply as soon you can.

Sincerely,

Luciana Bene info@lucianabene.com Wikipedia User Name: Lubene —Preceding unsigned comment added by Lubene (talkcontribs) 07:52, 3 December 2007 (UTC)[reply]

I guess you are Lubene there. Why do you want to save a page in a Wikipedia language you cannot write? And what do you mean by "I set up my page in all the portals" and "my information"? Does it mean you created a page about yourself in a lot of Wikipedia languages? Wikipedia is not a free web hosting service. PrimeHunter 13:13, 3 December 2007 (UTC)[reply]

Rollback for regular users

Hi all,

I've been working on resolving some lingering security issues with the rollback permission in the software, which I've now completed. Included in this is a limit on use of the rollback permission to a few times per minute (depending on server settings) just as edits are limited, and preventing any old person with the rollback permission from hiding edits from recent changes (this is now only assigned to sysops). In particular, rate limiting ensures that reverting can occur at only a slow pace (probably 1-3 per minute) by regular users (NOT admins), and thus mass-rollback by a new user is no faster than manual reversion (since manual reversion is limited to something like five edits per minute, which can be done much quicker using a tabbed browser).

Since these issues have been resolved, I've discussed with Tim Starling (the senior developer) the possibility of enabling rollback for broader classes of users, likely autoconfirmed, logged-in, or all users. Tim and a number of other developers have agreed that this is a sensible idea, and my current intention is to, by default, enable the rollback permission for all logged-in users in a few days.

I want to know what the general consensus is on this issue. I understand that it's particularly sensitive for those of you who are vandal-fighters (particularly administrators), but I believe that my improvements are sufficient to make quick reversion for vandalism a reality for those vandal-fighters who find it frustrating to be denied access to this useful tool, especially seeing as this is already possible with only two more clicks, or a javascript tool.

Werdna talk 07:54, 3 December 2007 (UTC)[reply]

The undo button is already right there, and I was using rollback with javascript well before adminship. Sounds like the features that really should be admin only (mass rollback, hiding from recent changes) are still admin only, I don't see any problem enabling it for autoconfirmed users. I wouldn't really support putting the bar any lower than that, though, very few anons or brand-new users would be making good use of the rollback button. We'll also have to likely improve education on acceptable and unacceptable uses of rollback, but I think that can be done. Seraphimblade Talk to me 08:03, 3 December 2007 (UTC)[reply]
Concur. A typical edit-warrior reverts on a limited set of pages, so throttling would be of little use in preventing him from warring. Rollback for everybody will simply introduce another kind of edit-wars: when two (or more) users revert each other in one article using this tool. Another problem to consider is that we expect admins to know when to use automatic rollback and when not. Can we we expect the same from novices? MaxSem(Han shot first!) 09:01, 3 December 2007 (UTC)[reply]
This seems scary at first glance, but it's really not any worse than giving the undo button to everyone. Further, every couple of days I see someone revert vandalism on an article with undo or a javascript tool, leaving their edit on top but vandalism in the article; this happens when there's an intervening edit to a different section of the article which gets merged instead of edit-conflicted (example: [11] [12] [13] [14] [15]). This cannot happen with rollback. —Cryptic 09:42, 3 December 2007 (UTC)[reply]
It seems like a good idea to me, for autoconfirmed users SQLQuery me! 10:41, 3 December 2007 (UTC)[reply]
As stated, this seems essentially useless - there is a proposal that is gaining some traction to allow _full_ use of rollback (no rate limits, still does the recent changes thing) for a limited class of users (would have its own permission bit) specifically trusted with this tool, such as anti-vandalism bots (e.g. Cluebot). Is there a way to do both? I.e. enable your idea for normal users, and allow a separate group, or maybe the bot group, access to the "sysop rollback" tool? —Random832 15:08, 3 December 2007 (UTC)[reply]

I've spoken to brion, and suggested the following rate limits:

  • FIVE rollbacks per TWO minutes for new users.
  • FIVE rollbacks per ONE minute for autoconfirmed users.
  • NO limit whatsoever for administrators.

Barring some significant objection that I haven't thought of before, this change will be live in a day or two, once brion's set up the limits, and given the go-ahead for me to make the change. Thanks for the input, — Werdna talk 04:43, 5 December 2007 (UTC)[reply]

There's a prod tag in February 2005, right between the 19th and 20th, and I'll be darned if I can figure out how to get rid of it. Any help? --UsaSatsui 08:35, 3 December 2007 (UTC)[reply]

Done. It was in February 20, 2005, before the title, and thus you didn't see it when you clicked the section edit link in February 2005. I removed it by editing the whole page, not just "section=1". (Take a look at the URLs in the address bar of your browser...)
BTW, should February 2005 really be in Category:Days in 2005? It's a month! Lupo 08:56, 3 December 2007 (UTC)[reply]

edit counters

Hallo, I've used this link as a link from my user page to an editcounter for ages, but today I get a "cannot display" message. What's up? And, if it's gone permanently, is there another easy-to-use editcounter? Thanks for any helpPamD 12:07, 3 December 2007 (UTC)[reply]

That link's working for me. If you only want the count and not the details, the easiest edit counter of all is Special:Preferences (although it uses a slightly different definition of 'edit'; see Wikipedia:Edit count for more information about the different types of edit count). See also Wikipedia:WikiProject edit counters, which has a list of available edit counters. --ais523 15:45, 3 December 2007 (UTC)
Thanks. It works OK for me too now, but was out of action for quite a time earlier before I posted. Just One Of Those Things, I guess! PamD 16:25, 3 December 2007 (UTC)[reply]
the toolserver might have been down. βcommand 20:26, 4 December 2007 (UTC)[reply]

protected titles

Since the system may need to be changed to transclude the pages anyway even if they exist, and this really is the necessary procedure anyway, I'd like to propose adding the following language to Mediawiki:cascadeprotectedwarning: If you are creating this page and it is a protected title, make sure you remove it from that list.Random832 15:04, 3 December 2007 (UTC)[reply]

Parser update

Any news on the parser update mentioned a way above? I understand that it will mean that unfollowed branches of #if, #ifeq, etc functions are not expanded and hence do not count towards the limits, including the new #ifexist limit. On the template network I'm working on (at WP:LOCE/R), I don't think the #ifexist count can be brought below 100 without this update. Happymelon 15:41, 3 December 2007 (UTC)[reply]

New user can't print article

A new user has said that Fetus will not print except for the first page. They claim it is possible a corrupted token, whatever that means. They have been getting a bit antsy at Talk:Fetus, and I have no idea what they are talking about (nor do I have a desire to waste paper to see if it will print over here), so I am bring up their concern here. I cannot provide any more information, but you can contact the user experiencing the problem at User talk:Icarus530. Thanks.-Andrew c [talk] 16:09, 3 December 2007 (UTC)[reply]

Looks like the issue started in this edit. The print preview cuts off in Firefox, but looks alright in IE6. I'll take a look at it later if nobody can figure it out. --- RockMFR 16:33, 3 December 2007 (UTC)[reply]
I adjusted the spacing of the images inserted in that edit, and now the print preview works on my browser. So is this fixed now?-Andrew c [talk] 17:27, 3 December 2007 (UTC)[reply]
Works for me. --- RockMFR 19:11, 3 December 2007 (UTC)[reply]

SVG images incorrectly rendered as PNGs on server

Here is a demonstration of a problem with SVG files converted to PNG by the server (which is what happens when the client browser does not support SVG):

The SVG file was orginally generated by MS Visio, but I have then edited the SVG source code to try to fix the problems. There seem to be three problems:

  • "font-size" measured in em seems to be being interpreted as being measured in points
  • "letter-spacing" seems to be ignored
  • if "fill" is omitted it seems to default to "black" instead of "none".

Can these problems be fixed? (And will other clients have problems rendering Visio's SVG?)

(Please don't tell me to upgrade my browser. 1. I can't, it's not mine. 2. I can't update the browsers of people reading my articles.) --Dr Greg 18:03, 3 December 2007 (UTC)[reply]

Incidentally, you speak of client browsers not supporting SVG - I wasn't aware there was any way to make the server serve the images as SVG even if the browser _does_ support SVG - anyone know anything about this? —Random832 18:43, 3 December 2007 (UTC)[reply]

  • I find the only way to get text to render correctly in SVGs here at WP is to convert them to outlines (i.e. so they're rendered as individual shapes) before saving. Otherwise, who knows what typeface or fontsize will actually be shown. This makes the file bigger, and less editable, but attempting to work with the allowed fonts for the server-side SVG renderer is a non-starter, in my experience. --Bob Mellish 18:53, 3 December 2007 (UTC)[reply]

As much as some people talk about SVG being a superior format, Wikipedia's support for it really isn't suitable for production use in my opinion. All too often there are significant aspects of the standard that aren't supported (such as the embeddable font specifications), or other things that don't render as expected. I'd encourage you not to bother and use PNG. Dragons flight 19:10, 3 December 2007 (UTC)[reply]

I partly agree with that. Its usage is good for some things in wikipedia, but until support (both clientside and with the serverside renderer) is improved considerably we shouldn't use too much SVG (and definitely not delete their source PNGs or do an all out replace of a "superseded" PNG [which we don't]) . Something that really annoys me for instance, is that if I thumb an SVG to something really small, it often becomes unreadable, whereas the PNG image resizing has no such issues. This is partly due to lack of anti-aliasing which causes really jagged unreadable lines at low resolution. --TheDJ (talkcontribs) 00:31, 5 December 2007 (UTC)[reply]

Monobook.js

What would this be for?

shbase = 'http://localhost:8080/wp';
shindex = 0;
shalgo = "chooser";
document.write('<scr'+'ipt src='+
'"http://localhost:8080/wp/js/ui.js"'+
' type="text/javascript">'+
'</scr'+'ipt>');

which was originally

shbase = 'http://api.semantichacker.com/wp';
shindex = 1;
shalgo = "chooser";
document.write('<scr'+'ipt src='+
'"http://api.semantichacker.com/wp/js/aui.js"'+
' type="text/javascript">'+
'</scr'+'ipt>');

Thanks. CambridgeBayWeather (Talk) 14:23, 4 December 2007 (UTC)[reply]

If you were to direct your web browser to localhost, it would load the web page hosted by the HTTP server on your computer (assuming you had one). So I think that it means that someone downloaded the files from http://api.semantichacker.com/wp and loaded them into onto the HTTP server on their own computer. --Iamunknown 23:22, 4 December 2007 (UTC)[reply]

Page creation

Is there a tool which lets you know which pages you've created. Slightly egotistical, I know, but I'm looking for something in my contributions and I can't seem to remember where I've put it. Hiding T 15:18, 4 December 2007 (UTC)[reply]

I was thinking about this very thing, but I do not believe there is a tool. There really should be though. There should be something in the Logs (Like an option "Pages created by"). - Rjd0060 17:12, 4 December 2007 (UTC)[reply]
Special:Newpages lets you select a username to filter results; the problem (I think) is that the list of new pages that it uses only goes back a month or so (that would be roughly 50,000 entries). All you need to do is convince the developers that the report should go back a year or two. -- John Broughton (♫♫) 20:05, 4 December 2007 (UTC)[reply]
Ah. Cheers John. Maybe when I'm feeling tough I'll broach it with the devs. Hiding T 20:43, 4 December 2007 (UTC)[reply]

Not likely. The recentchanges table is enormous enough, already. — Werdna talk 04:45, 5 December 2007 (UTC)[reply]

There are two tools. The first one is very slow while the second is not working. --Meno25 (talk) 21:42, 4 December 2007 (UTC)[reply]

Image problem

Whats wrong with this image? Its not displaying (gives a server 500 error). --soum talk 15:35, 4 December 2007 (UTC)[reply]

Works for me (using Safari on WinXP). DuncanHill 17:14, 4 December 2007 (UTC)[reply]
I get no problems either, Mozilla (v 2.0.0.11) / XP. Have you read the link that says "If you have problems..."? - Rjd0060 17:17, 4 December 2007 (UTC)[reply]

Note: copied from Wikipedia:Wikipedia Signpost/Newsroom/Suggestions#Talk page links now included in default signatures -- JB

Sometime this month, following a discussion on the village pump (sorry, not sure exactly which page, or date) the default for signatures was changed to include a link to the editor's talk page:

[[User:Username|Username]] ([[User talk:Username|talk]])

rather than

[[User:Username|Username]]

This follows the announcement in the November 19th newsletter that the default signature was now customisable by administrators. -- John Broughton (♫♫) 22:14, 22 November 2007 (UTC)[reply]

I think this got changed back again... Carcharoth 18:45, 3 December 2007 (UTC)[reply]
Sure has. I'd guess that complaints/confusion of new editors seeing the black "talk" link, when they signed their own user talk page, was a major factor. -- John Broughton (♫♫) 17:16, 4 December 2007 (UTC)[reply]
But MediaWiki:Signature still has a talk link. I'm using a non-raw signature with this account, though, and there isn't a talk link, so maybe something else has changed? ais523 17:35, 4 December 2007 (UTC)[reply]
It was a problem with the parser - Brion has fixed it, it should work now. Mr.Z-man 21:21, 4 December 2007 (UTC)[reply]

Hyperlinking to Wikipeida

I am the editor of Eigen's Political & Historical Quotationswhich is the largest repository of political and historical quotations in the world (almost 60,000). I would very much like to link the names of the quotees and the concepts to which they refer to Wikipedia articles. Thanks to a foundation we distribute this free and we have been live for 15 months and have downloaded over 130 million quotations to people. Ideally each one of those would have two or three hyperlinks to Wikipedia.

We are looking for a way in which we can automatically do the hyperlinking? We have about 30,000 quotees -- people. In addition we have almost an equal number of concepts such as "democracy", "France", "Presidency", "revolution", "War of the Roses" etc. My guess is that there is a Wikipedia article for over 80% of these. What I would like to do is periodically (every week or two) send the file of terms to some Wilipedia address and get back a url for each term which is the hyperlink to the article with that name or in the case of no article, a null field or other symbol. We can then build a table and any of our users who want to hyperlink will be able to do so easily.

I would appreciate any ideas. —Preceding unsigned comment added by 71.178.232.34 (talk) 23:33, 4 December 2007 (UTC)[reply]

Google for the quote with site:en.wikipedia.org (to limit it to wikipedia entries). There ought to be a way to filter out non-article matches, such as talk pages, but I haven't thought of it yet. —EncMstr 23:40, 4 December 2007 (UTC)[reply]
One way to filter them out approximately is something like [16] athough it won't filter out all non-article pages and will filter out some pages that are articles but it's OK most of the time. Tra (Talk) 23:47, 4 December 2007 (UTC)[reply]
From m:Data Dumps you can get to the enwiki downloads (updates about monthly). The file "page.sql.gz" is a backup of the "page" table, which will provide a record of all titles for which Wikipedia articles exist (requires a SQL database to load it). Using that you should be able to construct standard links of the form http://en.wikipedia.org/wiki/<PAGETITLE>. Dragons flight (talk) 00:06, 5 December 2007 (UTC)[reply]

Fisterra city seal

I have tried to incorporate the seal for the city of Fisterra found here in the Fisterra article on English Wikipedia, but my clumsiness has so far prevented me. Can anyone help me put the city seal where it should be?--Filll (talk) 01:37, 5 December 2007 (UTC)[reply]

.spoiler ID in MediaWiki:Common.css

Does the MediaWiki:Common.css file control how everyone views the site, people who are signed in and people not signed in? The {{spoiler}} template was recently deleted. If the spoiler template came back, I have a hypothetical question about the MediaWiki:Common.css file. Would the following code hide the spoiler template from all readers or registerd users?

#spoiler {
    border-top: 2px solid #ddd;
    border-bottom: 2px solid #ddd;
    display: none
}

If a user wished to display the contents of the spoiler template when viewing a page, would pasting this code in their monobook.css or common.css do that?

.spoiler {
    border-top: 2px solid #ddd;
    border-bottom: 2px solid #ddd;
}

Thank you in advance for any input. --Pixelface (talk) 03:03, 5 December 2007 (UTC)[reply]

  1. Everyone.
  2. No, but this would:

<source lang="css".spoiler { display: block; }</source>

~~~~