Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Sniggity (talk | contribs)
No edit summary
Line 669: Line 669:
:: The appropriate place is [[MediaWiki:Monobook.css]]. [[User:Titoxd|Tito]][[Wikipedia:Esperanza|<span style="color:#008000;">xd</span>]]<sup>([[User_talk:Titoxd|?!?]] - [[User:Titoxd/Flcelloguy's Tool|help us]])</sup> 04:23, 23 December 2005 (UTC)
:: The appropriate place is [[MediaWiki:Monobook.css]]. [[User:Titoxd|Tito]][[Wikipedia:Esperanza|<span style="color:#008000;">xd</span>]]<sup>([[User_talk:Titoxd|?!?]] - [[User:Titoxd/Flcelloguy's Tool|help us]])</sup> 04:23, 23 December 2005 (UTC)


I've gotten fed up with the ugly popup box and have taken things into my own hands. Insert this code into your Monobook.css and the fundraiser notice will be waaay less intrusive (but still there).

<pre>div#siteNotice {float:none;border:0;background:inherit;margin:0;}
div#siteNotice * {display:inline;font-size:8pt;}
div#siteNotice img {display:none;}</pre> &mdash; <span style="font-variant:small-caps;font-family:sans-serif;">[[User:Ambush Commander|Ambush Commander]]</span><sup style="font-family:serif;">([[User talk:Ambush Commander|Talk]])</sup> 22:11, 23 December 2005 (UTC)


== vandal edit summaries violating privacy policy ==
== vandal edit summaries violating privacy policy ==
Line 759: Line 754:


My main concern is that this technique, which uses dozens of very small images, will cause the image server to explode. If this process can be used, I'm also wondering if there is anyway to make it easier. The very small map at [[Wellington Street]] took many hours of work. - [[User:SimonP|SimonP]] 20:49, 23 December 2005 (UTC)
My main concern is that this technique, which uses dozens of very small images, will cause the image server to explode. If this process can be used, I'm also wondering if there is anyway to make it easier. The very small map at [[Wellington Street]] took many hours of work. - [[User:SimonP|SimonP]] 20:49, 23 December 2005 (UTC)

:This is the absolute antithesis of everything HTML is about. {{tl|click}}, in my opinion, is just a horrible hack. Developer's help needed: what are the security implications of HTML image maps? &mdash; <span style="font-variant:small-caps;font-family:sans-serif;">[[User:Ambush Commander|Ambush Commander]]</span><sup style="font-family:serif;">([[User talk:Ambush Commander|Talk]])</sup> 22:14, 23 December 2005 (UTC)


== How do you turn on Uploading? ==
== How do you turn on Uploading? ==
Line 772: Line 765:


[[User:Sniggity|Sniggity]] 21:45, 23 December 2005 (UTC)
[[User:Sniggity|Sniggity]] 21:45, 23 December 2005 (UTC)
:that looks right to me. Does the upload link show and if so what happens when you try and use it? [[User:Plugwash|Plugwash]] 22:43, 23 December 2005 (UTC)

:Those settings should enable uploading. You have ImageMagick installed, correct? And, it would be helpful if you told us what the error message is, as well as your version of MediaWiki. &mdash; <span style="font-variant:small-caps;font-family:sans-serif;">[[User:Ambush Commander|Ambush Commander]]</span><sup style="font-family:serif;">([[User talk:Ambush Commander|Talk]])</sup> 22:12, 23 December 2005 (UTC)

<br><br>I don't think I have it installed, at least I didn't install it. Where would I get it, and how/where would I install it if you don't mind me asking? I'm brand new at this as you can probably tell. lol Also, the only thing is tells me is "''Sorry, Uploading is Disabled''" when one tries to add a picture to my site. The site is www.wikibands.org if you'd like to try it out. There is still a lot of work that needs to be done, but it's hard doing it all alone. Thanks very much ! One more thing, I am using the most recent version of Wikimedia.
[[User:Sniggity|Sniggity]] 22:41, 23 December 2005 (UTC)

Revision as of 22:43, 23 December 2005

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues. Bugs and feature requests should be made at BugZilla since there is no guarantee developers will read this page.

FAQ: Intermittent database lags can make new articles take some minutes to appear, and cause the watchlist, contributions, and page history/old views sometimes not show the very latest changes. This is an ongoing issue we are working on.

Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).

Please add new topics at the bottom of the page.

Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

I noticed that on the page you get after successfully moving a page, you get a link to check if anything links to the old name of the article, but this link instead points to the "Whatlinkshere" for the new name of the article. Shouldn't it point to the old name, instead? --Spring Rubber 01:09, 12 December 2005 (UTC)[reply]

The short answer is no. The point is to fix any double redirects (redirects to redirects) caused by the move, not every direct link to the old name. From "Whatlinkshere" for the new name, you can see which links are redirects (including the old name), and whether any redirects links to that name. Double redirects are a problem because the software only follows redirects "1-deep". If you click on a redirect, and it sends you to another redirect, you end up on the second redirect (not where it, in turn, redirects). -- Rick Block (talk) 02:33, 12 December 2005 (UTC)[reply]
Okay, I understand now. I never realized there was a "tree" system to indicate redirects before. Thanks for the help. --Spring Rubber 02:52, 12 December 2005 (UTC)[reply]
Incidentally, why don't redirects send you straight to the final article at the end of the redirect chain? This has been broken so long I can only imagine there must be some reasonable explanation. Deco 04:34, 15 December 2005 (UTC)[reply]
There isn't necessarily an end (redirects might loop), but arbitrarily cutting off the number of redirects that are traversed at a number a little larger than 1 seems reasonable to me. Do you know how to use bugzilla? -- Rick Block (talk) 05:01, 15 December 2005 (UTC)[reply]
Yes yes, I'm just lazy. :-) Circular redirects really aren't a problem, as it's trivial to detect these. I searched now and couldn't find anything. There seems to be a running assumption that this is just the wrong thing to do, but I can't figure out why. Perhaps because it would necessitate database operations that are inefficient in the current relational schema. Perhaps I'll enter a bug and see how it gets resolved. Deco 05:14, 15 December 2005 (UTC)[reply]
I think it comes down to, if the limit is 1, a whole class of problems just disappears. If you increase the limit, you need to check for loops, database strain, define a "reasonable" limit, and presumably people will be less encouraged to ever fix the double redirects. Stevage 03:20, 18 December 2005 (UTC)[reply]

Complaints of spam

Ernie has e-mailed the Wikimedia Help Mail list complaining of spam coming from Wikipedia IP addresses.

"I keep getting spam from what looks to be aol addresses, but the IP addresses are coming from you. I want this stopped, NOW. They range from 63.80.24.00 and up as well as63.80.31.00 and up. I would be glad to forward some to you. I recieve about 6 per day. AOL seems to not care, although they are probably phoney AOL accounts, I would like to forward these to you as I get them so you can shut these bastards DOWN.

I haven't heard anything about this. Is anyone else aware of such incidents?Capitalistroadster 09:51, 12 December 2005 (UTC)[reply]

I suspect that Ernie may be confused. CIDR range 63.80.24.0/21 (IP addresses 63.80.24.0 - 63.80.31.255) are, according to ARIN's whois, part of a UUNet range which UUNet have assigned to a company called Lightspeed. These IP addresses do not have anything to do with AOL, nor do they appear to have anything to do with Wikipedia. Has Ernie shown any copies of the spam he says is coming from Wikipedia, or said which specific IP addresses assoicated with Wikipedia are the problem? -- AJR | Talk 02:27, 13 December 2005 (UTC)[reply]
If they just have "wikipedia.org" in the *From: address* there's nothing we can do about it, as it has nothing to do with us. The way e-mail works, the contents of the 'From' address can be completely forged at will; they are not verified in any way at all. If he's actually got some reason to believe they're coming from our servers, please email me an example of the full headers to brion at wikimedia.org and I'll check it out. --Brion 18:52, 15 December 2005 (UTC)[reply]
You could try using SPF. It might help. --cesarb 02:54, 17 December 2005 (UTC)[reply]
SPF deals only with the envelope sender address, not the 'From:' line. --Brion 23:37, 17 December 2005 (UTC)[reply]

I've shamelessly stolen from the Dutch and Vietnamese Wikipedias to create a new template, allowing an image to link somewhere other than its image description page. More info is on the talk page.

The main place this can be used is on the Main Page sister projects template, and there is a test version at Template:WikipediaSister/temp if anyone wants to check it before it goes up. the wub "?!" 12:02, 13 December 2005 (UTC)[reply]

Sorry about that. I protected it since I was going to be bold and put it on the Main Page straight away, but decided to do a test run first just to make sure. It's unprotected for now. the wub "?!" 23:11, 13 December 2005 (UTC)[reply]
This is a great idea. The featured article pic in particular should link directly to the featured article. God knows how many users make that mistake everyday. Deco 04:30, 15 December 2005 (UTC)[reply]
See also BugZilla #539 - Allow images that link somewhere other than the image page for the feature request which would make this template hack redundant. Rob Church Talk 03:47, 18 December 2005 (UTC)[reply]

Finding out the number of users watching an article

Is there currently a way to find out how many users are watching a given page? If not, is there a bugzilla issue for this?

Thanks, nyenyec  18:52, 14 December 2005 (UTC)[reply]

No and no. Note that being able to determine how many users are watching a page might be useful information for vandals. -- Rick Block (talk) 19:07, 14 December 2005 (UTC)[reply]
Yes and yes, though not on this mediawiki. Fixed using the Enotif patch. See meta:Share watchlists for more information. here 19:09, 14 December 2005 (UTC)[reply]
Thanks, I believe it would also be useful information for fighting vandals. -- nyenyec  19:41, 14 December 2005 (UTC)[reply]
It could be both. If it existed, it would be interesting to show edits made by users to unwatched pages. Or, you could always group together low numbers of watchers to avoid giving the precise number to vandals Stevage 03:15, 18 December 2005 (UTC)[reply]
"But how many people are watching RecentChanges?" -- Beland 09:07, 19 December 2005 (UTC)[reply]

Need a dev to clear a revision on a long page

This diff contains a great deal of personal information which probably doesn't belong here - I asked on #wikipedia and they tell me the page is too long for an admin to delete the revision without freezing the database, but a dev can just wipe that one revision. Any help would be appreciated... (ESkog)(Talk) 21:38, 14 December 2005 (UTC)[reply]

That's either been done, or something's screwed up which makes the revision unviewable. Either way, I guess it's the desired result. Rob Church Talk 03:54, 18 December 2005 (UTC)[reply]

Category:Long words

Is there any way to force Category:Long words to display in one column instead of three? Melchoir 01:42, 15 December 2005 (UTC)[reply]

Nope, but it sounds like a great software suggestion. Deco 04:28, 15 December 2005 (UTC)[reply]
You might try a workaround using the category indexing function. Try forcing the longest words to the bottom with something like [[Category:Long words|z]]; the entries should alphabetize after being forced to the bottom, i.e. all in column three, which might change the column widths. I've not tried this myself, so this is a hypothesis rather than speaking from experience, and it's far away from a perfect solution. Courtland 01:16, 17 December 2005 (UTC)[reply]
I don't think that would work. Large letter sections get split over multiple columns, see Category:User warning templates's "T" section, for example. And anyway, having everything in Category:Long words categorised under "Z" would just be confusing. -- AJR | Talk 12:13, 17 December 2005 (UTC)[reply]
I was suggesting that only the longest be categorized under "Z" so that there would effectively be two alphabetical schemes, one for shorter words and one for longer -- sacrificing clarity for format. Courtland 03:11, 18 December 2005 (UTC)[reply]

Remove / increase recommended article size limit

Right now WP gives a recommendation to keep article sizes under 32kb every time you edit an article larger than that.

I know it once was a technical issue, but that is no longer so. While it is also true that large articles are better off broken into different subsections with the main article only listing summaries, still, even then 32kb is too little for good articles.

Another former reason reasonably valid 3-4 years ago when WP started was that not everyone has fast internet (many people still had 14,400 baud and 56k was considered good), but internet speed (like other computer-related measurable quantities) has increased exponentially in the last years, and now over half of internet users have cable/dsl for which downloading 100kb is nothing, and 99% of the rest have 56k which can also load a 50-100kb page reasonably fast.

About 90% of featured articles are WAY over 32kb. Except for really specific topics where one can cover it all in a smaller article (such as the recent shoe wax article), an article of 50 to 100kb is pretty much required to have enough material for featured status. Whereas before a good broad article was pretty much a collection of subpages with short summaries, the present widely accepted definition is an article which is strong and sound by itself, which can be informative on its own, and subpages would further expand on the subject for those interested in the particular subtopic, rather than being forced to go there just to understand the material of the main article.

And large article sizes are even more essential now when there is a big initiative to include lots of references and links.

You may say that its still not a big deal to have the reminder, but I'd argue that it may actually discourage editors (especially new editors) to contribute new material to an article which already contains quite a bit, but is still far off from FA.

In light of that, I propose to, either,

- Remove the warning at all, as irrelevant on both technical and editorial grounds, or

- Increase the article size reccomendation from 32kb to at least 100kb. Elvarg 04:19, 15 December 2005 (UTC)[reply]

I agree that instead of recommending any particular size, we should instead recommend that articles that grow to unwieldly lengths be broken up, where this term is subjectively determined on a per-article basis. Deco 04:26, 15 December 2005 (UTC)[reply]
I was under the impression the limit was first enforced because of a hard limit on the amount of text allowed in a editable text box in certain ld browsers. I think that that reason is now gone. I would support getting rid of the warning, and enforce common sense at the FAC stage. --Martyman-(talk) 09:30, 15 December 2005 (UTC)[reply]
Somebody mentioned the other day on the extra-long AfD that this is still an issue on handheld devices. Even there it's probably not a big problem, since you can edit individual sections (until you hit an edit conflict). Zocky 09:49, 15 December 2005 (UTC)[reply]

This is not only a problem with handheld devices, but also article style. Long articles tend to be daunting to edit and discourage further expansion. I think the 32k limit for a plain text simple article is already quite large. My suggestion is; create a new "Wikifeature" where long articles can be (like in most encyclopedias) and break up all articles longer than 40k into bits smaller than 20k. The only exception I can think of is the situation where the article is clearly too detailed already. Mozzerati 20:53, 21 December 2005 (UTC)[reply]

Note: I have warned User:Bitcyh, who claims on User talk:Bitcyh he/she is an animal at the Okinawa zoo, that he/she may be blocked soon. I am not an admin. --Unforgettableid | talk to me 06:32, 15 December 2005 (UTC)[reply]

I have blocked User:Bitych with the template {{UsernameBlock}}, a template that is also accessible to you. Sycthos 02:42, 17 December 2005 (UTC)[reply]
Scythos, I feel it would be misleading to admins etc. to put that template if I can't actually block them. --Unforgettableid | talk to me 21:21, 20 December 2005 (UTC)[reply]

Edits by browser

I would like to do research that would be required for doing an offline Wikipedia (similar to a German "Wikipedia-CD"-like project, but for frequent editors) in English. What percentage of Wikipedia edits are made by users who use browsers other than IE, Netscape, Safari and Firefox releases? Firefox betas are ok to count. (I feel my set of criteria is an okay proxy for "at least somewhat-technically-inclined users" but the information is not accessible at Wikipedia:Statistics.) --Unforgettableid | talk to me 06:32, 15 December 2005 (UTC)[reply]

Honestly. I use the betas, but in between releases and betas, I see no reason to rush off and get the nightly build. That's just a waste of time. Your criteria seems quite sketchy; I would at least include regular Firefox releases. Superm401 | Talk 04:30, 20 December 2005 (UTC)[reply]
Yes, that was a bit arbitrary, but the problem is that more and more people are using preinstalled Firefox at libraries, schools, etcetera. But that's OK, let me change the question then: what percent of our edits are made by non-IE, non-Safari users? :) --Unforgettableid | talk to me 21:20, 20 December 2005 (UTC)[reply]

Watching pages

Why can't I add comments to my watchlist to note down for myself why I marked a page to be watched? --Unforgettableid | talk to me 06:32, 15 December 2005 (UTC)[reply]

Why? Because that feature doesn't exist. If you want it, you should request it, either on the proposals page, in mediazilla, or find a friendly developer :) Stevage 03:12, 18 December 2005 (UTC)[reply]
Do others agree this would be useful? --Unforgettableid | talk to me 21:22, 20 December 2005 (UTC)[reply]
It'd be useful to me if I could use that information in displaying my watchlist. What I'd like is to be able to put tags on pages on my watchlist, like "featured", "vandal-magnet", "discussion", etc., so I can filter the watchlist by those tags (suppose I want to see only discussions where I'm waiting for a reply, or I'm in the mood to fix articles that attract vandals, or whatever). It would be like having sub-watchlists. rspeer 22:19, 20 December 2005 (UTC)[reply]
Now on MediaZilla as bug #4354. 86.133.53.111 13:24, 22 December 2005 (UTC)[reply]

Remove content warning on talk pages

The warning

Content must not violate any copyright and must be based on verifiable sources. By editing here, you agree to license your contributions under the GFDL.

Is good for article pages, but it should be removed from talk pages. Talk pages are discussion portals, not articles, and discussion should be as free as possible.

The only thing we can remove from that is verifiable sources, as discussion is supposed to be ones own opinion. Copyright violations and GFDL contributions all apply to talk pages as well however. WAvegetarian (talk) (email) (contribs) 20:17, 15 December 2005 (UTC)[reply]
Clearly we cannot allow copyright violation, as this is against the law. However, there are some who have made a reasonable case that participants in discussions should, as on newsgroups or mailing lists, retain copyright to their original statements, particularly since we hardly ever edit the comments of others. I like it like it is though. Deco 20:43, 15 December 2005 (UTC)[reply]
You retain copyright on any talk page comments you make; you just implicitly agree to license them under the GFDL whenever you post to a Wikipedia talk page. AFAIK, this is non-negotiable. A user who wanted to not license his talk page comments in this way (User:Pioneer-12, I believe) has been banned indefinitely for disagreeing with this policy. android79 21:06, 15 December 2005 (UTC)[reply]
Well, then at least remove the references part on talk pages. Elvarg 21:22, 15 December 2005 (UTC)[reply]
I think the references part should remain as well. Talk pages are for discussing the article, and so all statements should be based on verifiable sources. Even on the talk page we should be saying "I think we should do X because Y", not "I think X". I do not think we shoukd seek to encourage people to post unverified statements to the talk pages, as they could then become a repository of false information which google can pick up and disseminate further. Wikipedia is not a discussion portal and talk pages are not for general discussion, and there should be an onus on us to source our opinions. Steve block talk 13:27, 16 December 2005 (UTC)[reply]
I'd put this differently. On talk pages, people should be clear when they are using unverified sources. For example "I think remember he was the first to land on the moon.. does anyone have a reference for that" hardly needs to be verified. Mozzerati 20:57, 21 December 2005 (UTC)[reply]

From the Wikimedia Help Desk:

When i try to view the article on 'globalization' on Firefox (ver 1.5), i get a bad layout in my browser where the containers 'Content' and 'Trade Series' overlap. Vik Nuckchady

WAvegetarian (talk) (email) (contribs) 01:40, 16 December 2005 (UTC)[reply]

Using the same version of firefox, I don't see any actual overlaps, either in the Classic or Monobook skins. The article does feature rather an unfortunate number of floaty boxes which pile up horizontally in an ugly manner (something that also happens in IE and Opera). -- Finlay McWalter | Talk 01:47, 16 December 2005 (UTC)[reply]
If it's the pileup that is the problem, it's easy to fix with {{clearright}}. Fixed. --cesarb 02:50, 17 December 2005 (UTC)[reply]

CSS errors

Results from attempting to validate http://en.wikipedia.org/wiki/Main_Page with the W3C CSS validator

--Dfeuer 09:46, 16 December 2005 (UTC)[reply]

Please see my comment here which suggests fixes to the two errors I was having at the time. There's yet another error now coming from a line-height with the invalid value auto, which I suspect should be inherit instead. I already made the change, failing to notice the (very clear) warning at the top, and reverted it; but if there are no objections, I would really like to reapply the change. HorsePunchKid 2005-12-17 03:42:11Z
Won't get any objections from me!
--Dfeuer 07:49, 19 December 2005 (UTC)[reply]

List is somewhat broken

A lot of the examples in Help:List does not work. For example:

#list item A1
##list item B1
##list item B2
:continuing list item A1
#list item A2
  1. list item A1
    1. list item B1
    2. list item B2
continuing list item A1
  1. list item A2

AzaToth 09:51, 16 December 2005 (UTC)[reply]

Yes, as stated above, you need an extra #. See example:

#list item A1
##list item B1
##list item B2
#:continuing list item A1
#list item A2
  1. list item A1
    1. list item B1
    2. list item B2
    continuing list item A1
  2. list item A2

Image upload licensing line broken for IE

If you try to upload an image with IE, the handy-dandy licensing template button doesn't work - or more to the point, only the top three lines can be selected (no license, unknown licence, "image found"). Any useful templates you have to enter by hand. Can this bug be fixed, please? Grutness...wha? 12:33, 16 December 2005 (UTC)[reply]

No repro for me with IE 6.0.3790.1830 on Windows Server 2003 SP1 Standard. Deco 02:13, 17 December 2005 (UTC)[reply]

Well it's no go with 5.2 on Mac OS 10.2. Grutness...wha? 23:05, 17 December 2005 (UTC)[reply]

Please file it as a bug report on BugZilla if it's a reproducible bug, and provide clear information on the conditions under which it occurs, and steps for reproducing, if possible. Thanks. Rob Church Talk 04:00, 18 December 2005 (UTC)[reply]
Thanks - now listed as Bug no. 4313. Grutness...wha? 06:11, 19 December 2005 (UTC)[reply]
Whoops; the bug it's duped to is one I was aware of. Getting forgetful in my old age. ;-) 86.133.53.111 13:26, 22 December 2005 (UTC)[reply]

Stabilisation of articles for general release

It seems to me the strength of the wikipedia is the editors. Particularly the well established editors with many good edits.

The other strength of the wikipedia is the users (these are people who aren't logged in). These make the wikipedia useful, and attract new editors to the wiki. These users need to see well established article versions, that have had a chance to be viewed and corrected by editors, and repaired as appropriate.

The main problem we have is low-edit editors. These users tend to 'test edit'/vandalise the wikipedia and this appears immediately to the users; but many of them also do good edits.

We need a mechanism for stopping the edits from low-edit editors from immediately appearing to the users.

My suggestion is an ad-hoc review process in keeping with the current 'esprit d'wikipedia'

I think that the wikipedia should follow the following rules:

An 'immature editor' is defined as any editor that has made less than 200 edits. A mature editor has made 200 or more.

No raw edit from an immature editor will be displayed to a non logged-in wikipedia user within less than 1 day. (Exception: users at the same IP address will have the article displayed immediately to avoid confusion after edits).

Modification within a day by another immature user resets the counter, and the article will only time out after another day The article displayed will be the newest article that has not been edited for a whole day, or has been edited by a mature user, or has been edited by the same IP address as the viewer. This rule can theoretically mean that a new edit never becomes visible, but in practice this will rarely happen, and the next rule helps avoid it anyway.

Modification of the article by a mature user makes the article immediately visible. This can make immature users edits visible- clearly the mature users are supposed to check to make sure that any previous edits are appropriate... the wiki software could help by pointing out if there had been recent changes...

Any mature editor caught making inappropriate edits has their account locked out. They have to start from scratch, this means that at most 0.5% of editors edits are bogus, even if an editor is a rogue.

Ok, my view is that these rules are not absolutely perfect, there's probably no such thing as perfect rules, but they are enormously better than what we have at the moment.

Comments? — Preceding unsigned comment added by Wolfkeeper (talkcontribs) 2005-12-16 22:32:16 (UTC)

An m:Article validation feature is being actively worked on and will apparently be available in trial form in the not too distant future. I suspect similar ideas (like yours) will not be acted on until after this trial. -- Rick Block (talk) 04:40, 17 December 2005 (UTC)[reply]
I question the need for validation of articles. I claim that rejection of bad article revisions is far more important and normally does not require experts. The mechanisms proposed are a superset of what I propose, and the other features seem difficult to implement and at best of debateable value. A more general attempt at a solution is often not better since it is harder to use and harder to implement. WolfKeeper 05:02, 17 December 2005 (UTC)[reply]
I think requiring even the edits of mature editors to be reviewed is a good idea. We may not be vandals, but we still make mistakes. Probably the simplest scheme imaginable is that no new version would become visible until at least k other editors had approved it, with a user preference to view either the newest or most recent approved version. Deco 06:20, 17 December 2005 (UTC)[reply]
The wikipedia has done pretty well so far, without such mechanisms. It would be premature to add such mechanisms, my contention is that there may be better ways to do similar things without heavyweight voting. I also disagree with the political aspects such voting can introduce, it can introduce horse trading on articles and such like. Also groups of users can conspire to push through edits arbitrarily anyway. But that isn't at all the point of my proposal anyway. It is only an antivandalism mechanism, not a validation mechanism.WolfKeeper 06:33, 17 December 2005 (UTC)[reply]
200 edits would be a very high bar. I don't think I would have made it to 200 knowing that none of my edits were going to be public for a day. 10 edits would be plenty. But yeah, there are other proposals that go into a bit more detail than this. Stevage 03:08, 18 December 2005 (UTC)[reply]
10 is much too small. Any vandal can do 10 edits typing with their nose. 50-200 should be workable. WolfKeeper 03:21, 18 December 2005 (UTC)[reply]
Any determined vandal can. But it would block the majority of vandals, including the "does this really work?" and "Johnny is gay" types. Nothing can stop a truly determined vandal.
I think 10 is too small; IMO there are too many vandals that are more determined than that. But it's irrelevant really, such a number is extremely easy to change up or down if the scheme has been implemented. My point is not that 24 hours and 50 or 100 edits are critical to the scheme working; my point is that the general scheme is lightweight from the users point of view whilst giving good protection to the wikipedia against vandalism.WolfKeeper 11:48, 19 December 2005 (UTC)[reply]

Fundraiser's progress bar is wrong

The Fundraiser's objective is something around 500'000$ - the green line suggests 100'000$. The reasoning: there are 10 little grey vertical lines, 20'000$ has been raised until now which is 2 grey lines, that means that 10*10'000=100'000$ is the goal. This is wrong. Please, correct it. I will try to contact User:Brion for this, but anyone with the correct permission, please do something. Thx, Msoos 22:26, 17 December 2005 (UTC)[reply]

Seems like its not a bug (according to Brion), but is like that on purpose. I do not see the idea behind it, but if others agreed, than let it be! Msoos 22:32, 17 December 2005 (UTC)[reply]
There actually isn't a formal target amount for this fundraiser, which makes it a little confusing. In further tweaks to the bar, the scale has been upped to show a $500k scale by default though. The small ticks are at $25k intervals, with larger milestone ticks every $100k. --Brion 23:35, 17 December 2005 (UTC)[reply]

Exteded syntax

Because if the reecent war against/for the usage of logical templates, I made a simpple extended syntax that could be used, the code is located at m:User:AzaToth/Logic, and if incoorperated into wikipedia it could make a lot of people happy AzaToth 23:45, 17 December 2005 (UTC)[reply]

These do not work for me. I have date preferences set to yyyy-mm-dd. Looking at the HTML "view source" I see the link is to

<td><b><a href="#10_December_2005_.28Saturday.29" title="">11</a></b></td>

where the date is in dd_monthname_2005 format.

At the destination end, I see

<p><a name="2005-12-10_.28Saturday.29"></a></p>

where the date is in yyyy-mm-dd format.

Thus the link doesn't work. -- SGBailey 00:02, 18 December 2005 (UTC)[reply]

Linking to headers with wikified dates is simply not a good idea. I've made an experimental fix, adding an explicit anchor defined with an id attribute attached to blank lines before each header. I'll bring this up at Talk:Current events. -- Rick Block (talk) 02:04, 18 December 2005 (UTC)[reply]

Multicolumn lists

Value#Personal and cultural values has a long list of values which would be well-served by a multicolumn display. Is there a nice way to get the list to wrap, say by 3 or 4 columns?

Thank you, --Ancheta Wis 00:19, 18 December 2005 (UTC)[reply]

One way to do this is using a table - I arranged the entries in three columns. Please take a look to see how it was done. -- Rick Block (talk) 01:24, 18 December 2005 (UTC)[reply]
Yep, use {{col-begin}},... {{col-break}}..{{col-break}}..{{col-end}}. Stevage 03:05, 18 December 2005 (UTC)[reply]
I brought in a couple of templates from Wiktionary a while ago that do this. Take a look at {{Top4}}, {{Mid4}} and {{Bottom}}; the page Template talk:Mid4 presents information on their origin and how to use them. Courtland 03:16, 18 December 2005 (UTC)[reply]
Thank you all. --Ancheta Wis 10:39, 19 December 2005 (UTC)[reply]

It seems that while external links to IRC servers (e.g. - [1]) and FTP servers (e.g. - [2]) link correctly, links to telnet servers (e.g. - [3]) do not get handled properly. I'd like to think this is a simple thing to fix, hence my posting it here. Comments? —Locke Cole 12:13, 18 December 2005 (UTC)[reply]

telnet is an obsolete protocol, and should not be encouraged to be used, there shouldn't be any links to telnet-servers from wikipedia at all AzaToth 13:33, 18 December 2005 (UTC)[reply]
IRC and FTP are obsolete as well, so the "it's obsolete" argument doesn't really hold a whole lot of weight for me. As for links to telnet servers, while they continue to disappear, there are still bulletin boards (for example) that operate on the internet that may be worth linking to. —Locke Cole 13:51, 18 December 2005 (UTC)[reply]
So we shouldn't be linking to servers that only support HTTP/1.0 either? How is whether or not the protocol is considered deprecated at all relevant to anything? (and AFAIK IRC at least hasn't been deprecated by anything) —Ævar Arnfjörð Bjarmason 14:03, 18 December 2005 (UTC)[reply]
Some might argue that IM has largely replaced IRC (especially where the IM protocol supports having groups of people together ala an IRC channel). But that's really besides the point and not something I want to debate: whether or not it's obsolete is irrelevant. Afterall, I note that the old gopher protocol is supported: [4]. So can something be done for poor old telnet? :P —Locke Cole 14:15, 18 December 2005 (UTC)[reply]
Define obsolete... Telnet is still is use, remote Linux shells, finantial institutions MUD games etc still use them, as well as remote administration of routers, printers and what not. Now granted there are no longer a huge number of public telnet services available, but still. It's usefull if you want to provide a direct link to for example a MUD like telnet://discworld.imaginary.com or whatnot...--Sherool (talk) 14:43, 18 December 2005 (UTC)[reply]
Yeah, in my case I was specifically thinking of MUD servers that are open to the public. And like I mention above, for whatever reason, the Gopher protocol is still supported. So telnet seems like a given. :P —Locke Cole 06:18, 21 December 2005 (UTC)[reply]

Since this won't hurt anything (it's not like people are using telnet:// for anything else) and it might be useful I've gone ahead and enabled it in MediaWiki. —Ævar Arnfjörð Bjarmason 06:29, 21 December 2005 (UTC)[reply]

Google Web Accelerator causing problems?

I recently gave UrineForGas (talk · contribs) a {{usernameblock}} and managed to inadvertently block several other users.

It seems that they are using Google Web Accelerator and this seems to be acting as a IP proxy. As our article says it seems to cause administrative websites such as ours problems.

IP addresses mentioned are 64.233.173.85 and 72.14.194.19 -- both belong to Google web accelerator. See http://ws.arin.net/cgi-bin/whois.pl

Do we have a policy of blocking proxies on site because they cause problems with IP addresses? I know you can't edit through Babel Fish (website). Or not? — Dunc| 17:02, 18 December 2005 (UTC)[reply]

If anyone from anywhere on the Internet can use it as a proxy, even if it requires installing a specific program, it should be considered an open proxy, and indefinitely blocked. --cesarb 23:07, 18 December 2005 (UTC)[reply]
Open proxies are blocked when they allow editing, not when they simply read pages. It's very common for ISPs and countries to use read caching proxies and those are harmless. The potential for harm from the Google Web Accelerator is that it goes and loads pages which the user hasn't clicked on. It's proably insignificant at present. Jamesday 22:32, 19 December 2005 (UTC)[reply]
The official FAQ says it can be disabled for specific sites, which means it might be possible to block it with a message asking people to add wikipedia to the list. But this should probably be discussed at WP:AN first. --cesarb 23:10, 18 December 2005 (UTC)[reply]

Editboxes are slow?

Does anyone else have this problem... since a couple of weeks, the 'edit this page' function performs extremely slowly on my computer when dealing with lengthy pages - by that I specifically mean the edit box that appears. It feels like some complex function is called for each letter I type, the keyboard rate literally goes down to one letter per second! Radiant_>|< 21:53, 18 December 2005 (UTC)[reply]

I've noticed it too, I'll try to hunt it down with CVS & gprof;) —Ævar Arnfjörð Bjarmason 06:30, 21 December 2005 (UTC)[reply]

Donations may be elsewhere?

In the User: namespace, the fundraising message reads "Donations are tax-deductible in the U.S. and may be elsewhere." I guess it's funnier that way, but someone might consider changing "may be" to "maybe". Dmharvey 22:35, 18 December 2005 (UTC)[reply]

Ah yes. Someone should change my "en" to "en-0". Dmharvey 23:10, 18 December 2005 (UTC)[reply]
In any case, it changed to "Donations are tax-deductible in some countries (like the U.S.)" and quickly changed to "Donations are tax-deductible in some countries". Stevage 01:02, 19 December 2005 (UTC)[reply]

Problem with an old account?

My girlfriend created User:Southpaw some time ago but ended up never using it. Now, she wants to revive the account to upload some photos she took, but she couldn't remember the password and I had her click the "email me a new password" button. However, she never received the email, nor does she receive emails from the "email this user" link, so I suspect that she never initially supplied her email address (sigh). Is there any way for her to revive this account? Her email was <email removed> and is now <email removed>.

Thanks for any suggestions.

—Steven G. Johnson 00:00, 19 December 2005 (UTC)[reply]

I've taken out the emails (they're still available in the page history) because making it public here makes it very public across the Internet, and we don't want her to get spammed. Since there are no contributions on that account, might I recommend creating a new one? That ended up happening to me too when I came here (see User:TitoXD), and I just made another one and made sure I didn't forget the password. Titoxd(?!? - did you read this?) 00:57, 19 December 2005 (UTC)[reply]

Short Articles

Hi folks, as part of my efforts to clean up wikipedia, I've been hunting around looking for short articles that are suitable to be WP:CSD. The way I have been looking for them now is to just repeatedly click random article until I bump into something unsuitable. This is a inefficient process since I hit a lot of good articles (and a lot of 'town' articles which I think should go... but that is another issue...). I was wondering - is there a good way to browse through the shorter articles or to browse through the articles? novacatz 04:04, 19 December 2005 (UTC)[reply]

Wikipedia:Neglected articles and Special:Shortpages might help.--Sean|Black 04:24, 19 December 2005 (UTC)[reply]

Session data problems?

I'm having a lot of problems not being able to make edits due to "session data being lost". Anyone else? Stevage 14:36, 19 December 2005 (UTC)[reply]

You are not alone. I've gotten quite a few of them today. It's almost like the cookie is expiring in under one minute. Slambo (Speak) 14:47, 19 December 2005 (UTC)[reply]
Incorrect. This bug has been reported (and reproduced) in environments where the load is not as great as that on the Wikimedia farm, and the chances of it being a load issue were reduced. It remains unsolved, however... 86.133.53.111 13:31, 22 December 2005 (UTC)[reply]

Possible commiting fraud using signatures

If enabling raw signatures, and add to the signature ~~~~ and/or {{subst:template}}, then those will get expanded by the next editor, not the editor whose signature contains given strings AzaToth 16:17, 19 December 2005 (UTC)[reply]

This is something I thought of separately, although it's good to see my thoughts echoed here. It's now something we're aware of and will likely patch up soon. 86.133.53.111 18:06, 23 December 2005 (UTC)[reply]

IP Administrator?

We at the CVU have been pondering... Is it possible (and by saying possibly I mean techinically possible) to give an IP address admin privilages? The IP in question is 68.39.174.238, who does a lot of work in the CVU but won't create an account. It's a static IP - it doesn't change - but it'd be interesting to see if it would be possible for them to get admin privilages, and if the rules could be bent a bit. FireFox 21:59, 19 December 2005 (UTC)[reply]

Nope, can't be done, won't be done. --Brion 22:01, 19 December 2005 (UTC)[reply]
It is technically impossible. Rights are related to accounts and an IP address has no account to grant rights to. With apologies to the IP user, some form of account is mandatory. Jamesday 22:17, 19 December 2005 (UTC)[reply]
Added to which, an IP isn't as secure as an account. I'm not sure whether it could be spoofed, but imagine if one day the user's ISP reassigns his IP, and some random stranger suddenly has admin rights. Goodie! :) Stevage 22:18, 19 December 2005 (UTC)[reply]
I'm not sure whether it could be spoofed. Definitely: by anyone with access to any of the routers in path from the IP to wikipedia. However the same people could just steal your session cookie or password. Mozzerati 21:06, 21 December 2005 (UTC)[reply]

Trouble with Template:Ref

I have burned way too many hours trying to figure this out -- it is definitely time to ask!

I am using mediawiki, but for some reason, couldn't get Template:Ref to work using {{NAMESPACE}} or any other generic tag, therefore, I cannot use the same template across different pages.

I first employed template:ref on this page. (at [5])

The Template:ref that I tried to appropriate: <span class="reference"><sup id="ref_{{{1}}}" class="plainlinksneverexpand">[{{fullurl:{{FULLPAGENAME}}}}#endnote_{{{1}}}]</sup></span>

Would not work in any way shape or form, so I had to resort to this:

<span class="reference"><sup id="ref_{{{1}}}" class="plainlinksneverexpand">[http://wiki.uscpublicdiplomacy.com/index.php/European_Commission_Policies_and_Initiatives#endnote_{{{1}}}]</sup></span>

How can I fix this so my Template:Ref can work across different pages on the wiki and not have to make a new Template for each page?

Try: <span class="reference"><sup id="ref_{{{1}}}" class="plainlinksneverexpand">[{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}}}#endnote_{{{1}}}]</sup></span>
The fullurl stuff is probably newer than your version of mediawiki. - Lee (talk) 05:38, 20 December 2005 (UTC)[reply]

Thanks... that did it!

...messes up if invoked on a username containing spaces (since in a single-bracket URL, a space is the delimiter between URL and description, part of the ULR will be turned into the desc). Any ideas on fixing that? Radiant_>|< 03:42, 20 December 2005 (UTC)[reply]

It would appear $1 is not expected to be used in an external link. Seems like providing the username in external link format (as, say, $2) this should be a reasonably trivial fix for somebody who knows what they're doing in the source. Have you looked in bugzilla? -- Rick Block (talk) 05:16, 20 December 2005 (UTC)[reply]

Bot advice

I've seen the requests for bots on the community portal and would like to help. I'm pretty handy with Perl, which I understand isn't the ideal language for bots, but it's what I know. Are there any guides or tips out there for would-be bot coders? Or perhaps examples of bots written in Perl that I could crib from? Thanks. | Klaw ¡digame! 05:45, 20 December 2005 (UTC)[reply]

My bot uses perl, and perl only. :) The hard part is to download and install Meta:WWW::Mediawiki::Client package and its dependencies (there are around 6 of them). I can help installing it if you plan running it on Linux. That package has good documentation about how to use it.
See what others have to say also. I need to go to bed now, but we can talk more about it tomorrow. PS Despite of what people say, Perl is the language for bots! :) The python framework works very well with Wikipedia, but for actual serious text processing Python is not good enough in my opinion. Oleg Alexandrov (talk) 08:00, 20 December 2005 (UTC)[reply]
Mine is in Perl too and uses the Anura MediaWiki library which I'm the co-author of, it has some rough edges but is mostly neat-o;) —Ævar Arnfjörð Bjarmason 06:32, 21 December 2005 (UTC)[reply]

Strange diff highlighting

See this diff [5]. What is odd is that what has actually happened is that one line of text has been moved up (call it A), two lines have been moved down (B and C), and one new line of text (D) added below A's new location. However, what is highlighted in Red is the old A, and the new B and C, while the new D is just in the normal green. I would have expected at the very least for D to be highlighted, and preferably for none of the other text to be highlighted in red. Is this a bug, or just some weird side effect of the colouring algorithm? Stevage 13:06, 20 December 2005 (UTC)[reply]

as far as I can see, it's fairly standard diff / minimal change behavior. Note that the square brackets aren't highlighted. This means that that secton of text is seen as a section which has been kept but modified. The rest is seen as standard deletion and addition so isn't highlighted. It sort of makes sense if you get away from your actual knowledge that the removed and added lines are actually the same thing. Mozzerati 21:11, 21 December 2005 (UTC)[reply]

User preference to reject edits without edit summaries

Edit summaries, in revision control circles, are a very important function that help make sure we can figure out exactly what is going on when someone edited a page. Unfortunantely, even the best of us sometimes forget to add edit summaries. I would propose a user preference that would allow users to force the system to reject their edits if they did not give an edit summary. I would like that. — Ambush Commander(Talk) 21:20, 20 December 2005 (UTC)[reply]

This can easily be achieved for your own purposes with a user script. See Wikipedia:WikiProject User scripts/Scripts/Force edit summary. jnothman talk 23:46, 20 December 2005 (UTC)[reply]
Oooh, I've been looking for that for a while... Shimgray | talk | 23:49, 20 December 2005 (UTC)[reply]

Wikipedia causes browser lag?

I've noticed that large pages like Special:allmessages will lag my browser. However, other sites with large pages (for example, a message board with 100 replies per page) do not lag my browser. Perhaps there is too much HTML code on Wikipedia? Oh, and I'm using the Classic skin, if this helps. --Ixfd64 00:27, 21 December 2005 (UTC)[reply]

Most wikipedia pages are cached. The ones that aren't (like Special:allmessages) are dynamically generated based on database queries, and these will typically take somewhat longer to generate. Responsiveness is related to a number of factors, raw amount of traffic being one of the most important. Your message board site almost certainly has nowhere near the traffic of wikipedia, so even though its pages may be dynamically generated they may be able to be generated faster than wikipedia's pages. -- Rick Block (talk) 01:16, 21 December 2005 (UTC)[reply]

Characters with unusual diacritcs: how?

How do I enter characters with unusual diacritical marks, especially for transcribing Arabic? (This Wikipedia page gives codes for a variety of coding systems.) Which coding system is best to use? ISO or unicode? How does one enter Unicode? (Entering Unicode would also make it easier to enter non-Latin-based characters, such as from Arabic or Urdu.) Thanks! Kitabparast 00:51, 21 December 2005 (UTC)[reply]

Wikipedia uses UTF-8, which is a Unicode encoding. If your browser is up to it, you can just directly enter the characters in the edit box. -- Rick Block (talk) 01:08, 21 December 2005 (UTC)[reply]

New Cite extension

Following a discussion on my talk page I've written a followup to my Special:Cite extension, a specification and test page for it are avalible on my test wiki.

It basically adds sofware support for the {{ref|}} and {{note|}} hacks that are being used right now for citations, citations can be specified inline with it as <ref[ id]>Some citation text here</ref>, if you supply id you can reference it again as <ref id/>. There's no need for adding something like {{note|}} for each citation anymore because the citation section will be automatically generated on the page wherever the editors put <references/>. This improves workflow a lot because it's possible to edit an individual section adding <ref> tags in it and it'll automatically be referenced in the section where <references/> is. The output of <references/> is completely customizable through the MediaWiki namespace so editors aren't bound by what I cooked up.

I'd like to get some comments on how it works (and should work), some things that need fixing currently are to make the error output prettier (need some styling, any ideas?) and most of all, make it work with my mortal enemy, HTML Tidy. —Ævar Arnfjörð Bjarmason 01:24, 21 December 2005 (UTC)[reply]

Way frickin' cool! Someone built a telepathy machine and figured out what I was hoping for regarding footnotes! Yes, please add this into the code, exactly as you've got it specified, so I can start using it yesterday! Really, that's exactly the way I had envisioned a proper references system working, I just didn't have time to put my thoughts down into a statement more coherent than this spec. B-) Slambo (Speak) 02:20, 21 December 2005 (UTC)[reply]
I object to the abuse of XML-like syntax. It would be better to use <ref name="id">...</ref> and <ref name="id"/>. This is more similar to all other uses of XML-style tags on Wikipedia, and the use of "name" has a precedent on HTML forms (use of "id" as the attribute name would be confusing, since IDs are supposed to be used only once, while on HTML forms a "name" value is often used more than once). --cesarb 02:30, 21 December 2005 (UTC)[reply]
While I agree with CesarB's objection, I found one part of the extension a bit difficult to understand: the automatic numbering of the list doesn't correspond to the actual citations. So you clicked number "6" and you get sent to number 5. I understand that the way the system is built to handle multiple citations, this must be done, but it is confusing.
While I haven't thought about it much, I might propose keeping all reusable refs the same number. But whatever you do, I think you keep the list number matching the reference number. — Ambush Commander(Talk) 02:34, 21 December 2005 (UTC)[reply]
I was a bit unsure about how to handle that, articles like Alchemy currently use a b c d e f ... for that. That's a bit hard to handle in code though (remember that it has to handle every language out there), one way to do that would be to have a MediaWiki message with whitespace delimited tokens that should be used for that, .e.g "a b c d e f g h.." or "á a b é ..." depending on the language. Another way would be as you suggested to use the number of the actual reference, to do that properly however it couldn't use a HTML ordered list (<ol>), that's doable too, and that could easily be supported. —Ævar Arnfjörð Bjarmason 03:21, 21 December 2005 (UTC)[reply]
The convention for backlinks became a b c... simply to have symbols which are different for many backlinks. I thought it would be awkward to use numbers for both downlinks and uplinks. Maybe PHP could emit other symbols, although having them memorably sequential is helpful for tasks such as clicking on each one while checking refs. (SEWilco 04:55, 23 December 2005 (UTC))[reply]
Yup... it seems the numbers of the links aren't that important to you. Love the idea though. Absolutely awesome actually. — Ambush Commander(Talk) 02:36, 21 December 2005 (UTC)[reply]
I like the idea, but is this the 3rd or 4th footnoting system? Already putting urls in square brackets makes big numbers [6]. Then {{ref| whatever makes little numbers. There's some other system I think that forces you to number the references explicitly. And now this. I like it, but please can we kill off the other systems? Also I agree about the faux-XML syntax. It would be nice if it could conform to wiki syntax, like being <<ref id|url>> or ((ref id|url)) or something. Stevage 02:40, 21 December 2005 (UTC)[reply]
Discuss the multiple systems at the Talk page for WP:CITE. (SEWilco 04:55, 23 December 2005 (UTC))[reply]
Agree, I like the XML though, just use name instead of id. —Locke Cole 02:57, 21 December 2005 (UTC)[reply]
I chose to go with <ref[ id]> rather than <ref[ id=id] because it's quicker to type and there isn't a current need (and I can't imagine a need) for extra parameters, but even if extra parameters were to be added it would be easy to support them and the current system. Our extension paramters aren't XML anyway, not even close. —Ævar Arnfjörð Bjarmason 03:12, 21 December 2005 (UTC)[reply]
I would strongly suggest using <ref[ name=id]>. —Locke Cole 03:35, 21 December 2005 (UTC)[reply]
They aren't XML, but they are XML-style. You'd be having one style (key=value) for almost everything, and another (naked value) just for <ref>. I can also easily imagine a lot of extra parameters: class=, style=, dir=, id= (to turn it into an anchor), etc. Supporting both key and value pairs and a naked value can quickly become confusing. I also think it's better to use <ref [name="id"]> instead of <ref [id="id"]> due to the common implied semantics of the id attribute. --cesarb 03:39, 21 December 2005 (UTC)[reply]

Some valid suggestions above (I especially agree with the need for the inline-number to match up with the down-below-number, one way or another, in all cases: otherwise printed output is essentially broken, since you can't figure out which note is for what) but I'm mostly going to say this: PLEASE HURRY! THIS IS GREAT! :-) (Sorry for the shouting.) Oh -- why not dump all the notes at the bottom of the page if a <references/> tag isn't present? That would make it even friendlier to learn. —Bunchofgrapes (talk) 02:48, 21 December 2005 (UTC)[reply]

agreed. Despite it's learning curve (I figured it out in 2 minutes), it's better than what we have now. Broken S 02:53, 21 December 2005 (UTC)[reply]

There is very little in wikipedia where the code is XML-like and I'm not sure we want to encourage that. To borrow a page from Docuwiki, how about notation like ((footnote text)) and for repeated references ((name | footnote text)) with simply ((name)) being refered back to the defined footnote text. I realize such a configuration would be somewhat harder to write a parser for, but wiki code is meant to be as simple as possible on the writer, not the parser, right? Regardless an effective citation system would be a big step up for wikipedia. Dragons flight 03:20, 21 December 2005 (UTC)[reply]

Because for a parser it introduces possible ambiguity. OTOH, XML is a standard, and it should be embraced. —Locke Cole 03:31, 21 December 2005 (UTC)[reply]
Another possibility is to use a template as an interface so the template syntax is used. {{ftemplate|text}} or {{ftemplate|name=Time3|text}} could be used, with the template emitting the XML-like wrapper. (SEWilco 04:55, 23 December 2005 (UTC))[reply]

This is your brain | This is your brain on Tidy, Tidy completely messes up inline parser extensions for some reason and until that's fixed (or Tidy is disabled) it can't and will not be enabled on Wikimedia sites. I think tidy should be disabled anyway, it encourages sloppy and unportable syntax. It was disabled for a few days not so long ago and people whined to get it back;/ —Ævar Arnfjörð Bjarmason 03:26, 21 December 2005 (UTC)[reply]

I'd like to help, but I fail to see any difference between these two links. --cesarb 03:47, 21 December 2005 (UTC)[reply]
See these screenshots: without Tidy, with Tidy. —Ævar Arnfjörð Bjarmason 04:05, 21 December 2005 (UTC)[reply]
BTW, Avar, your site is consistently giving unknown page format errors on IE for me and wants me to save your content to disk rather than view it. Netscape is well behaved though. Are others getting the same response? Dragons flight 03:49, 21 December 2005 (UTC)[reply]
I think this is because the pages have no extensions, and so IE doesn't open them as html pages. I saved the spcs page to my hard disk, remnamed it to cite.html, and then (and only then) I could view it.DES (talk) 03:56, 21 December 2005 (UTC)[reply]
That's probably because he's using XHTML with the application/xhtml+xml MIME type, which older browsers do not understand. Using a more recent browser would fix the problem. --cesarb 04:02, 21 December 2005 (UTC)[reply]
Yeah, that's it, Internet Explorer doesn't support the reccomended MIME types for XHTML. —Ævar Arnfjörð Bjarmason 04:05, 21 December 2005 (UTC)[reply]
Firefox also seems to be happy (not surprisingly). My IE can't get any more current, and so as someone who does web development, I am a little surprised you'd rely on a format not supported by 80+% of the web browsing audience. Dragons flight 04:13, 21 December 2005 (UTC)[reply]
He's probably relying on the application/xhtml+xml MIME type because it forces the browser into a strict mode, where even the smallest misclosed tag will cause the whole page to fail to render with an ugly error message. Since it's a test site for his changes to the MediaWiki codebase, being more strict is useful. --cesarb 13:03, 21 December 2005 (UTC)[reply]
Exactly, keeps the code I write error free in that area. —Ævar Arnfjörð Bjarmason 13:59, 21 December 2005 (UTC)[reply]
If the files have an HTML or an XHTML extension IE will open them. I'm not sure if it then obeys the strict mode or not, but I presume that the browsers which do support this MIME type will still support it even if the extension is present. DES (talk) 22:32, 21 December 2005 (UTC)[reply]
Browsers do not use the file extension, unless the file comes from the local filesystem (i.e. a file: URI). They always use the MIME type supplied by the HTTP server. There are some obscure situations in which MSIE ignores the MIME type (thus breaking the specification) and tries to guess the file type, causing much grief to webmasters, but this is not one of them. So, what is happening is that, when you saved the page to your local filesystem, it lost its association to the application/xhtml+xml MIME type, and MSIE had to guess using the file extension (which being .html gives the text/html MIME type). --cesarb 14:50, 22 December 2005 (UTC)[reply]

Update: I solved the issues I was having with tidy, this might be enabled soon, brion seemed to like the idea. —Ævar Arnfjörð Bjarmason 04:43, 23 December 2005 (UTC)[reply]

Another update: Brion did a review of it and we found some issues with it, in particular it would break the static HTML dumps. Also there were issues with using <ref key> (could only use [A-Za-z0-9_] keys) so I went for <ref name=""> as suggested above. Just as I was about to fix all this stuff, commit & deploy it my hard disk broke down, so I won't be able to do it until sometime after Christmas, hopefully. Currently doing a backup over 802.11b hoping it'll keep spinning (all my MW work is backed up though). —Ævar Arnfjörð Bjarmason 20:18, 23 December 2005 (UTC)[reply]

List of all articles

Now that I have your attention ... is there a straightforward way to get a list of all the articles on a particular Wikipedia? I'd like to prepare a script that can compare, say, all the articles on en: and es: to see 1) what's missing from the former vs the latter and 2) where the greatest differences in article sizes (sans images) lie. I know there's a partial list of missing en: articles based on # of crosswiki links on es:, but that's not quite what I'm after. Thanks. | Klaw ¡digame! 01:29, 21 December 2005 (UTC)[reply]

Watchlists

Is there any way for me, looking at a particular article, to see how many editors have it on their watchlist? Thanks. Matt Yeager 01:48, 21 December 2005 (UTC)[reply]

No - this is a feature that has been requested forever. Raul654 01:53, 21 December 2005 (UTC)[reply]
What's it's BugZilla number? I feel like coding another special page. :) 86.133.53.111 13:35, 22 December 2005 (UTC)[reply]

My SVG got squished

Tennessee looks a lot like Arkansas when it gets squished.

I tried to make an SVG image (shown on the right) to replace the image in Template:Tenn voting example. The problem is that it's getting squished into a square when it appears on Wikipedia. Other SVGs have had slight rendering differences on Wikipedia, but never this drastic. Does anyone know how to fix this? rspeer 03:54, 21 December 2005 (UTC)[reply]

Your file has a weird header which specifies width="100%" height="100%". This would make it fill the available space its given, but tells the programs dealing with it nothing clear about how it ought to be sized. It ends up defaulting to a square. If you could change it to specify some actual size, it ought to clear up. --Brion 08:59, 21 December 2005 (UTC)[reply]

I've enabled Special:Unwatchedpages for users with protect permission (that's sysop and above to those not familiar with the permission system), there 5000 rows generated on that page as opposed to the usual 1000, making that value larger is a bad idea since paging gets exponentially more expensive the further in one goes (that can be fixed though).

Having more people watch pages might help avoid something like the recent incidents, it's restricted so that it won't serve as a "vandalize this" list, currently approximately 27% of pages in the main namespace which are not redirects are watched (252502/906363*100 = 27.85881594901821896900). —Ævar Arnfjörð Bjarmason 06:07, 21 December 2005 (UTC)[reply]

It would be useful to know how many of these unwatched pages are categorized and how many appear in lists. It generally more difficult to find a page associated with a particular topic area if it is not included in that topic area by categorization, thus making it more difficult to find for watching. Also, some people monitor large numbers of pages for changes via the related changes function applied to lists; such monitoring can decrease the percentage of pages appearing on watch lists despite their being watched indirectly. User:Ceyockey 05:35, 23 December 2005 (UTC)

Watchlist

Is it possible to transclude my watchlist in User:Rschen7754/Tools just like the AFDs are set up? I'm not sure if it is but I thought I'd give it a shot. --Rschen7754 (talk - contribs) 08:27, 21 December 2005 (UTC)[reply]

Try it and see. 86.133.53.111 17:18, 23 December 2005 (UTC)[reply]

Page Counters

Can't we get at least a page counter on each article page? Statistics would be nice (visitors per day/week/month), but a counter should be fairly trivial?

Or is there a workaround which would enable a third-party counter added? --Iantresman 08:54, 21 December 2005 (UTC)[reply]

Please see Wikipedia:Technical FAQ#Can I add a page hit counter to a Wikipedia page?. -- Rick Block (talk) 16:08, 21 December 2005 (UTC)[reply]
Heh, that certainly covers the question, but it doesn't seem to give the answer: No, it's not possible to add an external page counter image. Stevage 21:07, 21 December 2005 (UTC)[reply]
However, you can get a recent database dump and examine the column which shows number of visits. This is reset every now and then though, so for older articles it's not entirely accurate. Deco 22:46, 21 December 2005 (UTC)[reply]
Actually it hasn't been updated for years. We stopped displaying it on pages when we stopped updating it. It's never been reset. -- Tim Starling 23:42, 21 December 2005 (UTC)[reply]
But presumably, a database dump indicating the number of visits, could be extracted and compared for two different time periods resulting in an average number of visitors per day? But I guess it would not be completely accurate because of the way pages are cached? --Iantresman 13:28, 22 December 2005 (UTC)[reply]

Within the past day or so, my browser has started showing the external link icon (box with an arrow) after every single link within articles, including internal wiki links. Its making WP quite annoying to read. Can somebody explain this? I haven't made any changes to my browser recently. --Mcpusc 12:33, 21 December 2005 (UTC)[reply]

Is your browser the Opera 9 beta? This is a known issue; report the bug to Opera. --Brion 23:44, 21 December 2005 (UTC)[reply]
Nope, its FireFox 1.0.7, which I've been using for months without this showing up. I can't recall making any config changes, but it this isn't a widespread problem, I guess I'll have to check that. --Mcpusc 00:24, 22 December 2005 (UTC)[reply]

I really like the new diff link that comes up on the "New Message" bar. However, if I could request one small change: The diff link only shows the diff of the last person to edit the message. If it could show all the edits that were made since you last saw the page it would be a lot more useful. — Asbestos | Talk (RFC) 15:47, 21 December 2005 (UTC)[reply]

This would be helpful for watchlists, but not very feasible, as the MediaWiki software would have to know which pages you had seen. (huge overhead) — Ambush Commander(Talk) 22:35, 21 December 2005 (UTC)[reply]
I believe the proposal is simply to show changes since the last time that user had viewed their talk page (and only that page). This isn't unreasonable at all, only requiring the storage of the version of that page last seen by that user. Deco 22:45, 21 December 2005 (UTC)[reply]
Ah... that's right. Well... I'm just some lowly MediaWiki hacker with no arcane knowledge of MediaWiki's internals, so I really can't tell you if it's feasible or not. — Ambush Commander(Talk) 23:01, 21 December 2005 (UTC)[reply]
I coded something people like? I must be doing something wrong. Anyway, hmm...well, it's technically feasible, I suppose, but a bit more fiddly. Still, I'll have a play - nothing's impossible, after all. 86.133.53.111 13:37, 22 December 2005 (UTC)[reply]

Honouring white space

I recently added a couple more examples to the word square article, where I wanted multiple spaces to be honoured and not collapsed into one. If you look at the article you can see that the way I did it is a horrible mess of &nbsp; characters. Does anyone know a clean way to get Wikipedia/HTML to honour multiple spaces without adding unwanted vertical spacing and WITHOUT adding that nasty dotted box? Matt 03:00, 22 December 2005 (UTC).

Edit: Oh, without the box? Guess I should read the whole comment. Nope, sorry, no way that I know of, except perhaps through CSS or a font tag. --Golbez 03:06, 22 December 2005 (UTC)[reply]
I gave it a try with <pre>. See if you like it. If you don't, you can easily revert to what it was. Oleg Alexandrov (talk) 03:16, 22 December 2005 (UTC)[reply]
In my skin at least, that's identical to beginning the line with a space, which is what he was trying to avoid - it has the dotted box. --Golbez 03:21, 22 December 2005 (UTC)[reply]
Thanks, yes I tried <pre> but unfortunately it doesn't work properly. On my browser at least, the text displays OK at first, but if it is scrolled off the screen and then scrolled back into view then a partial dotted box appears. The dotted box also always appears when you print the page. (There is also supposedly a "white-space:pre" style attribute which supposedly forces multiple spaces to be honoured, but that doesn't work either.) I can't believe that something so simple can be so difficult... ho-hum... Matt 12:11, 22 December 2005 (UTC).
Well, I found it very strange that white-space:pre would not work, since the way Firefox implements <pre> is exactly by using white-space:pre. Looking at the generated HTML, it looks like it's MediaWiki that's eating the whitespace (or perhaps the HTML Tidy step). The solution would be to use <pre> with some CSS to undo the skin's CSS (hard to do because it can vary between browsers), or as Ambush Commander said, use a table. --cesarb 15:13, 22 December 2005 (UTC)[reply]
I'd say use tables. — Ambush Commander(Talk) 03:35, 22 December 2005 (UTC)[reply]

Soliciting comments

I have recently rewritten meta:Writing a new special page. Soliciting comments and expansion, as it is not finished. — Ambush Commander(Talk) 03:41, 22 December 2005 (UTC)[reply]

Rollback bug?

I ran across an odd edit at Troy. According to Master Jay this was the result of using "rollback" to revert this edit by 70.188.178.146 to the 20:44, December 18, 2005 revision of the article. But if you compare that version with the version produced by Master Jay's edit, you can see that in fact his edit, in addition to the intended reversion, introduced several other changes. Is there a bug in the "rollback" feature? Paul August 04:14, 22 December 2005 (UTC)[reply]

User:Master Jay isn't a sysop, so could not have used the rollback feature. If he used a local javascript hack, that hack might be buggy. --Brion 04:22, 22 December 2005 (UTC)[reply]
Let's cripple such hacks. 86.133.53.111 17:10, 23 December 2005 (UTC)[reply]

pending commits for anonymous users

With the recent discussion of restricting anonymous edits - it occured to me that one useful solution might be to have edits from unknown/untrusted users go in a pending commits queue that can only be applied after a reviewer has approved. This would still allow anonymous editors to add stuff on the 'spur of the moment' while protecting against the serious issue of casual vandalism.

LetterRip

Page protection interface updates

I've installed the new user interface for page protection. It's a bit more complex, but it does make it possible to tell what things are set to, hoepfully without being too complicated.

Additionally a new level between unprotected and full-protection is available (per WP:SEMI) which restricts edits from unregistered users and users registered less than 4 days ago. (At the moment the time restrictions apply only to accounts registered since the upgrade was installed.) This mode is currently only on en.wikipedia.org; on our other wikis it's just the updated interface with the same levels available.

The protection log also now shows the exact permission settings being stored; it's a bit of an ugly field, but it'll allow distinguishing full from move-only restrictions, etc. --Brion 07:06, 22 December 2005 (UTC)[reply]

Hmmm, has the "less than 4 days ago" part actually been implemented? JosephBostwick (talk · contribs · deleted contribs · nuke contribs · logs · filter log · block user · block log) was registered at 10:52 (UTC) today (after you wrote the above) and was able to edit George W. Bush immediately. -- Curps 11:19, 22 December 2005 (UTC)[reply]
Yes, Splash was able to create a test account and post to GWB immediately. I'm guessing it's just a bug, but please look at it, Brion. --Woohookitty(cat scratches) 12:53, 22 December 2005 (UTC)[reply]

Semi-protection and George W. Bush

JosephBostwick (talk · contribs · deleted contribs · nuke contribs · logs · filter log · block user · block log) is the first vandal of George W. Bush under semi-protection, and he did so 2 minutes after registering the username. Clearly, the time-delay aspect of semi-protection hasn't been implemented yet.

Probably we should introduce some artificial delays for registering an account... make them do captchas or answer skill-testing questions for about 30 to 60 seconds. Something that can't be automated: random obvious skill-testing questions like "how many legs does a dog have?" that any human can answer but would stump a registration bot. A set of several hundred randomly varying skill-testing questions might be preferable to captcha, because visually-impaired users wouldn't be affected.

This wouldn't be much of an annoyance to legitimate users (who only register one or a couple of accounts, ever), but would raise the hassle factor for large-scale throwaway account creation. It's like spam... if you could charge 1 cent per e-mail message, spam becomes uneconomical. Same concept. -- Curps 11:15, 22 December 2005 (UTC)[reply]

Let's just put the 4 days thing into effect...see if we can get the software to accept that...and just do that. --Woohookitty(cat scratches) 12:52, 22 December 2005 (UTC)[reply]
Not the whole mess, please. As to the problems - it's quite possible, as Brion appears to mention it's a configuration option, that he made the honest oversight of not enabling that option in the English Wikipedia's configuration. 86.133.53.111 13:19, 22 December 2005 (UTC)[reply]
Spelled it wrong in the config. :P Fixed. --Brion 23:56, 22 December 2005 (UTC)[reply]

IPA characters in the "insert" box

I want to give a big thank you to whoever added IPA characters to the "insert" box that appears under the edit window. How do I find out who did that, so I can thank them personally? Can anyone add things to the "insert" box (i.e. could I have done it myself)? --Angr (t·c) 14:40, 22 December 2005 (UTC)[reply]

That "insert" box is MediaWiki:Edittools, editable by any sysop. You can just look at its page history. --cesarb 15:18, 22 December 2005 (UTC)[reply]
Aha. So being a sysop, I could have done it myself. Wish I had asked three months ago! --Angr (t·c) 15:45, 22 December 2005 (UTC)[reply]

Adding CSS for metadata

I would like to add the following CSS to Common.css:

/* Metadata */

table.metadata {
        border: 1px solid #aaaaaa;
        display: none; 
}
.metadata-label {
        color: #aaaaaa;
}

This will help us to implement metadata schemes like the German Wikipedia does, which will open up a whole new world of possibilities for accessing Wikipedia data. For example, imagine being able to search for all Wikipedia articles on authors who died in 1954, or cities in Italy with more than 100,000 people. For more info on the German effort, see this article. The first step is being able to add hidden metadata to articles, which this CSS will make possible. The second step is to create metadata templates such as Template:Persondata. The third step is to take over the world! Muhahahaha! Kaldari 17:57, 22 December 2005 (UTC)[reply]

I've gone ahead and added the necessary CSS so that I can develop a proof of concept for the English Wikipedia. Stay tuned... Kaldari 19:39, 22 December 2005 (UTC)[reply]
If you'd like to keep track of my efforts, check here: Wikipedia:Persondata. Kaldari 23:56, 22 December 2005 (UTC)[reply]

View source and template list

When viewing source of a protected page, it would be good to be able to show a list of templates that the page includes, in the same way as you currently get when editing a page. Of course, there may be a case for those templates being protected themselves, but that's not a strong reason against having a list of them in a convenient form. TerraGreen 18:31, 22 December 2005 (UTC)[reply]

No more time delay for page moves either??

User:Guillermo con sus ruedas was created at 17:54 today and started pagemove vandalism immediately. A bunch of other socks followed. What happened to the time delay for doing page moves? -- Curps 19:12, 22 December 2005 (UTC)[reply]

  • I was wondering about the same thing as well. It seems that the page-move throttle may have been inadvertently removed during the recent software upgrade. --Ixfd64 19:16, 22 December 2005 (UTC)[reply]
It's a four-day delay on new accounts created since the upgrade. --Brion 23:48, 22 December 2005 (UTC)[reply]

new protection feature

I don't know if this is intentional, but for pages that are protected from editing by new users, the page protection link still shows as "protect this page" as if it's not protected. For example, see the penis article. --Ixfd64 19:14, 22 December 2005 (UTC)[reply]

It's not that different from pages protected against moves having the link show as "unprotect". --cesarb 22:18, 22 December 2005 (UTC)[reply]
IMO now we have so many different types of protection changing the text on that button has outlived its usefullness and it should just be marked "protection" and take the admin to a page showing the pages current status and letting them change it. Plugwash 23:11, 22 December 2005 (UTC)[reply]
It says 'unprotect' to me. --Brion 23:47, 22 December 2005 (UTC)[reply]

Huh?

I tried to move a page and was told my account was too new -- but I have been here for a few months now! Has moving broken somehow, are there new restrictions, or something? I haven't heard anything regarding this... --WCQuidditch 23:58, 22 December 2005 (UTC)[reply]

After seeing a question above -- is this an inadvertent side effect of a recent upgrade? --WCQuidditch 00:00, 23 December 2005 (UTC)[reply]
You're not the only one who is experiencing this problem. Perhaps it's restarting the count for everyone. -- Dissident (Talk) 01:05, 23 December 2005 (UTC)[reply]
That's fixed. --Brion 01:44, 23 December 2005 (UTC)[reply]

Problem with donations page header?

Just today, the little box at the top of each page which starts "You can help Wikipedia grow and improve by donating here!" has started appearing to the right of the page title, not above it like it usually does. If this is a bug, it's happening on every page I go to. If it is deliberate, I think it looks terrible :). So which is it? Raven4x4x 04:19, 23 December 2005 (UTC)[reply]

I bet some sysops are arguing over the best place to put it, so it's been schizophrenic. Try clearing your cache... if only I could find the page where this stuff gets edited. Personally, I don't like it floated to the right. Looks like some ugly ornament that was lackadaisically slapped on. — Ambush Commander(Talk) 04:21, 23 December 2005 (UTC)[reply]
The appropriate place is MediaWiki:Monobook.css. Titoxd(?!? - help us) 04:23, 23 December 2005 (UTC)[reply]


vandal edit summaries violating privacy policy

Could a developer please remove the summaries from the following edits? All of these edits are from the Jimmy Wales article:

All the times are in Pacific Standard Time.

I will post the links to the bad edits on the George W. Bush article (also badly-hit) shortly. --Ixfd64 05:23, 23 December 2005 (UTC)[reply]

All right, here are the bad edits I found on the George W. Bush article:

Again, all the times are in Pacific Standard Time. I'm pretty sure that similar edits also exist elsewhere. Unfortunately, I do not have the time to look for all of them. If anyone spots any similar edits, please take the time to report them here. Thanks! --Ixfd64 05:57, 23 December 2005 (UTC)[reply]

The bush links don't load for me (starts my browser spinning until I close the tab), but the edits to Jimmy Wales giving Jimbo's address are pretty harmless. His address is already readily available to anyone with 30 seconds of time on google; for example it is available here: meta:Articles of Incorporation. Thue | talk 18:13, 23 December 2005 (UTC)[reply]

Clickable maps

I've continued my quest to find a good way of creating clickable maps on Wikipedia. Using the new {{click}} I've put together a map of a prominent portion of Ottawa. It looks much better and is more precise than my previous ACSII art maps, and it would be even better if it had been done by someone with a modicum of artistic ability.

My main concern is that this technique, which uses dozens of very small images, will cause the image server to explode. If this process can be used, I'm also wondering if there is anyway to make it easier. The very small map at Wellington Street took many hours of work. - SimonP 20:49, 23 December 2005 (UTC)[reply]

How do you turn on Uploading?

I have a Wiki site and for the life of me I can't figure out how to turn on uploading for pics and such. This is what I have in my LocalSettings.php file and it still doesn't work.

$wgEnableUploads = true; $wgUseImageResize = true; $wgUseImageMagick = true; $wgImageMagickConvertCommand = "/usr/bin/convert";

Any ideas as to how to get it to work? Is this configured properly? Thanks and my email is bucklerchad@comcast.net I'm always online.

Sniggity 21:45, 23 December 2005 (UTC)[reply]

that looks right to me. Does the upload link show and if so what happens when you try and use it? Plugwash 22:43, 23 December 2005 (UTC)[reply]