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.
Details about the occasional slow speeds and deadlock errors: here
Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).
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.
Lock out unsafe browsers?
Dead Thread
This thread began:
A small minority of edits to Wikipedia are made using browsers such as Internet Explorer for the Macintosh and Netscape 4, which cannot cope with a full character set in edit boxes, and corrupt characters in the existing text, sometimes destroying links. Would it be a good idea to direct attempts to edit with them to a page explaining why they are unsuitable to edit wikis and how users can fix the situation? Susvolans(pigs can fly) 11:44, 27 July 2005 (UTC)[reply]
The concern raised was answered with this comment:
we do now have a workaround in place to allow browsers that can't handle unicode in the edit box to edit safely. However we need to know what those browsers are to make mediawiki use the workaround when it detects them. currently the list contains regexps for what appears to be some old version of netscape for linux (the regexp is "/Mozilla\/4\.78 \[en\] \(X11; U; Linux/") and IE mac (the regexp is "/Mozilla\/4\.0 \(compatible; MSIE \d+\.\d+; Mac_PowerPC\)/"). If you know of other browsers that screw up unicode text in the edit box please file a bug report asking for them to be added to $wgBrowserBlackList Plugwash 21:11, 30 July 2005 (UTC)[reply]
This thread is now dead, in the sense of a dead ball. You may still add your comments to the thread at the bottom of this section, but this issue has been resolved.
A small minority of edits to Wikipedia are made using browsers such as Internet Explorer for the Macintosh and Netscape 4, which cannot cope with a full character set in edit boxes, and corrupt characters in the existing text, sometimes destroying links. Would it be a good idea to direct attempts to edit with them to a page explaining why they are unsuitable to edit wikis and how users can fix the situation? Susvolans(pigs can fly) 11:44, 27 July 2005 (UTC)[reply]
I think this is too harsh, given that many people are unable to change browsers (just today my workplace has blocked non-IE browsers from accessing the internet). Seems to be a good idea to insert a warning on the edit page though... presumably quite doable without requiring changes to the MediaWiki software (the shipped JS already has some browser detection)? Pcb21|Pete 13:30, 27 July 2005 (UTC)[reply]
I agree blocking such users is too harsh, however I don't think a warning on the edit page is enough (what does a naive user do with such a message?). I've noticed what look like bots running around changing interwiki links to unicode characters. Because of this, users may well run into this issue on pages that they wouldn't expect to be a problem. I would suggest we immediately stop changing interwiki links from html entities to unicode (even consider changing them back) and request a software change to detect the unicode breakage caused by these browsers (and ideally simply silently fix it). -- Rick Block (talk) 15:15, July 27, 2005 (UTC)
The problem with entities is that it’s harder to read changes from the page source, which is what both the editing screen and MediaWiki’s diference function give you. This is a particular problem with link targets, which aren’t previewed. For instance, a change from [[ja:東京]] to [[ja:北京]] is little more than gobbledygook, but one from [[ja:東京]] to [[ja:北京]] is understandable to anyone who knows Chinese characters. Sometimes this happens in Roman script too; the Łódź article used to make repeated references to “Łódź”. Your suggestion is tantamount to letting a tiny minority hold maintainability hostage. Susvolans(pigs can fly) 16:06, 27 July 2005 (UTC)[reply]
I believe link targets are previewed for me (is this a skin issue? I use classic). And, I'm not saying we should do this permanently - only until we have some way to prevent the damage that might occur. I'd much rather the software detect and fix the breakage than block older browsers. If we block older browsers, I'd prefer to block them only when editing pages that contain unicode characters that their browser will mangle than block all editing or (shudder) block any access at all. I think what we're doing now is essentially creating a mess for ourselves that we'll have to straighten out. As of the switch to 1.5, for 100% of the articles in the en wikipedia this was not a problem. Changing all the interwiki links will make it so editing any article with a non-compliant browser is virtually guaranteed to break something. Why would we choose to do this before we have something in place to handle the problem? -- Rick Block (talk) 22:42, July 27, 2005 (UTC)
I agree with Susvolans. At some point we have to stand up and say "Your actions are harming wikipedia" and insist that they correct the situation. Based on statistics from my own websites and similar figures I've seen online, we are basically talking about 1-3% of all web traffic. Most everyone already uses a recent enough version of IE, NS, or Firefox to not cause problems, but the small minority of editors who don't are both annoying and disruptive. I find it to be unreasonable to continue using unintelligible html entities just to coddle the people not using unicode supported browsers. I would support disabling editting for the oldest browsers almost immediately (the sub 0.05% market shares) and adding a strong warning for other noncompliant browsers that they will be blocked in the future. Dragons flight 16:22, July 27, 2005 (UTC)
I don't think it's a good idea to block out people based solely on an easily forged User-Agent string. However, we could create some templates for talk pages explaining the situation to the people with older browsers and handle this as if it were a social issue, not a technical one. — Ambush Commander(Talk) 19:30, July 27, 2005 (UTC)
What is the advantage of tracking these people down by hand as opposed to redirecting them to a page that says there browser is out of date and incompatible with editting wikipedia and offering them information and links that way? Dragons flight 20:31, July 27, 2005 (UTC)
People who are able to forge their user-agent are unlikely to be using ancient buggy browsers. -- Cyrius|✎ 00:24, 28 July 2005 (UTC)[reply]
Maybe we should just block everything except IE? Pcb21|Pete 21:29, 27 July 2005 (UTC)[reply]
I'm hoping that was some kind of bizzare joke? IE is the worst browser...ever. The problems in question concern old browsers, including old versions of IE. Firefox, Opera, and Safari stand posed to replace Explorer...if people would only download them and give them a chance. Aren't you tired of downloading viruses onto your computer yet? ;-) Func( t, c ) 04:08, 29 July 2005 (UTC)[reply]
As far as I know the vast majority of browsers, be they IE, NS, Firefox, etc. are causing no problems. However there are a small minority of old browsers that kill all the unicode notations with their edits, and frankly on large and frequently editted pages, e.g. subpages of WP:RA, this is more than a little annoying, not the least of which is because the corrupted character codes left in their place is often unintelligible without sorting through the history to figure out who messed things up. I'm all for designing websites to recieve the widest participation possible, but now that we have made a decision to go with Unicode, we ought to accept that this neccesitates shutting out non-Unicode platforms which do, in fact, damage wikipedia pages when editting. Dragons flight 22:15, July 27, 2005 (UTC)
*spills drink coughing* Bought any Microsoft stock lately? I don't feel like starting a big "My browser is better than your browser" war here, but Firefox handles Unicode and the likes quite well, thank you. Last time I checked, market share and quality weren't the same thing. --IByte 21:15, 14 August 2005 (UTC)[reply]
Lockout Browsers = Bad idea, major screaming, my ears are hurting already. Possible good idea: Have a script that detects incompatible browsers, then perhaps sends them to a special page on their first visit to Wikipedia. The page gives them a list of possible browser settings they can try to avoid problems (where applicable) or points them to download links for updated browsers from their manufacturer that will solve the problem. Xaa 04:33, 29 July 2005 (UTC)[reply]
we do now have a workaround in place to allow browsers that can't handle unicode in the edit box to edit safely. However we need to know what those browsers are to make mediawiki use the workaround when it detects them. currently the list contains regexps for what appears to be some old version of netscape for linux (the regexp is "/Mozilla\/4\.78 \[en\] \(X11; U; Linux/") and IE mac (the regexp is "/Mozilla\/4\.0 \(compatible; MSIE \d+\.\d+; Mac_PowerPC\)/"). If you know of other browsers that screw up unicode text in the edit box please file a bug report asking for them to be added to $wgBrowserBlackList Plugwash 21:11, 30 July 2005 (UTC)[reply]
Blocking is against the whole wiki concept, and won't work in any case. For example, I have an extension for Firefox that lets me determine what user-agent string is transmitted to sites (I pretend to be IE for some sites that block Firefox). If we block people because they have old computers (seems un-wiki to me) they will just use similar hacks to get round it (or use privacy features/firewalls to stop their computer telling WP the user agent in the first place) Cynical 15:50, 5 August 2005 (UTC)[reply]
Here's my idea: we add a module to the existing software that checks edits and sees whether or not Unicode characters were corrupted: it could be some sort of heuristic, and if it is, notify the user about the problem, and either let them submit their changes (in case the heurstic got it wrong), or explain why there's a problem and try to help them get a better browser. — Ambush Commander(Talk) 18:58, August 12, 2005 (UTC)
It might be an idea to do that both as a means of identifying problem browsers and a method of limiting such damage when its caused by other means like copypasting to a text editor. However its not too urgent now, the workaround in place for IE mac seems to have stopped nearly all of the bad edits. Plugwash 21:01, 14 August 2005 (UTC)[reply]
First, and instanter, block obsolete browsers from editing any page. This is extreme, but very fast to implement. By "obsolete", I mean any browser presenting a known unsafe user agent token. Direct such users to a friendly page that makes concrete and specific suggestions.
Second (optionally), check for Unicode in markup before imposing the block. Meanwhile, upgrade the redirect page and log hits to it, so we can contact such users individually. Don't worry about browsers presenting false tokens; it's a non-issue, statistically.
Third, and most complicated, write a module to quietly fix such corruption, and remove the block.
The last step might never become necessary if we make an honest effort to upgrade problem users -- not merely with a bland notice, but with individual, personal contacts.
There are very few of these users; they can be fixed; but meanwhile they cause damage all out of proportion to their numbers. — Xiong熊talk* 21:26, 2005 August 14 (UTC)
This is not a purely Unicode issue by the way: there are some browsers that affect plain old ISO-Latin-1 (changing é to e, turning ü into ue, munging Icelandic letters). So the problem preceded Mediawiki 1.5. -- Curps 21:34, 14 August 2005 (UTC)[reply]
Xiong have you even read the discussion so far? !!!!a workaround for allowing known problem browsers to edit safely is ALREADY IN PLACE!!!!. 22:01, 14 August 2005 (UTC)
But see, there is a problem for some browsers. Some of them are fixed, but others are not. The reason why this discussion was brought up was because some Wikipedians got fed up with corrupted pages and posted to this page. Please don't shout. — Ambush Commander(Talk) 22:12, August 14, 2005 (UTC)
This section was started before the workaround was in place when there was a big problem with bad edits coming almost entirely from IE mac.
the workaround is pretty generic it just needs browsers to be added to the list (which sadly is something only a dev can do so it takes time to get it done). The only bad edit i've seen reported since then was caused by a user copypasting the text to a text editor. If you have other examples of bad edits from after 2005-07-29 10:16 UTC when brion declared the fix in place please post them. Plugwash
Erm, I was mistaken then. Sorry. Here's a logical extensions of this: a user preference that turns this fix on all the time, or the ability to get a unicode safe version of the text for just a certain edit. Perhaps that would be helpful. — Ambush Commander(Talk) 23:23, August 14, 2005 (UTC)
By the way... you should sign your edits. — Ambush Commander(Talk) 23:24, August 14, 2005 (UTC)
i usually do sign and i thought i did then. i've noticed sometimes the sig system screws up. btw i like your suggestions and i might try and code up a patch to do them. Getting it committed and put on the live site is another thing entirely though and can take weeks even for fairly urgent bugs. Plugwash 23:51, 14 August 2005 (UTC)[reply]
I missed, in the flurry of comments, the one apposite notice that the concern had been addressed. I grovel. — Xiong熊talk* 23:51, 2005 August 14 (UTC)
I very occasionally edit from my WAP mobile phone. I know it uses IE something-or-other on Windows Smartphone 2003 (a version of Windows CE). I don't know whether this breaks unicode or not, is there a page where I can test safely whether it does or doesn't and the user agent can be easily identified if it does break? Thryduulf 00:46, 15 August 2005 (UTC)[reply]
you could try the bad edits are kinda expected in sandboxes and there is bound to be some non-latin in there ;). If you find a problem we can then worry about getting the user agent but i don't think we will. Plugwash 00:53, 15 August 2005 (UTC)[reply]
mmm that needs looking into and possiblly discussion with the lynx developers. can you be more specific about when it does and does not cause problems. Plugwash 15:46, 15 August 2005 (UTC)[reply]
Some additional wiki markup ideas
Some ideas for things that could be added to the available markup to keep it cleaner-looking (less HTML tags and entities). Mostly math related, I guess:
Obviously we should resurrect the old en and em dash markup so people see the markup: break in thought -- a parenthetical statement instead of break in thought—a parenthetical statement for the output break in thought—a parenthetical statement. There were two competing markup methods, and it was implemented for a few minutes, and then abandoned because it conflicted with table and comment markup and some titles. Seems easy enough to fix and put back in place... See Wikipedia talk:Manual of Style (dashes)
==> instead of ⇒ for ⇒
Super and subscripts: we could use TEX markup, but with mandatory brackets: x^{3} instead of x<sup>3</sup> for x3, or CO_{2} instead of CO<sub>2</sub> for CO2.
220+-5% instead of 220±5% for 220±5%
|x| >= 0 instead of |x| ≥ 0 for |x| ≥ 0
Maybe even 3.5E2 instead of 3.5×10<sup>2</sup> for 3.5×102
and so on. Some are not a big deal. Some (subscripts) would be much easier to type this way and provide cleaner markup. Yeah, the math tags are good, but no one wants to type the math for all the time. - Omegatron 21:16, August 2, 2005 (UTC)
btw now we are utf-8 you can just use proper dashes in the wikitext directly and we have "links" to insert them below the edit box. ± was in iso-8859-1 and could therefore always be placed directly in the wikitext. i agree that subscript and superscript are a pain but ² and ³ the most commonly used ones can be safely put directly in the wikitext using the links below the edit box (other numbers are also availible in that form but they have browser support issues). maybe it would be an idea to put the greater than or equal to and less than or equal to signs in that box below the edit box. Plugwash 23:03, 2 August 2005 (UTC)[reply]
What box below the edit box?? - Omegatron 19:32, August 4, 2005 (UTC)
Oh, that one. Why is it below all the template links?? - Omegatron 19:32, August 4, 2005 (UTC)
Entering dashes by clicking on another box is almost as bad as typing them in, though it does fix the ugly markup problem. I still wish there were a shortcut for these. Bug 1485
Super and subscript would still be useful. I hate the ² and ³ when used in the general case, since there are only the two of them (I hate the unicode fractions, too), and think they should only be used in units. Bug 3080
Also a wiki version of <br clear="all"/>, since it is hard to remember the exact syntax and it looks ugly in markup.
I will write up a feature request for these, but maybe people have ideas for better syntax? - Omegatron 23:52, August 8, 2005 (UTC)
I'll try a feature request first. - Omegatron 03:46, August 9, 2005 (UTC)
I promise to write a really nifty template that solves a huge range of related markup problems, or at least provides a "dummies" solution to them -- but -- as most of these resolve to single characters (or a handful) I can't in good conscience do so as long as it is so difficult to employ the subst: atom. For once, I have to side with the server-load alarmists.
I have previously asked for this syntax to invoke recursive substitution rather than transclusion:
{{':sometemplate}}
This would be even better:
{{;sometemplate}}
By "recursive substitution" I mean to demand that all nested templates are fully expanded at the time the edit is saved. If I see this implemented, I will develop not only this really nifty template, but also others depending on nested templates but not justifying multiple transclusion.
Meanwhile, I offer this tool: {{markups}}. Stick it on your user page, which you then open in another browser window and copy from to your heart's content. If desired, I can cough out similar quick reference cards on request.
These days, I generally step to one side of the typesetter's barfight over dashes and spaces, but just for old time's sake: Emdashes must be surrounded by thin spaces! — Xiong熊talk* 00:14, 2005 August 15 (UTC)
I like spaces around mdashes, too — even though some don't like it. I really would like the wiki markup to be updated instead of creating templates for everything. Templates are a kludge in a lot of cases. - Omegatron 06:04, August 15, 2005 (UTC)
Better Upload Page to Get More Images Tagged
Over at the policy section, some people have crafted an idea for a better upload page to encourage people to tag their images or at least provide the information needed to tag them. You can go there for details, but basically we want a check box that says, "Is this a photograph you took yourself, or an image you created from scratch?" On the page where it says, "If you upload a file here to which you hold the copyright, you must license it under
the GNU Free Documentation License or release it into the public domain. Alternately, you can upload your file to the Wikimedia Commons under a different free license." change it to "If you upload a file here to which you hold the copyright, you agree to license it under the GNU Free Documentation License, unless you specifically release it into the public domain. Alternately, you can upload your file to the Wikimedia Commons under a different free license." Then, say, "If not, do you have the image tag? If so, please enter it.". Then, "If you don't have a tag, please explain the source of this image in detail in the box below."
Below can be the summary box that's always there. Server-side(not client JS) validation should ensure that either the first box is checked, the second contains text(preferably ensure there is a valid tag, but that's more difficult), or the third box contains text.
If the first is checked:
If there is nothing in the second, add {{GFDL-self}} to the summary.
If there is something in the second, add
The uploader owns the copyright to this image. By uploading it to Wikipedia, he or she agreed to license it under the GFDL, unless he or she released it into the public domain below.
If the second is filled,
Check whether the form of the field is {{*}}. If it is, just add it to the summary.
Otherwise, add {{<FIELD>}} to the summary.
If the third is filled,
Add it to the summary.
Can someone implement this, or at least provide feedback. If you are unsure what I am proposing, I can create an HTML mock-up. Superm401 | Talk 19:46, August 6, 2005 (UTC)
I think this is a great idea, and would urge others to show support/criticism so this idea can hopefully be acted upon. Martin (Bluemoose) 08:53, 7 August 2005 (UTC)[reply]
Great idea. - Omegatron 19:02, August 12, 2005 (UTC)
Good thought; an element of a larger effort needed to shift more work onto the engine, in part by using form elements other than one giant editable text field. — Xiong熊talk* 21:07, 2005 August 14 (UTC)
Agreed. --Workman161
Okay, then. Developers, can this be implemented without a change to the MediaWiki software? Superm401 | Talk 04:26, August 15, 2005 (UTC)
Any objections from anyone? Superm401 | Talk 03:49, August 20, 2005 (UTC)
How do you change a temp page to a regular page?
How do you change a temp page to a regular page? Thank you.
However, this caution: If you developed a new page in a private sandbox over the course of many edits, and now you want to move the page to a public space, you may want to copy-and-paste the markup instead of using page move. Create the new page with the single edit summary "new". Otherwise, the history for the new page will show all the trivial edits you made in your private sandbox. — Xiong熊talk* 01:17, 2005 August 15 (UTC)
Two Category-related peeves (from newbie)
1. I was browsing the Category "Pets" for some child-friendly material and was taken aback seeing an entry for "User:SPUI/dogshit" under "U". Upon investigating I realized SPUI had copied the "Dog" page and was just using it as a personal sandbox, probably not realizing it was still linked via "Category" to the outside world. Would it make sense to disable Category linking from User pages / from anywhere outside the Main wiki space?
2. Browse any Category list containing people and there'll always be a number of entries misfiled under their given name rather than their family name, due to an editor coding [[Category:CATEGORY]] instead of [[Category:CATEGORY|Familyname, Givenname]] . I wish there were a way to declare "This article is a person's name and should be alphabetized like so in all Categories it belongs to automatically." Or, maybe there's some other solution?
About 1: There's also categories to categorize wikipedians, so disabling categories outside the main namespace might not be the best idea. 2: A while back (no idea if it was resolved) there was a dispute about whether to categorize people like Baron von Munzhauzen (sorry about the spelling) under the v or the M. Automization would cause a problem here if the dispute hasn't been resolved yet. - Mgm|(talk) 15:58, August 11, 2005 (UTC)
You can generally edit any page(even a user space page) to remove it from a incorrect category. Assuming it was an accident, most people will be grateful for the help. If it's protected, mention the problem on the Admin noticeboard, and an admin will do the same thing. I fixed a few mistakes like that in the Category:Museums a few days ago. JesseW 19:10, 14 August 2005 (UTC)[reply]
Disabling categories outside the main namespace could be done if the categories that need to contain pages from elsewhere can be identified with a tag. You could calso spider Category:People to find pages missing sort keys or with badly formed sort keys (accents and CamelCase). This would also report non-people in categories meant for people. Susvolans(pigs can fly) 14:32, 15 August 2005 (UTC)[reply]
Somehow, the section editing is off by two on that page. The fact that it transcludes Template:Did you know might have something to do with it or not, or maybe the funny secion headers using variables (the ones on the current time). I don't know how to fix it, but it sure is annoying. One user already added an entry under August 9 that he probably wanted to add under August 11 (and should have placed at August 10). Can some experienced hand go take a look, please? Lupo 18:48, August 11, 2005 (UTC)
It was a result of h3 HTML headers included in the template. Now that the main page and the template all use wikipedia syntax this should no longer happen. - Mgm|(talk) 13:38, August 15, 2005 (UTC)
Bullets and photos; white space after colon
While editing the page on Gautama Buddha section on Personality and character, I could not have a picure on the left and show bullets on the left as well. Is that unavoidable or a glitch? Also, there is a big white gap after the colon in "The Buddha as presented in the Buddhist scriptures is notable for such characteristics as:" that leads to the bullets. Is that because of the picture size and the text being stretched to accomodate? Rsugden 20:00, 12 August 2005 (UTC)[reply]
Pictures on the left generally don't work very nice; I'd recommend keeping them all on the right. -- Finlay McWalter | Talk 20:38, August 12, 2005 (UTC)
Depending on skin, images are going to look this way or that if floated left or right. You don't really have as much control over the final look as you think. That said, you don't want to float an image left of a list (unordered or ordered; HTML <UL> or <OL>; wiki markup * or #). You can try this a couple of different ways:
Once again, it looks like a demand for a more flexible {divbox}. I really do wish we could move the template transclusion mechanism into the 21st Century, or at least into the 1960s. — Xiong熊talk* 02:15, 2005 August 15 (UTC)
Divbox/2 solution
Template:Divbox/2
And here's more text, mostly for the purpose of showing what it looks like after the float is cleared. Please comment at Template talk:Divbox/2. Thank You! — Xiong熊talk* 05:41, 2005 August 15 (UTC)
Preemptive contribution of redirects: a possible bot-task
I've been thinking about this problem for a while and after pondering different ways of solving it, I think it might be a task best handled by a bot.
The problem is this: No one has yet stepped up to write a particular article, but there are redirects that should be created when the article does get created -- alternate spellings, known aliases, etc. It's possible to create the redirects before the article is created -- but this makes each redirect turn blue, giving the false impression that it contains content. Creating a bare stub for the subject amounts to almost the same problem.
Proposed solution
A public page is created to list "clusters" of redirects that should be created when one of them is made into an article. These clusters may include moves and/or one-way redirects (for example, if a page is made at the misspelled name Micheal Morgan, the article can be auto-moved to Michael Morgan, but creating the article Michael Morgan will not create Micheal Morgan as a misspelled redirect.) The page is publicly editable so that all users can see what moves and redirects are proposed to happen, and can raise objections before it becomes a fait accompli; if there is a naming conflict, it may well be resolved before the article exists.
A bot periodically scans the page to see if any redlink in any cluster has become blue. If it has, and the moves/redirects are not flagged as controversial, it carries out the moves and creates the appropriate redirects. If it is flagged as controversion, it adds a notice to the subpage for the cluster, so that anyone who has it on their watchlist will be notified that an article now exists. -- Antaeus Feldspar 16:15, 13 August 2005 (UTC)[reply]
seems workable, i'd wait until the new page has been left unedited for a few hours though before moving it to avoid conflicts with the editor that created it.
Good idea; the bot could be programmed to do that. -- Antaeus Feldspar 18:06, 13 August 2005 (UTC)[reply]
Nice idea. I'd always been hesitant to pursue anything like this because a mere redirect shows up as a "blue link"; your proposal of a way to do this without actually creating the ridirects in advance is great. -- Jmabel | Talk 01:11, August 14, 2005 (UTC)
Won't work. Many languages have minor variables of spelling for names. Wikipedia policy is to use the version most used by English speakers, not the one necessarily in English. A bot like that would cause chaos with such names. For example Micheal may be a mis-spelling, or it may be the Irish language version of Michael. Eamon may be a misspelling or it may be the Irish language spelling of Eamonn. Willem may be a misspelling or it may be a foreign language of William. One prominent writer was called Patrick O'Brian. O'Brian is not a valid name normally but it was his correct pen-name. If a bot automatically a Micheal Morgan to a Michael Morgan there would be war from Irish users, if it turned out he was called Micheal (pronounced Me-hawl) not Michael. This is one bot that needs to be strangled at birth, before native language users of Wikipedia do the strangling of it themselves.
I'm afraid you've entirely misread the proposal. The bot does not make any decisions. Period. The bot only carries out instructions set for it in advance by the users; it is of course possible that the bot might carry out a mistaken set of instructions but since the same human would have made the same mistake if doing it manually, there is little sense in blaming the bot. You're writing as if this bot would make its own decisions, moving articles based on its own ideas of what the "correct" spellings are; you're right that that bot would be a bad idea, but you're describing something unrelated to the bot that was proposed.
Let's forget my poorly chosen imaginary example and use a real example. Pretend that no one had yet created an article for Patrick O'Brian, and a forward-looking editor who wasn't ready to write such an article themselves nevertheless realized that someone probably would write such an article at some point. This editor thinks, "Gee, if someone creates an article at Patrick O'Brian, I should probably create Richard Patrick Russ as a redirect. And if they created it at Richard Patrick Russ, well, Patrick O'Brian should probably be created as a redirect. If they created it at Patrick O'Brien, however, it should be moved to what I know is the correct spelling, Patrick O'Brian. Moving it would create a redirect from the incorrect spelling to the new location, but I don't think it would be a good idea to create that misspelled redirect just because someone created the article under one of the two correct titles." (No, this is not a great example either, because there is a Patrick O'Brien, who is different from Patrick O'Brian. Please pretend.)
That editor could regularly check back to see if one of those articles exists yet, and if so, manually create all the redirects. And be strangled, if he happened to be mistaken about a spelling. =) Or he could create a new sub-section/sub-page of the page the bot looks to for its instructions, stating "If an article is created at this title, optionally move it to this title, and create these redirects for it." This page is publicly readable and writable, so in case that editor did make a mistake, and proposed moves and redirects that shouldn't be made, others have a chance to see the plan, say "Hold on wait a moment", and thresh it out before the dook hits the fan. This bot could really result in fewer stranglings. -- Antaeus Feldspar 23:35, 15 August 2005 (UTC)[reply]
No favicon?
Recently, Firefox has ceased to show a favicon for Wikipedia pages. I've changed nothing. What is causing this? ~~ N (t/c)
Some people have also seen a light blue circle with blobs inside it as a favicon. (SEWilco 16:48, 14 August 2005 (UTC))[reply]
Everything is fine here (at least in the URL box, don't know about favorites). — Ilγαηερ(Tαlκ) 17:01, 14 August 2005 (UTC)[reply]
It's probably a Firefox bug. I've been seeing the Yahoo! logo as a favicon on Wikipedia links. — Nowhither 20:53, 14 August 2005 (UTC)[reply]
Is Whatlinkshere on a redirected template updated on the target template rather than the redirected template?
Because seemain is redirected, might Whatlinkshere:seemain be showing articles not edited since the redirect? (SEWilco 19:03, 14 August 2005 (UTC))[reply]
Running a replace bot on references to 'Template:main' does find pages which refer to {{seemain}} (t/l) which are not in Whatlinkshere:seemain. (SEWilco 19:19, 14 August 2005 (UTC))[reply]
An example of the redirected target linking is that Ancient Greece uses {{seemain}} (t/l) and not {{main}} (t/l). WLH:seemain does not show Ancient Greece, but WLH:main does (about halfway down a list of 500). (SEWilco 02:07, 16 August 2005 (UTC))[reply]
Page move vandalism is still a problem
Pagemove revert helps, but only up to a point. It needs to be improved.
The latest User:FREE ZOIDBERG ON WHEELS pagemove vandalism script ran from 17:58 to 18:02 today. The final fix (moving Tabuk, Kalinga ON WHEELS back to Tabuk, Kalinga at 19:52 was not done until nearly two hours later. This was not two hours of continuous effort: the page move log shows that some users moved some pages back for a while, then gave up.
One suggested improvement:
Pagemove revert should have the option of NOT creating a redir back. We really DON'T need a redir from Tabuk, Kalinga ON WHEELS back to Tabuk, Kalinga. This redir makes Tabuk, Kalinga ON WHEELS a bluelink, making it impossible to tell from examining the page move log whether this page has been moved back yet or not. A second time-consuming sweep is needed to delete these useless "ON WHEELS" back-redirs, just to turn all the "ON WHEELS" links red in the pagemove log so we can be sure everything was moved back properly. This would also avoid the dreaded double-revert bug (when two users pagemove revert at the same time, the article page gets turned into a redir to itself).
In fact, we should have a quick pagemove revert that automatically:
does not create a back-redir
does not detour through the Special:Movepage screen (prompting for a reason and requiring an extra click)
As long as pagemove vandals can create hours of disruption by running an automated script for a few minutes, they will keep at it. Worse, sooner or later we will get "ON WHEELS" pages that miss scrutiny and remain at the renamed title. -- Curps 20:27, 14 August 2005 (UTC)[reply]
PS, and how about throttling the rate of page moves... do we really need to allow a single user to move 25 pages per minute? -- Curps 20:29, 14 August 2005 (UTC)[reply]
Limiting page move rates for non-admins may help. But perhaps what's needed (admins+ only!) is "mass reversion" of a user's contributions (all or a defined subset) - a sort of anti-bot-bot. (Maybe this exists already?) Rd232 21:22, 14 August 2005 (UTC)[reply]
That's a damn good idea. If it doesn't already exist, it should be added. For accounts which are created "indisputably" in bad faith and which commit only vandalism(and there are plenty), when blocking there should be an option to revert all edits for which they are last(and obviously if they have a chain of edits at the end, go to the last edit not from the bad account). That's not foolproof but it would be very helpful. If something similar already exists, forgive my ignorance(though I would like to hear more about the feature). Superm401 | Talk 03:57, August 20, 2005 (UTC)
I second the need for a single-click page move revert. In addition, we also need a way to see new user accounts (is there a way already I don't know?) since I think they need to age for a week or so before they can be used for page moves. Or how about requiring a certain number of edits (10? 25? 100?) before the account can be used for page moves? Page move vandalism is so much harder to deal with than the "regular" kind that I think some slightly higher bar must be reached for a new user before page moving is possible. Antandrus (talk) 19:47, 15 August 2005 (UTC)[reply]
I think that's reasonable. It's quite easy to get an admin or veteran editor to help and the need for page moves is much rarer than edits, obviously. Superm401 | Talk 03:57, August 20, 2005 (UTC)
Format of bulleted "What links here" list
I am confused about the meaning of the various bulleted lists one gets on a "What links here" page (and I might have found a bug). For example, suppose, on the "What links here" page for "AA", I get:
I've understood this to mean that "X" and "Z" link directly to "AA", while "Y" links to "BB", which is a redirect to "AA".
Is that the idea? If not, please explain. But if so, I've found a bug.
Explanation: A few days ago, I edited Template:R.E.M. to link to "Eponymous" (one of the R.E.M. albums) indirectly, through the redirect page "Eponymous (album)". Now, a number of pages that use the template, but include no other "eponymous" link, are listed in the position of "X" above, in the Eponymous "What links here" page, when it seems to me that they should be listed like "Y", with the "Eponymous (album)" in place of "BB". For example, the page "Bill Berry" is one of these.
(Note that this is different from the "Whatlinkshere problem" above.)
I think this actually is related to the Whatlinkshere problem above. Articles edited after a redirect appear in positions "X" or "Z". Position "Y" contains only articles edited before the redirect. Thus "X" or "Z" may contain articles without the name of the template whose list is being displayed. (SEWilco 21:22, 14 August 2005 (UTC))[reply]
Thanks; let me see if I understand. Apparently, entries for some article (say "X") are created in other articles' WLH pages when X is edited, and only then. Thus, X appears in the WLH page for AA if X referred to AA the last time X was edited. And how X appears in the WLH page for AA depends on how X referred to AA the last time X was edited. Therefore, when we change the way X refers to AA without changing X (by changing a template that X uses or a redirect to AA that X links to) we do not change whether X appears in AA's WLH list, nor do we change the way in which it appears. Is that right? If so, then I guess a quick do-almost-nothing edit to the mis-listed pages should fix things. — Nowhither 08:06, 15 August 2005 (UTC)[reply]
It depends what the definition of "mis-listed" is. And whether it is an index for which fixing is necessary. At present, you can read the "Y" entries as being articles whose editors wanted to use the template BB and have not yet approved the AA appearance. (SEWilco 18:48, 15 August 2005 (UTC))[reply]
The WLH page looks fine to me. I don't see any problems with it as described above. —Mike 23:42, August 15, 2005 (UTC)
An example of the redirected target linking is that Ancient Greece uses {{seemain}} (t/l) and not {{main}} (t/l). WLH:seemain does not show Ancient Greece, but WLH:main does (about halfway down a list of 500). (SEWilco 02:06, 16 August 2005 (UTC))[reply]
Articles that are not being watched by anyone
There should be a function to list articles that are not being watched, or being watched by less than x number of people. - Omegatron 00:07, August 15, 2005 (UTC)
see bugzilla:3128 - don't forget to vote for it if you want it implemented. Thryduulf 01:16, 15 August 2005 (UTC)[reply]
What is the use for the list? The list can also be called "Best pages to vandalize". (SEWilco 02:31, 15 August 2005 (UTC))[reply]
Voted. I was thinking more of a "this article is not being watched by anyone. Would you like to take it?" notice when a logged-in user visits such a page. - Omegatron 03:36, August 15, 2005 (UTC)
Perfect. And administrators should be able to see the whole list. ~~ N (t/c) 03:48, 15 August 2005 (UTC)[reply]
Anyone should be able to see the whole list. Superm401 | Talk 03:59, August 15, 2005 (UTC)
I've copied these comments to the Bugzilla page - Bugzilla:3128 - please make all further comments there, not here. Thryduulf 08:10, 15 August 2005 (UTC)[reply]
Shared IPs
I'm using the Direcway internet service, and its not working too well with wikipedia. At this moment, I'm currently logged out. When I clicked the edit link, I was logged in as Workman161, which is who I am. I'm finding it very very annoying that this is happening, as I am not getting credit for my contributions. Heck, look at my own User Page. Those two IPs in the history are mine, but if you view the contributions for them, there are about a hundred. Viewing the contributions under my name, you will find very few, because of wikipedia logging me out when I am actually logged in. --Workman161
Template:Divbox/2
Not all users enjoy the flexibility of the CSS box model; some go so far as to forget the plural of "box". Other users rely on boxes, especially those generated by pairs of <div> tags, to handle formatting tasks that were formerly done with tables. CSS is considerably more powerful than the old ways, though, and a bit tricky, too.
I created {{divbox}} to offer editors rapid, standard access to the box model, including a set of color-coordinated styles. Many have found a use for this and one editor created a new style. However, I've come across requests for more flexibility -- particularly, in floats and widths. (I've wanted these myself, but been content to substitute and edit.)
Please see the notes and demonstrations at Template talk:Divbox/2. You also might like to play with the new version and try to break it. Please leave your comments there before you go.
Thank You! — Xiong熊talk* 04:14, 2005 August 15 (UTC)
That's really silly! Thank you so much! --Celestianpowerhab 12:23, 15 August 2005 (UTC)[reply]
Image sizing issues
I have been trying to add to an article a reduced-size version of an image I uploaded. According to the imaging tutorial, to size an image differently from the file's actual size one needs to add a: 300px, or whatever size, to the command adding the image. This works fine, HOWEVER, if I try and then add a frame and a caption, then it ignores the size specification and reverts to the full size image. I could use a thumbnail, but then it is too small. I have been actually uploading smaller-sized images to circumvent this problem, but it would be nice to be able post a high-res image, and then display a smaller version, with a frame and a caption. Am I missing something? The image I last posted was Image:SynapseIllustration.png for the article Synapse. I originally had a larger version, but I had to post a low-res version in order to have it display properly in the article. Any suggestions? Thanks! Nrets 17:05, 15 August 2005 (UTC)[reply]
Say "image:foo|thumb|300px|right|Caption text" -- Finlay McWalter | Talk 17:27, August 15, 2005 (UTC)
Aha! Thanks! Nrets 18:08, 15 August 2005 (UTC)[reply]
Blocks washing off in the rain?
I have a feeling that users are becoming unblocked without any admin action. For example, I know that an account of the Willy on Wheels vandal were blocked indefinitely several months ago, yet it was able to vandalize recently.
Also, on en-Wiktionary, the vandal "ConneI MacKenzie" (impersonating user Connel MacKenzie) was blocked indefinitely, yet he disappeared from the IP block list, and no record of him being unblocked could be found in the block log. --Ixfd64 22:23, 2005 August 16 (UTC)
When an account or IP is blocked more than once with differing lengths, it becomes unblocked when the shortest one expires. ConneI MacKenzie was blocked for one week and indefinitely; therefore his block ran out after one week. —Cryptic(talk) 23:19, 16 August 2005 (UTC)[reply]
That sounds backwards. Shouldn't it be when the longest one expires? — Nowhither 23:57, 16 August 2005 (UTC)[reply]
That's what I thought too. --Ixfd64 00:03, 2005 August 17 (UTC)
You'd think, but the software probably checks the database every x amount of time for expired blocks, and then unblocks those cases, causing this behavior. — Ilγαηερ(Tαlκ) 00:06, 17 August 2005 (UTC)[reply]
The block list has become rather big, stressing both the server and client when retrieved. Could it perhaps be a good idea to check which indefinite username blocks are so old that they can be deleted, possibly in combination with deleting the account itsself? This is probably easiest for someone with SQL access. --fvw* 01:49, August 17, 2005 (UTC)
Perhaps the simplest thing is to scramble the password and blank the email address for any indefinitely blocked user accounts. No checking of the accounts' edits would be necessary; just a check that the block is indefinite. The block can then be removed.
I suggest that only accounts blocked a certain period of time ago - perhaps six months - be treated in this way, to make sure that no appeal against the block is in process.
I think there are a very small number of accounts which are blocked indefinitely but the block will be lifted after some condition is reached (e.g. legal action is resolved). If any of these accounts are scrambled by mistake, they can be restored to their rightful owners on application to a developer with proof of identity once the appropriate condition is met.-gadfium 03:47, 17 August 2005 (UTC)[reply]
I wish there was a way I could be alerted if a user is already blocked at the special:blockip page. Checking is such a pain. But some offensive usernames have been blocked over and over again because no one looked to see if already was. Or if someone has been indef blocked for being a reincarnation/sockpuppet, and I block them for 48 hours for petty vandalism, it wipes out the prior block. So often it's importent to check, but quite annoying. Dmcdevit·t 05:45, August 17, 2005 (UTC)
Yeah, but what about those with automatic cookie logins? Dunc|☺ 13:40, 17 August 2005 (UTC)[reply]
Blocks on IPs have to be checked every time the "Save page" button is pressed. But theoretically, a block on a username should only need to be checked once, at login time, so that we could have a billion username blocks with no strain on the server.
Currently, I guess it doesn't work that way, since you can still login when you're blocked, to respond to messages and so forth. But could we make it so, somehow? Wikipedia has a zillion read-only mirrors out there... why not make it so that when a blocked user logs in, they get sent to a read-only mirror server, maybe with a different domain name (but ours, not a third party's).
Could something like that possibly work? -- Curps 15:15, 17 August 2005 (UTC)[reply]
HTTP is not stateful, so blocking only at login is not actually sufficient. This is the same reason all web applications must validate all fields on a submit whether or not the entered data was prevalidated in the browser using something like javascript. In addition, if the user is redirected to a read-only mirror it seems like they wouldn't be able to write to their own talk page (which is currently allowed, even for blocked users). -- Rick Block (talk) 22:44, August 18, 2005 (UTC)
It's a good idea to remove all old (e.g. half a year or more) indefinite blocks from the list, and scramble the passwords. It's also a good idea to change the software so that you cannot block a user that is already blocked (to fix the one-day-overwriting-indefinite-block thing). Radiant_>|< 12:23, August 19, 2005 (UTC)
Google spiders a strange way...
Does anyone know how Google is spidering Wikipedia?
Recently I created a new article, James Harris Simons. I then posted a question about it at the Help Desk.
Now when I do a Google search for "James Harris Simons" Wikipedia, I noticed something curious:
The search results indicate that in almost no time, Google had cached the text appearing on the help desk -- including a link to the article -- but not the article itself.
Wikipedia:Help desk - Wikipedia, the free encyclopedia
For policy and technical information see Wikipedia:Village pump. ... Note that
I've moved the article to James Harris Simons, and created appropriate ...
en.wikipedia.org/wiki/Wikipedia:Dead_ letter_office_(proposal) - 86k - Cached - Similar pages
Isn't this a bit odd? Just curious, really. Paul Klenk 10:23, 17 August 2005 (UTC)[reply]
I'm just talking out of my ass right now, but could it be because the help desk has a high page rank? I imagine those pages get updated alot more often than other ones. And if your article doesn't have that many links to it (which it appers it doesn't have) that would have a pretty low page rank? Although, I don't see how it can have a low page rank if it doesn't exist......As I said, I'm talking out of my ass (it's really quite a useful expression). What creeps me out the most, and this happens often with google is when it says 'Results 1 - 4 of about 8 for "James Harris Simons" wikipedia. (0.10 seconds)". Where's the other 4????? Scaaary!gkhan 10:48, August 17, 2005 (UTC)
I think I understand your point. But here's where I have a problem: Let's say that the help desk page has a high page rank. Fine. But since my comments on that page have been spidered, including the link to the new page, then shouldn't Google have spidered that link and added it to its list of pages? Anyway, this is just a question of pure curiosity, nothing else. Thanks. Paul Klenk 11:32, 17 August 2005 (UTC)[reply]
Yes, I realised that point myself, and honestly I don't know. They should spider the link pages. Maybe they have like two processes, one that updates pages and one that spiders, because spidering (I'm guessing here) is more computationally expensive. Maybe they hide pages with really low pagerank (ie. the "Showing 1-4 out of 8" thing). Anyway, someone with more knowledge into the arcane beast that is google should probably answer this. gkhan 12:14, August 17, 2005 (UTC)
We're getting large and important enough so we can speak directly to Google management and ask them to spider our site in a particular manner -- if we can agree on what we want. — Xiong熊talk* 21:37, 2005 August 17 (UTC)
Either they omitted results which they deemed unuseful or they estimated (I get results on gmail searches that say '1-10 of hundreds' :-\ — Ilγαηερ(Tαlκ) 01:25, 18 August 2005 (UTC)[reply]
Layout problems
I am getting several weird (and possibly related) layout problems the last day or so when I use IE (which is my only browser at the office). They do not apply to all pages, but on some pages:
I do not get the section edit links
The body of the left nav bar is all the way at the bottom of the page
the main body of the page is shifted left, so the upper part is partly covered by the Wikipedia logo
When I edit, my edit box is too wide, with no scroll bar, so I can't see anything I type in the righthand portion of it. It's as if the box width were calculated on just the screen width, ignoring the fact that there are page elements to its left and right.
Any insights? -- Jmabel | Talk 17:08, August 17, 2005 (UTC)
What browser version and OS, and are you sure you’re editing the latest version of the page? Susvolans(pigs can fly) 17:13, 17 August 2005 (UTC)[reply]
Yes, I'm sure it's the latest versions of the pages. And even if it weren't that would hardly explain the bad edit box width. IE version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519. XP (SP2). -- Jmabel | Talk 19:17, August 17, 2005 (UTC)
Wikipedia is slow
Wikipeid is getting really slow. My time is getting wasted. Edits are failing.SEE HERE4.246.21.180 18:20, 17 August 2005 (UTC)[reply]
Does this link apply? (from the Viilage Pump - Technical box up at the top of this page)? TonywaltonTalk 18:40, 17 August 2005 (UTC)[reply]
Well, it was good not so long ago, and that post is from January, so while it's probably correct, it's really general. — Ambush Commander(Talk) 21:43, August 17, 2005 (UTC)
The target of that link is barely relevant today -- as AC notes, very general. I, too, would like to know why we are having such terrible and persistent troubles. — Xiong熊talk* 21:58, 2005 August 17 (UTC)
Don't always get a notice when I have new messages
For the last couple of days, sometimes (and I can't figure out when it does and doesn't happen), I haven't been getting a notice at the top of the page when I have new messages on my Talk page. I only notice it when I am looking through Recent changes and see that somebody has edited my Talk page. But like I said, it isn't consistantly a problem. Zoe 06:23, August 18, 2005 (UTC)
I've been having the same problem—only I notice it when I see the edit show up on my watchlist. — Knowledge Seekerদ 06:26, August 18, 2005 (UTC)
Exactly the same thing here. — Ilγαηερ(Tαlκ) 02:31, 19 August 2005 (UTC)[reply]
Likewise... it's not consistent, and it developed within the last two days. Antandrus (talk) 02:37, 19 August 2005 (UTC)[reply]
Don't always want a notice when I have new messages
I have disabled my yellow message, and wish I could do so in a more straightforward manner than creating a separate account to redirect my talk page to. It irritates me no end, affects the page layout when it comes up while editing as you can't reach the bold text etc horizontal line without scrolling, doesn't switch off if you access your talk page through diffs (from the watchlist, which I always do after somebody redirected my talk page to an obscene picture). Does noone else feel the same way? Is there an easier way to disable it? If not could one be added to preferences, SqueakBox 02:47, August 19, 2005 (UTC)
You can simply change your user stylesheet (if you are using the Monobook skin, it's at User:SqueakBox/monobook.css) and add a rule to not display these messages. I believe the correct rule to do so is ".usermessage { display: none }" (without the quotes). See Help:User styles for more information. --cesarb 17:58, 19 August 2005 (UTC)[reply]
Fantastic. Works a treat. Cheers, SqueakBox 00:04, August 22, 2005 (UTC)
Article content in the edit summary when deleting a page
Why is it that sometimes the contents of the article shows up in the edit summary when I go to delete a page, and sometimes it doesn't? Zoe 07:56, August 18, 2005 (UTC)
I believe if it's a certain length it will include it in the reason field, but when it is longer, you have to fill it in yourself. Dmcdevit·t 08:09, August 18, 2005 (UTC)
images not showing for some browsers
images not visible in article or image page, but image itself is fine. problem described at Talk:Eugenics#Main_image. seems to be a problem with some users of firefox. can you see this?
i notice the style="visibility: hidden ! important; tag. --Rikurzhen 02:18, August 19, 2005 (UTC)
I see it, and I'm using firefox 1.0.6 — Ilγαηερ(Tαlκ) 02:29, 19 August 2005 (UTC)[reply]
Don't know if this is the right place to post, but I have a question about the "What Links Here" function. I use it often to find related pages to edit, but going through all of the links can be clumsy.
Is there any reason the "What Links Here" couldn't be organized into catergories for easier browsing?
Like a catergory for "References in other Wiki articles", "Redirects", and "References in non-article Wiki pages (like user profiles and help pages)". I'm really only interested in seeing references from other articles, and it seems a little clumsy to have to go through a bunch of links I don't care about.
Sorry if this was suggested before --Rc251 02:58, 19 August 2005 (UTC)[reply]
This would be nice. I don't have much hope of it happening, though, since it involves change to the software for a not-terribly-huge benefit.
Another problem is the handling of redirects. To avoid the necessity for huge searches, pages are placed in the what-links-here list for the articles they link to at the time the pages are edited. If the situation of a page changes, without the page itself being edited, then the list is not updated, and so the list is incorrect.
Here is an illustration. Suppose page "X" uses a template that links to page "AA". Then the template is changed so that it links to "AA" indirectly, through the redirect "BB". Until page "X" itself is edited, it will still be listed in the what-links-here list for "AA" as linking directly.
This is not such a big deal now, but if we were to do categorization, then I think we would want it to be reliably correct, which would require fixing this issue, which would increase the load on the server.
Sorry to be so negative. — Nowhither 12:36, 19 August 2005 (UTC)[reply]
Trouble displaying GIF files
I realize GIFs are not the preferred image format, but I am having trouble getting them to display. They seem okay on other peoples' pages.
I've scoured WP for help on this, but found nothing. Can someone please give me some help?
Which image is causing you trouble? Also, see two sections up about the Eugenics image, and see my answer on the referenced talk page about why some images don't display for some people.-gadfium 05:08, 19 August 2005 (UTC)[reply]
Short Pages glitch?
When looking at the Short Pages page, a number of pages show up as zero length which have substantial content. For example, Our Gang was last edited on July 21, is 39K, and hasn't been vandalized to empty anywhere in the recent history. But it shows up as size 0 in Short Pages. Boojum 05:03, 19 August 2005 (UTC)
(And the link is red instead of blue!)[reply]
That list is cached. It's not always up-to-date. --cesarb 17:53, 19 August 2005 (UTC)[reply]
The IP Block List has "expires expires" for every block that isn't indefinite. Zoe 06:27, August 19, 2005 (UTC)
This is fixed. And welcome back, Zoe. -- Tim Starling 01:36, August 21, 2005 (UTC)
Why does my watchlist fail to show articles that were edited 1 month before current date?
When I select 'Show all', my watchlist only lists articles that were edited within the last month.
On 16 Aug, it only showed articles edited between 18 Jul and 16 Aug. When I select 'display and edit the complete list', the complete list included articles edited before 18 July. The list only had 174 pages.
Today (19 Aug), it only shows articles edited between 22 Jul and 19 Aug. When I select 'display and edit the complete list', the complete list includes articles edited before 19 Aug. The list only has 81 pages.
Am I the only one experiencing this problem? How do I fix it? Bobblewik 13:02, 19 August 2005 (UTC)[reply]
There's a cut-off. It prevents over-loading the server. [[smoddy]] 17:13, 19 August 2005 (UTC)[reply]
Aha. I thought it was unintended. Thanks for replying. I thought it was broken because it has the options: Show last 1 | 2 | 6 | 12 hours 1 | 3 | 7 days all
The term all is misleading. Could all be changed to a number of days as in Recent changes? For example: Show last 1 | 2 | 6 | 12 hours 1 | 3 | 7 | 30 days
Would it be possible to make it a rolling list just like Recent changes. That has very similar options, no cut-off, and permits me to go backwards in time page by page as far as I want. Bobblewik 17:48, 19 August 2005 (UTC)[reply]
I suggest you make a feature request on Bugzilla. Cheers, [[smoddy]] 18:27, 19 August 2005 (UTC)[reply]
Has this changed recently? It used to show changes back to year zero... -- ALoan(Talk) 18:40, 19 August 2005 (UTC)[reply]
IE 6.0 - How do I prevent this error message in IE 6.0?
"Warning: Page has Expired The page you requested was created using information you submitted in a form. This page is no longer available. As a security precaution, Internet Explorer does not automatically resubmit your information for you.
To resubmit your information and view this Web page, click the Refresh button."
I get this message when I am editing an article and then temporarily go to another article or an external link for reference. Upon returning to the editing page, I have to refresh as directed by this message, and it takes quite a while.
This doesn't happen with Firefox or my home IE, of which I'm not sure of the version number. I tried Tools>Internet Options>(Temporary Internet Files) Settings both to automatically refresh the page and to refresh every visit to the page. Is there some other setting somewhere?
One way is to open a second browser window to go to the external link or other article, then return to the original window, continue editing and save your results. Paul Klenk 19:25, 19 August 2005 (UTC)[reply]
Thanks, Paul. It looks like I'm a victim of using two browsers. Since Firefox is my favorite at home, and of course I have to use IE at work, I'm in the habit of using control-click to open links in new tabs in Firefox. That same action in IE does nothing, it just opens the link in the current window. Before Firefox, I was in the habit of using shift-click, which opens the link in a new window in both browsers. But now I realize I have been trying control-click at work, and having a vague feeling that it used to work. Ahhh, habituation. I would like to find the root cause of this problem, though, even if for nothing else other than curiosity's sake. Spalding 23:24, August 19, 2005 (UTC)
Opera, at least on my machine, doesn't appear to display tables properly. Specifically, it doesn't display the lines which demarcate table rows. What could possibly cause this? I'm using Opera 8.2 on a Windows 2000 box. Mackensen(talk) 21:21, 19 August 2005 (UTC)[reply]
Opera 8.0 on XP shows the same problem (I checked it on monobook and classic). That table uses "prettytable", but removing that didn't fix it. So I suspect it's a problem in the basic CSS stylesheet. -- Finlay McWalter | Talk 21:33, August 19, 2005 (UTC)
I made this suggestion at (proposals), and it was recommended that I bring it here. So, here it is:
Would the developers be willing to put in a #top link next to the edit button at the top of each ==Section== or ===Subsection===? I think most browsers now automatically predefine the top line of an HTML page as <a name=#top></a>. Alternatively, it shouldn't be so difficult (I say, as I sit here coaching from my easy chair) to predefine all the article pages with a hidden #top.
Would this be worth the added clutter when you can just press Home? ~~ N (t/c) 22:31, 19 August 2005 (UTC)[reply]
Oh cool! Thanks ptar! I dinna know you could do that! :-p /me makes note: that was my one thing I learned today. TomerTALK 22:40, August 19, 2005 (UTC)
Glad to help. ~~ N (t/c) 22:44, 19 August 2005 (UTC)[reply]
The last part is in the code already. As to the proposal, I don't think it necessary. There may be a piece of Javascript you could use to do your settings only. [[smoddy]] 22:33, 19 August 2005 (UTC)[reply]
How to send messages
I have received messages, but do not know how to respond. How can I send a message to someone? - NWOG
For complex articles (Such as is Sustainable energy) which by definition refer to a list of other articles, I would like to see Articlespace partial transclusion. That is the ability to transclude only the opening section of a referenced article. This in general would expand lists to be readable articles without creating duplicate and forkable information. Benjamin Gatti
{{:Wind power/Main|noimage}} should produce the opening section
No. That just encourages lazy editing. If you're going to include information about a secondary topic, summarize it yourself and relate it to the main topic. You don't want the same information about coal power for the environmentalism article as you do for the fossil fuel article. This is why transclusion is strongly discouraged. Superm401 | Talk 16:12, August 21, 2005 (UTC)
Random article bug?
I've been using the Random article link a bit and, with 2/3 million articles to choose from, the probability of seeing an artice twice should essentially be zero. However, I've just had Nacirema for a second time and am sure that a couple of others that I didn't make a note of have also repeated in the last few weeks. Has anyone else noted this behaviour? I presume the random number is intended to be from a Uniform Distribution? Dlyons493 16:03, 21 August 2005 (UTC)[reply]
Hmm... Birthday paradox? anyway, it's really impossible to get really good random numbers: I doubt Wikipedia uses external sources (i.e. webcam/audio/static streams) to generate its random numbers: it might still be using PHP's internal pseudorandom number generator. Who knows? You can always take a look at MediaWiki yourself. ;-) — Ambush Commander(Talk) 19:51, August 21, 2005 (UTC)
Did some checking myself, it uses mt_rand called twice:
function wfRandom() {
# The maximum random value is "only" 2^31-1, so get two random
# values to reduce the chance of dupes
$max = mt_getrandmax();
$rand = number_format( mt_rand() * mt_rand()
/ $max / $max, 12, '.', '' );
return $rand;
}
I damn well hope not. That random number function is demonstrably awful, and I thought I fixed it 6 months ago. I'll look into it. -- Tim Starling 02:45, August 22, 2005 (UTC)
It was fixed in 1.5. That function was introduced by someone who was worried about the 32-bit granularity of the previous random number function, a complaint which I ignored because of the extremely low probability of observing any related artifacts. Unfortunately, they replaced it with something far worse. I spent some time thinking about how bad that function is, as a mathematical game. There's two effects: firstly, the distribution is skewed towards zero because the probability distribution of X2 where X is uniformly distributed is not itself uniformly distributed. Secondly, the probability of the integer $rand*$max*$max having lots of prime factors is higher than the probability of it being a prime number. I seem to remember there's a simple relationship between the number of prime factors and the probability.
Dlysons493 may simply be seeing chance coincidences, you'd expect such coincidences after about √700,000 = 837 requests. -- Tim Starling 03:12, August 22, 2005 (UTC)
Automated open proxy testing
When a block is applied to an anon IP address, the Mediawiki software should apply the block right away and then automatically queue an open proxy test to be done (either immediately or queued for later). If an open proxy is detected, the 24 hour block should be upgraded (automatically) to an indefinite block.
I believe such proxy checking software already exists and was running at one time. However, some ISPs objected to random, "unsolicited" probes of their address range to detect open proxies. But if it's one specific IP address that has visited our site very recently (ie, Internet traffic has been exchanged between our IP address and the ISP's) and has done something to warrant blocking, then a proxy check is perfectly appropriate and there would be no grounds for objection by the ISP. -- Curps 16:41, 21 August 2005 (UTC)[reply]
We can just scan every editor if we want to, the unofficial word from our colo is that they will stand up for us in the face of complaints. The only thing we're missing is software and a bit of system administration -- all proxy scans should be run from a single IP address. -- Tim Starling 23:27, August 21, 2005 (UTC)
Wasn't that already done before, and abandoned because too many IP blocks slowed MediaWiki down? --cesarb 23:56, 21 August 2005 (UTC)[reply]
It was abandoned because admins at other sites were complaining that we were probing them for vulnerabilities. -- Cyrius|✎ 00:17, 22 August 2005 (UTC)[reply]
Don't pay too much attention to Jamesday's speculation. Maybe that's why he wanted it switched off, but it's certainly not why it was switched off. Proxy scanning was switched off because Jimbo asked us to switch it off, and not to switch it back on again without asking him. He did this because of the large number of complaints received, and he was worried that it would jeopardise our internet access. More recently, a colo staff member told us that our internet access was not at risk, and that they have no problem with us doing this, as long as we warn them first. -- Tim Starling 02:36, August 22, 2005 (UTC)
Wikipedia:Copyright_problems Page Needs Sectioned
I just displayed the Copyright_problems page to check for an image on August 22nd. Even though I have a broadband connection the page took at least 15 minutes to fully download, possibly longer since I was tired of waiting and did something else. I noticed the comment about Wikipedia being slow and took that into account but the Copyright_problems page is just too slow to download because of its size and gets bigger every day. Also, the Village_pump_(technical) page is very slow too. I don't have any problems with much shorter pages.
My proposal is to separate each day on its own page with a link pointing to it from the main page. I know with regular coding this would be easy but with a table of contents and Wiki special coding to deal with I don't know if it can be done. If I knew how I would do this myself but I'm fairly new and still learning.
I'm using Firefox 1.0.6 and noticed the same results in IE 6.0 under Windows XP Home.
Section header underlines are now crossing through infoboxes (since yesterday evening) - it's never happened before on en wikipedia, tho' I have seen it on some other language wikis. Anyone any idea why this has started happening, and how it can be remedied? It looks awful! - MPF 13:47, 22 August 2005 (UTC)[reply]
Where’ve my messages gone?
I’ve had two messages on my talk page, but I wasn’t notified either time. Any ideas? Susvolans(pigs can fly) 16:18, 22 August 2005 (UTC)[reply]
\(caint) 01:07, 15 August 2005 (UTC)
Talk 18:40, 17 August 2005 (UTC)
i notice the style="visibility: hidden ! important; tag. --Rikurzhen 02:18, August 19, 2005 (UTC)
