Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
(Automated archival of 17 sections older than 7 days to Wikipedia:Village pump (technical)/Archive)
Line 582: Line 582:

:A large image uses more disk space, takes more bandwidth when transferred at full size, and requires more resources when being resized. It takes no more resources to refer to an already existing image of large size other than the network transfer.

:Generally, you should not worry much about little things like templates and "server load" at a policy level. If they're expensive, we'll either fix it or restrict it at a technical level; that's our responsibility. --[[User:Brion VIBBER|Brion]] 01:01, 21 January 2006 (UTC)

Line 589: Line 591:

:At the moment, very large PNG images are more expensive than JPEGs to resize due to the memory usage of the converted program. This is a technical issue and can be improved; we already have technical measures in place to restrict very large such images. --[[User:Brion VIBBER|Brion]] 01:01, 21 January 2006 (UTC)

Line 594: Line 597:

:Generally, if an image isn't usable in the encyclopedia you probably shouldn't upload it to Wikipedia. Remember that everything here must be freely licensed, and can and will be redistributed to and by third parties.

:If you don't want the picture of you, your cat, or your girlfriend to be copied, modified, reused, and redistributed by commercial and noncommercial publishers, don't put it on Wikipedia. --[[User:Brion VIBBER|Brion]] 01:01, 21 January 2006 (UTC)

Line 600: Line 607:

:As a design and usability matter, you should avoid unnecessary images which don't contribute something to the article.

:As a technical matter, it's our responsibility to keep the system running well enough for what the sites require. In other words: it's not a policy issue. If and when we need to restrict certain things, we'll do so with technical measures. --[[User:Brion VIBBER|Brion]] 01:01, 21 January 2006 (UTC)

Line 606: Line 617:

:Community space is a small fraction of total hits, and stock images that don't change much are not terribly expensive to serve. Definitely not an issue.

:Signatures are a different matter because of the way they multiply; a bad sig can pollute thousands of pages and is hard to clean up. This isn't really specific to images, but generally we have been cracking down on too much fancy stuff in sigs due to their tendency to break when "clever markup tricks" rely on software bugs which get fixed. --[[User:Brion VIBBER|Brion]] 01:01, 21 January 2006 (UTC)

Line 612: Line 627:

:"Policy" shouldn't really concern itself with server load except in the most extreme of cases; keeping things tuned to provide what the user base needs is our job. --[[User:Brion VIBBER|Brion]] 01:01, 21 January 2006 (UTC)

Revision as of 01:01, 21 January 2006

 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.

Technical archive

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.

Deleted history permissions

A couple months ago the software got tweaked to display history info (but not contained text) of deleted revisions to any and all random visitors. In the last few weeks we've gotten a rash of complaints about edits being made with private, embarrassing, vandalistic, libelous, etc stuff in the edit summaries etc, and of course deleting the revisions from the wiki still shows them to everybody.

For the moment I'm shutting off this ability (restoring the pre-August behavior) until we get more fine-grained revision deletion / scrubbing in place. I've added a permission key to control it, 'deletedhistory', so if there's a need to turn it back on this can just be added to the '*' pseudogroup in the config to restore the previous behavior. --Brion 20:02, 25 December 2005 (UTC)[reply]

This really sucks. It was incredibly useful to be able to see who deleted articles (as well as their reasons why), and in cases where an article was moved (with the redirect being deleted), this was an easy way to track down where a page went. —Locke Cole 23:13, 25 December 2005 (UTC)[reply]
I agree this makes it harder, but you can still track down who deleted a page through Special:Log. For instance, searching the log for Musterbation allows you to see that I deleted it as a copyvio. I successfully did this while logged out. --best, kevin [kzollman][talk] 22:11, 26 December 2005 (UTC)[reply]
Thanks for the tip kzollman, that'll work, even if it is a little more clunky. =) —Locke Cole 02:02, 27 December 2005 (UTC)[reply]
Deletion logs show why a page was deleted, it does not however, show why images are deleted. Could we have a deletion log for images? - Hahnchen 00:30, 28 December 2005 (UTC)[reply]
The problem with Special:Log is it lists only the deletion reason, not any information about how many revisions there were between deletions, and who made the revisions before deletion, their summaries, etc. --Mysidia (talk) 06:34, 15 January 2006 (UTC)[reply]
Agreed. :( —Locke Coletc 06:37, 15 January 2006 (UTC)[reply]
Was there any proper consensus or discussion about this? I've just found out about this, and have been looking around to find out why it had been changed. Anyway, I think this is a bad idea, because I do not think that the deleted history pages were libellous in any way. All it showed me was why the page was deleted, be it a CSD criterion or a link to an AFD discussion. I mean, all it showed were the edit summaries, and in general vandals don't concentrate their attacks on the edit summary, which was all that was displayed anyway. I would very much like this feature back, it may be minor, but it was useful having it there, and I'm sure Locke and I can't be the only ones who feel this way. - Hahnchen 02:45, 26 December 2005 (UTC)[reply]
We actually have been having a rash of vandals putting libelous comments into edit summaries, believe it or not. Things like people's home addresses and the like, too. —Bunchofgrapes (talk) 02:49, 26 December 2005 (UTC)[reply]
A very prolific vandal has been posting allegations of child abuse by Jimbo, along with his (more-or-less public) business address to various high-profile articles, leaving the nasty stuff in the edit summaries. This is a loophole that needs to be closed. I'm sure Brion will have a fix in place as soon as possible; consensus and discussion really don't apply to the devs as much as they do the rest of the project :-) android79 02:56, 26 December 2005 (UTC)[reply]
"Consensus and discussion really don't apply to the devs as much as they do the rest of the project" - that needs to change, and quick. Developers are quickly becoming the tail that wags the Wikipedia dog. In this particular case, why not just add the ability for admins to delete specific edit summaries, and those would then be replaced with a boilerplate phrase like "Libelous edit summary removed by User:Admin" or something of that nature. Firebug 01:10, 27 December 2005 (UTC)[reply]
Because your "why not just" is the "until we have more" part of my message above. That's the part that's more work than the temporary hack, which is why there's a temporary hack until that gets done. --Brion 23:23, 27 December 2005 (UTC)[reply]
This is ridiculous that just because of one vandal it ruins the site for everyone else. History of if an article has been deleted is an invaluable thing to see in articles - if something has been deleted you would think twice about recreating it and put more work into recreating it. If you dont show the histories articles will keep being recreated and deleted because no-one can see past reasons they've been deleted for. Isnt there a way to not show the edit summaries but still show the edits, or selectively delete some edit summaries where appropriate? -- Astrokey44|talk 12:35, 7 January 2006 (UTC)[reply]
  1. "just because of one vandal" is false; multiple different issues led me to disable this new feature
  2. "ruins the site for everyone else" is false; for the majority of Wikipedia's existence only sysops have had access to deleted history. Somehow we survived!
  3. "isn't there a way" yes, when there's time to put in the work as stated numerous times above, this will be done.
--Brion 16:52, 7 January 2006 (UTC)[reply]

Now there's a problem. In order to enforce accountability, we need edit summaries. But if edit summaries are submittable by all, theres no way to get rid of them. But if we allow people to edit edit summaries, there needs to be an audit trail for that to. And ad infinitum. WP:BEANS. — Ambush Commander(Talk) 02:55, 26 December 2005 (UTC)[reply]

I don't really see how it would be ad infinium; only admins would be able to edit edit summaries, and there would be no reason to have to edit and edit summary of an edit summary. Sure, it would be good to have an audit trail for the editing of an edit summary, but it would pretty much stop there; I don't see how you could possibly take any further audit steps. Also, to the argument that libelous edit summaries is a reason to restrict the undelete/log feature from regular users, we don't we delete major articles just because some vandal decided to vandalize it with a libelous edit summary? --Spring Rubber 05:18, 6 January 2006 (UTC)[reply]
I'd set it up like this - any user can "comment" (ie, append only) on an edit summary, admins can purge/replace an edit summary. An admin purging a malicious summary would basically purge the offending summary text (causing it to be replaced with "summary deleted" or similar text, and then comment on the edit with what it really was, therefore keeping the attribution/audit trail intact and keeping a meaningful summary. This implementation would also allow someone to add a summary to an edit which lacks a meaningful one - Triona 16:21, 16 January 2006 (UTC)[reply]

If this feature is to be disabled (which sucks) we should at least see the edit user account names (attribution) and dates of the revisions, (even without the edit summary reasoning text). It seems GFDL requires that attribution be made available, since the contents of any deleted article could have been copied to another article (this is extremely common, and no tracking is done or possible). Regardless of any legal requirements (which I don't know/understand) in principal, we should never hide who contributed to Wikipedia. Also, on a minor note, why the heck am I redirect to the main Wikipedia page after five seconds? This makes no sense. When giving the error message, please make it longer, and give me time to read it. --Rob 21:47, 26 December 2005 (UTC)[reply]

I thought seeing these histories was a really useful feature, it's unfortunate to see it disappearing like so; can we not have some method of flagging an individual edit as edit-summary vandalism, making the summary text invisible from that view, as a solution? Or limit it to registered users, with appropriate warnings about the possible nature of the Summaries to be accepted, and a well-hidden option in "My preferences" or a manual edit to one of those User-specific theme .js or .css files before being able to review any deletion history log: still better than nothing... --Mysidia (talk) 04:59, 28 December 2005 (UTC)[reply]

This appears to have changed again. Can not find an example, but it seems that when this was first disable non-admins could see if an article had been deleted or not before, by seeing the deleted edits message, even though it gave a permissions error; now it does not let you know if there have been deleted edits at all. I oppose this as it removes information regarding the article's history, making the fact that anything was deleted invisible; invalidating the comment above suggesting that if an article had deletions you could get some information from the deletion logs, now you would not have a reason to even begin looking in the logs. xaosflux Talk/CVU 02:08, 31 December 2005 (UTC)[reply]

  • It has changed again, and I implore the devs to fix this up. At least revert it so we can see that something has been deleted. If I'm thinking of writing a borderline notable subject article, I'd quite like to know whether it's been deleted before. - Hahnchen
I agree. It was a really useful thing to have there -- Astrokey44|talk 14:44, 4 January 2006 (UTC)[reply]
I'll look into adding some sort of "this page has been previously deleted" link to the deletion log now. Rob Church Talk 19:37, 12 January 2006 (UTC)[reply]
  • I believe this hack is -- extremely undesirable, as for "the majority of Wikipedia's existence only sysops have had access to deleted history. Somehow we survived!"; for the majority of Wikipedia's existence, users weren't required to register to create articles either; just because a feature wasn't present at one time, doesn't mean it is in any way disposable or not extremely helpful. This feature is important for examining the use of Speedy Deletion, in particular; until this is fixed, the Speedy Deletion procedures ideally ought to be temporarily suspended and that all materials to be deleted must pass through a Vfd, Tfd, etc, so that the state of their history can be reviewed prior to deletion to establish a reasonable level of accountability, unfortunately the backlog could be a nightmare; Speedy Deletes are periodically erroneous though, and this feature provided the only easy way to see the deleted revision record of an article (Whether it was one of a repeat speedy, or something else...). --Mysidia (talk) 03:06, 15 January 2006 (UTC)[reply]

GFDL issue

It is possible to violate the attribution requirement of the GFDL by hiding deleted history, since edits that are deleted may have had text cut and pasted elsewhere. If user names are visible, but not edit summaries, this issue will be resolved. The issue of using user names to libel can be solved by showing only IP addresses instead of user names judges libellous. --- Charles Stewart 02:40, 31 December 2005 (UTC)[reply]

  • Attribution information could in theory be placed in an edit summary, for instance, if a contributor was pasting a blurb of GFDL'ed content originally published elsewhere. --Mysidia (talk) 09:46, 4 January 2006 (UTC)[reply]

As an admin I didn't realise anything had changed since I can still see everything, but I think it's important for people to see which admin deleted an article. That might explain why I haven't been receiving complaints about deletions recently - your average user doesn't know to check the logs! I find it important for me to be able to explain to new users that it's nothing personal and that they can improve for next time. enochlau (talk) 04:44, 13 January 2006 (UTC)[reply]

After something was deleted, I would always click the link at the top of every deleted page just to see who deleted it and what their reason was, even if it was a completely obvious speedy deletion. I guess I'm just curious about those types of things. Now, when I tag something for deletion, I have to go to the deletion log, copy the article's title, and paste it in the deletion log; repeat ad nauseum for everything I tag (which, lately, has been images), but one thing the whole lengthy process has taught me is that you, Enochlau, have been the deleter of 90% of the images that I tag for deletion, and for that I am thankful. --Spring Rubber 05:52, 15 January 2006 (UTC)[reply]

Texvc patches

I don't know if this is an appropriate place to do so, but I'd like to draw attention to four texvc bugs that I wrote patches for a few weeks ago. Please could a developer review them and perhaps commit them? I'd especially like to see the colour patch in Wikipedia. Here are the bugs: #1663 (colour support), #2026, #3052, #4000. Lupin|talk|popups 01:42, 7 January 2006 (UTC)[reply]

You should have had four emails corresponding to four commits I made. Rob Church (talk) 15:24, 13 January 2006 (UTC)[reply]
For some reason I only got one, but I noticed that you'd commited the changes. Thanks! Do you know when these will take effect in wikipedia? Lupin|talk|popups 18:16, 20 January 2006 (UTC)[reply]

Wikipedia disables ALT-E?

(copied from Wikipedia:General complaints) I spotted a comment on the resolved complaints noting that Wikipidia disables ALT-E? I've been pulling my hair out for a while trying to figure out why I can't use ALT-E in Explorer when in Wikipedia to open up Explorer's Edit menu, in the same manner I do in hundreds of other applications. For people using a keyboard, rather than a mouse, this kind of remapping is very painful. How does one disable this on a user by user basis to return normal functionality? I can't find a mention to this except in that resolved comment. Nfitz 19:18, 10 January 2006 (UTC)[reply]

I think this can be undone by editing your personal css page, but that is not simple. i am copyign this to the technical section of the village pump. I have complained about the wikipedia take over of common shortcut keys on Bugzilla before this. DES (talk) 21:13, 10 January 2006 (UTC)[reply]
  • A standard shortcut that still works is Alt key, then E, which still brings up the edit menu, by the way, and not both Alt and E at the same time. If the "Edit this page" shortcut is a problem, you could also change your theme to something other than Monobook, such as Classic. I think the Alt+E shortcut for Edit This Page is really, very useful; as a keyboard user, it would be a pain to use the Wiki without the benefit of this shortcut. Internet Explorer and Firefox don't even have much useful stuff on the Edit menu, and all those commands have their own shortcut keys. --Mysidia (talk) 06:31, 11 January 2006 (UTC)[reply]
    • As a data point, pressing alt, releasing and the E doesn't work on firefox for me under linux. Lupin|talk|popups 21:34, 12 January 2006 (UTC)[reply]
  • I can see a shortcut for this would be useful. But I don't think that remapping the standard shortcuts that are already in use for basic Windows (which, like it or not, is the most widely-used browser), is sensible. Sure, there are work-arounds to still do it in Windows ... but this is just going to create problems for users who then have to remember different key-stroke combinations for different programs. No application should interefere with the basic shortcuts! How do we go about either remedying this on either a user-by-user basis, or for the entire site? Some of the other skins than the default do seem to not have this remapping - though all are horrendous, and look ancient! Nfitz 17:16, 11 January 2006 (UTC)[reply]
Adding this to preferences has been requested more than once. To handle it in the meantime, you will need to edit your javascript, file, not your CSS file; go to User:Nfitz/monobook.js and copy in this line, then follow the instructions on the page to bypass your cache:
       ta['ca-edit'] = new Array('','Edit this page');
This line overrides the 'e' shortcut defined for "ca-edit" by the site-wide javascript file with the empty string ''. The lines to disable other common problem children, ALT-D (delete page or go to browser address bar?) and ALT-F (Find box, or browser file menu?) are as follows:
       ta['ca-delete'] = new Array('','Delete this page');
       ta['search'] = new Array('','Search this wiki');
Hope that helps....going to go add this to the Keyboard Shortcuts page now. — Catherine\talk 03:15, 16 January 2006 (UTC)[reply]
Wonderful!! Much appreciated! Nfitz 19:59, 17 January 2006 (UTC)[reply]

edit window tool box

Hi ,In the hebrew version of wikiepdia the Java edit toolbox is much mroe extensive ,I was wondering how One could use a more extensive functional box in here?

morevoer it seems I can't get color html fonts to work as my signature ,although the tagging is correct(I tried t in my sandbox) ,i get an HTML errorr while saving my new prefrences. Procrastinator 15:28, 11 January 2006 (UTC)[reply]

Looking at your personal sandbox, I see you have an unclosed tag (you are using [[User talk:Diza|<font color="green">talk2me]], while the correct version should be [[User talk:Diza|<font color="green">talk2me</font>]]. See Wikipedia:How to fix your signature for more information. --cesarb 18:45, 11 January 2006 (UTC)[reply]
Thank you cesarb ,I've already fixed it. Yet regarding to my open query about the seemengly simplified version of the Java box... -Procrastinator talk2me 12:58, 14 January 2006 (UTC)[reply]
As you might have noticed, some people have been playing with it recently (it's at Mediawiki:Edittools, if you want to follow the discussion). --cesarb 04:45, 15 January 2006 (UTC)[reply]

subst titlde includeonly breakage

Some reecent change of the mediawiki software has made the tilde expansion from templates errorious. Until today if a template contains ~<includeonly>~</includeonly>~~, it will expand the the current editors signature (used in {{tfd2}} for example). But now it will save it to four tildes, and expand it on the next editor, breaking everything up and put wrong signatures on the wrong place, and is also possible to use for abuse and etc.

Example: Here I subst tfd2, and the editor after me will get it's signature added here. ==== [[Template:{{{1}}}]] ==== [[Template:{{{1}}}]]
{{{vote}}} — {{{text}}} Nurg 02:25, 12 January 2006 (UTC)[reply]

Would be good if the previous behavour is restored, othervise a lot of template and procedures must be changed, and probably a lot of people will be angry when their singatures is placed where they didn't put them. AzaToth 23:04, 11 January 2006 (UTC)[reply]

Yes, I'm angry already. I never put my sig there.  :-) Nurg 05:59, 12 January 2006 (UTC)[reply]
This is fixed now. -- Tim Starling 15:55, 12 January 2006 (UTC)[reply]
IMO this trick is a poor ideqa, because one can never be sure it will contiue to work. DES (talk) 21:50, 12 January 2006 (UTC)[reply]
If automated testing is performed, this should be added as a test-case. —Locke Coletc 22:15, 14 January 2006 (UTC)[reply]

Something strange with CSS styles

I just updated {{Policy in a nutshell}} to use the standard CSS class "messagebox" which specifies width="80%"; the template formerly specified this width explicitly. For some reason, this template is now displaying slightly wider than other templates using the same styling: see the top of WP:NOT for a salient example, where {{Policy2}} and {{Policy in a nutshell}} both use class "messagebox" with no further alteration of "width". What's happening? Has my browser thrown a gear? Or could it possibly be because {{Policy2}} uses table syntax whereas {{Policy in a nutshell}} uses <div> tags? —Phil | Talk 11:34, 13 January 2006 (UTC)[reply]

I've no idea what causes it, but I fixed it the obvious way — by wrapping the div in a table. —Ilmari Karonen (talk) 14:57, 13 January 2006 (UTC)[reply]
Why would you wrap anything with a table? We're 2006 now... --Joris Gillis 16:40, 16 January 2006 (UTC)[reply]

Special Characters

My special characters box appears to malfunctioning; it has what appears to Vietnamese under 'Spanish', IPA (which it calls API) under 'Welsh', Old English under Maltese, Maltese under Italian etc. Does anyone know what's happening? I'm using FireFox. smurrayinchester(User), (Talk) 15:17, 13 January 2006 (UTC)[reply]

It seems to be solved now. Thanks! smurrayinchester(User), (Talk) 16:35, 13 January 2006 (UTC)[reply]

Whoever wrote that (IMO superfluous) code should either use display: none or (for no good reason) visibility: hidden and not the former and visible: hidden (sic)! onclick="insertTags()" is also much cleaner than href="javascript:insertTags()". Christoph Päper 23:36, 13 January 2006 (UTC)[reply]

The changes to the special characters bar make it hard to get to characters needed for typing articles on Japan. Every time I edit an article, it's necessary to select from the drop-down menu before the characters I want appear. Worse, my selection doesn't remain in effect when I click on Show preview or return to editing after Show preview. Is there a way to get around this? I want the characters that are on the "Romaji" menu selection to replace the European special characters, which I seldom use. Fg2 07:11, 14 January 2006 (UTC)[reply]

The problem seems to have returned, with the IPA box containing Cyrillic instead. smurrayinchester(User), (Talk) 11:21, 14 January 2006 (UTC)[reply]
There is an experimental code currently being discussed at Mediawiki talk:Edittools which saves the current selection in a cookie. --cesarb 04:48, 15 January 2006 (UTC)[reply]


Has the sig code been messed with again? My four-tildes sig is coming out as just

While it should be

My preferences still shows my sig as being "— [[User:Asbestos|Asbestos]] | [[User talk:Asbestos|<FONT COLOR="#808080">Talk </FONT>]] [[User:Asbestos/RFC|<FONT COLOR="#808080"><small>(RFC)</small></FONT>]]", with "Use Raw Sig" clicked. Any thoughts? Asbestos 16:12, 13 January 2006 (UTC)[reply]

Hmm, testing AzaToth 16:21, 13 January 2006 (UTC)[reply]
I just noticed it too, with my sig which should be "—Kmf164 (talk | contribs) 16:37, 13 January 2006 (UTC)". Not sure what's going on? Kmf164 18:56, 13 January 2006 (UTC)[reply]
It works for me AzaToth 18:59, 13 January 2006 (UTC)[reply]
It works now. But, an odd glitch. Kmf164 20:06, 13 January 2006 (UTC)[reply]
Not for me — and not for you either if you sig is supposed to be the one you noted earlier. — Asbestos | Talk (RFC) 02:02, 14 January 2006 (UTC)[reply]
Don't know what's going on. My sig was working in the preview mode. I just tried modifying it without the — and it seems to work. -Kmf164 (talk | contribs) 02:17, 14 January 2006 (UTC)[reply]
There is some related discussion currently on Wikipedia talk:How to fix your signature. --cesarb 22:58, 14 January 2006 (UTC)[reply]

Special character box

Somebody changed that special character box today. And now I have huge troubles contributing in my language (Lithuanian). So who should I contact? I would like to see Lithuanian language having its own section in the drop down meniu with these symbols: Ą ą Č č Ę ę Ė ė Į į Š š Ų ų Ū ū Ž ž. Please let me know who is in charge of these changes. Renata 18:17, 13 January 2006 (UTC)[reply]

  • While i am glad to have the enormous box cut back to reasonable size, some change along those lines sounds called for. (The grouping by base character rather than by diacritic added is also much more workable; keep that no matter what the outcome.) I note that the AE and OE quasi-digraphs were included, but not the lower-case-only "Ess-Tzet" or ß in German (often mistaken for Beta, and the single-character title of an article ) and the two characters (each with upper and lower) from Icelandic and Old English whose sounds are roughly those of TH in "that" and "thin" (Edh or Eth, and Thorn, respectively). I make a brief for all of those 5 graphics (3 lower case, 2 upper), since (like Æ and Œ but moreso) 4 of them require wordy explanations such as i used here, and very wordy instructions to be sure people will recognize them beyond doubt when they see. (Upper-case Edh is the exception: "Capital D, with a bar crossing the vertical stroke" is not that wordy.) Even the Lithuanian chars requested can be described as one of the 26 English letters with "a tail hooked to the right" or a "dot" or "tiny V" on top, and similarly e.g. Polish has tails i recall and the "slashed L" for Lech Wałęsa's proper spelling. Finally, thanks for the Euro, but IMO the Yen is also international enough to deserve its currency symbol's inclusion. If a set of drop-downs or single-puprose pages for various languages is not feasible, how about at least a prefs option for the form the box takes, including the exhaustive one as an option?
    Jerzyt 20:01, 13 January 2006 (UTC)
  • Check out MediaWiki:Edittools (the talk page anyways), there's some discussion towards the bottom there. —Locke Coletc 20:25, 13 January 2006 (UTC)[reply]
  • what drop down manu i don't see any! Plugwash 23:46, 13 January 2006 (UTC)[reply]
    • You need to go to a page (almost any will do) and reload/refresh. —Locke Coletc 02:36, 14 January 2006 (UTC)[reply]

Access errors

I keep getting "Access control configuration prevents your request from being allowed at this time" messages about 80% of the time right now. Are there some maintainance work underway or is one of the squids having trouble? All the errors I get are generated by (squid/2.5.STABLE12). --Sherool (talk) 21:51, 13 January 2006 (UTC)[reply]

That message usually means your IP was explicitly blocked in the server configuration, and will not go away by itself. --cesarb 03:00, 14 January 2006 (UTC)[reply]
IIRC (and one of the other devs will correct/elaborate as needed), there were some problems with Hawthorne. AFAIK, they're now resolved, but do let us know if this persists. Rob Church (talk) 04:12, 19 January 2006 (UTC)[reply]

Javascript bug

Error: missing ; before statement
Source File:
Line: 280, Column: 58
Source Code:
    var menu = "<select style=\"display:inline\" onkeyup="chooseCharSubset(selectedIndex)" onChange=\"chooseCharSubset(selectedIndex)\">";

Looks like someone forgot to escape the quotation marks. howcheng {chat} 00:23, 14 January 2006 (UTC)[reply]

This should be fixed. I blame Brian0918. :P FYI: The file this was in is MediaWiki:Monobook.js. And you can really blame me, I wasn't literal enough in my suggestion, heh. =) —Locke Coletc 02:34, 14 January 2006 (UTC)[reply]

monobook.js rendering as wikitext sometimes?

Right after I save my monobook.js, it renders as wikitext. I saw this and thought, "hey, I'll put wikitext inside javascript comments and javascript inside <nowiki> tags, and it will be both a functional javascript and a well-formatted page at the same time. When I tried it, it looked like this:


But then I noticed that it doesn't stay like that. If I view it on a different (browser? computer? I'm not sure what has to be different), or log out and view it as an anon, it just shows plain text, and stays that way until I save it again. Now it looks like this:


Why does it do this? Is there a way to get it to always render as wikitext, or should I revert back to plain javascript comments for documentation? — Omegatron 03:53, 14 January 2006 (UTC)[reply]

I believe it has a feature which automatically renders both user js and user css as plaintext. Sometimes it doesn't work, for some reason. Perhaps the when saving it uses a different code path. --cesarb 04:18, 14 January 2006 (UTC)[reply]
It may not be a good idea to do that anyways, as it loads on every wikipedia page you visit, making you have to load invalid js. — Ilyanep (Talk) 06:04, 15 January 2006 (UTC)[reply]
I've found that purging the cache makes the page render correctly as plain text almost all the time. Titoxd(?!? - help us) 19:09, 15 January 2006 (UTC)[reply]
It's not invalid because the extra stuff is just a comment as far as js is concerned. I thought it would be a neat way to combine the best of both worlds, but apparently the parsing of wikitext is a bug, not a feature. — Omegatron 04:09, 16 January 2006 (UTC)[reply]

My Signature

My signature is supposed to look like this: JarlaxleArtemis. Instead, it's just plain. JarlaxleArtemis 06:18, 14 January 2006 (UTC)[reply]

See Wikipedia:How to fix your signature. --cesarb 15:37, 14 January 2006 (UTC)[reply]

Redirects to categories

I notice redirects to categories have stopped working again. Shortcusts like CAT:CSD or CAT:NS and such no longer work properly, the contents of the category is not visible. I though this very bug was fixed some time ago, at least ut has worked fine for some months, but not so anymore. Wassup! --Sherool (talk) 17:07, 14 January 2006 (UTC)[reply]

Fixed again. Domas is trying to make page loading more efficient but had managed to break redirect handling a couple of times. I've reverted the changes pending correction. --Brion 20:30, 14 January 2006 (UTC)[reply]

/w/index.php doesn't check integrity of data before committing edit to article

  • The problem: Here's how the bug can be recreated, and why it's actually a MediaWiki bug:
  1. I started editing a section of the page.
  2. At some point I wanted to "Show Preview". Obviously, I somehow clicked the "Save Page" button instead, unknowingly -- classic error.
  3. However, right after clicking the button, I saw a typo in the (still displayed) edit window: so I had the reflex to immediately hit the ESC key (shortcut for the browser's Stop icon) in order to cancel the operation and edit a bit more.
  4. But at this point, the browser had already started to POST the *first half* of the edit field's content, before it cancelled the sending operation (abruptly resetting the HTTP connexion).
  5. When the POST was aborted (from my side), the partial edit that had been sent yet was commited to the article instead of being ignored, resulting in a corrupted (and apparently vandalized) section of the page.

IMO, MediaWiki should NEVER have accepted to commit to the database a half-sent contribution, whose POST operation was aborted and never completed, and thus whose integrity was undefined.

  • A solution: Now, one really simple and reliable software solution is:
  1. In the HTML code for the edit form, to add just before its ending </FORM>, a hidden field with a static "magic value", such as:
    <INPUT TYPE="HIDDEN" NAME="EndOfForm" VALUE="Commit"></FORM>
  2. In the PHP code for "/w/index.php" that receives and processes our edits, to accept as a valid edit only an edit that did send the "EndOfForm" field and with the exact magic value "Commit".

The logic is of course that if/when the sending of the form is aborted by any mean before its full completion, then the server will never receive the last field, or its complete value (worst case scenario it would receive a partial "EndofForm=Commi"), and it should react by not writing to the database. Conversely, if the server did receive the exact "EndOfForm=Commit" parameter, then it can be sure to have received 100% of the data that was all before that, and it can safely commit it to the database.

  • An example: I've already detailled the whole affair (with links to diffs) on the talk page of the admin who thought I was vandalizing a page (he saw the article corrupted by the half-sent edit-in-progress that was commited to the database):

(I'm going to post this both at Wikipedia:Bug_report and Wikipedia:Village pump (technical) as per the advice on the bug-report's talk page...) 18:31, 14 January 2006 (UTC)[reply]

We have such fields already (or did have). Please confirm. --Brion 20:22, 14 January 2006 (UTC)[reply]
An HTTP post sends the character count before the data, so if the connection is interrupted before all the data has been transmitted the server can tell it didn't get all of the data. It's not clear to me where this should be detected, but at the protocol level enough information is already present to do so. -- Rick Block (talk) 21:38, 14 January 2006 (UTC)[reply]

Watchlist Changes

On village pump proposals, a consensus emerged to automatically add pages to their creator's watchlist and to warn (and preferably ask for confirmation) the last watcher of a page when they attempt to unwatch it. I've created a Bugzilla entry. Is anyone willing to implement this? Superm401 | Talk 19:05, 14 January 2006 (UTC)[reply]

Post further comments on the Bugzilla bug. Superm401 | Talk 19:10, 14 January 2006 (UTC)[reply]
That VPP link points to a non-existent location. --TheParanoidOne 20:05, 14 January 2006 (UTC)[reply]
The link has been fixed (I thought VPP stood for Village pump (proposals) but it actually stands for Village pump (policy)). Superm401 | Talk 21:17, 14 January 2006 (UTC)[reply]
On my to-do list. Will be assigned to self within 48-72 hours if nothing major crops up. Rob Church (talk) 04:14, 19 January 2006 (UTC)[reply]

Contributions from before creation of account

On my talk page, User:Democritus claims that he created his account last month; this is confirmed by the creation log. Nevertheless, Democritus' contribution list shows four edits from 2002. How is this possible? Democritus would like these contributions to be removed from the list of his contributions. -- Jitse Niesen (talk) 20:56, 14 January 2006 (UTC)[reply]

I believe that a user may have registered that address long ago in the dim and distant past. A software change, I believed, wiped out some of the records of names (or something along those lines), so a recent user could choose the same names and those edits from the history would be assigned to them. [[Sam Korn]] 21:04, 14 January 2006 (UTC)[reply]


The current Special:Blockip page sucks just a wee bit. I'd like to improve it, but I can't just go off willy-nilly adding things, without asking you lot what you'd like to see. Asking for ideas? Yes, I have gone off the bat. Still, your thoughts, suggestions opinions will be welcomed at - sign, please, so I know who to ask for more information on an interesting idea.

Ta, Rob Church (talk) 23:42, 14 January 2006 (UTC)[reply]

Bold links in navigation bar

Why did somebody remove the bold links from the sidebar? Before, if you were on a page with a link in the sidebar, it was bold. Also, is there any way that I can still get it in my wiki (MW 1.6devel, taken from CVS at about 12:00am Jan 15 EST) Thank you, Shardsofmetal [ Talk | Contribs ] 06:33, 15 January 2006 (UTC)[reply]

The bold had to be removed in order to facilitate a cache for the sidebar, which helps to increase performance. You'd have to hack the core code to put it back. Rob Church (talk) 04:16, 19 January 2006 (UTC)[reply]

Bad What links here

The what links here (WLH) is still very bad. Articles accumulate on WLH of certain templates. This makes the TfD process very difficult. For example we have substed and deleted template:ll after seen that WLH had stabilized. But obviously WLH of template:ll is still not stable as articles pop up now that really include the now deleted template:ll. Example: Al-Qanoon (permalink). Side note: WLH doesn't mark Al-Qanoon with "(inclusion)" even though it actually should. This makes the cleanup even harder. I'm working to fix now the newly appearing broken articles. --Adrian Buehlmann 09:31, 15 January 2006 (UTC)[reply]

Yeah, it's clear {{ll}} was deleted too soon. There are still lots of pages using it. I'm going to be bold and restore it until it's really subst'ed everywhere. --Angr (tɔk) 09:41, 15 January 2006 (UTC)[reply]
It only takes a few minutes for me to find all the instances of the template from the database dump, unfortunately the newest dump is a month old so it isn't much help. If a new dump does appear I can sort it out though. Martin 11:43, 15 January 2006 (UTC)[reply]
Many thanks, Martin. I've fixed those newly popped-up articles on the WLH for now. I'm again watching that WLH. If that should be needed I will happily return to your offer. --Adrian Buehlmann 18:40, 15 January 2006 (UTC)[reply]

See bugzilla:4549 -- Netoholic @ 11:05, 15 January 2006 (UTC)[reply]

Thanks for the pointer. I've added also a warning note at the holding cell on the TfD page. --Adrian Buehlmann 18:40, 15 January 2006 (UTC)[reply]

I'm having some luck in finding links by adding "<includeonly>[[Category:Something]]</includeonly>", where Something is a short existing category. A bunch of entries will show up. Still won't be listed in What links here. We could use a standard Category:Temporary and maybe Category:Holding cell.

--William Allen Simpson 15:53, 16 January 2006 (UTC)[reply]
I added Category:Holding cell and some things showed up in it, and I orphaned them. However, according to "Rick Block" below, categories added by templates won't update article categories. So, why did some articles not listed in What links here show up in the new category? Were they already in some cache somewhere? Do we still have to wait for an edit to most articles before the rest of the changes are seen?
--William Allen Simpson 02:30, 17 January 2006 (UTC)[reply]
An excellent example is to compare Special:Whatlinkshere/Template:4LA with its Category:Ambiguous four-letter acronyms. I've eliminated virtually all What links here, but there are hundreds appearing in the category!
--William Allen Simpson 06:11, 17 January 2006 (UTC)[reply]

Special characters box

A lot of people have noticed the changes going on the "Special characters" box that appears below the edit box. There is now a line for special characters that are not alphabetic letters, followed by a drop-down menu that includes Wiki markup, math and TeX symbols, and several alphabets and special letters needed for writing in other languages, as well as IPA characters. If these aren't working as expected (e.g. you select "Spanish" but are given a set of Scandinavian letters to choose from), the first thing to try is a forced refresh (e.g. in Firefox 1.5, hit Control-F5). If that doesn't work, try purging your cache history and refreshing. If it still doesn't work, or if you have suggestions as to what special characters and letters should be added, please leave a comment at MediaWiki talk:Edittools. Thanks! Angr (tɔk) 09:36, 15 January 2006 (UTC)[reply]

ImageMagick for Linux

In order to use ImageMagick for linux, do you have to compile it? If so, is there a way to do so on a windows computer, and then upload it to a linux server? Also, in order for MediaWiki to use it, do you have to have all of the ImageMagick files, or just the convert file? Thanks, Shardsofmetal [ Talk | Contribs ] 15:52, 15 January 2006 (UTC)[reply]

Most Linux distributions should already have a precompiled version you can install. While it's possible to cross-compile it on Windows, it's not easy (as you'd first have to compile a cross-compiler). --cesarb 22:42, 15 January 2006 (UTC)[reply]

Log of uses of CheckUser/IP address storage of users on database/Privacy policy

I have made proposal at Wikipedia:Help_desk#¬¬¬¬\_How long are IP addresses logged and stored by Wikimedia?_/¬¬¬¬ -- 18:34, 15 January 2006 (UTC)[reply]


Hi, this image is without uploader info. --F. Cosoleto 22:22, 15 January 2006 (UTC)[reply]

Solved. --F. Cosoleto 23:42, 15 January 2006 (UTC)[reply]


Is it possible to have templates automatically "update" on every page they are utilized on once they have been changed? (sort of like how when a category is added/removed from a pages info the hyperlink to the page is added/removed on the Category page). I don't really know much about how Wikipedia works, so my apologies if this is a stupid question. -- 08:26, 16 January 2006 (UTC)[reply]

Templates do update on the pages they are used on, so the behaviour you describe already exists. --TheParanoidOne 10:33, 16 January 2006 (UTC)[reply]
Yes they do update and there is no way to say no to that besides making an own template for every new version of a template (For example version 1 of template:book reference could be made at template:book reference/1 and protected forever). Templates even break the promise of Wikipedia that you can always go back to an old revision of an article. Example: on article Bill Clinton, User:NetBot changed on this revision the parameters of the president box on the right side (diff). All revisions after that edit of that article now show a good president box on the right side. But all revision prior to that NetBot edit show a broken box (example: revision before that edit). See also this message on wikitech-l and my talk with Rick Block on this (User talk:Rick Block#Some toughts about templates). --Adrian Buehlmann 10:44, 16 January 2006 (UTC)[reply]
So do images. Superm401 | Talk 11:16, 16 January 2006 (UTC)[reply]

Actually, the template only updates once the page where the template is used is edited. i.e. Even if someone changes the president template, a president page itself doesn't change to reflect the new infobox until someone edits some aspect of the page in question. Thus, for pages that are less often edited, the alteration of a template used on the page often doesn't occur until much later. -- 18:34, 16 January 2006 (UTC)[reply]

I can't believe you. Can you provide any detailed examples and steps you have taken (with references to wiki pages). BTW: Please create a login for yourself. It does not hurt :-). --Adrian Buehlmann 18:45, 16 January 2006 (UTC)[reply]
That's only the cached version. Changing a template clears the cache of all pages linking to it. [[Sam Korn]] 20:30, 16 January 2006 (UTC)[reply]
There are some things in templates that aren't updated, like adding a category (if the template adds a page to a category, changing the category in the template does not automatically recategorize all referencing articles). So a more complete answer is formatting information is updated when a template is changed, but information contained in internal database records (categories, what links here, etc.) is not updated until the page is next changed. -- Rick Block (talk) 21:05, 16 January 2006 (UTC)[reply]

I see. Thanks for clearing that up. -- 01:00, 17 January 2006 (UTC)[reply]

CSS hack reduces accessibility

I just learned about a CSS hack being added to a number of templates, to compensate for a changed policy on template transclusion. I understand that there is an alternative way of recoding these templates, but the CSS hack is being implemented because it is easier. This hack injects junk code into the body of the page, then hides it from most visual browsers using CSS. This is already in use for template:Journal reference, template:Taxobox, and many others, and is being added to more.

This makes Wikipedia less accessible for users of assistive technologies, like web page readers for the handicapped, and text readers. This is sloppy programming and bad practice from the point of view of web page accessibility, web page usability, and standards implementation. Wikipedia is an open encyclopedia; please lets not start treating the minority who has the most difficult time reading like second-class citizens. Main discussion on this is at Wikipedia talk:No meta-templates. Please make your opinion heard there. Michael Z. 2006-01-16 17:51 Z

Comment: Example: look at the html of George W. Bush. You will find there:
<tr class="hiddenStructure">
<td>{{{death_date}}}<br /></td>
Due to the CSS trick used in template:Infobox President. Discussion is on MediaWiki talk:Common.css per Netoholic. --Adrian Buehlmann 23:01, 17 January 2006 (UTC)[reply]

Can the article title be disabled on a particular page?

Hi. I'm on the Main Page Redesign team. I'm looking into possibly turning off the title (H1 heading?) at the top of the page we are working on. We need to see what the Main Page Redesign Draft would look like without the page name showing up on the screen. What is the link to the the documentation on this? --Go for it! 20:25, 16 January 2006 (UTC)[reply]

You already have the answer: the same way you turned off the #siteSub, with a hack on MediaWiki:Monobook.js. There is no documentation, of course, since it's a hack. --cesarb 21:03, 16 January 2006 (UTC)[reply]

So then, how do we refer to the page's title in the source code? That is, what do we edit in the above hack to make it work on the page's title? --Go for it! 01:20, 17 January 2006 (UTC)[reply]

How do you create and use backgrounds in Wikipedia?


Welcome to Wikipedia, the free encyclopedia that anyone can edit.

In this English version, started in 2001, we are currently working on 6,500,803 articles.

Art | Culture | Geography | Health | History | People | Philosophy | Science | Society | Technology

Almanac · Categories · Glossaries · Lists · Overviews · Portals · Search · Questions · Site news · Index

Does anyone know how to use a graphic as a background image in Wikipedia? I'd like to try an experiment and place the puzzle globe behind the 4 lines of text of the header above. Any help/guidance you can provide would be greatly appreciated. --Go for it! 06:09, 17 January 2006 (UTC)[reply]

Yeah, but you need an admin (naturally). First, wrap the whole in a div with an id of EnWpMpHead (arbitrarily chosen). Then, go to MediaWiki:Common.css and have an admin add
There's already a long list of stuff for your project. It can be placed at the end. Superm401 | Talk 10:01, 17 January 2006 (UTC)[reply]
I hate it when people post their questions in multiple places. As I said over there, it doesn't look good anyway. Lupo 10:13, 17 January 2006 (UTC)[reply]

NetBot and {{Further}}

This template may be the best new thing since sliced bread — or maybe not — but some NetBot went around converting See to Further, and it made a horrible mess of things!

The span class notice presumably caused the massive paragraph break in Israel at Zionism and Aliyah, through bad interactions with other templates. Note the differences using "Older edit".

I do hope this is being fixed, everywhere, and folks don't run Bots until they're thoroughly tested!

--William Allen Simpson 15:59, 17 January 2006 (UTC)[reply]
The last time Netbot edited that page was the 19th of May, is that really the edit you refer to? Martin 16:11, 17 January 2006 (UTC)[reply]

No, for Israel, they appear to be from Special:Contributions/

However, others show up in Special:Contributions/NetBot, see the range:

  • 2006-01-15 09:18:44 ... Canadian federal election, 2004 (Robot: migrating See calls to Further)
  • 2006-01-15 10:07:07 ... Tank (Robot: Migrate See to Further (match displayed text))

Is somebody running the same Bot simultaneously from an IP address? Is that permitted?

--William Allen Simpson 04:30, 18 January 2006 (UTC)[reply]
There is a quirk in some bot interfaces which cause a logged-in bot to sometimes cause an anon edit. (SEWilco 05:32, 18 January 2006 (UTC))[reply]

What is Wikimedia's energy source?

What energy source powers the Florida data HQ and by which power company? The lorax 20:09, 17 January 2006 (UTC)[reply]

No idea, but you could call them and ask. --00:18, 18 January 2006 (UTC)
Do they provide their service in exchange for that giant advert about Wikipedia? Martin 00:22, 18 January 2006 (UTC)[reply]
The energy source for Wikipedia article content, on the other hand, is traditionally caffeine. (SEWilco 05:34, 18 January 2006 (UTC))[reply]
I disagree. I say chocolate. [[Sam Korn]] 12:16, 18 January 2006 (UTC)[reply]
Chocolate contains a small amount of caffiene! --Aussie Evil 21:52, 18 January 2006 (UTC)[reply]

What would be involved in...

I am trying to find ways to stop User:Gibraltarian. We've tried everything save one idea. I know that right now for AOL users, we have {{AOL}}. Is there any way that we can develop something similar for Gibraltarian? He uses the IPs to The thing is. I can write the template. But how do we get it on all pages on the IPs he uses? It would aid users. Right now, he's being warned several times before we're blocking him. It was for 30 minutes yesterday. He got 10-11 posts in. If we put a template up, he can be blocked faster. --Woohookitty(cat scratches) 21:15, 17 January 2006 (UTC)[reply]

That'd be easy work for a bot. You could personally ask someone who runs one or submit a bot request. That said, please be careful with the wording for the template; you're talking about tagging the entire dialup IP range of an ISP as potential vandals. —Ilmari Karonen (talk) 14:51, 18 January 2006 (UTC)[reply]
I created a template at Template:Gibraltarian. I think it's pretty clear. Thanks for the help. --Woohookitty(cat scratches) 13:18, 19 January 2006 (UTC)[reply]

Categories and tags

Is it technically possible to make our category system work more like the tagging system used by flickr, for example. This approach seems to display the information better, and would alleviate a number of problems related to ethnicity, nationality, gender and sexual orientation, focussing the categorisation debate upon each article's talk page rather than on the system itself. Steve block talk 20:24, 18 January 2006 (UTC)[reply]

Ignoring display issues for the moment, are you thinking this is fundamentally different than the category intersection and union suggestions that have been floating around for quite some time? I suspect categories in Wikipedia are actually implemented pretty much like tags at Flikr (database record for each category/tag including references of some kind to each article/photo), but Flickr lets you do set intersection and set union quite easily. Calling it a tag rather than a category, and (significantly) allowing intersection and union operations likely would avoid much of the angst we subject ourselves to. Databases are pretty good at intersection and union, but I don't know if the 200 per page limit we use (for category displays) is because of the expense of returning a large search set (and with a tag based mechanism there would likely be lots of cases where far more than 200 articles would have the same tag). So, technically possible? I think almost certainly. Easy from where we are now? Not so much. Seems like it might be worth bringing this up with the developers and seeing what they think. -- Rick Block (talk) 03:10, 19 January 2006 (UTC)[reply]
See, I have no idea what intersection and union thingummy's are. It was just a thought that occurred to me whilst I was debating the pros and cons of sub-categorising. It seemed that the way tags work, like flickr and, where you have one tag, and then on that page are other tags by which you can better sort the tags, that would be better for categorisation. That way, everything in Category:Foo would be displayed, with the sub-categories allowing a reader to sort them. That sort of system would take away issues of sub-categorisation, although I guess another way around that would be to allow articles to be displayed in top level categories. Maybe another way to do it is to have nothing in top level categories but sub-categories, with one of the sub-categories being all foo. Sort of:
I don't really know about display issues. Would that need to change beyond a 200 per page limit? Steve block talk 15:03, 19 January 2006 (UTC)[reply]
Let's back up a bit. Wikipedia has categories that can include categories or articles. This leads to the structural issues we all know and love hate. I'm pretty sure Flickr doesn't actually have "subtags". The Wikipedia analogy would be articles can only have elemental categories (tags) and there would be no explicit subcategories. In Flickr when you add another tag to the list of tags (to "better sort") you're selecting to display only those photos that have all the tags in your list (in database terms, this would be an intersection, i.e. show only things with tag1 and tag2 and tag3 ...). In a sense, you're making your own "subcategory", on the fly. I haven't used Flickr much, but I imagine if you start with tag1 the other tags you can add (to filter the list) are any other tag applied to any of the photos tagged with tag1. Back to Wikipedia - if categories worked like tags, an article like Enrico Fermi would be "tagged" with elemental categories only, i.e. category:1901 births, category:1954 deaths, category:physicists, category:American people, category:Italian people (and some more), but NOT category:American physicists (or any other "intersection" sort of category). From this article, to get to other American physicists, I think you'd have to click on category:physicists or category:American people, and then add the other tag/category to what turns up from that display. Note that you could find physicists born in 1901 this way, too, without anyone ever having created a category:physicists born in 1901. Rather than have any explicit "subset" categories, you'd build your own subset criteria. The display problem is that most "elemental" categories in Wikipedia would have thousands of articles (imagine category:American people, for example). We could display the first 200 articles that have all the categories/tags you've selected, with a count of how many articles match altogether. There are some details that would need to be worked out, but I think this is an excellent idea and would be a far more useful feature to readers than the current category feature (and it would drastically reduce the workload at WP:CFD as well). -- Rick Block (talk) 16:06, 19 January 2006 (UTC)[reply]
Yeah, that's the way I was thinking it would work, but from my experience tags can only be one word, so Category:1901 would be one, Category:Births another, Category:American another and Category:People another. It makes every word a category. Still, I think I'll mention it to a developer. Steve block talk 19:57, 19 January 2006 (UTC)[reply]
I don't think single word would be the issue so much as single concept. Tagging Enrico Fermi with Category:1901 and Category:Births loses the concept of "born in 1901", i.e. if these are individual tags their intersection doesn't mean "born in 1901" (could be someone who died in 1901). Note that categories/tags could be placed in categories/tags as a way of doing a "union" operation. For example, the category/tag 'physicist" might itself be categorized/tagged as "scientist" so from Enrico Fermi you might be able to select "scientist" (lots and lots of results) and then "Italian people" to find all Italian scientists regardless of their specialty. Any "second level" tag (like scientist) would be a potential performance nightmare, but I can imagine ways to structure the software so that this wouldn't necessarily be a huge issue. -- Rick Block (talk) 04:48, 20 January 2006 (UTC)[reply]
I posted it to wikitech, although I forgot to subscribe so I haven't followed up yet. You might be able to get your head around the responses better than me:
I was also pointed to the following pages:
They seem to come from the same angle but hit different targets, if you ask me. Anyway, I'll have to follow up back on the list, once I get my head around the information. Steve block talk 20:28, 20 January 2006 (UTC)[reply]

Polish characters in "edit" menu

Hi! Polish special characters that you can choose from the list below the editing window aren' t in fact Polish. Is there a chance to fix it? The Last V8 21:55, 18 January 2006 (UTC)[reply]

Please bring this up at MediaWiki talk:Edittools. -- Rick Block (talk) 01:59, 19 January 2006 (UTC)[reply]

History & Authors

Hi all. I noticed that some pages now have a "History & Authors" tab instead of just "History"--like Wikipedia:Community Portal. Does anyone know if this was discussed anywhere...? It doesn't seem to correspond to any particular pages, and I'm also curious what files were edited to make this change. Thanks! ~MDD4696 22:56, 18 January 2006 (UTC)[reply]

That would be MediaWiki:History short, and it's been reverted. --TheParanoidOne 23:33, 18 January 2006 (UTC)[reply]

Bug in diff?

This diff [1] looks like a blanking, but isn't, see these diffs: [2], [3]. Or does Wikipedia display the first diff as a blanking only for me? Kusma (討論) 23:01, 18 January 2006 (UTC)[reply]

Looks like a bug to me, too. I'll make sure there's a Wikipedia:MediaZilla bug report on it. -- Rick Block (talk) 01:50, 19 January 2006 (UTC)[reply]
This was reported and, as far as we know, has been fixed. --Brion 20:45, 19 January 2006 (UTC)[reply]
Less than 24 hour turnaround! Thanks, Brion - you guys are awesome. -- Rick Block (talk) 02:23, 20 January 2006 (UTC)[reply]
Great! The speed is really impressive. Thanks a lot! (And thanks to Rick for filing the bug report). Kusma (討論) 02:52, 20 January 2006 (UTC)[reply]


What is the first address of the processor?

The meaning of your question is not clear. This is a page for discussions about the technical workings of this encyclopedia. If your question is relevant, please try to reword it and give more context so we can understand what you mean. If you are asking a general question unrelated to this page, for example about the address space of a computer processor, please ask on the appropriate page of the Wikipedia:Reference desk, perhaps the science and computing one.-gadfium 03:04, 19 January 2006 (UTC)[reply]

Problems with Template:Talk Spoken Wikipedia id

Hello all. I am having an enormous amount of trouble with the Talk Spoken Wikipedia id template. For some reason, it only works on certain articles. That is, the link to the specific revision of the article is not being generated properly. For example, Talk:Puff, the Magic Dragon doesn't work, but Talk:Ada Lovelace does. I've spent a good amount of time trying to figure it out, but I'm not making any headway whatsoever. Does anyone have any ideas? ~MDD4696 04:19, 19 January 2006 (UTC)[reply]

Acoording to Help:Variable, {{PAGENAMEE}} should not be used as a parameter to {{localurl}}. I changed them to {{PAGENAME}} (without the extra E), and it seems to work fine now. —Ilmari Karonen (talk) 08:02, 19 January 2006 (UTC)[reply]

Nested wikitable possible?

Is it possible to nest wikitables? Also, can someone point me to a tutorial or list of options to use within wikitables? Many thanks. — Bellhalla 14:59, 19 January 2006 (UTC)[reply]

I see
no reason
that wouldn't work.

As for the syntax, see Help:Table. —Ilmari Karonen (talk) 16:21, 19 January 2006 (UTC)[reply]

Server Converting + into "+" Instead of White Space, in URL

Historically, Wikipedia's web server has taken "/wiki/Elvis+Presley" as part of the URL and converted it to "/wiki/Elvis_Presley".

This is, of course, as it should be, since "+" in a URL represents a whitespace.

But, as of the last week or two, the web server has stopped doing this properly, and the above string will end up coming out "not found" because it tries to send you to an article NAMED "Elvis+Presley", with the plus.

This screws up, for example, the Google desktop/toolbar/taskbar custom searches which most of us have installed and some of us, myself included of couse, have configured to go to Wikipedia's article.

In other words, I've added a "custom search" so that if I type "Elvis Presley" into the google taskbar, then hit control-E to search (instead of enter), it sends me to

But it encodes it with a + for each whitespace, as is required by the protocal.

But now, instead, it literally sends me to "" -- Click that link and SHOULD be converted to the actual article with the _ in the middle, but it isn't.

I suspect that other automated systems of generating Wikipedia URLs will be encountering the same problem.

What caused the sudden change in parsing, and will it be fixed?Kaz 19:01, 19 January 2006 (UTC)[reply]

Actually, the convention that "+" represents a space in only standard in query parameters. Its use elsewhere in URLs is no more standard than the Wikipedia convention of replacing spaces with underscores. The proper encoding for a space, which works anywhere in an URL, is "%20". Alternatively, if you want to continue using "+" for spaces (or can't help it), try using an URL like —Ilmari Karonen (talk) 19:14, 19 January 2006 (UTC)[reply]
It was changed so links like C++ can work. It is a change in the Apache handlers, I think. It seems logical to me. [[Sam Korn]] 19:17, 19 January 2006 (UTC)[reply]
It would be logical if the percentage of entries which absolutely must have a "+" in them were not freakishly small. As it is, this is damned inconvenient for very little benefit.
Ilmari, the fix worked. There should be some announcement about this, though. Being able to add wikipedia to custom searches is really useful, and custom search tools are reasonably popular.Kaz 19:43, 19 January 2006 (UTC)[reply]
Custom searches should go through Special:Search, which does still use "+". [[Sam Korn]] 19:46, 19 January 2006 (UTC)[reply]
Well, I'd had Google set up with{1} as the search string, and that'd worked until this conversion. Now{1} works, but I had been unaware of that, before. There could be other people in a similar predicament. --Kaz 20:29, 19 January 2006 (UTC)[reply]
Try setting it up as{1}. That'll work even better. [[Sam Korn]] 20:40, 19 January 2006 (UTC)[reply]

Line breaks

Is there any chance we can get have a way to do a proper line break? Due to what I assume is a bug, pressing enter once does nothing, and pressing it twice skips a line entirely, meaning there is currently no way to go the the next line, annoyingly enough. -- 21:57, 19 January 2006 (UTC)[reply]

Just use <br />.-gadfium 22:28, 19 January 2006 (UTC)[reply]

What links here and colons

Has anybody noted that wikilinks to images which are preceded by a colon (like this: Image:ElectoralCollege2000-Large.png) don't appear in the "What links here" special page?

DLJessup (talk) 03:25, 20 January 2006 (UTC)[reply]

Aha, found the bug in BugZilla at bugzilla:00360#c4! I'll comment there.
DLJessup (talk) 06:59, 20 January 2006 (UTC)[reply]

Edit counter broken

Kate's Tool doesn't seem to be working properly now. I get the following error: onoes!! some kind of database error occured ((1044, "Access denied for user 'kate'@'' to database 'enwiki_p'"))... please try again later Any idea why? Crotalus horridus (TALKCONTRIBS) 05:41, 20 January 2006 (UTC)[reply]

Page showing up as file

When I try to visit counter-recruitment my computer asks if I want to download a file. This isn't happening for any other page. Does anyone know why this is happening? Catsv 07:05, 20 January 2006 (UTC)[reply]

Update: I am now having the same problem with Anthony Arnove; however, I am NOT having the problem with military counter-recruitment, which redirects to counter-recruitment. Catsv 07:12, 20 January 2006 (UTC)[reply]
Sounds like you have excessive line noise, which is causing random html pages to be misinterpreted as binary. Are you on a dial up connection, and if so has something changed recently with your phone line or modem setup? If this is the cause, I'd expect you to see this problem on numerous web pages, but not on the same web page every time.-gadfium 07:55, 20 January 2006 (UTC)[reply]
Once in a while, someone somewhere has seen compressed pages incorrectly marked or something. Try putting ?action=purge on the end of the URL to force it to rerender. --Brion 09:26, 20 January 2006 (UTC)[reply]

Open proxy policy

This multipost removed. See Wikipedia:Village pump (policy)#Open_proxy_policy for discussion.

Questions re server load from images in userspace

A policy is being prepared that may advise editors to remove templates with images from their userpages to lessen server load. Realizing that its hard enough to tune a system and near-impossible to explain it to civilians, still, I'm trying to understand this more. If anybody reads this who is familiar with the technical side of these issues and wants to reply that would be great, thanks. Herostratus 22:49, 20 January 2006 (UTC)[reply]

  • To clarify -- I'm given to understand that the size of the image does not matter much, in other words a 45x45 image uses basically as much as a 450x450 image. Is this correct?


A large image uses more disk space, takes more bandwidth when transferred at full size, and requires more resources when being resized. It takes no more resources to refer to an already existing image of large size other than the network transfer.
Generally, you should not worry much about little things like templates and "server load" at a policy level. If they're expensive, we'll either fix it or restrict it at a technical level; that's our responsibility. --Brion 01:01, 21 January 2006 (UTC)[reply]

  • Does color depth make much difference? What about file format (jpg vs png)?


At the moment, very large PNG images are more expensive than JPEGs to resize due to the memory usage of the converted program. This is a technical issue and can be improved; we already have technical measures in place to restrict very large such images. --Brion 01:01, 21 January 2006 (UTC)[reply]

  • Is it advisable to delete all images from userpages? Recognizing that this is an intersection of policy and system capacity, would an advisory such as "no more than five images is recommended on a userpage, including those in templates" help reduce server load?


Generally, if an image isn't usable in the encyclopedia you probably shouldn't upload it to Wikipedia. Remember that everything here must be freely licensed, and can and will be redistributed to and by third parties.
If you don't want the picture of you, your cat, or your girlfriend to be copied, modified, reused, and redistributed by commercial and noncommercial publishers, don't put it on Wikipedia. --Brion 01:01, 21 January 2006 (UTC)[reply]

  • Recognizing that this is policy issue, would system capacity issues possibly be addressed by advising editors to go easy on image use in articles? (For instance, in a few articles I placed images more for page-design purposes than to illustrate a point. Should editors not do that? Only worry about it for likely-to-be-popular articles? Or not worry about it all?


As a design and usability matter, you should avoid unnecessary images which don't contribute something to the article.
As a technical matter, it's our responsibility to keep the system running well enough for what the sites require. In other words: it's not a policy issue. If and when we need to restrict certain things, we'll do so with technical measures. --Brion 01:01, 21 January 2006 (UTC)[reply]

  • What about images in community space (for example, the one at the top of this page). There aren't many but they are served often. Would it help to cut back on those? What about Images in signatures? (I know sigs are discussed somewhere but are the servers straining enough to make a crackdown advisable, I wonder.)


Community space is a small fraction of total hits, and stock images that don't change much are not terribly expensive to serve. Definitely not an issue.
Signatures are a different matter because of the way they multiply; a bad sig can pollute thousands of pages and is hard to clean up. This isn't really specific to images, but generally we have been cracking down on too much fancy stuff in sigs due to their tendency to break when "clever markup tricks" rely on software bugs which get fixed. --Brion 01:01, 21 January 2006 (UTC)[reply]

  • I suppose this is unanswerable, but is there any way to quantify image load vis-a-vis our server capacity in a way that a civlian could understand enough to contribute in an informed way to a policy discussion?


"Policy" shouldn't really concern itself with server load except in the most extreme of cases; keeping things tuned to provide what the user base needs is our job. --Brion 01:01, 21 January 2006 (UTC)[reply]

Template experts, please help with dead link wayback machine

Dear those of you who understand templates:

Please have a look at this problem with the {{dlw}} and {{dlw-inline}} templates, which are designed to make it easy to hook dead links into the Internet Archive Wayback Machine, used to fix Wikipedia:Dead external links.

Apparently, if a dead URL has a "=" equals sign in it, it screws up the argument passing.

Is this reasonably fixable? Please respond at Template talk:Dlw#Problems with '=' character in URLs. Thank you! --James S. 23:10, 20 January 2006 (UTC)[reply]

Apparent solution: put url in nowiki tags; recommended for bot use. --James S. 23:26, 20 January 2006 (UTC)[reply]