Wikipedia:Village pump (technical)/Archive 43

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Something funny going on

I've noticed at the Communist Party of Great Britain article. It seems to miss out an entire paragraph of text in the 1940s and 1950s section. The text appears when you edit, but dissapears when you save it or look at a preview.

The text in question is suposed to be: (I've had to use <nowiki> because it does the same thing here)

• The party's membership peaked during 1943, reaching around 60,000<ref name="To Build A New Jerusalem"/>. Despite boasting some leading intellectuals, especially among the [[Communist Party Historians Group]], the party was still tiny compared to its continental European counterparts. The [[Communist Party of France|French Communist Party]] for instance had 800,000 members, and the [[Italian Communist Party]] had 1.7 million members<ref name="To Build A New Jerusalem"/>. The Party tried, unsuccessfully, to affiliate to the Labour Party in 1935, 43 and 46.

• In 1951 the party issued a programme called ''The [[British Road to Socialism]]'' (officially adopted at the 22nd Congress in April 1952), which explicitly advocated the possibility of a peaceful reformist transition to socialism - but only after it had been personally approved by Stalin himself<ref>Geoff Andrews, ''Endgames and New Times,'' Lawrence and Wishart, 2004, p 74, p 90</ref>. The importance of this document is that it implicitly renounces the revolutionary purpose for which the party was founded in the first instance. The BRS would remain the programme of the CPGB until its dissolution in 1991 albeit in amended form and even today is the programme of the [[Communist Party of Britain]] which claims political continuity with the CPGB.

But when you save it or preview it, it appears:

• The party's membership peaked during 1943, reaching around 60,000<ref name="To Build A New Jerusalem"/>. Despite boasting some leading intellectuals, especially among the [[Communist Party Historians Group]], the party was still tiny compared to its continental European counterparts. The [[Communist Party of France|French Communist Party]] for instance had 800,000 members, and the [[Italian Communist Party]] had 1.7 million members<ref name="To Build A New Jerusalem"/>. The Party tried, unsuccessfully, to affiliate to the Labour Party in 1935, 43 and 46.''

• In 1951 the party issued a programme called The British Road to Socialism (officially adopted at the 22nd Congress in April 1952), which explicitly advocated the possibility of a peaceful reformist transition to socialism - but only after it had been personally approved by Stalin himself. The importance of this document is that it implicitly renounces the revolutionary purpose for which the party was founded in the first instance. The BRS would remain the programme of the CPGB until its dissolution in 1991 albeit in amended form and even today is the programme of the Communist Party of Britain which claims political continuity with the CPGB.

Anyone know what's going on? G-Man ^? 21:36, 23 July 2008 (UTC)

One of the refs was missing a closing </ref> tag -- now fixed. BTW, the standard format is for the refs to come after the punctuation (periods, commas etc) - a bunch of those need to be fixed in this article. – ukexpat (talk) 21:44, 23 July 2008 (UTC)

Actually, there is no requirement for the reference to be after the punctuation, rather, usage should be consistent within an article. DuncanHill (talk) 21:46, 23 July 2008 (UTC)

Well there should be! Punctuation after the refs looks ugly and is certainly non-standard for print media, in my experience. – ukexpat (talk) 21:50, 23 July 2008 (UTC)

I prefer ref then punctuation myself, but it's not one of my pet peeves (of which, devoted readers, you may have noticed I have many). DuncanHill (talk) 21:52, 23 July 2008 (UTC)

I see, a simple little thing like a missing / huh! Thanks. G-Man ^? 22:12, 23 July 2008 (UTC)

See WP:EFAQ#REFTAGERR. --—— Gadget850 (Ed) ^talk - 15:08, 25 July 2008 (UTC)

Altering block lengths

Has anyone ever proposed an extend/shorten block function? It is a fairly often occurrence to see an admin unblock a user just to block them again. I think it would be a useful function and not that hard to implement. - Icewedge (talk) 05:04, 25 July 2008 (UTC)

T12080. It's been fixed a couple of times, but there were problems and the fixes got reverted. —Simetrical (talk • contribs) 14:56, 25 July 2008 (UTC)

Problem/hack/unseen... for so long?

Resolved

http://en.wikipedia.org/w/index.php?title=ESCB&action=history shows the last change as 10:42, 24 May 2004, but ESCB appears strange. All the best.

Strange how? —Wknight94 (talk) 20:07, 25 July 2008 (UTC)

ESCB is a standard redirect to European System of Central Banks. – ukexpat (talk) 20:11, 25 July 2008 (UTC)

For a little while it appeared as stolen, as if to be shown as a form of a userpage. Maybe I can bring back from my cache the former looks of it. It would speed things up if someone provided the path of firefox's cache on winXP. —Preceding unsigned comment added by 78.30.153.144 (talk) 20:14, 25 July 2008 (UTC)

It was just template vandalism on Template:Central banks of the European Union, I think. User:Alai shot it down pretty fast, nothing to see here. :-) --Grey Knight ⊖ 21:51, 25 July 2008 (UTC)

Line break before #switch

Because there's a line break that occurs before a #switch, I'm having trouble creating a reliable template that returns a colour, as having a pound sign at the beginning of a line causes an unordered list. For example:

{| style="color:{{#switch:|#FF0000}};"
|-
| Test
|}

becomes

1. FF0000;"

Test

I found that putting nowiki tags around the pound sign works (e.g. <nowiki>#</nowiki>FF0000) but I'm wondering if there is a more concise solution for the line break. —LOL ^T/_C 05:36, 20 July 2008 (UTC)

This is a common problem, it can be circumvented by using {{!}} in pace of the bar. - Icewedge (talk) 06:38, 20 July 2008 (UTC)

I can't seem to get it working with {{!}}; could you please demonstrate the solution by modifying the example above? —LOL ^T/_C 07:10, 20 July 2008 (UTC)

{| style="color:#{{#switch:|FF0000}};"
|-
| Test
|}

Test

Is that something like that you want? — chandler — 07:18, 20 July 2008 (UTC)

That would work for hex values but not for named colors e.g. color:red would fail if a "#" is added. It would not be unreasonable for a switch statement to contain a mixture of these. — CharlotteWebb 12:08, 20 July 2008 (UTC)

I've definitely considered putting the pound sign outside the switch, but I'd have to make changes to the template by converting all the HTML colour names to hex and modifying the pages that transclude the template. However, if that's the only solution besides the inconcise <nowiki>#<nowiki>, I'd prefer to do that. Thanks all for the input. —LOL ^T/_C 16:45, 20 July 2008 (UTC)

If you change all the colors in the template to hex and put the pound sign outside of the switch, you shouldn't have to make any changes to the pages using this template, as far as I can see. --- RockMFR 20:46, 20 July 2008 (UTC)

You could use something like style="color:rgb(255,0,0)" and no "#" would be needed. This format would also be easier for users unfamiliar with base-16 but I have no idea whether IE supports it. Let me know if you don't see red. — CharlotteWebb 17:28, 24 July 2008 (UTC)

IE7 supports it, I have no idea of earlier versions though. —Dinoguy1000 19:26, 24 July 2008 (UTC)

Unfortunately I can't use rgb(255,0,0) because it doesn't work in <font color="rgb(255,0,0)">. It turns out that there's even a line break at the transclusion of the template, so #{{#switch:|FF0000}} also produces the ordered list. As hopefully the best solution at present, I've removed the pound sign from the template and added pound signs to the transcluding pages. —LOL ^T/_C 00:40, 27 July 2008 (UTC)

Categories and Special:PrefixIndex

Hello, I have a couple of questions.

• When using Special:PrefixIndex, are there any other search functions available? In particular, is it possible
  • to search for all pages with a certain category?
  • to search for pages without any category?

• When listing the pages in a certain category, is it possible to sort them other than alphabetically? For example, in order of page creation date.

Thanks in advance. MSGJ (talk) 08:55, 26 July 2008 (UTC)

• Try Cat Scan on the tool server. (sometimes slow) --Apoc2400 (talk) 19:04, 26 July 2008 (UTC)

Off-site sandbox

I was wondering if there were any good alternatives to Wikipedia itself for off-site sandboxing? Wikipedia too frequently stalls when loading a page (have to hit refresh), or is slow in other regards when making frequent rapid edits. Can anyone recommend a good place, or even software that resides on a user's local hard disk? Compatibility with Wikipedia's templates is a plus. Thanks! SharkD (talk) 22:11, 26 July 2008 (UTC)

The MediaWiki software that Wikipedia runs is freely available; you could easily download and install it on your own website, or even run it on your own computer (with some configuration). Just click the "powered by" button at the bottom-right of any page. EVula // talk // ☯ // 22:37, 26 July 2008 (UTC)

Well, I was hoping for something more newbie-friendly. I'm not that techno-savvy. SharkD (talk) 22:46, 26 July 2008 (UTC)

Should media wiki prompt when categorizing images here, where the images are on commons

I was looking at new image pages[1], and noticed that many of the images are where a user has categorized an image that is on commons here, so the image page only consists of a category. There are also some instances where it is just basic testing or vandalism. Is there any way to have the user prompted before adding a description or category to a non-existant image? I was also thinking this might be something for a bot and a template notice. I've been sandboxing a template notice based on {{Un-commons}} at one of my sandboxes (User:Optigan13/Sandbox 2). -Optigan13 (talk) 05:12, 27 July 2008 (UTC)

What's in a (ref) name?

Hello everyone.

Sometimes, when editing an article and, more specifically, adding references, the ref name instructions trip me up. Namely, I tend to type refname instead of ref name in both of the pieces of code where the words "ref name" are needed, which means that the article has these big error messages or has some code in it or something, meaning that I have to go back and look through it again and see what went wrong.

My request is this. Could you change the list of Wikimarkup instructions so that <refname = "x"> ... </ref> and <refname = "x"/> also work, just like {{Reflist}} and <references/> both work? It Is Me Here (talk) 09:40, 23 July 2008 (UTC)

I'm guessing the devs will say no. The idea is to be XML compatible I suspect. (I already find it annoying enough that it allows you to not include " around the actual name. Also, {{reflist}} is just a template that includes <references/>. The two situations are not comparable. --TheDJ (talk • contribs) 01:00, 24 July 2008 (UTC)

What do you mean? I did use quotes, didn't I? It Is Me Here (talk) 08:27, 24 July 2008 (UTC)

Yes, but you didn't have to. Allowing <ref name=foo> to work is bad XML. Algebraist 09:07, 24 July 2008 (UTC)

Well for better or worse we also allow quotes to be omitted for other tags like <font color=red/>, but I did notice that this is tidied up by the software (quotes around "red" are absent in the wikitext but present in the rendered html). — CharlotteWebb 17:14, 24 July 2008 (UTC)

And besides everybody knows that quotes in ref tags are bad juju . — CharlotteWebb 17:17, 24 July 2008 (UTC)

Well, guys, look, Wikipedia is about imparting knowledge to its readers, right? And, hence, the easier its editors' jobs are, the better. Moreover, Wikipedia does not set out to teach people XML (as far as I'm aware), and if you're a purist, there is nothing stopping you using the more orthodox commands. It Is Me Here (talk) 18:04, 24 July 2008 (UTC)

This is not going to happen. It's all very well to suggest allowing all sorts of weird syntaxes to be forgiving of mistakes, but there are conceptual costs too. Every alternative way you allow of doing things creates that much more confusion. People will see <refname> and assume it's invalid, try to fix it, and only then realize that both ways are valid. There's a lot of merit in having only way way to do things. It makes things simpler and gives people fewer things to learn. Having many obscure constructs that do the same thing, even in the name of being forgiving of errors, is worse than having a single well-known construct that does one thing.

Moreover, the way this is set up internally currently requires matching start/end tags, and does not allow tags like <x=y> (only <x y=z>). This would not be very trivial to do. —Simetrical (talk • contribs) 14:46, 25 July 2008 (UTC)

It would be trivial to set up a {{rename}} tag which did something similar to this though, {{refname|foo|blahblahblah}} resolving to <ref name="foo">blahblahblah</ref>. Comments? Chris Cunningham (not at work) - talk 14:59, 25 July 2008 (UTC)

You'd actually have to use #tag syntax, but it could be created easily enough. I don't really see the point though, especially since you have to remember to use "2=" (or "c=" in my version) whenever your content contains an equal sign. I guess with the named parameters it could make the wikitext slightly easier to read if #tag would have to be used anyway. Anomie⚔ 00:56, 26 July 2008 (UTC)

OK, thanks for the feedback, guys, and I can see where you are all coming from so this proposal can be scrapped. It Is Me Here (talk) 18:29, 28 July 2008 (UTC)

Bug: revisions/pagesizes/pagerendering/wikisource not matching up, resulting in blanking or page replacements

Did this edit accidentally blank the page? It showed up in the page history as 14,490 bytes (edit @ 03:45, 26 July 2008), but when I load that revision, it's blank. The revision I reverted to is not blank. Can anyone confirm that the linked-to revision is blank, and has anyone seen similar problems?--Father Goose (talk) 04:20, 26 July 2008 (UTC)

Weird. I can confirm that the revision appears blank and has no wikisource despite it showing up in the page history with a size of 14,490 bytes. I don't know why this is happening. —Lowellian (reply) 04:48, 26 July 2008 (UTC)

Weird indeed! I'd call this one a bug. Gary King (talk) 05:54, 26 July 2008 (UTC)

Another instance [2]. Check the editor's history. A long string of good faith additions using HotCat, and in the middle of the string you get a blanking. 4 minutes apart in time from Goose's edit.

I saw yet another instance, but don't remember where. Notice that servers have been playing up a lot on the last 12 hours or so, constantly go into read-only mode. --Enric Naval (talk) 05:56, 26 July 2008 (UTC)

Yep, could very well be related to the recent problems with the servers. It's not unusual to visit Wikipedia and have to wait a minute or two for the page to load. However, I've recently (in the past 24 hours) been receiving the "this page will not load" errors IMMEDIATELY, which means that the servers have been offline for a few seconds at the very least when I was visiting. Which is a huge problem. Gary King (talk) 06:00, 26 July 2008 (UTC)

Something weird is happening. Go to the page Fairy Queen. It looks fine...but now click the edit button. Instead one gets the wikisource for the Blue Angels article. What's going on? —Lowellian (reply) 04:50, 26 July 2008 (UTC)

I had a similar problem at Crystal_Lake,_Newton with what became an old revision of the page [3]. -- User:Docu

It looks fine to me. The article mentions the Blue Angels a few times so perhaps that's the text you saw that helped you mistakenly identify the article? Gary King (talk) 05:52, 26 July 2008 (UTC)

It looks fine now because User:Slakr reverted my edit which apparently caused MediaWiki to bug out. But look at that 23:35, 25 July 2008 [4] edit of mine: reported page size of 901 bytes in the page history, but that revision is clearly far larger than 901 bytes and is bizarrely a copy of the Blue Angels article, even though I was just trying to add a few words to the article. And if you look at the diff, it looks like I attempted to replace the article with the Blue Angels article. And I'm not sure what you mean by "the article mentions the Blue Angels a few times"; the Fairy Queen article doesn't mention the Blue Angels, except in the buggy revision. —Lowellian (reply) 09:39, 26 July 2008 (UTC)

The previous version of the Fairy Queen article is at [5]. Given what happened at Crystal Lake, I don't think Loaellian overwrote it with a version of Blue Angels. -- User:Docu

Definitely not. The edit history shows his version as about 900 bytes, but the "Blue Angels" page has more than that in the infobox alone. --Carnildo (talk) 06:08, 26 July 2008 (UTC)

Just to clarify that something very weird is happening, here is what happened: I attempted to add a handful of words to the 02:50, 13 July 2008 revision [6] to get the 23:35, 25 July 2008 revision [7]; if you look at the reported page byte sizes, 874 and 901, they back up that this is what happened (901 bytes is far, far smaller than the Blue Angels article). However, if you look at the diff [8] or the revision [9], it looks like I overwrote the Fairy Queen article with the Blue Angels article, which is not what I did! —Lowellian (reply) 09:31, 26 July 2008 (UTC)

I had the same problem earlier tonight at Talk:Pikachu]. However, I saw the edit I was trying to do show up (along with the rest of the page) and didn't realize that the talk page had been blanked until I noticed another user revert my edit a few minutes later. -Jéské ^{(v^_^v Mrrph-mph!)} 09:53, 26 July 2008 (UTC)

See AN/I for related discussion and diffs. « Gonzo fan2007 (talk ♦ contribs) @ 09:55, 26 July 2008 (UTC)

Now filed as bug 14933: "New revisions occasionally created with wrong text on enwiki". —Ilmari Karonen (talk) 11:00, 26 July 2008 (UTC)

• Cool, I accidentally on purpose discovered a bug! Just for some extra info, when I initially made this first edit, I did so by clicking the "edit section" button, not "edit this page". I also previewed the page several times before submitting. --NickPenguin_(contribs) 14:46, 26 July 2008 (UTC)

It should have stopped happening now. The corrupted revisions might be able to be recovered after we find someone to fix the damaged server (maybe not on a Sunday). -- Tim Starling (talk) 21:31, 26 July 2008 (UTC)

It's still happening: [10]. Algebraist 16:34, 27 July 2008 (UTC)

Sorry, I broke that test case. Yes it's disturbing, and I'm looking into the cause, but it's not showing DB corruption in that case. It looks like the anomalous blank revisions are just cache pollution, and will fix themselves when the cache expires in a week. The revisions that show the wrong article are due to database corruption, and will need to be fixed manually. -- Tim Starling (talk) 13:05, 28 July 2008 (UTC)

Link problem: parser?

Can someone explain to me why the link in this diff is not working as I wish it to? It seems to be placing a space after the equals sign in the parser. The Evil Spartan (talk) 06:33, 27 July 2008 (UTC)

You have to urlencode quotes (as well as spaces, plusses if they don't represent spaces, and any other special characers), like this. --Splarka (rant) 08:19, 27 July 2008 (UTC)

Cuil not showing Wikipedia hits

I have been trying the new search engine Cuil which was produced by former Google engineers. I have found very few Wikipedia hits in the search results. Am I doing something wrong? Is this just how the search engine works?--Filll (talk | wpc) 15:04, 28 July 2008 (UTC)

"Too many high-ranking Wikipedia entries in Google" is a complaint that's been bandied about a lot — directed both here and at Google — so conceivably they might have built the system in such a way that this doesn't happen so much. I tried a few queries and got a few results from Wikipedia, so we aren't being blacklisted or anything. :-) --_{tiny plastic} Grey Knight ⊖ 15:35, 28 July 2008 (UTC)

We are clearly very highly penalized though, a search for "Prodego" turns up wikipedia mirrors, not wikipedia. Prodego ^talk 17:38, 28 July 2008 (UTC)

I'd just chalk it up to Cuil not being a very good search engine. Whenever I search for something, I tend to get a lot of irrelevant results. --Carnildo (talk) 21:11, 28 July 2008 (UTC)

userrights log

I'm reasonably confident that this is not right - since when should none → none rights changes be logged? What seems to have happened is that the groups promoted to (bureaucrat and sysop) are not recognised for some reason. Something to take to bugzilla? Happy‑melon 17:22, 28 July 2008 (UTC)

The older sections of the user rename log are also corrupted. Have there been any recent changes to the way the logs are stored or rendered that could be causign this? Happy‑melon 17:24, 28 July 2008 (UTC)

The corruption to the user rename log begins sometime between 20:23 August 23 2007 and 17:28 August 25 2007. The corruption to the userrights log begins between 15:13 July 31 2006 and 03:37 August 3 2006. Just dumping detail in here as I find it. Happy‑melon 17:27, 28 July 2008 (UTC)

Rights promotions done by bureaucrats used to be shown that way, with a summary of +sysop. Back then, the "from $1 to $2" part did not exist in the local message, it was only used by stewards on meta. This was back when the Special:Makesysop extension was used. For example: http://en.wikipedia.org/w/index.php?title=Special:Log&type=rights&page=User:Prodego. The same thing (the logging method changing) happened to the renameuser log. Prodego ^talk 17:32, 28 July 2008 (UTC)

See also: bugzilla:13889. --MZMcBride (talk) 22:52, 28 July 2008 (UTC)

Template limit

I was recently told by two different people that, a) there is a limit on the number templates a page may have (including any templates used internally by other templates) and, b) the wiki will stop processing templates if it takes longer than 30 seconds to evaluate them. Which is true, or are both statements accurate? Also, does the 30 second limit apply to a single template or the sum of all templates in a page? Thanks! SharkD (talk) 23:50, 19 July 2008 (UTC)

The template limits are documented at Wikipedia:Template limits. There are limits on how long a page can take to parse and how much memory can be used in the course of parsing, but I don't know if they are documented anywhere. It's much more common to encounter the template limits first, since their goal is to prevent the most common reasons that a page might be too expensive to parse. — Carl (CBM · talk) 00:10, 20 July 2008 (UTC)

Thank you! I've noticed that this article takes a long time to load since I switched to using templates for the dates. Here is the message from the HTML source:

"NewPP limit report
Preprocessor node count: 196354/1000000
Post-expand include size: 297426/2048000 bytes
Template argument size: 122988/2048000 bytes
Expensive parser function count: 258/500"

I was wondering if I am maybe pushing it with regard to template use. Most of the values aren't really near the limits, yet the affect upon page load times is nonetheless considerable. Finally, within the template itself (Template:Vgrtbl (backlinks edit)) I would like to replace some of the common operations with additional templates in order to simplify the source code. What effect will this have upon the above limits? Would you recommend this action? SharkD (talk) 01:23, 20 July 2008 (UTC)

Yes, you are pushing the limits. The important number in your data is the preprocessor node count, which at 196,000 is extremely high. The limit for that node count was reduced once in the past, then made larger again because of some complaints. I expect it will be made smaller in the future (much less than 100,000). Your 'expensive parser function count' is also high.

I would advise you to stop using templates for the dates, and switch back to the previous method. Just because you can make it work with templates doesn't mean you should, in this case. — Carl (CBM · talk) 01:43, 20 July 2008 (UTC)

Isn't one of the basic en-wp laws: "use as much templates as possible"? *scnr* HardDisk (talk) 01:47, 20 July 2008 (UTC)

Templates make maintenance much easier. SharkD (talk) 01:56, 20 July 2008 (UTC)

Yes, of course. In an ideal world we could use them as liberally as we want and never hit any issues. In practice, pages that have long tables with complicated templates in every row can overwhelm the mediawiki parser. So for pragmatic reasons we have to do things other ways, like hard-coding formatting. — Carl (CBM · talk) 02:02, 20 July 2008 (UTC)

Sidenote: I don't think there is a 30 second limit anywhere. I was able to get that page up to 35 seconds with profiling (seen here). I think the fist time limit you'll hit is a WMF squid error (looking sort of like this) if the apache backend or database server hasn't responded within 60 (?) seconds. But that is pretty rare with the new preprocessor/template/parserfunction limits and thumbnail resolution limits designed to stop that sort of thing. You might also hypothetically run out of memory with some thumbnailing or parsing issues, or get a general HTTP/500 error (I did, when trying to save a page with 15,000 unique links), much faster than 30 seconds. --Splarka (rant) 02:16, 20 July 2008 (UTC)

Could you maybe provide some specific optimization tips for this particular template? By turning the c parameter off in the template I was able to bring the preprocessor node count down to about 175000, but this is not a significant improvement. SharkD (talk) 02:19, 20 July 2008 (UTC)

If there were some way of storing local variables, I could bring down the number of calls to the parser functions considerably (I estimate by 90% in this case). Is there a "local variables" extension installed in Wikipedia? I found one in the WikiMedia help pages, but haven't seen it used here anywhere, so assume it hasn't been installed. SharkD (talk) 02:35, 20 July 2008 (UTC)

No, there's not, and there never will be. Even if there were, it would be pointless if your sole goal is to cut down on repeated use of parser functions like #if or #ifexist with the same arguments, since evaluating the variable declaration would probably be about as expensive. You might save something on #expr, I'll grant, if that's your issue. —Simetrical (talk • contribs) 17:34, 20 July 2008 (UTC)

I'm curious as to why you say, "there never will be"? Also, here's an example of one of the conditions:

{{#if:{{{ 3|}}}|{{#ifexpr:{{#ifeq:{{DATEDIFF2|{{{ 2}}}|{{{ 4}}}}}|0|1|0}}or{{#ifeq:{{{ 2}}}|{{{ 4}}}|1|0}}|/{{Video game release/abbr|{{{ 3}}}}}}}

Maybe you could evaluate whether local variables would be beneficial in this case. SharkD (talk) 03:04, 21 July 2008 (UTC)

Note that the above line of code has changed to this:

{{#ifeq:{{#iferror:{{#time:c|{{{16}}}}}|{{{16}}}|{{#time:c|{{{16}}}}}}}|{{#iferror:{{#time:c|{{{18}}}}}|{{{18}}}|{{#time:c|{{{18}}}}}}}||}}

SharkD (talk) 04:43, 21 July 2008 (UTC)

I say "there never will be" because that's the sentiment I've heard expressed by at least one core developer. At any rate, in that statement variables would indeed be useless for performance.

First of all, note that you can make it look a bit nicer, and probably reduce the node count slightly, by using the fact that {{#iferror:A|B}} is the same as {{#iferror:A|B|A}}. So your code could become just {{#ifeq:{{#iferror:{{#time:c|{{{16}}}}}|{{{16}}}}}|{{#iferror:{{#time:c|{{{18}}}}}|{{{18}}}}}||}}, which removes any repeated expression that you could possibly make a variable.

Second of all, #time maintains a per-render cache of return values. The statement {{#time:c|{{{16}}}}} will be evaluated only once, and {{#time:c|{{{18}}}}} will be evaluated only once, even if they occur many times. Variables will not reduce that. They still have to be parsed multiple times to get the arguments and pass them to the correct function, and this increases various limits like node counts, but the same would be true of variables. —Simetrical (talk • contribs) 22:08, 21 July 2008 (UTC)

The issue is (mostly) not with regard to the number of repeated expressions within each line of code; rather it's with the fact that the same line of code, with few changes and with largely the same expressions inside, is used 200 times in the template. Note that the line of code also contains a call to another template, which I failed to show in the example I gave. Here's a more accurate example:

#if:{{{ 3|}}}|{{#ifeq:{{#iferror:{{#time:c|{{{ 2}}}}}|{{{ 2}}}}}|{{#iferror:{{#time:c|{{{ 4}}}}}|{{{ 4}}}}}|/{{Video game release/abbr|{{{ 3}}}}}}}{{

And, thanks for the tip regarding the #iferror: statement. That was really helpful. SharkD (talk) 06:44, 22 July 2008 (UTC)

(de-indenting) I don't think a variable would be very much faster there either, although it would look prettier. If it's the same template being called over and over, I don't think it would make any big performance difference. I'm not an expert on the parser, though. —Simetrical (talk • contribs) 16:46, 22 July 2008 (UTC)

If there is no negative performance difference, and the code is prettier, does that not mean that the benefits outweigh the expenditure? SharkD (talk) 23:12, 25 July 2008 (UTC)

Well, yes, it would, if variables existed in wikisyntax. They don't. The existence of variables presupposes things like a particular order of parsing. The closest equivalent is calling a template with the desired expression in it, like in functional programming. —Simetrical (talk • contribs) 15:29, 29 July 2008 (UTC)

This whole template should be re-thought. What is the important functionality? I see a number of things that are being done, or might be planned:

• Linking dates
• Formatting dates
• Collapsing dupe dates
• Linking regions
• Sorting

Sorting using template code is a really terrible idea, so if you're doing that, don't. Auto-linking regions is fairly simple and is quite useful, so that's good. Linking dates is ever a controversial practice. Formatting dates is likely beyond the scope of the template - if people can't format the dates consistently, they're likely not going to use the template correctly. This is easy enough for a human to do by hand. Collapsing dupe dates is very cool, but it can definitely be done better. Specifically, you should assume that the person using the template can tell that the dates are the same, and can somehow tell the template this knowledge (e.g., by leaving the date parameter after the region blank). --- RockMFR 03:31, 20 July 2008 (UTC)

I thank you for your comments. While, in its current form, the template might not be suitable for long lists or tables after all, the performance hit on an individual article shouldn't be too steep.

"NewPP limit report
Preprocessor node count: 372/1000000
Post-expand include size: 1703/2048000 bytes
Template argument size: 998/2048000 bytes
Expensive parser function count: 1/500"

The point is to unify the template so that it uses a single syntax in every case. Currently, the standard template for this purpose requires that it be applied in one of four or five different ways to achieve the same results.

Also, I was hoping you might provide more guidance along the lines of the use of local variables to store temporary values, as per the request above, as that will have an markedly greater impact than the suggestions you provide. I would appreciate any information in this regard. SharkD (talk) 06:35, 20 July 2008 (UTC)

m:Help:Calculation#Length_of_expressions says something about providing some of the functionality that variables offer.--Patrick (talk) 10:38, 20 July 2008 (UTC)

I don't know where your last report came from, but the article in question is getting worse instead of better:

NewPP limit report
Preprocessor node count: 200998/1000000
Expensive parser function count: 258/500

This really should be changed to a more efficient setup. — Carl (CBM · talk) 17:50, 20 July 2008 (UTC)

The quoted values were for a single instance of the template with two dates and regions passed as parameters. The count is still high, though using your suggestions I was able to lower it considerbaly. SharkD (talk)

Improved

I spent a few minutes making the templates more efficient for Chronology of tactical role-playing video games. The results:

NewPP limit report
Preprocessor node count: 31260/1000000
Post-expand include size: 153476/2048000 bytes
Template argument size: 73840/2048000 bytes
Expensive parser function count: 0/500
Served by srv60 in 8.341 secs.

I think the main culprits were some sorting code, and Template:ISO_3166-1, which is much too expensive. Here are a couple tips if this comes up again:

• Don't use parser functions to sort. Expect users to sort the input.
• Don't make a template that does the same thing to each entry or pair of entries in a variable length list. Instead, use the same template over and over, once for each entry or pair of entries.
• Avoid nesting templates very deeply - if needed, rewrite templates to avoid it.
• Avoid the ifexists call when possible - don't use them just to avoid redlinks to pages that will probably be created at some point.

— Carl (CBM · talk) 19:31, 20 July 2008 (UTC)

You're right, Template:ISO_3166-1 (or, rather Template:Video game release/abbr which makes use of it) was the main culprit. By making it less likely for the template to be called, I was able to reduce the count (see User:SharkD/Sandbox2) to the following:

Preprocessor node count: 69863/1000000
Post-expand include size: 404395/2048000 bytes
Template argument size: 153574/2048000 bytes
Expensive parser function count: 258/500

Removing the "expensive parser function count" is the next main priority.

Note that your version is missing one of the main features added for the express purposes of sortable tables: the date should appear in YYYY-MM-DD format within <span style="display:none"></span> tags, as discussed in Template talk:Vgrelease. SharkD (talk) 02:34, 21 July 2008 (UTC)

Since only the year was typed into the page source, how do you get the month and day for the long date? — Carl (CBM · talk) 02:41, 21 July 2008 (UTC)

I was anticipating the article possibly listing the full dates instead of just the year at some point in the future. Also, the template wasn't designed to be used merely in a single article.

As for your individual points:

• The template was designed to make automated input feasable. I.e., another template was supposed to be able to input values without having to handle different cases specially. I've since learned that parser functions are too expensive for this to be an advisable design goal.
• I'm not sure what you mean here. I've externalized repeated functions as much as I was able (which, incidentally, seems to conflict with your next recommendation).
• This is an unfortunate case.
• I wasn't using them to avoid redlinks, per se. Rather, I was using it to determine whether the inputted date was a four digit year or a full date. I'll work on finding a better way of doing this.

SharkD (talk) 02:49, 21 July 2008 (UTC)

I think the issue here is entirely the conflict between clean design goals on one side and efficient use of mediawiki on the other. What I meant by the second point is that {{template1|A|B|C}} is more efficient as {{template|A}} {{template|B}} {{template|C}} if it operates on each input separately and has a variable length input list. Your sandbox version is down to 16 seconds to parse, which is much better than the original version. The time is at the very bottom of the html source. Until an actual server admin (I'm not) complains about the ISO template, your version is already an improvement over the one you originally had, so if you prefer that one I'm in no position to complain. I was just looking to see how lean I could make the page with the same user-visible output; I got it down to 9 seconds. — Carl (CBM · talk) 02:57, 21 July 2008 (UTC)

I'll keep tweaking it. I've thought of two more optimizations that I haven't implemented yet. If, after the modifications are completed, the loading times are still inordinately long, then I'll just have to resign myself to the fact that efforts along these lines are futile. SharkD (talk) 03:12, 21 July 2008 (UTC)

I managed to bring the totals down to these:

Preprocessor node count: 62798/1000000
Post-expand include size: 439473/2048000 bytes
Template argument size: 119961/2048000 bytes
Expensive parser function count: 0/500

However, if I leave the "Expensive parser function" as it was before, I can bring the preprocessor node count down to 50350. Which is more significant, 258 "expensive functions" or 12448 preprocessor nodes?

Also, how do I pipe the | character in an expression or condition? I tried wrapping it in the nowiki tags but received an error. Also, I looked for but could not find a template for this use, like there is for table rows (e.g., {{!-}}). Thanks! SharkD (talk) 06:11, 21 July 2008 (UTC)

That is not possible, the number of parameters in a template call is determined by parsing the explicit braces and pipes. so this cannot depend on a condition inside the template call.--Patrick (talk) 08:21, 21 July 2008 (UTC)

That's too bad. As an afterthought, I don't think it's possible in any of the other programming languages I've used, either. SharkD (talk) 06:44, 22 July 2008 (UTC)

Many languages support some form of varargs. MediaWiki templates do not. —Simetrical (talk • contribs) 16:46, 22 July 2008 (UTC)

You can compare the two different versions here: User:SharkD/Sandbox/2, User:SharkD/Sandbox/4. The load times vary wildly regardless of which page I load. The highest I've gotten is ~20 seconds, the lowest ~2 seconds. SharkD (talk) 06:28, 21 July 2008 (UTC)

The time to look at is at the bottom of the HTML source. It will say something like: Served by srv172 in 14.340 secs. That number is the time it took the server to generate the html, and will only fluctuate by a second or two depending on server load. Because of caching, sometimes the page will be served very fast once it is already generated. — Carl (CBM · talk) 13:48, 21 July 2008 (UTC)

That's the value I've been looking at. I've observed it fluctuating by the amounts I specified. SharkD (talk) 06:44, 22 July 2008 (UTC)

Current version

I brought the totals down to this:

Preprocessor node count: 46426/1000000
Post-expand include size: 342490/2048000 bytes
Template argument size: 84760/2048000 bytes
Expensive parser function count: 0/500
Served by srv132 in 10.020 secs.

This is roughly three times as expensive as Carl's version, and twice as expensive as the article minus any date templates at all (the original, minus the date templates, had a preprocessor count of 23674, and Carl's version had 31260). This is still pretty good, IMO. There's still a few tweaks planned that should bring the count down a bit more. SharkD (talk) 04:38, 23 July 2008 (UTC)

Down to 41927 nodes. SharkD (talk) 23:11, 23 July 2008 (UTC)

I've been theorizing why the "served" times vary so greatly. It's possible that the time varies with each server. Is there a way to force a page to be served by a particular server, such as like the "?action=purge" command? SharkD (talk) 23:15, 25 July 2008 (UTC)

A few reasons. First of all, and most importantly, the template might be cached. In that case, it won't have to be parsed. You can avoid this with action=purge. Second of all, there might be some effect from which server it hits, yes, since the application servers used are not necessarily all identical (I'm pretty sure they're not). Third of all, your request is being executed in parallel on the same server with a large number of other requests, and how much load those requests are putting on the server at the exact moment your request is processed can affect the outcome. You can try running the request a number of times and taking an average, then disregarding small fluctuations in the average. —Simetrical (talk • contribs) 15:32, 29 July 2008 (UTC)

I've glanced at the template briefly. My suggestion would be that you should stop using #time altogether. It's really not necessary for people to be able to input the date in Unix time or as "last Tuesday" or any of the other formats #time supports. (Try it yourself: {{#time:Y-m-d|last Tuesday}} -> 2024-11-05.) I doubt the template's users would mind at all if they had to enter it strictly as YYYY-MM. This would probably reduce the runtime to a second or less, I'd guess. —Simetrical (talk • contribs) 15:38, 29 July 2008 (UTC)

Request

Hi, the portuguese wikipedia community made a votation and it was consensus to adopt this [wizard that's already translated, could you please make it start to appear for non registered people that want's to create an article? --Jack Bauer00 (talk) 00:31, 23 July 2008 (UTC)

If you're inquiring about the Portuguese Wikipedia, we don't have any control or say in their processes here at the English wikipedia. If you're proposing a similar process here, I'm afraid it's been discussed at length, on multiple occasions, and the consensus at this time is not to permit anonymous users to create articles. Sorry, UltraExactZZ ^Claims ~ Evidence 02:14, 23 July 2008 (UTC)

No, we were just asking advice about implementing the wizard in the portuguese wikipedia. We don't want to change anything here. GoEThe (talk) 10:26, 23 July 2008 (UTC)

My apologies, I mis-read that. UltraExactZZ ^Claims ~ Evidence 11:08, 23 July 2008 (UTC)

No worries, I made a request at mw:talk:developers. GoEThe (talk) 12:17, 23 July 2008 (UTC)

Your best bet would be Bugzilla, though. Titoxd^{(?!? - cool stuff)} 19:23, 25 July 2008 (UTC)

Except that there's no clear technical request here, unless it's "enable page creation for unregistered users but only via the wizard", and that would not be trivial to do cleanly at all. And anyway that wouldn't work too well with the page creation log, since we still have no log_user_text . . . —Simetrical (talk • contribs) 19:03, 29 July 2008 (UTC)

Duplicate images

Is there a way to browse images with duplicates, like Image:Arc fragata caldas.jpg (look in File links)? I am confused as to why this doesn't add the image to a category, like Category:Duplicate images. That'd be really helpful as people like me could just go through and clean up. If such a category does not exist, can it be created? ~ JohnnyMrNinja 09:54, 26 July 2008 (UTC)

It's possible to generate a list (appears to be about 1300 pages) via this Google search: site:en.wikipedia.org intitle:image "exact duplicate". (After the initial search, which returns only a couple of pages, click to get the full list).

Also, what looks like a template-created message about an "exact duplicate" isn't in fact a template (if you check the edit history of the image description page, you'll not see any edit that created it. Rather (I'm fairly sure) it's something the software adds, because (relatively recently) a hash total is being calculated for each image. I'm not sure why the software doesn't add a category as well, but of course that would complicate matters if the category is incorrect, is renamed, etc. Still, it might be helpful, as you note. -- John Broughton (♫♫) 12:44, 26 July 2008 (UTC)

The mediawiki software could be modified to add these to a category whenever it adds the duplicate image message. Unfortunately, I believe it isn't possible to do without a software change. — Carl (CBM · talk) 12:58, 26 July 2008 (UTC)

A new Special: page listing duplicates might be easier? --_{tiny plastic} Grey Knight ⊖ 07:34, 28 July 2008 (UTC)

Ideal, probably. Good idea, how do those happen? ~ JohnnyMrNinja 07:45, 28 July 2008 (UTC)

Someone writes them. In this case it would likely be just another QueryPage. It should be fairly easy to write, but the query will be expensive (scan of image table), so it's not going to be updateable in real time. Commons people don't get enough love, though, so I think I'll write one up now ― I'm sure they have a tool somewhere that already does this, though. —Simetrical (talk • contribs) 19:22, 29 July 2008 (UTC)

Ohm sign; Omega; and problems with the former

The Ohm Sign character "Ω" (U+2126) and the Capital Omega character "Ω" (U+03A9) look very similar. Indeed Ohm Sign exists in Unicode to allow for round tripping of with legacy code that uses both characters, with the Capital Omega being the preferred character to represent ohms. Indeed, if one types in the Ohm Sign character directly "Ω" It appears that MediaWiki is obligingly automatically converting it at some stage into a Capital Omega, so how did I get that red link earlier? Well, that's because that first link is using a character reference, as is used by the article ISO/IEC 6937. You'd think the problem would be simple to fix, just fill in the redlink with a redirect. No can do, because that same magic that MediaWiki does, causes any attempt to edit it to edit instead Capital Omega. (Which may also account for why that redirect to Omega has three separate occurrences of being changed to point to Ohm and then being reverted.) I could easily enough tweak ISO/IEC 6937 to get rid of the red link in that article, but how many others might be in other articles now and in the future? I can't even use what links here to find out as even if I type in the correct URL by hand ( http://en.wikipedia.org/wiki/Special:WhatLinksHere/%E2%84%A6 ) the autocorrection that MediaWiki is so obligingly providing gives me gives me instead the page of what links to Capital Omega!!!

I'm not particularly desirous of adding an account for myself at MediaZilla, as I like to keep the universe of accounts I've established small and memorable, which is why I'm posting this here instead of there. Caerwine Caer’s whines 01:58, 27 July 2008 (UTC)

I see that you don't use the unicode character entities for both examples, so I thought I'd test them here: Ω Ω . They look identical to me on Windows/IE7 using whatever font is specified as the default. I think it's a browser/font issue, as Wikipedia doesn't alter character entities. One workaround is to use LaTeX (see WP:MATH) to generate the ohm sign. The times font uses characters that are highly distinguishable. For example: $\omega \Omega$. SharkD (talk) 02:24, 27 July 2008 (UTC)

MediaWiki (or, I suspect, actually PHP which it runs on) does convert the Ohm sign (U+2126) to a capital Omega (U+03A9) under various circumstances. I suspect it happens whenever MediaWiki actually tells PHP to treat the string as Unicode; most of the time it just passes data around as (UTF-8 encoded) octet strings. Same, incidentally, happens with the Ångström sign and capital "Å" and the Kelvin sign and the capital "K". That last part actually caused me to accidentally blacklist all titles containing the letter "K" some time ago: for details, see the discussion at MediaWiki talk:Titleblacklist#Two odd inclusions. —Ilmari Karonen (talk) 02:49, 27 July 2008 (UTC)

BTW, which font is the default for English Wikipedia? I've looked at MediaWiki:Common.css, but can only find definitions for special cases. I also haven't been able to access the stylesheets listed in the HTML source. SharkD (talk) 03:03, 27 July 2008 (UTC)

The default font is "sans". This will be whatever you have configured as your default sans-serif font in your web browser. If you haven't changed it, it will probably be Arial on Windows, but it will be different on other platforms. On GNOME, my default is just called "Sans" as far as I can tell (although I suspect it's secretly called something less generic and I just don't know how to figure out). —Simetrical (talk • contribs) 19:52, 29 July 2008 (UTC)

MediaWiki is what does the Unicode normalization. PHP 5 has no native Unicode support ― that will only come in PHP 6. —Simetrical (talk • contribs) 19:52, 29 July 2008 (UTC)

Under most fonts, they will look the same and even when they don't (Ω Ω Ω Ω) they look very similar, but I wasn't complaining about the appearance but the unalterable redlink. Caerwine Caer’s whines 04:03, 27 July 2008 (UTC)

I've submitted this for you as bug 14952. -- Tim Starling (talk) 05:28, 28 July 2008 (UTC)

Proposal to disable hotlinking - question

There is a proposal to disable hotlinking for all Wikimedia projects, but the question was raised if there was a way to see how much bandwidth is actually given up to hotlinks. If anyone knows a way to find out, aside from filing a bug (which I did), could you please comment here. ~ JohnnyMrNinja 23:43, 27 July 2008 (UTC)

Just so readers know, Tim Starling has answered there. (Answer: probably not worth blocking for bandwidth-saving reasons.) —Simetrical (talk • contribs) 20:20, 29 July 2008 (UTC)

Deprecation of {{video}} and the multi-video templates ({{multi-video start}} et al)

I've worked through all the articlespace transclusions of these templates and replaced them with image tags which do the same thing. This simplifies the code and unbroke a lot of articles which had half-broken tables littering their "Media" sections. All these templates still see common use in other namespaces, but I'd like to start the ball rolling in deprecating them. Is this the right place to have that discussion? Chris Cunningham (not at work) - talk 10:24, 29 July 2008 (UTC)

WP:TFD, I think. -- John Broughton (♫♫) 16:52, 29 July 2008 (UTC)

How can I printout Wikipedia pages with links in blue color?

Please tell me how I can printout (hardcopy) a Wikipedia page onto paper with links in blue color ? —Preceding unsigned comment added by Brittanics (talk • contribs) 22:26, 29 July 2008 (UTC)

http://en.wikipedia.org/w/index.php?title=article_name&printable=yes

Geni 22:32, 29 July 2008 (UTC)

Actually that's how to remove the blue -- as I understood it, Brittanics wanted the blue. So if you have a color printer, you can just print the page from your browser. --Trovatore (talk) 22:53, 29 July 2008 (UTC)

Recent browsers actually print following the @media: print rule in the CSS, so that doesn't work. Titoxd^{(?!? - cool stuff)} 23:42, 29 July 2008 (UTC)

Hmm, seems to be a good question, then. Anyone have a solution? --Trovatore (talk) 01:33, 30 July 2008 (UTC)

It's moderately tedious, but if you have Microsoft Office 2007, and you copy+paste, the links will be in blue. As will the references. It's at least one way to do it. seresin ( ¡? ) 01:39, 30 July 2008 (UTC)

Surely there's some way to override link-color-disabling in user CSS. Can't be arsed to find out how, though. ;-) --Father Goose (talk) 07:47, 30 July 2008 (UTC)

If your browser supports inline @media, try in your monobook.css:

@media print {
  html > body a, html > body a:visited,
  html > body a.external, html > body a.external:visited,
  html > body a.extiw, html > body a.extiw:visited,
  html > body a.new, html > body a.new:visited { color:blue !important }
}

If not, you could do some javascript at monobook.js:

if(document.location.href.indexOf('printable=yes') != -1) {
 var rule = 'html > body a, html > body a:visited, '
 + 'html > body a.external, html > body a.external:visited, '
 + 'html > body a.extiw, html > body a.extiw:visited, '
 + 'html > body a.new, html > body a.new:visited { color:blue !important }'
 appendCSS(rule);
}

--Splarka (rant) 07:52, 30 July 2008 (UTC)

Wikipedia Mobile

Why do not we do something as m.en.wikipedia.org which will help getting contents at lower brandwith. (i.e only article intros will be viewed). It will proove a good Idea.--Double Helix 09:17, 30 July 2008 (UTC)

See Wikipedia:WAP access. Anomie⚔ 11:41, 30 July 2008 (UTC)

Random number generation

Is there some extension that enables using random numbers? I.e. something like RND(6) to get a random number between 0 and 5. I'm using {{#switch: {{#expr: {{#time: U}} mod 6}} at the moment - which kinda works but obviously isn't random. CaAl (talk) 14:30, 30 July 2008 (UTC)

{{rand}} isn't random either, but it seems to be what's used. Algebraist 15:25, 30 July 2008 (UTC)

Thanks. That seems to be a fancier version of what I did in the above. No need to change anything then :-) CaAl (talk) 19:55, 30 July 2008 (UTC)

Also, see User:Misza13/Random. (When in doubt, check the editor's index.) -- John Broughton (♫♫) 21:38, 30 July 2008 (UTC)

Since you can't get truly random numbers without lo-fi input, your best bet might be something like {{#expr:{{#md5:{{WP:AN/I}}}} mod 6}}. — CharlotteWebb 21:54, 30 July 2008 (UTC)

#md5? Wut? --MZMcBride (talk) 22:02, 30 July 2008 (UTC)

It's a joke, but a hash function would have a few niche uses. — CharlotteWebb 22:20, 30 July 2008 (UTC)

Sorting tables by the arrows at the top of the column

Hi, I was just looking at List of countries by GDP (PPP) per capita, and tried to sort the table by the Rank column, but when you use the arrow at the top of the column to do that, you get the ranks sorted by 1, 101, 102, 103, etc., and 2 down below everything starting with a 1. Is there a way to fix that? Corvus cornix_talk 21:27, 30 July 2008 (UTC)

Use one of the sorting templates, like {{nts}} or {{smn}}, per Help:Sorting. — Andrwsc (talk · contribs) 21:32, 30 July 2008 (UTC)

I didn't have any problems when I tried (FF2, Mac OS). What are others experiencing? -- John Broughton (♫♫) 21:35, 30 July 2008 (UTC)

Yes, {{nts}} should do. See 2002 Commonwealth Games for an example. —Wknight94 (talk) 21:39, 30 July 2008 (UTC)

If a column contains any cells with non-numerical data, the others which are numbers are interpreted as strings for purposes of sorting. The current hack is to use something like {{sort|008|8}} which basically puts invisible text to the left of the data. You would of course have to assign a number (either "000" or "999") to values like "—" and "N/A". — CharlotteWebb 21:40, 30 July 2008 (UTC)

IIRC, it actually looks at the contents of the cell in the first row to pick numeric or string comparison, which is why some tables seem to sort numerically sometimes and textually other times. Anomie⚔ 23:13, 30 July 2008 (UTC)

External editors

I'm trying to set external editors up but I'm afraid they are really giving me a headache. I created User:It Is Me Here/monobook.js as per the help page and my thingy now looks like that, but when I click the ee button, I just get the option to open some weird file that my PC doesn't recognise. I would like to use IE7 to edit Wikipedia if possible; if not, then FF3. Also, is it possible to rename the "ee" button to, say, "external edit" or something? It Is Me Here (talk) 08:51, 29 July 2008 (UTC)

A web browser is not a text editor. "External editors" means text editing programs like emacs or vi, for example. As for editing in FF3 or IE7, it's not clear what you mean - when you're viewing a page with a web browser, and you click "edit this page" or an "edit" link, you are editing using that web browser (unless you set preferences to edit using an external editor). Did you have something else in mind when you said you want to use FF3 or IE7? -- John Broughton (♫♫) 16:57, 29 July 2008 (UTC)

No, no, I would like to use external programs to edit things (like using Word to edit pages, Inkscape to edit SVGs and GIMP to edit all other images), but I don't understand how to do that, unfortunately. It Is Me Here (talk) 17:29, 29 July 2008 (UTC)

You can't edit images or other media files at Wikipedia; you need to download them to your computer, edit them there, and upload them. The "external editor" option is only for text. And you still haven't explained what "using IE7 to edit Wikipedia" means, if it doesn't mean clicking on "edit this page" and seeing an edit box. Does IE7 have some sort of built-in text editor (search and replace, multi-clipboard, etc.) that isn't well advertised? Can you provide an example of using IE7 (or FF3) to edit other type of web pages or files, that demonstrates what you have in mind? -- John Broughton (♫♫) 19:51, 29 July 2008 (UTC)

Well I was thinking of setting my WP account / copy of IE7 so that pressing ee opens a page in an appropriate text editing program that has normal bold etc. buttons so that you don't see lots of Wiki markup when editing but see instead more-or-less normal text.

Returning to your comment that I just get the option to open some weird file that my PC doesn't recognise, I think that you're being asked, at that point, to select a specific text editing program (in IE7, there should be a "Find" button). Do you actually have a text editing program on your computer? -- John Broughton (♫♫) 21:45, 30 July 2008 (UTC)

Indeed - upon clicking the ee button, I get this, and clicking the Find button just links me to some Microsoft site which tells me that Notepad and something called "Microsoft Picture It!" can open the file. As far as I know the only text editing programs I have installed are Word 2007 and Notepad. It Is Me Here (talk) 19:47, 31 July 2008 (UTC)

Lupins popups and the demise of query.php

As mentioned here, query.php is scheduled to die the 25th of august. I have a replacement for popups that adds support for api.php. I suggest that we replace both User:Lupin/popups.js and MediaWiki:Gadget-popups.js, with my new version (i'll prepare both versions) august the 10th so that we are in time. I would really appreciate it if some more users would test my replacement code before that time. --TheDJ (talk • contribs) 11:27, 31 July 2008 (UTC)

How about you get it made a Gadget so it's easier for people to try out? —Simetrical (talk • contribs) 18:24, 31 July 2008 (UTC)

There is a popup gadget already: Wikipedia:Tools/Navigation popups under Preferences > Gagets. In fact, I thought it was Lupin popups which I used to have. —Mattisse (Talk) 18:28, 31 July 2008 (UTC)

Good idea actually. Let's add an apipopus Gadget, so people can test. thx for the suggestion.

Article uses old version of image

The current version of Holes (novel) uses the correct image; this version uses an old version of the image. The only difference in wikicode is the image size. (I changed the size to get it to update the image. It did not help to purge the article or make a null edit.) This seems to be a bug. —teb728 t c 18:54, 31 July 2008 (UTC)

Purging the image fixed it; I don't know why. Algebraist 20:12, 31 July 2008 (UTC)

Theora

foundation-l asked for some comment on Theora with Firefox 3.1a2pre and its support of <video> and I figure this might be a good place. Besides the known bug of closing a tab won't stop audio it seems that with larger videos like Image:HardDisk1.ogg the buffering is very poor and leads to you getting one frame per second with no way to pause while it loads. gren グレン 19:45, 31 July 2008 (UTC)

"Unable to proceed"

Resolved

Whenever I try to rollback an edit, this is what I get:

"There seems to be a problem with your login session;

this action has been canceled as a precaution against session hijacking.

Please hit "back" and reload the page you came from, then try again."

What could the problem be? CL — 23:52, 31 July 2008 (UTC)

I think it means you logged yourself out in another window/tab. Log out and log back in, that should fix it. Calvin 1998 ^(t-c) 23:59, 31 July 2008 (UTC)

Tried that, but the same thing shows up - CL — 00:00, 1 August 2008 (UTC)

This is happening to me too. I asked at WP:HD, but I'll cross-post here too. Perfect Proposal ^{Speak Out!} 00:05, 1 August 2008 (UTC)

Me too. Not a cookie problem (cleared cookies prior to logging back in). Calvin 1998 ^(t-c) 00:09, 1 August 2008 (UTC)

Okay, I'll watchlist WP:HD to see what comes up there :) CL — 00:09, 1 August 2008 (UTC)

(ec) The same thing has just showed up on my computers. I had two IEs open, but I don't know if it's the case. Anyway, I used WP:UNDO. Admiral Norton ^(talk) 00:11, 1 August 2008 (UTC)

Yes, I'm using UNDO as well; it just doesn't have the cachet of using the oh-so special "rollback" feature :) CL — 00:13, 1 August 2008 (UTC)

I also asked the same question at Wikipedia talk:Rollback feature#Unable to roll back. I'll direct it here. ... discospinster _talk 00:14, 1 August 2008 (UTC)

I was afraid the rollbacker group somehow went missing, but it shows up at Special:ListUsers. Must be some weird bug. I hope it'll have been fixed by tomorrow. Admiral Norton ^(talk) 00:17, 1 August 2008 (UTC)

Bug 14997. Titoxd^{(?!? - cool stuff)} 00:45, 1 August 2008 (UTC)

I'm having the same problem. I hope it gets resolved. L337*P4wn 00:54, 1 August 2008 (UTC)

Admins have been notified (WP:AN#Rollback is currently down). Not sure whether discussion will come here or whether we'll have more cross-posting... Calvin 1998 ^(t-c) 00:57, 1 August 2008 (UTC)

A recent change to MediaWiki broke it This is cross-wiki, too. The smaller wikis will be getting hammered. This levels the playing field for the vandals. Enigma ^message 01:01, 1 August 2008 (UTC)

It's already fixed, we just need to wait for the change to become live (which it evidently hasn't yet). Calvin 1998 ^(t-c) 01:02, 1 August 2008 (UTC)

Until then, God help us, we're at DefCon 1. Ugh, you really take Rollback for granted sometimes - CL — 01:06, 1 August 2008 (UTC)

• It's working again! Enigma ^message 01:08, 1 August 2008 (UTC)

User:Redirect fixer

Can anyone figure out what when wrong with this automated edit by User:Redirect fixer? -- Ed (Edgar181) 17:44, 29 July 2008 (UTC)

API messing up again? Either that or something went terribly wrong with the bot/whatever it is. Calvin 1998 ^(t-c) 17:50, 29 July 2008 (UTC)

Here is another one. Looks like a copy of User talk:Acroterion. -84user (talk) 19:14, 29 July 2008 (UTC)

At least 12 redirect fixer edits today were broken. --- RockMFR 20:49, 29 July 2008 (UTC)

Hmn... is it even possible to block the account, given that it is basically a shell for a MediaWiki process? Clearly there are bugs here that need to be addressed. Happy‑melon 21:07, 29 July 2008 (UTC)

See the long discussion at User_talk:Gimmetrow#WP:GO. SandyGeorgia (Talk) 21:09, 29 July 2008 (UTC)

As far as I'm aware, the account is unblockable. If it's causing issues, file a bug like you would for any other MediaWiki issue. Be sure to include relevant diffs. Cheers. --MZMcBride (talk) 21:15, 29 July 2008 (UTC)

Filed: T16976 Happy‑melon 21:34, 29 July 2008 (UTC)

It's not related to this bug above, is it?--Father Goose (talk) 21:30, 29 July 2008 (UTC)

This should stop happening now, hopefully. Apparently it was editing from srv104, which is inaccessible by ssh and had the incorrect DB configuration. I've firewalled it on all the database servers. -- Tim Starling (talk) 02:58, 30 July 2008 (UTC)

I went back this morning and reverted about 25-30 Redirect fixer edits; in case this problem ever occurs again, the methodology was to search through that user's contributions for pages where it was the last editor [i.e., "(top)" appears at the end of the contribution item], and where the text of the page did not contain "#REDIRECT", which indicates an error since any page that this "user" edits should by definition be a redirect. --Russ (talk) 13:04, 1 August 2008 (UTC)

Idiotic Wikipedia code turns fact into fallacy

In the mark-up of the South Island article, the statistics box says "ethnic groups". Why does this show up as "Indigenous people"? This bizarre piece of coding needs to be changed. In an earlier version of the article, the editor had stated, correctly, "ethnic groups = Māori, European". This showed up, incorrectly, as "Indigenous people Māori, European", and a subsequent editor quite reasonably re-edited it to "ethnic groups = Māori", so that it would read, "Indigenous people Māori". Less reasonably, s/he pointed out the previous editor's "error" in the edit summary.

Koro Neil (talk) 04:01, 31 July 2008 (UTC)

The parameter name was "ethnic groups" but the caption was "indigenous people". Someone didn't know the difference when they added this option; I've changed the caption to read "ethnic groups" which is what people will probably mean when they write "ethnic groups = ...". Pegasus «C¦T» 07:03, 31 July 2008 (UTC)

Cheers, Pegasus. Koro Neil (talk) 09:46, 31 July 2008 (UTC)

I agree it's best to not limit it to indigenous people but the documentation has said so since January 2007 [11] (still says so), and I wonder how many of the current uses follow that. PrimeHunter (talk) 12:17, 31 July 2008 (UTC)

As there is nothing written anywhere why the option should be restricted like that, I updated the documentation as well. Pegasus «C¦T» 09:56, 1 August 2008 (UTC)

Section link in edit summary broken

Resolved

The '→' section links in automatic edit summaries are no longer working for me. They point to the relevant page, but not to the section. This occurs everywhere almost everywhere the links appear (watchlist, history, contribs, recent changes, etc.), whether logged-in or -out, and on FF, IE, Opera and Safari (all WinXP). This has only been affecting me for a few hours, but User:Fuhghettaboutit reports having experienced it for the last two weeks. Any ideas? Algebraist 00:37, 1 August 2008 (UTC)

It worked for me yesterday. Is it a possibility that it has something to do with the recent demise of rollback? Calvin 1998 ^(t-c) 00:38, 1 August 2008 (UTC)

Probably. Opinion on Bugzilla seems to be that the same revision broke both. Algebraist 00:50, 1 August 2008 (UTC)

• I came here to report the same thing. For example, the section link in this diff [12] goes to http://en.wikipedia.org/wiki/. ·:· Will Beback ·:· 00:44, 1 August 2008 (UTC)

• Bug 14995. Titoxd^{(?!? - cool stuff)} 00:45, 1 August 2008 (UTC)

  Oops, forgot to check diffs. That happens for me too. Algebraist 00:47, 1 August 2008 (UTC)

Fixed. Algebraist 01:09, 1 August 2008 (UTC)

I don't thnk so. This diff [13] leads to this link "http://en.wikipedia.org/wiki/#Section link in edit summary broken". ·:· Will Beback ·:· 01:13, 1 August 2008 (UTC)

Now the watchlist/contrib links are broken in a new way: the first character of the section title is missing. Algebraist 01:21, 1 August 2008 (UTC)

I came here to say the same thing. The link URLs from clicking watchlist section links use %20 instead of the proper _ (underscore.) Grandmasterka 06:21, 1 August 2008 (UTC)

Just came here to post the same thing. Good thing others have noticed. -- RattleMan 09:19, 1 August 2008 (UTC)

Me too. It's also failing to encode correctly other characters (actually, it doesn't seem to be encoding anything). See [14], if you click to reach the correct section, it uses the anchor "Unable to proceed", but the correct anchor is .22Unable_to_proceed.22 I bet that it also has problems with apostrophes and other punctiation characters. --Enric Naval (talk) 13:22, 1 August 2008 (UTC)

I fixed part of this last night, Rotem fixed the rest in r38356. Don't know when it will go live. —Simetrical (talk • contribs) 15:56, 1 August 2008 (UTC)

Should be all fixed now. :) --brion (talk) 17:54, 1 August 2008 (UTC)

Importing article histories

Is there currently any way to import the history of an article from another-language Wikipedia? (Special:Import does not seem to be working; see Help:Import#Wikipedia-specific help.) {{translated}} allows for some attribution in the form of linking to the version of the article that was translated, but it does not transfer the contributions history. Thanks, –Black Falcon ^(Talk) 15:58, 1 August 2008 (UTC)

If this feature is disabled it should probably remain so until all SUL-related name conflicts are resolved. — CharlotteWebb 16:06, 1 August 2008 (UTC)

(ec)Full history imports are disabled here (IIRC) because they cause very complicated GFDL issues. Although the problems are reduced by SUL, the biggest problem is that contributions can be assigned to users who do not exist, or users who share a username with someone on another project may be credited with edits that they didn't actually make (effectively plagiarism). {{translated}}, while sub-optimal, at least avoids these issues. Happy‑melon 16:08, 1 August 2008 (UTC)

What about making a dummy edit so as to include links to the userpages of contributors (that is, typing "Contributors: de:Benutzer:User 1, de:Benutzer:User 2, ..." instead of "Contributors: User 1, User 2, ..."). Would that be an acceptable method of attribution, when combined with {{translated}}? –Black Falcon ^(Talk) 16:29, 1 August 2008 (UTC)

Anything's better than nothing - {{translated}} is more user-facing than attribution-based. Happy‑melon 16:39, 1 August 2008 (UTC)

OK, thank you. –Black Falcon ^(Talk) 16:48, 1 August 2008 (UTC)

Administration of Wiki Accounts

Hello,

I've just installed MediaWiki on a server at work, and I'm wondering where I can find documentation on how to secure the Wiki by only allowing one account to be able to edit anything on the site. Thanks in advance.

- Amin —Preceding unsigned comment added by 216.249.3.98 (talk) 17:11, 1 August 2008 (UTC)

I think you mean you want to disable account creation and disable anonymous edits in LocalSettings.php:

$wgGroupPermissions["*"]["edit"] = false;
$wgGroupPermissions["*"]["createaccount"] = false;

Of course if anybody has created an account before you disabled account creation, you will need to either block those accounts or disable their editing like this.

$wgGroupPermissions["user"]["edit"] = false;

More options can be found at mw:Manual:User rights. — CharlotteWebb 18:37, 1 August 2008 (UTC)

mw:Manual:Preventing access is a pretty good read as well. --MZMcBride (talk) 22:24, 1 August 2008 (UTC)

Request

Request: can the degree symbol (°) be added to the repertoire of tiny blue characters available below the edit screen when editing a page? Thank you, Badagnani (talk) 21:36, 1 August 2008 (UTC)

It's already there? Insert: – — … ‘ “ ’ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · § --MZMcBride (talk) 21:40, 1 August 2008 (UTC)

OHH, way up top! I didn't even see those. You're good! Badagnani (talk) 21:41, 1 August 2008 (UTC)

Toggle tech--help on the commons

re: http://commons.wikimedia.org/wiki/Category:Maps_in_Spanish In large commons categories on the commons, particularly the Maps by languages "List categories" (like the link given) it would be very useful to be able to toggle the magic word __NOGALLERIES__ on or off... like the templates which toggle between show and hide (Collapse). (I've just temporarily installed one on that page)

1. A template which could be "defaulted" to do either and toggle to the other state would be truly good.
2. A script adding a tab or some such to do the same on any category page would possiblly be even more useful to me personally, and to others which work there and here as well.

Any help in one or both of these "wish list" endeavors would be truly appreciated. If this has a rapid resolution please ping me here this evening! Thanks // FrankB 23:39, 27 July 2008 (UTC)

Commons has it's own village pump; that's the best place to discuss changes to that website: Commons:Commons:Village pump. -- John Broughton (♫♫) 15:47, 28 July 2008 (UTC)

Gee, I asked for how-to', and I get the blindingly obvious. Ahem. The last I looked there were hundreds of script savvy computer science trained editors here and a very relatively few comparatively there... or perhaps you know of a VPT there I'm unaware of? Anyone else? // FrankB 16:11, 28 July 2008 (UTC)

You can ask for a script at commons:Commons:Bots/Requests. I have a bot for use here at enwiki, but I would never use it on the commons, as I don't know enough about their policies; I hope that other enwiki bot operators would agree. -- Eugène van der Pijll (talk) 16:38, 28 July 2008 (UTC)

As an experiment I've written User:Splarka/togglegallery.js, which so far only toggles it on. Well, it sort of does. For every Image: link on a 'd category page it (when you click it in the toolbox) inserts an <img> tag. It uses batched (50 at a time) API queries to perfectly generate a thumbnail of the specific width (or smaller if none larger). It is based on User:Splarka/galleryimagelist.js which does something similar to Special:ImageList. I haven't written the off yet, but it should be a simple matter of just removing all image tags on the page and hiding the space they took up. You can test it by adding to your commons monobook.js:

if(wgCanonicalNamespace == 'Category') importScriptURI('http://en.wikipedia.org/w/index.php?title=User:Splarka/togglegallery.js&action=raw&ctype=text/javascript');

--Splarka (rant) 10:14, 30 July 2008 (UTC)

I appreciate the good faith unfresh answer... but did you finish here...?

(BTW-John B: There are maybe 60-70 regular editors on the commons... and most only contribute images. If anyone is interested in either category or template support work, talk to me or Rocket000 over there for ideas of what can be done. If you have language skills outside english, Rocket000 implied we're really short of translations there in lots of needs. I say "We're" for it's a foundation project, AND so is this. We should all be contributing a bit there and timesharing anyone with editing skills here can figure out the category system there and contribute by helping sort the images all the wiki's dump there--and the auto-categories on BOT moves really suck most times... it's constantly putting images in root categories... which needs hands to move.)

Your post on my talk implies something finished in both modes. So, did you finish here? // FrankB 20:13, 1 August 2008 (UTC)

You tell me. It now has both an 'on' and 'off' mode, but they are not opposite sides of the same coin. One removes galleries (and replaces with a list), and one turns a list of links to Image: namespaces into a sort of gallery. To emulate exactly what __NOGALLERY__ does in javascript would be a bit DOM-heavy/slow, this is faster and clean ... if not exactly the same in appearance to adding/removing __NOGALLERY__. I consider it "done", but you'll have to test it and see. To test it, go to commons:Special:Mypage/monobook.js and paste in

if(wgCanonicalNamespace == 'Category') importScriptURI('http://en.wikipedia.org/w/index.php?title=User:Splarka/togglegallery.js&action=raw&ctype=text/javascript');

(or copy mine) and then purge your browser cache. Go to a category with __NOGALLERY__ and look for a link in your toolbox sidebar, and do the same for one showing a gallery. --Splarka (rant) 07:27, 2 August 2008 (UTC)

Mystifying display of page title

I have just accessed Wikipedia:Template messages/User namespace for the first time in months, and not only does the page title at the top display as Wikipedia:template messages/User namespace (note the lower-case t), but the browser's history, the tab, and the title bar all refer to it as title (more accurately, title - Wikipedia, the free encyclopedia). Quite odd indeed... I have checked the page and there is nothing in the syntax to suggest such an effect (by the way, the title is replaced with the full name in edit mode, though still with lower-case t both on the page and in the browser). It's probably one of the transcluded templates, but they all look innocent. I've purged the page, and then bypassed my cache; nothing has changed. Waltham, The Duke of 21:33, 1 August 2008 (UTC)

It's transcluding {{wronguser}}, which uses a JS hack to change the page title. --MZMcBride (talk) 21:37, 1 August 2008 (UTC)

And {{lowercase-user}} is making that t lowercase. Algebraist 21:38, 1 August 2008 (UTC)

I see. (These templates slipped under my radar.) Isn't there a way to circumvent this problem? The former doesn't display anything, but the latter should be kept up to date, and this seems pretty hard to do that without transcluding the template. Any ideas? Waltham, The Duke of 21:26, 2 August 2008 (UTC)

Fixed. --Random832 (contribs) 23:40, 2 August 2008 (UTC)

Union / Intersection operations

This must surely have been suggested before but is there a way of doing intersections and unions of article groups listed under categories and what-links-here. For instance I would love to replace the long lists of movies with cockroaches at Cockroach#Popular_culture with a piped wikilink to something that produces the intersection of category:movies and what-links-here for cockroaches. Shyamal (talk) 14:56, 2 August 2008 (UTC)

Found the material on this here. Shyamal (talk) 16:03, 2 August 2008 (UTC)

Global bot policy

The global bot policy at meta has recently been finalised, and en.wiki is required to 'opt in' to any associated global rights. All comers are welcome to participate in the discussion at WT:Bot policy. Happy‑melon 21:00, 2 August 2008 (UTC)

Page redirecting to external unaffiliated site

A user asked a question at the help desk here regarding being redirected to an external site when searching for Golem: It!, intending to be taken to the article The Golem: It!. As he/she explained, clicking on the first link (or using the search bar with go), takes one directly to a page at an external and unaffiliated site, http://golem.linux.it/index.php/It%21. I'll let you tech gurus explain this one.--Fuhghettaboutit (talk) 11:27, 3 August 2008 (UTC)

It appears to be a function of entering Golem: into the search box. DuncanHill (talk) 11:42, 3 August 2008 (UTC)

Golem: is listed as an interwiki at meta:Interwiki map [15]. I don't know why it's there, or whether it's a good thing, but that is the reason for the redirect. -- zzuuzz ^(talk) 11:50, 3 August 2008 (UTC)

Moving pages.

I really want to add pages to my watchlist manually, when pages are moved the moved page gets automaticlly to my watchlist, I'm sick of having to remove unneeded pages from my watchlist because of move. Now what I am suggesting is an option in "My preferences" where I can choose "Automatically add moved pages to the watchlist" and disable that. Is there any chance that can be done? TheBlazikenMaster (talk) 15:21, 3 August 2008 (UTC)

My page moves settings already give a click box to select adding it to the watch pages, including the talk. Perhaps yours is being over-ridden by a different setting. My default used to be Add any page I edited to the watch, but is now set to I'll manually add such pages... (however that's worded)... suggest trying that. // FrankB 15:56, 3 August 2008 (UTC)

The point is that when someone else moves a watched page, you end up watching both the original and new titles. This is in general a good thing (who wants to stop watching a page just because someone's changed the title to use and endash?) but makes pagemove vandalism more annoying. Algebraist 16:00, 3 August 2008 (UTC)

What would be nice would be a clearer definition of when a pagemove is 'reverted' - and when a page move is reverted (ie after vandal pagemoves) the pagemove target (HAGGER or whatever) should be removed from all the watchlists it was automatically added to. Kind of complicated to implement, I expect, though. Happy‑melon 16:19, 3 August 2008 (UTC)

It is enough for me to see on my watchlist "Page X moved to Page X" and I want to decide for myself whether or not I wanna watch the moved page. Of course this is not only if the page move gets reverted, I also often have to remove pages from my watchlist that used to be the title. I wanna do it manually, not automatic. TheBlazikenMaster (talk) 16:34, 3 August 2008 (UTC)

Reflist with 2 columns

Template:Reflist(edit talk links history) doesnt work with multiple columns in all browsers. I need a format with only 2 columns. Is there any already made, that works in all browsers? If not, can anyone help me make one? thanks Ark25 (talk) 15:39, 31 July 2008 (UTC)

What browser are you having problems with? There has been some discussion about on the template talk page— you should comment there so we can see what issues you have. --—— Gadget850 (Ed) ^talk - 18:36, 31 July 2008 (UTC)

The discution took place many times about the same issue. It doesnt work in IE and Opera. So it's not much use I open the same discution again, as the conclusion is "it will work sometime later". I am looking for another template, with only 2 columns, but anyways I will move my comment on the {{reflist}} talk page. Ark25 (talk) 01:50, 1 August 2008 (UTC)

It also doesn't work in Safari on WinXP. DuncanHill (talk) 13:49, 1 August 2008 (UTC)

For previous discussion about this problem, see Template talk:Reflist/Archive 2008#Multiple columns deemed bad. DuncanHill (talk) 14:25, 1 August 2008 (UTC)

This is a general problem with the mozilla extension, like SVG, most browsers don't support it, not just some. Such tech frills ought be waited upon... If it doesn't work in IE5, shouldn't be used imho. // FrankB 17:12, 1 August 2008 (UTC)

TEMPLATE WISE ADMIN NEEDED HERE STAT -- Template_talk:Reflist#Editprotect_request_2008-08-01 <g> (Why do I feel like an Nurse on a PA system?) // FrankB 19:35, 1 August 2008 (UTC)

IE5 was released 9 years ago and as a 0.07% market share [16]. I think it's pretty safe to not support it. —Remember the dot ^(talk) 19:40, 1 August 2008 (UTC)

Reflist with more than one column does not work on the current IE, or on several other browsers either. I think it is lunatic to have a feature (and such an important one at that) which degrades the Wikipedia experience for so many readers. DuncanHill (talk) 19:53, 1 August 2008 (UTC)

I think it is something like 75% for all IExx - none of which support the multi-column reflist. DuncanHill (talk) 19:58, 1 August 2008 (UTC)

I know that multicolumn layout is not supported in the current version of IE - I was just pointing out that it's impractical to try and support every browser ever made. I don't think that having multicolumn layout in Firefox and Safari but not in IE and Opera is a big deal, since I'm pretty sure there's no good way to give IE and Opera multicolumn support from our end. —Remember the dot ^(talk) 20:01, 1 August 2008 (UTC)

Multicolumn doies not work properly in Safari on WinXP either. DuncanHill (talk) 20:20, 1 August 2008 (UTC)

I'd have to agree with RTD here... most visitors to Wikipedia who use IE have never (and likely will never) view it in any browser besides IE, so they'll never know the refs are supposed to be multicolumn. And it's pretty hard to miss something you never knew about... ;) As for Opera... well, it's probably the visitor's choice to be using it, so if they know about the reflist layout and it bothers them that much, they can either live with it or use FF or another browser that supports multicolumns. —Dinoguy1000 —Dinoguy1000 20:07, 1 August 2008 (UTC)

So why bother having multiple columns anyway? They don't display as multiple columns for most users, and for some they break the links between a refnumber in the text and the reference itself. "Wikipedia - the encyclopædia which doesn't display properly for most users" DuncanHill (talk) 20:20, 1 August 2008 (UTC)

Can you show me an example of multicolumn references breaking something? —Remember the dot ^(talk) 22:17, 1 August 2008 (UTC)

Yes, here it is (as featured in the archived discussion linked above) Image:Safariscreenshot.PNG. As you will see, the little letters from references get displaced (reference 7), and (which I cannot illustrate from a screenshot) when one clicks on a ref number in the article text, it does not take one to the reference, but rather to where the reference would be if the reflist was in one column. DuncanHill (talk) 22:22, 1 August 2008 (UTC)

If the columns don't display right in (some versions of) Safari, it would be a simple matter to remove the -webkit vendor-specific rule. Safari should then ignore the columns, just like IE. —Simetrical (talk • contribs) 17:38, 3 August 2008 (UTC)

While multicolumn references are a bad idea in general (it's annoying to scroll through, causes wrapping problems with long words and URLs, and is very unfriendly to small screens), there is nothing obviously wrong with Image:Safariscreenshot.PNG. The window has scrolled down as far as possible, bringing the reference into view as requested. This is no different from the result of linking to a reference in a single-column list that's near the end of the page. --brion (talk) 01:21, 4 August 2008 (UTC)

See DuncanHill's remarks above. First of all, the backlink letters for reference 7 are clearly wrong: if you look, you'll see that they're overlapping "Obituary" in external links, and are missing from the reference itself (there's just a gap). By the same token, he says that clicking the ^[7] in the text brings you down to that line in External links, not to the proper place. —Simetrical (talk • contribs) 16:01, 4 August 2008 (UTC)

Clock offset

I have already indicated the time offset I would like in my Preferences and it shows the correct offset and correct subsequent time there, but my clock in the top right-hand corner of my Wikipedia page still shows the default server time without my offset applied. Am I doing something wrong? Images:

• http://www.picoodle.com/view.php?img=/3/8/3/f_Time1m_b30592f.jpg&srv=img34
• http://www.picoodle.com/view.php?img=/3/8/3/f_Time2m_178e48e.jpg&srv=img32

It Is Me Here (talk) 13:12, 3 August 2008 (UTC)

As I understand it the clock gadget always shows UTC (server) not your local time. – ukexpat (talk) 16:36, 3 August 2008 (UTC)

Hmm that's annoying - is there no way at all to change it, then, I take it? It Is Me Here (talk) 20:54, 3 August 2008 (UTC)

The local time is shown on the clock on your PC. The UTC clock gadget is mainly to see what time it is in relation to posts on discussion pages, where the time is always in UTC. Mr.Z-man 21:02, 3 August 2008 (UTC)

OK, thanks guys. It Is Me Here (talk) 07:07, 4 August 2008 (UTC)

Template self-inconsistent issue

Can use a hand from an expert template programmer. History will show the usage was trying to update (suggest at least two tabs), but the base issue is using and example of the template seems to be causing a premature

expression. I've tested it using Lorem, against a colored background, and it terminates the color "/div" when it shouldn't. Examining the page source when operating normally, even in the various modes, shows balanced pairs of <div ... /div> as does painstaking counting of pairs inside a text editor.

The only good news is the template (which has a wide distribution) continues to keep working fine on used-on-page inspections, despite a few trial changes as you can see in the history. The only other thing I can think to maybe do is subst the examples I want on a sandbox page, then paste that back in. I'd rather not, as the template is already a long complicated page.

See Template:Commoncats(edit talk links history) which generally replaces {commons cat} and {catmore} plus will link multiple categories/articles. Any help on this snag will be truly appreciated. // FrankB 13:45, 3 August 2008 (UTC)

• Side issue question: Is there a public domain editor compatible from XP out there that will highlight HTML BLOCK ENDS, show mismatches and so forth like some C/C# editors will show nesting issues? /// FrankB

If you don't get any help here, you probably should try WP:RT. I think that's where the template experts hang out. -- John Broughton (♫♫) 17:06, 4 August 2008 (UTC)

Thinking in a different box

There was a discussion on whether to disable hotlinking on Meta to disable image hotlinking recently that had some support but went down in flames anyway after a lengthy discussion. The "problem" there was deemed a paper tiger, but there is a real background problem too.

The underlying problem remains though which I'll state as: How to stop everyone possessed of excessive juvenile attitudes with a camera phone from getting gratification for abusing our tolerance giving them the ability to upload images while overburdening process here. I cite as a case in point the crap/trash non-content the overworked image specialists here have to deal with every day on pages like this here, where one finds images like this gem and This junk (This one struck me as a camera phone, almost certainly), and all this kind of stuff and half a dozen other pages I viewed on en.wikipedia images for deletion on the August 1st log are just trash and a burden on the time of people already overburdened... So the questions (asked here first, but the page has "died" for now):

1. Does the system software, as I infer, already have some sort of edit count "trusted editor" feature already built in... I refer to my impression that "page move" wasn't available as a tab to me in my early editor days, then became available... seemingly (Actually I was told this by an admin, I believe) because I'd been editing long enough.
   1. as a further indicator, something like this is already present on the system, the tabs on the commons are somewhat different depending on the page one is on, and there are certainly background variables identifying ME when I view a page source on the browser, that have come from the system.
   2. in short, I think most of the tech for this is already in place, or could be an easy upgrade.
      
      
2. Would it be possible to add a bit or bits to control image hotlinking, including to our own pages, until the image was vetted and approved.
3. Unlike the site discussed hotlinking block of the Meta discussion, the thought is good editors aren't generally uploading such junk, but are instead more like the guy that uploaded the second image above... someone with essentially no significant edits.... he had four or five, counting the deleted image, and I'll let you judge the merit of the one where he created a page that said "Boobs" <g>
   1. There is one side issue here too... why aren't the anti-vandalism and new page patrolling folks checking new images and warning their uploaders... the guy had already had one image deleted, yet I was the only one that placed a warning on his page. Harumph!
   2. Even that little effort would help the image specialists, a lot, I suspect...
      
      
4. In sum, my concept is if the system were set up so people could upload an image, and if they weren't "trusted editors" then they'd have to find such an editor to vet the image, make sure it was categorized properly and so forth, much as we vet images and re-categorize such as Bot transfered images on the commons from here.
5. One would hope that any trusted editor, or admin could and would continue having the image link disabled and immediately nominate it for speedy deletion... reducing said burden already overloading image specialists. (Which I am certainly not!)
6. In my conceptual visualization, the image would be something showing as a blue link on the target page, until vetted... then with the proper dotting of eyes and crossing of tees, would show thereafter.

Thanks // FrankB 14:28, 3 August 2008 (UTC)

Yes, part 1 does already exist, see mw:Manual:$wgAutopromote. The problem with the rest of the system is, Tim Starling pointed this out on the poll on meta, that the extra processing effort to determine whether or not the image is hotlinked would be on the same level as the bandwidth used by hotlinking, except in this case, you'd be querying the database instead of checking the request information, so it may be more expensive (computationally), but I'm not sure. However, this would still allow images to be hotlinked, if they were approved, so you would only have a fraction of the bandwidth savings. Mr.Z-man 15:41, 3 August 2008 (UTC)

To clarify, I'm not concerned at all with bandwidth savings or costs in this case, but with discouraging such trash images firstly, and secondly unburdening the already way over worked volunteer staff... if that takes an extra ten thousand or fifty thousand a year, it's still a bargain for the foundation overall... and there are offsetting savings. Also, I believe you would be wrong on the computational costs, as a 'permissions bit check' would mean only a few lines of code in the operating system... at most a few microseconds to substitute a boilerplate image and tag a line "Image not yet released by mediawiki" or some such combination.

Given your link data, the cost becomes a check when the image is uploaded... with some kind of block bit set to indicate it's not been vetted. Again, not much processing time for a "one of per image" situation. So I'll take that as a first indicator that the overall scheme is technically feasible. Thanks. Anyone else have two cents on this? // FrankB 15:54, 3 August 2008 (UTC)

The big cost is not on upload (we already have to check usergroups there) or when someone comes to approve the image (basically the same as newpages patrol), those are one-time events, so cost would be minimal. The cost would be checking whether or not each image is approved whenever the server gets a request for it. Mr.Z-man 16:28, 3 August 2008 (UTC)

Am I being that unclear? That is the cost... all those man-hours because we have an overly-liberal always assume AGF policy in place that is being victimized to play pranks... did you see the length of that list page of 'delete these image proposals' for just one day, forsooth! Doesn't THAT needless work bother you—especially knowing that it falls on the heads of relatively few of us? This is other people's time were allowing to be wasted... leisure time DONATED in a thankless task... I'm trying to lighten that burden for it's the Right Thing and needs done. (We're all underpaid after all <g>) Those folks are just less appreciated than most... and encouraging the backlog to be continually renewed is the current process. // FrankB 17:39, 3 August 2008 (UTC)

The larger and more in-your-face you make comments, the less likely people are to read them. Bold and italic are invariably more than adequate. Happy‑melon 17:41, 3 August 2008 (UTC)

Except, A) This won't significantly reduce the work, it will actually create a lot of work initially unless existing images are grandfathered in, this doesn't physically stop people from uploading the images, they'll still have to be tagged and deleted or sit in unapproved-purgatory forever. B) Any technical solution has to be approved by the CTO. If it will have a major impact on performance, it likely won't be done, short of intervention by the board of trustees. C) Nobody's forcing people to patrol these images, if they don't like it, they're free to stop at anytime. D) This would require policy changes anyway, why not start with, as Simetrical says below, with a change to the CSD criteria, or trying to recruit recentchanges patrollers to patrol the upload log, as is done on commons? E) You talk about donated time, where do you think the money for the servers comes from? The only required costs from having these images is bandwidth, storage space, though there is the possibility of copyvios as well. If people don't want to patrol these images, they don't have to. That cost is totally optional. Mr.Z-man 19:19, 3 August 2008 (UTC)

I don't think this calls for a technical fix. I think it calls for an expansion of speedy deletion criteria for images. —Simetrical (talk • contribs) 17:43, 3 August 2008 (UTC)

Concur on that... as a fix but not as a 'feature' and changing just Speedy-D... that puts it all on the admins. The other path is some kind of two man rule, or one man rule check, which can ease the load on admins. // FrankB 17:59, 3 August 2008 (UTC)

There should be no problem with load on admins. As far as I've heard, there are currently not serious issues with admin task backlogs. If any develop, that problem should be fixed by making more people admins. In practice, a CSD of "image has no reasonable encyclopedic purpose" should be enough to cut out most of the trash very efficiently. Say, any image may be deleted if it's been posted for at least a day, is used in no articles, and seems to have no possible encyclopedic use (or for Commons, no possible educational/academic/etc. use). —Simetrical (talk • contribs) 16:07, 4 August 2008 (UTC)

An alternate proposal

These are just some quick notes, not a full proposal, it would probably need a bit more work to be workable, but its a bit more lightweight than the above one:

Veteran image patrollers are pretty well trusted and I would bet that having the image patroller and the deleting admin checking the image before deletion in many (most?) cases is just a waste of time.

1. Change the CSD image criteria to allow for quicker deletion of obvious crap images.
2. Create a new user right/group that only allows deletion/undeletion in the image (talk) namespaces and give it to the experienced image patrollers. This would require far fewer software changes and would have minimal impact on performance, if any.

   OR

3. Create an adminbot that deletes images tagged by approved patrollers. This would require no changes to MediaWiki at all.

--Mr.Z-man 19:19, 3 August 2008 (UTC)

4. Wait for the DeleteQueue extension, which will allow separate granting of the right to review image deletions. — Werdna • talk 23:13, 3 August 2008 (UTC)

Which may or may not end up existing, may or may not end up getting enabled, and even if it does will be who knows how far down the line. If it's a problem now, work out a solution now that will work for now. Don't just wait for months or years for a technical fix. A great record sweeping technical fixes have: several years for CentralAuth, and we're still waiting for a new image backend. DeleteQueue sounds great, and it will possibly obsolete any solution decided on now ― eventually. —Simetrical (talk • contribs) 16:07, 4 August 2008 (UTC)

So the change that easiest to implement is Change the CSD image criteria to allow for quicker deletion of obvious crap images. And the suggested criteria is something like this
 • (a) over 24 hours old;
 • (b) not linked to an article;
 • (c) does not appear in any way
to be intended to improve Wikipedia (does not appear to be an image that could be used in an article, nor something else useful, such as a screenshot for an instructional page). -- John Broughton (♫♫) 17:03, 4 August 2008 (UTC)

OIC, well, I can see having two is a waste... didn't think the community would be so practical, in truth. Soo...

Support most anything along these lines with two reservations... 1) Obvious crap images shouldn't be allowed to hang around more than an hour if they can be shot on site. 2) Mandantory requirement to tag uploaders page with notice. No exceptions.
Delete with permissions per or one of Mr.Z-man's 2 or 3' suggestions. (The Bot with approved list sounds really nice.) So either my two man rule... one tags {{speedy prank image}}, one agrees and closes a deletion... (The former involves non-admins, if they wish. Sorry to be solicitous of Admins time [I'm solicitous of EVERYONE's time, as Jimbo can attest! <g>], but don't you guys generally do enough thankless repetitive editing? I'd prefer you stay interested in articles edits, myself.)
Other than that, keep the 24 (or shorter) hour criteria as well so if an admin spots an aged one, it can be killed ASAP. One other alternative path: User check, if made an edit after uploading it... shoot on sight! [or give two hours or something]... if these are legitimate at all, they will be for a user page. If it can't be identified as content that might be user page material... BANG!

• Key Point, the longer such pages are allowed to remain... the more rewarding it is for a group of youngsters goofing off together to laugh about such. These days, phones are even accessing wikipedia... so need to cut cycle time on this as much as possible per "parenting 101" and general psych advice. (Note the NFL/MLB won't telecast misbehaving fans these days... same reason... encourages others.)
  Can always also tag the user page with If you're intentions were to use Image:ZKST*SL@#NSY in an encyclopediac article or user page, contact the below signed administrator after installing the image in a legitmate article or user page... something like that... which iirc, could be monobook.js extension tool made edit, I think to subst the warning/notice template. // FrankB 18:40, 4 August 2008 (UTC)

Animation help

Good day. I have a question: Why is the animation below not showing correctly in a gallery?

• 
  The animation

—Preceding unsigned comment added by Lykantrop (talk • contribs) 18:44, 3 August 2008 (UTC)

Seems to be fixed after puring the image pages here and at Commons (which causes the software to regenerate the thumbnail). Anomie⚔ 20:19, 3 August 2008 (UTC)

Thanks! It is fixed, but I do not understand how. What means "puring the image pages"?--  LYKANTROP  ✉ 08:53, 4 August 2008 (UTC)

That's a typo for "purging", as in WP:PURGE.-gadfium 09:17, 4 August 2008 (UTC)

Allright, got it, cool, thanks, have a nice day!--  LYKANTROP  ✉ 10:15, 4 August 2008 (UTC)

Wrong cite

In Advance-fee_fraud#The_victim_becomes_a_criminal. footnote No. 60 does not go to the proper citation. The message says it goes to No. 59, but it actually goes to the bottom of the page. Can somebody fix it? Sincerely, GeorgeLouis (talk) 21:29, 3 August 2008 (UTC)

Advance-fee fraud#cite note-59 works correctly for me. PrimeHunter (talk) 00:44, 4 August 2008 (UTC)

What browser are you using? --—— Gadget850 (Ed) ^talk - 01:33, 4 August 2008 (UTC)

I am using Safari 3.1.2. This is the link which shows up when I click on footnote No. 60: "http://en.wikipedia.org/wiki/Advance-fee_fraud#cite_note-59" Sincerely, GeorgeLouis (talk) 07:39, 4 August 2008 (UTC)

Are you complaining about the fact that the fragment in the link is "cite_note-59" rather than "cite_note-60", or are you complaining about the bug in Safari where Safari miscalculates the anchor positions of references in the second column? If it's the latter, discussion is currently underway at Template talk:reflist which will probably result in the removal of the Safari-specific instruction for displaying multiple columns until Apple fixes the bug. Anomie⚔ 11:36, 4 August 2008 (UTC)

How large is the wiki database

Just curious, how large (in bytes) is the wikipedia database? I searched but could not find an answer to this question. The only thing I could find was the amount of articles in English. Thanks. —Preceding unsigned comment added by 70.251.111.31 (talk) 03:16, 4 August 2008 (UTC)

Given the nature of Wikipedia, pinning an exact number of bytes would be an exercise in futility. The number would constantly fluctuate. -Jéské ^{(v^_^v Mrrph-mph!)} 06:16, 4 August 2008 (UTC)

Since there hasn't been a successful database dump in a long time, nobody can say for certain. At a rough estimate, I'd say 500 GB for the complete text history of the English Wikipedia; 4 TB for all editions of all projects. I think that images account for another 4 TB or so, but they aren't stored in the database. --Carnildo (talk) 09:14, 4 August 2008 (UTC)

Accidental save to a redirect's Talk page.

Hi! I just tried to save an edit to an existing section of Wikipedia talk:Notability (people). Instead it got saved to Wikipedia talk:Notability people (no ()s), creating it. Wikipedia:Notability people is a redirect to Wikipedia:Notability (people). I clicked the [edit] link for the section on (what I thought was/must have been?) [Wikipedia talk:Notability (people)]. In the history of the firefox3 tab, where I was editing, after a few "previews" that the target address switched from "... {people)" to just "... people" and stayed that way!? There were several RO locks while I was previewing.
(I blanked the new talk page, with edit summary.)
How could this have happened? Did I screw up? Thanks. Saintrain (talk) 18:41, 4 August 2008 (UTC)
P.s. Why does an edit preview need an unlocked database?

I redirected Wikipedia talk:Notability people to Wikipedia talk:Notability (people). I don't know why the database needs to be unlocked for a preview. -- Imperator3733 (talk) 20:44, 4 August 2008 (UTC)

I think the preview function saves your edit to a temporary database and then reads it back like a normal page (if this is true, it would make sense to me). I don't know if this is true though. — OranL (talk) 23:30, 4 August 2008 (UTC)

Nope, it just doesn't distinguish very well between transitory lag-based locking (in which case it's probably just fine to show an edit screen or a preview, just not to save it) and ongoing maintenance, which locks the whole editing process. It might be nice for us to improve that. :) --brion (talk) 23:54, 4 August 2008 (UTC)

Table/Sections problem

Hi. Can someone see what's happening in User:Mosca/Sandbox on Internet Explorer 7? (in other browsers works fine). Look at sections lines, in the first example they are above table. In the second example they are fine. If I remove the image in the first example or remove the following text:

''beak can be '''between''' yellow or green depending on the subspecies''

it works fine. "Example 3" uses {{Taxobox}} and have the same problem.

Note: this happens only in Internet Explorer 7 in window resolutions inferior to 1350px (width). You can see another example in pt:Coruja-buraqueira (Portuguese Wikipedia). Mosca (talk) 00:13, 4 August 2008 (UTC)

Looks fine using Mozilla Firefox 3.0. Can you help us out and tell us what the difference in the code is (if any)? − Twas Now ( talk • contribs • e-mail ) 05:52, 5 August 2008 (UTC)

As I said, that page its fine in others browsers. I tested on Firefox 3.0.1, Internet Explorer 6, Opera 9.51 on Windows XP x64; and Safari 3.1.2 and Firefox 3.0.1 on Mac OSX 10.5.4. In all of them works fine except on Internet Explorer 7 (note: in version 6 its fine). To see the problem you must see User:Mosca/Sandbox (test page) or pt:Coruja-buraqueira (real example) on Internet Explorer 7 in a Window with 1280x960px or less of resolution. This problem was reported on Portuguese Wikipedia. I thought It could be our local CSS, but it happens on english Wikipedia too, even with a simple table (see test page). Mosca (talk) 16:05, 5 August 2008 (UTC)

IE7 seems to have several bugs related to italic text and floats.[17] In this particular instance, it seems to be triggered by having italic text at the end of a line which is sandwiched between two floats. Anomie⚔ 17:09, 5 August 2008 (UTC)

I made an update to User:Mosca/Sandbox, adding Example 4 (good) same as Example 1 (bad) with italics but without [[Image:Burrowing_Owl_Florida.jpg|thumb|left|200px|Florida Burrowing Owl]]. Removing the image solves the problem too. Is there any workaround for this in MediaWiki:Common.js or MediaWiki:Common.css? It's not very important but should be corrected. Mosca (talk) 18:53, 5 August 2008 (UTC)

Images behind text

I was trying to create an simple gradient that I could use behind some text on my User page, but I can't figure out how to get the image to be displayed behind the text. It just moved the text down to the next line after the image. I looked through the Help space on Wikipedia and on Meta, but I wasn't able to find anything that talks about this issue. Does anyone know a way to make this work? — OranL (talk) 23:26, 4 August 2008 (UTC)

You can use CSS positioning, I suppose. Kinda dirty, but it should work.

O hai.

If you want more information, Google around for a bit with the term "CSS positioning." --MZMcBride (talk) 05:26, 5 August 2008 (UTC)

Aha! Thank you for the help! — OranL (talk) 17:56, 5 August 2008 (UTC)

P.S. After you told me how to do that, I found this page at Meta talking about how to do this very thing. Thanks for showing a good example though. It was very helpful! — OranL (talk) 20:13, 5 August 2008 (UTC)

Coodinate problem

Does anybody know why when you click on the coordinates in an article it returns "Fastcgi Protocol Error". An example is here, which may come up as a HTTP 500 error in IE. CambridgeBayWeather Have a gorilla 04:02, 5 August 2008 (UTC)

Posted too quickly. I found Template talk:Coord#Fastcgi error now in Coord display and Template talk:Infobox nrhp2#Latitude/longitude links aren't working and a qucik check of Coloma, California would seem to indicate that the coord template is the problem. CambridgeBayWeather Have a gorilla 04:18, 5 August 2008 (UTC)

After checking out various templates it appears that none of the coordinate templates (Category:Coordinates templates) other than the geolinks-country (Category:Geolinks templates work. CambridgeBayWeather Have a gorilla 04:52, 5 August 2008 (UTC)

Extensive discussion at Wikipedia talk:WikiProject Geographical coordinates#Fastcgi error, including the section immediately below that one. -- John Broughton (♫♫) 13:09, 5 August 2008 (UTC)

Inbuilt timeline

I was wondering, is it possible to somehow incorporate the magic word(s) for "current date" and the timeline? As you can see from Template:MedComChair, I haven't had any luck to date. Cheers, Daniel (talk) 08:40, 5 August 2008 (UTC)

Instead of using <timeline> ... </timeline>, use {{#tag:timeline| ... }}. That will allow magic words to work inside the timeline tag. --MZMcBride (talk) 20:08, 5 August 2008 (UTC)

<3. Thanks so much! Daniel (talk) 23:29, 5 August 2008 (UTC)

WP Logs

Are the web logs available that show the browsers that access Wikipedia? --—— Gadget850 (Ed) ^talk - 11:49, 4 August 2008 (UTC)

This information is stored, and can be accessed on a per-edit basis by checkusers (that is, they can see what browser was used to make an individual edit!), but it is not available publically due to privacy concerns. Do you, by any chance, want to see some compiled statistics to construct something like this for pageviews to en.wiki?? If so, consider me fully behind the idea... if not, consider it suggested :D Happy‑melon 12:46, 4 August 2008 (UTC)

That is exactly what I wanted. Looks like it pretty much matches market share.[18] Thanks. This is for the discussions at Template talk:Reflist --—— Gadget850 (Ed) ^talk - 13:10, 4 August 2008 (UTC)

The link is market share. It's not Wikipedia-specific. —Simetrical (talk • contribs) 16:10, 4 August 2008 (UTC)

Thanks- I misunderstood that. I need the Wikipedia browser usage. --—— Gadget850 (Ed) ^talk - 16:20, 4 August 2008 (UTC)

Wikipedia basically only keeps detailed information about edits, and that is only available to checkusers. If you're asking about details for page views, the answer is that the volume is so huge (Wikipedia - across all languages - ranks something like the 8th-most viewed domain) and there is no one using the details, so it's discard fairly quickly (somewhere between a day and a week), and isn't available without a subpoena, because of privacy concerns (as in, who is reading what?). (The Wikimedia Foundation has occasionally made sampling info available to researchers, I believe, but I'd guess that they removed any info - like the full IP address - that could have privacy implications.) -- John Broughton (♫♫) 16:56, 4 August 2008 (UTC)

That's not really true. There are Squid access logs that are kept, at least sampled ones, for some period. They aren't made publicly available in full, but some kinds of summaries are available. User:Midom would probably be the one to ask, since I think he's the one who keeps them. —Simetrical (talk • contribs) 18:36, 5 August 2008 (UTC)

See MediaZilla:15059! --- Best regards, Melancholie (talk) 16:45, 6 August 2008 (UTC)

I did find Wikipedia:Browsers, but that was last updated in 2004. --—— Gadget850 (Ed) ^talk - 21:05, 6 August 2008 (UTC)

"Search in history"

Am I going crazy, or is this new? Is it possible (through some javascript wizardry, or otherwise) to move it to the bottom of the page? It's kindof distracting. –xeno (talk) 01:49, 5 August 2008 (UTC)

Well, you might be crazy, but the feature is new. It was added on August 1 (see rev:38404). It currently doesn't have an ID, making hiding it using CSS difficult, but an ID was added in rev:38605, which, if not reverted, will be live in a few days or less. As for JS solutions, try WP:US/R? --MZMcBride (talk) 05:09, 5 August 2008 (UTC)

Page History format

Copied from Help Desk for further help, by Franamax Franamax (talk) 08:49, 5 August 2008 (UTC)
People would now recognise that ever since a couple of days ago there is now a search item at top of each page's history to filter the date and year just like user contributions. Is there anyway through scripts or anything at all that can change this, whether it be delete it or maybe move it to the bottom of the page? Is this at all possible? Thanks, sorry for my 'me knowing nothing' in regard to these sort of things. Monster Under Your Bed ^(talk) 08:01, 5 August 2008 (UTC)

Aggh, I can make it disappear (see User:Franamax/monobook.css) but it leaves a big blank spot. And I hadn't even noticed until I read this. Maybe better asked at the technical help desk? Franamax (talk) 08:45, 5 August 2008 (UTC)

You're looking for

#mw-history-search {display: none;}

Happy‑melon 09:31, 5 August 2008 (UTC)

Wheee! Thanks for the help. When I learned CSS, we cut the stylesheets out of cardboard. Also I only read the first three pages. Thanks. :) Franamax (talk) 09:53, 5 August 2008 (UTC)

Do we have someplace where these snippets are listed? --—— Gadget850 (Ed) ^talk - 12:44, 5 August 2008 (UTC)

• Sexy, thanks! –xeno (talk) 18:47, 5 August 2008 (UTC)

Thanks Franamax and thank you for the script Happy-melon! :) Monster Under Your Bed ^(talk) 07:35, 6 August 2008 (UTC)

All pages being "protected from being created"?

Hi. I am not sure if this is the best place to enquire, but: I keep being told that "the title X is protected from being created", seemingly regardless of what X might be. Help! Sardanaphalus (talk) 09:47, 5 August 2008 (UTC)
PS Creating categories seems to work.

I'm getting this when trying to move templates (which I know is one of your favourite pastimes). There definitely doesn't appear to be salting on the new titles. Specifically, {{infobox Dogbreed}} → {{Infobox Dog breed}} is refusing to work. Chris Cunningham (not at work) - talk 10:56, 5 August 2008 (UTC)

Working again. Chris Cunningham (not at work) - talk 11:07, 5 August 2008 (UTC)

• So it is. Thanks. Sardanaphalus (talk) 11:17, 5 August 2008 (UTC)

This could be the result of some recent MediaWiki:Titleblacklist tampering. --MZMcBride (talk) 20:09, 5 August 2008 (UTC)

For a while, the blacklist prohibited any pagemove to a title containing the letter "p". Might this have been what you were running into? --Carnildo (talk) 22:34, 6 August 2008 (UTC)

Re: history search

Hi! It's wonderful the way wikimediawiki just keeps improving all by itself. Magic!
Would it be possible to do a string search in (a subset of) the historical revs of an article? I have often run across an old vandalism but didn't know what the original text/intent was. Finding it required a search through the history. Tedious! That's what computators are for. If one could search (a la "grep -c vandalism") then it would be trivial to spot the first occurrence of the string thence the original text.
Such a search could be optioned to stop at the 1st non-occurrence, for just this case and to save load.
Thanks. Saintrain (talk) 19:58, 5 August 2008 (UTC)

http://wikipedia.ramselehof.de/wikiblame.php –xeno (talk) 20:00, 5 August 2008 (UTC)

WOOHOO!! WP* is the coolest. There has GOT to be a link to this on the History page! Better, a link to a WP/WM page with lists of History utilities. Thanks! Saintrain (talk) 23:59, 5 August 2008 (UTC)

I've added a link to MediaWiki:Histlegend. I'm not sure if it'll stick because it's an external link that doesn't point to the toolserver, but it is definitely a valuable tool. Happy‑melon 14:26, 6 August 2008 (UTC)

Great! Thanks! It's unfortunate that it's lost in the boilerplate, though. I'm glad to know it's there now, just yesterday I was looking too css that block away and got distracted! Saintrain (talk) 16:38, 6 August 2008 (UTC)

Add new magic word

{{PAGENAMENODISAMG}} or something similar. This would act like {{PAGENAME}} but would only return the page name to the last word before the first instance of a '(' i.e it would return Seán French from Seán French (1890-1937) or John Horgan from John Horgan (Cork politician) Gnevin (talk) 23:28, 5 August 2008 (UTC)

If you're linking to the page, the pipe trick is sufficient. Typing [[Foo (bar)|]] in edit mode will give [[Foo]]. Pegasus «C¦T» 02:48, 6 August 2008 (UTC)

The pipe trick doesnt work with {{PAGENAME}}Gnevin (talk) 07:20, 6 August 2008 (UTC)

Arguably, a more general pipetrick parser function would be the better solution. — Werdna • talk 12:03, 6 August 2008 (UTC)

Maybe so which is ever easier Gnevin (talk) 13:52, 6 August 2008 (UTC)

Page Errors

Why do wikipedia pages show a lump in IE8. It is quite fine in FF3.Do i have to install any plugin for ie8 to see them right ? My ff3 crashes when i browse wiki pages Unlike http://knol.google.com I aso Emulate IE8 to IE7...but no change :-(
;-) By 127.0.0.1 ( Report ) [ ^Evidence | _Block ] On :: 12:24, 6 August 2008 (UTC)

Not to answer the question directly, but I note that IE 8 is currently a beta (non-stable) version. -- John Broughton (♫♫) 14:23, 6 August 2008 (UTC)

Define "lump". I have been playing with IE8B1 and have not seen any new issues. --—— Gadget850 (Ed) ^talk - 21:03, 6 August 2008 (UTC)

OS

On Which Unix / Linux does WP work. (Distribution Name)
;-) By 127.0.0.1 ( Report ) [ ^Evidence | _Block ] On :: 12:43, 6 August 2008 (UTC)

Wikipedia is a website; it requires no plug-ins on installation or special software. Basically, if you can install a web browser like Firefox on a Unix/Linux system, then you can read and edit Wikipedia. (Your question is basically similar to asking about operating systems that Google works on. Google works when you have a working web browser. Wikipedia works when you have a working web browser.) -- John Broughton (♫♫) 14:27, 6 August 2008 (UTC)

If you're asking about the infrastructure of the servers that Wikipedia uses, Wikitech is a good place to start. The OS differences page answers your question. Ignore any certificate erros you get when visting the above HTTPS pages. Graham87 14:44, 6 August 2008 (UTC)

(ec)To be fair, the Wikipedia database is stored on, and the wikipedia website is hosted from, a set of servers that run Unix (IIRC). So there is merit to the question. Happy‑melon 14:49, 6 August 2008 (UTC)

See Wikipedia:FAQ/Technical#What software is used to run Wikipedia? which will lead you to Wikimedia servers. --—— Gadget850 (Ed) ^talk - 15:33, 6 August 2008 (UTC)

The servers used to serve Wikipedia and its sister sites run exclusively on Linux. Currently Ubuntu is favored, but there are lots of old Fedora Core machines, and apparently some SUSE variants too according to those links. Most of the toolserver servers run Solaris, though, and of course there are desktops in the office that run Windows, Mac, etc. —Simetrical (talk • contribs) 18:19, 6 August 2008 (UTC)

m:Wikimedia servers is incorrect, there are no servers running SUSE. Albert did a long time ago, but it was reinstalled with Fedora Core, before it was eventually decomissioned. Also, the FreeBSD test on isidore was removed long ago, replaced with Fedora Core and then Ubuntu. Everything at pmtpa is running either FC or Ubuntu. -- Tim Starling (talk) 01:28, 7 August 2008 (UTC)

A new page in my userspace about page history

See User:Graham87/Page history observations for, among other things, an demonstration that cut and paste page moves are very bad and can have permanent consequences. That page is also a good indication that I need to get a life. Graham87 14:50, 6 August 2008 (UTC)

I only skimmed the contents of your page, but is anything at your page not covered at Help:Moving a page that should be? − Twas Now ( talk • contribs • e-mail ) 20:56, 6 August 2008 (UTC)

The way I do page history merges of large pages wasn't covered anywhere. I've added a note about it at Help:Moving a page#Merging page histories of pages with many revisions and Wikipedia:How to fix cut-and-paste moves#Merging page histories of pages with many revisions. Graham87 01:08, 7 August 2008 (UTC)

Change DATE from monthname year to year-month

I've raised a question about changing the {{DATE}} from the format monthname year to year-month so it addhere's to the only accepted international standard ISO 8601 and the de facto standard used in (nearly) all template date parameters here at en-wiki. Today the {{DATE}} is extensively used by {{fact}} for filling out the date= parameter. Should {{DATE}} be changed to {{DATE2}} or should {{fact}} use the ISO 8601 compliant {{DATE2}} directly? Nsaa (talk) 07:03, 5 August 2008 (UTC)

I'm a proponent of using the ISO-8601 date format. It makes dates so much easier to compare. However changing the {{DATE}} template is too risky. Instead making {{fact}} refer to {{DATE2}} would definitely be an improvement. −Woodstone (talk) 07:40, 5 August 2008 (UTC)

I've raised a question about changing the fact, s it uses DATE2 here Template_talk:Fact#Use_DATE2. Probably some bots needs to be updated(?) Nsaa (talk) 07:53, 5 August 2008 (UTC)

I've made a request here to see if I can figure out which bots are affected. once that information comes, I'm happy to make the change - doesn't look too difficult on the face of it. --Ludwigs2 03:44, 7 August 2008 (UTC)

I don't see why we need to change to suit someone else's standards; however, if this proposal is carried out, please make sure that all the date-based categories are renamed accordingly (for example, Category:Wikipedia articles needing style editing from August 2008). --Russ (talk) 10:54, 7 August 2008 (UTC)

It's not proposed to suit someone else's standards. As far as I have seen the ISO format is used for (most of the) date parameters in templates here at en-wiki and is a de facto(?) standard on the project. Nsaa (talk) 15:32, 7 August 2008 (UTC)

The bot User:SmackBot#Current_tasks uses it and all the templates listed under #4: {{wikify}}, {{orphan}}, {{uncategorized}}, {{uncatstub}}, {{cleanup}}, {{unreferenced}}, {{importance}}, {{expand}}, {{merge}}, {{copyedit}}, {{fact}}, and {{not verified}}) and as Russ points out the category must be renamed (Category:Wikipedia maintenance categories sorted by month) Nsaa (talk) 15:39, 7 August 2008 (UTC)

Template problem (switch always forces new line?)

Can someone fix this? Look at User:Wknight94/KCChiefsColorStyle. No matter what I do with the transcluded template, User:Wknight94/TeamColor, I always get a new line in between the "color:" and the color code. It's as though the {{#switch: statement always returns with a new line at the beginning. What gives?! Known issue? —Wknight94 (talk) 20:16, 6 August 2008 (UTC)

The problem isn't the switch, it's that the # character is being interpreted as a ordered list. One option is to have the template output something like color: #xxxxxx instead of just #xxxxxx. — Carl (CBM · talk) 20:45, 6 August 2008 (UTC)

That's what it was doing. But, in another case, a template took only the color as a parameter. But I can't get the carriage return out of there. style="color: white" doesn't work if there is a carriage return between color: and white. —Wknight94 (talk) 21:02, 6 August 2008 (UTC)

Use a format like this, [19] , change "white" to "ffffff", and remove all the # symbols from colors inside the switch. — Carl (CBM · talk) 21:16, 6 August 2008 (UTC)

I see what you're saying but I actually have a second problem. I need the first template to return "color: white" and then the second template to return just "white". In some cases I need the first, in others I only need the second. Rather than duplicate every team in both, I was going to have the first template return "color:" plus the results of the second template. I modified my example a bit to more closely fit my original problem. See the new User:Wknight94/TeamColorStyle intermediate template. Some places may want to use User:Wknight94/TeamColorStyle but some - like {{Tnavbar-header}} - may need only the color component, "white", not the full "color: white" string. —Wknight94 (talk) 21:27, 6 August 2008 (UTC)

How do you feel about the solution at User:CBM/Sandbox2, tested in User:CBM/Sandbox? — Carl (CBM · talk) 21:39, 6 August 2008 (UTC)

Okay, maybe I'm brain dead. Explain again why yours is working and mine isn't?! The switch is actually evaluating the # in the results of each case of the switch statement?! That seems bizarre. Why isn't it just macro-substituting it the way I want it to? —Wknight94 (talk) 22:14, 6 August 2008 (UTC)

Oh yeah, look at this. It works. Wow, that's annoying. But thanks for the help!  :) —Wknight94 (talk) 22:17, 6 August 2008 (UTC)

Definitely a known issue. I recommend reading the advice at Wikipedia:Village pump (technical)/Archive 43#Line break before #switch. — CharlotteWebb 15:45, 7 August 2008 (UTC)

subst with MagicWords

Hi! Is there a way to get the functionality of {{subst:PAGESINCATEGORY:cat}} ? Thanks. Saintrain (talk) 05:14, 7 August 2008 (UTC)

That's already possible. For example, {{subst:PAGESINCATEGORY:Contents}} produces 16. Is that what you mean? --- RockMFR 05:42, 7 August 2008 (UTC)

So it is. Must have tyoped. Thanks. Saintrain (talk) 20:03, 7 August 2008 (UTC)

Odd blue link

Anyone know why this deleted image has a bluelink ? - Peripitus (Talk) 07:32, 7 August 2008 (UTC)

It's on Wikimedia Commons. --NE2 07:33, 7 August 2008 (UTC)

I feel silly now - that was obvious - Peripitus (Talk) 07:56, 7 August 2008 (UTC)

After-move advice is incorrect

As I understand it, now that bugzilla:4578, "Page moves should not create double redirects", has been implemented, per Wikipedia:Wikipedia Signpost/2008-07-28/Technology report#New features and this posting at Wikitech-L, double redirects are largely a thing of the past should be significantly fewer. (It's possible to tell the software to let a double redirect be created, by unchecking a box before doing a move, but it seems fairly obvious that few editors will do that.)

But the "Move succeeded" page still says Please check whether this move has created any double redirects, and fix the most serious ones. ... A bot will fix the rest within a few days. That seems incorrect. -- John Broughton (♫♫) 14:19, 7 August 2008 (UTC)

For reference, it's at MediaWiki:Movepage-moved. PeterSymonds responded to an {{editprotected}} with a wait-and-see, but that was a while ago now. Algebraist 14:23, 7 August 2008 (UTC)

Thanks. I see that Peter posted on the 28th of July, saying to wait "a week or so". (And I've corrected my first posting here; as can be seen at Special:DoubleRedirects, double redirects are not yet a thing of the past. But I did check a few on the list, and none seemed to have been created by a move; I also tested the MediaWiki software by moving a user page a couple of times, and it performed as expected.) -- John Broughton (♫♫) 17:37, 7 August 2008 (UTC)

Special:Search repeated link in boilerplate

I hereby inform you that search results like

Wikipedia does not have an article with this exact name. Please search for Carmel apple in Wikipedia to check for alternative titles or spellings.

 • Start the Carmel apple article or add a request for it.
 • Search for "Carmel apple" in existing articles.
 • Look for pages within Wikipedia that link to this title.

Contain a repeated link: of the four links, the first and third are the same. Please compact this template to not mention the same action twice. Jidanni (talk) 17:09, 7 August 2008 (UTC)

The text is from MediaWiki:Noarticletext, not from a template. And you already posted about this at MediaWiki talk:Noarticletext#repeated links, in September 2007, and were not able to get any support for a change. -- John Broughton (♫♫) 17:51, 7 August 2008 (UTC)

"Placename dropping" in captions without saying where the place is

Know what bugs me the most? People who put teasers like

[[Image:Water Flash.JPG|thumb|right|Water reflecting light in [[Crissy Field]]]]

in an article, causing people to have to click to find out where in the world "Crissy Field" is.

There ought to be a law/policy/encouragement saying that no fair "place name dropping" like that without also mentioning more of an anchoring location, e.g., Crissy Field, England, etc. Jidanni (talk) 01:47, 8 August 2008 (UTC)

I don't think that this is the right forum for that kind of proposal; in fact, the best place would probably be the appropriate MOS page at WP:MOS. Gary King (talk) 01:52, 8 August 2008 (UTC)

Deadlocking Things being generally slow and interrupted lately

Is it just me or has the database been locking awfully frequently the past week or so? Is there some reason behind this? In other news, I'll buy a pony for anyone who can simplify the code in {{Anarchism sidebar}} without altering its visible output. Skomorokh 03:57, 29 July 2008 (UTC)

Locking or deadlocking? They're two different things. -- Tim Starling (talk) 05:25, 29 July 2008 (UTC)

"Locked until the slave servers catch up to the master" (or words to that effect) is a lock message I have seen somewhat frequently in the past week or so. I think that is maybe what he is referring to. --_{tiny plastic} Grey Knight ⊖ 17:03, 29 July 2008 (UTC)

Apologies for the technical language from a non-tech. I' getting an awful lot of "Database locked", "changes from last X seconds may not show up on your watchlist", "Wikipedia has a problem" and "Wikipedia error" messages in the last two weeks. I assume this is a problem with the Wikipedia side of things rather that with mine. Is there a reason for this, I am wondering? Is this impression shared by others?Skomorokh 10:18, 31 July 2008 (UTC)

I have noticed this occuring more frequently than usual recently. --.:Alex:. 12:40, 4 August 2008 (UTC)

Me too! Deamon138 (talk) 21:32, 4 August 2008 (UTC)

I think everyone has noticed this. If I were to guess, it's that money isn't flowing as freely as it was before. ~ JohnnyMrNinja 04:38, 9 August 2008 (UTC)

How can I see only the pages that directly "links here"

I am working at a meta template. For example Template:ombox. After editing it, I want to see how it affects the pages that contain it. So I push the "What links here" link. Then I get a list with a few thousands pages. Now, it's quite unlikely I will have the time to check all of those pages to see if my modifications are ok. So I need to see a list of templates that directly use "ombox", not all pages that use it indirectly. Is there any way for getting that list? Ark25 (talk) 10:45, 8 August 2008 (UTC)

No, not without checking the page text. There's no difference between transcluding a template directly or by transcluding another template that in turn transcludes the same template. --Erwin85 (talk) 10:57, 8 August 2008 (UTC)

Ooops! there is the option to select "namespace". It's ok now, sorry. Ark25 (talk) 11:15, 8 August 2008 (UTC)

Just to make it clear for other readers of this section: Right, when on the "What links here" page, select the "Namespace: Template" and click "Go", that shows only the templates that use the meta-template, thus you don't see all the articles that use it. That also gives you any redirects to the template and any template /doc pages that link to the template, but that is usually just a handful and can be pretty interesting to see.

--David Göthberg (talk) 11:52, 8 August 2008 (UTC)

Random number

Is there a parserfunction or some variable that can return a random number? I'm trying to implement a template that returns one of several messages and intend getting the random number mod x, where there are x messages, to decide which one to use. Stifle (talk) 13:23, 8 August 2008 (UTC)

We had this discussion recently: Wikipedia:Village pump (technical)/Archive 43#Random number generation. {{rand}} amd User:Misza13/Random are both available. Portal:Middle-earth/Random-article uses a similar approach. Algebraist 13:30, 8 August 2008 (UTC)

Connection problems to normal site (secure site OK)

Hi all - having problems connecting to the main site (en.wikipedia.org). Connection times out / Page Load error.

Tracert to en.wikipedia.org is fine (200.80.152.2), and it pings back OK. I can access and login through the secure site, but it's quite slow, and the images are broken (referencing the normal site I assume). Trying to access any of the other language sites also times-out. Connecting through a computer on a different network (ie: iPhone) works fine.

Just trying to track this one down to see if it's a problem with my ISP doing some sneaky-yet-broken "transparent" caching, or if it's related something else (?). ISP is Telus.net in Canada. IP is 64.180.100.xxx

Any thoughts? —Preceding unsigned comment added by Nogami (talk • contribs) 21:08, 8 August 2008 (UTC)

Proposal: Move main page to a different namespace

I would like to propose that we move the Main Page to Wikipedia:Main Page. This would offer a number of benefits, including:

• Causing the top-left tab to read "project page" instead of "article"
• Making it easier to make a mass-copy of Wikipedia's articles without picking up project-specific pages like the main page

There would of course be a redirect from Main Page to Wikipedia:Main Page, and we could even hide the "redirected from Main Page" notice using CSS, making the transition virtually seamless. The German Wikipedia has actually their main page to the Wikipedia namespace and it is working great for them. —Remember the dot ^(talk) 05:11, 17 July 2008 (UTC)

I find illogical that the Main Page be in the article namespace, too, but wouldn't this proposal belong to Talk:Main Page? --A r m y 1 9 8 7 ! !  09:46, 17 July 2008 (UTC)

It's been proposed a few times, never seems to go anywhere. Doesn't bother me much, but whatever, I could go either way. -- Ned Scott 02:13, 18 July 2008 (UTC)

This would probably have a lot of opposition and discussion before it went anymore. I don't think it's such a big deal and it doesn't need to be changed. Gary King (talk) 07:49, 18 July 2008 (UTC)

I disagree with this. The main page is actually part of the encyclopedia, even though it contains a lot about the workings of wikipedia as well. --Apoc2400 (talk) 19:29, 18 July 2008 (UTC)

It will still be part of Wikipedia, just in a different namespace so that the software doesn't think it's an article. —Remember the dot ^(talk) 19:51, 18 July 2008 (UTC)

• Oppose. I think this is more trouble than it's worth. I don't count either of those arguments as particularly convincing- knocking up some coding to change the tab to read something different (I'm fairly sure it used to read something else anyway) shouldn't be too difficult for someone who regularly plays with that sort of thing. As for the other issue- if someone is going to the trouble of copying our millions of pages, I don't think it would be too much trouble for them to filter out those that they don't want. In any case, that's hardly our concern. As for an argument for keeping it as it is- don't try to fix what isn't broken. J Milburn (talk) 20:13, 18 July 2008 (UTC)
  • We tried coding things specially around the main page, and the developers rejected it. See [20] and bugzilla:14267, which was closed as WONTFIX because any way we do it it just comes down to being a hack. Moving the main page to the Wikipedia namespace, on the other hand, is a much more elegant solution that shouldn't upset the developers. —Remember the dot ^(talk) 20:49, 18 July 2008 (UTC)
• Support change to support for "Portal"; see below. I don't know how hard it is or whether it's really worth it; that's something that would need to be evaluated. But I do think it's clearly the right thing to do, if costs are not considered. Titles in article space are supposed to be about the concept (or at least a concept) standardly referenced by their names. Outside of a specifically WP context, no one considers Main Page to refer to the topics treated on the main page. So having it by that name in article space is incorrect. --Trovatore (talk) 20:20, 18 July 2008 (UTC)

What name space is say WP:NOPV in?Geni 20:23, 18 July 2008 (UTC)

Wikipedia space. --Trovatore (talk) 20:24, 18 July 2008 (UTC)

Hmm missed that change. http://en.wikipedia.org/w/index.php?title=Special%3AAllPages&from=CAT&namespace=0 this lot then].Geni 20:31, 18 July 2008 (UTC)

• Is this important? Both of the advantages cited above are (in my mind, anyway) pretty trivial (regarding the second, since the Main Page is, to my knowledge, the only "non-article" page in mainspace, I have no idea what else would incorrectly be caught by a "mass-copy", and in any case this proposal won't fix those other pages). So, yes, I'll concede that the Main Page belongs, in a theoretical sense, in projectspace, but is this really worth all the time and energy it will take - assuming it will be successful - to make the change? Perhaps we could work, instead, on something else - say, the hundreds of thousands of stub articles, or all of the maintenance backlogs? -- John Broughton (♫♫) 21:27, 18 July 2008 (UTC)
  • It will actually take very little time and energy to make the change - moving the main page can be done by any administrator, and Main Page will be made into a redirect to Wikipedia:Main Page. To ease the transition, a simple CSS declaration will keep the "redirected from Main Page" notice from appearing. And since the change is so subtle, I suspect that most people won't even notice. —Remember the dot ^(talk) 21:40, 18 July 2008 (UTC)
    • They will also have to change Mediawiki:Mainpage. Algebraist 22:07, 18 July 2008 (UTC)
      • Yes, I know. I probably should have been more explicit about this in my last comment, but still, it's not hard. —Remember the dot ^(talk) 22:08, 18 July 2008 (UTC)
        • Then there are the subpages, the backup pages, the redirects... Then there will need to be the technical updates (changing what en.wikipedia.org takes you to) updating the various links (such as in the sidebar) and probably other things- I'm really not a techy. Please don't pretend that this is a simple two minute job. Also, it's ironic that you advocate "a simple CSS declaration" after arguing against my advice to use such a thing to change the tab claiming that it is "a hack". J Milburn (talk) 09:33, 19 July 2008 (UTC)
          • CSS is much, much different than JavaScript. If someone doesn't have JavaScript, then the change won't work at all. If someone doesn't have CSS, they'll just see the "redirected from..." notice and be slightly more motivated to update their links to the main page. —Remember the dot ^(talk) 23:35, 19 July 2008 (UTC)

• Not broken, no point in fixing though if you really want the work of updating ALL of the main page templates, copies, and every page that links to it on all wikimedia projects, and do so seamlessly, I don't see the harm in it either Modest Genius ^talk 22:17, 18 July 2008 (UTC)
  • Yes, there will be a redirect Main Page → Wikipedia:Main Page, the "redirected from" text will be hidden, no links will break, and I will help update the links anyway. —Remember the dot ^(talk) 22:44, 18 July 2008 (UTC)

• Oppose I think things are fine, no real reason to do all of that. Chillum 22:49, 18 July 2008 (UTC)
  • Really, it's not as much effort as you think. Moving the main page is a straightforward process, and in fact has already been done on the German Wikipedia. —Remember the dot ^(talk) 22:57, 18 July 2008 (UTC)
    • It is not broken, no need to fix it. I don't think "Article" space is all that inaccurate, it is like the front page. It's content is article content, it is the result of a project. It is part of our encyclopedic content, not some area for meta discussions or other page only tangentially related to our encyclopedic content. Chillum 23:02, 18 July 2008 (UTC)
• Question: Shouldn't this discussion, which seems to be the 50th or so time this proposal has been debated, be on WP:VPR instead? Why is on WP:VPT? If this proposal has been discussed on-and-off every month for the past few months, it is more than just a mere technical issue you know. Zzyzx11 (Talk) 02:31, 19 July 2008 (UTC)
  • I really think it boils down to a technical issue, but all the same I've left at note at Wikipedia:Village pump (proposals)#Move main page to Wikipedia namespace. —Remember the dot ^(talk) 04:05, 19 July 2008 (UTC)
    • Has anyone put this on Wikipedia:Requested moves? I didn't see it. ~ JohnnyMrNinja 06:28, 19 July 2008 (UTC)
      • I've left a note at Wikipedia:Requested moves#19 July 2008. —Remember the dot ^(talk) 06:38, 19 July 2008 (UTC)
  • Sorry, I had copied the discussion to Talk:Main Page, but forgot to announce that here. --A r m y 1 9 8 7 ! !  08:34, 19 July 2008 (UTC)
• Support This does make a lot more sense and the it ain't broke so don't fix it argument is a bit silly, I mean, we could have Wikipedia's user skin looking like absolute crap, usable, but horribly ugly, so ugly that no one would use Wikipedia. It wouldn't be broken, but we'd still want to fix it. —Atyndall ^{[citation needed]} 04:07, 19 July 2008 (UTC)

  That argument is fallacious. The "ain't broke, so doesn't need fixin'" argument is an argument that there is no problem or that the "fix" does not provide a benefit, not an argument that a problem doesn't need improvement. {{Nihiltres|talk|log}} 23:28, 19 July 2008 (UTC)

• Support The Main Page doesn't really belong in the article space. It would also make a bit more sense for new people to see the first page they go to be titled "Wikipedia:Main Page" (which looks like "Wikipedia Main Page), even if they don't understand the role of the colon. There wouldn't really be any problems with implementing this, since as others have said there would be a redirect from Main Page to Wikipedia:Main Page and the text saying it's a redirect would be hidden. All links would still work and the Main Page would fit better in the Wikipedia namespace. -- Imperator3733 (talk) 05:21, 19 July 2008 (UTC)
  • In fact, we could even use a specialized version of Template:Wrongtitle to hide the "Wikipedia:" and make the page title still appear as "Main Page" to casual users. —Remember the dot ^(talk) 06:24, 19 July 2008 (UTC)
    • BTW, why on Earth is the 'P' in 'page' capital??? --A r m y 1 9 8 7 ! !  08:34, 19 July 2008 (UTC)
  • Note I change my support to Portal:Wikipedia (see below) -- Imperator3733 (talk) 16:47, 21 July 2008 (UTC)
• Support - Since when has Wikipedia been about it ain't broke so don't fix it? Wikipedia is all about slow improvement, through minor fixes, cleanup, and reformatting. Ideally, Wikipedia should always be considered "broke", and we should always be fixing it. This is a logical move, and most people won't even need the redirect as simply going to en.wikipedia.org lands you on the main page. ~ JohnnyMrNinja 05:22, 19 July 2008 (UTC)

de:Hauptseite - See the redirect in action. Neat! ~ JohnnyMrNinja 05:27, 19 July 2008 (UTC)

Support Portal:Wikipedia even more, as it is even logicaler. Also a great way to introduce readers to the idea of portals. ~ JohnnyMrNinja 17:48, 23 July 2008 (UTC)

• Comment - Didn't the upper-left tab used to read "Main page" at one point? I'm sure, because I remember thinking how intriguing it is to see that different from every other page. Don't know why they changed it though. I really don't know what to think, I too could go either way on this one. --.:Alex:. 08:35, 19 July 2008 (UTC)
• A simile: The Wikipedia space is made for editors. Placing the main page into the Wikipedia space forces casual readers into the background of Wikipedia, where they do not want to be. It's like placing the reception desk at a sports club in the manager's office- instead, it should be right in front of the door in an accessible place, pointing people to the facilities they want. Visitors should have to go into the manager's office only if they want to make a complaint or have some business of some sort with the club. Someone who has come along to use the facilities has no business with the manager and has no desire to be in his or her office. J Milburn (talk) 09:40, 19 July 2008 (UTC)
  • The article space is made for articles. Placing something that is clearly not an article in the article space is counterintuitive. —Remember the dot ^(talk) 19:15, 19 July 2008 (UTC)
• Oppose, there's not much point in this. The redirect will not be hidden for browsers and other pieces of software that don't support CSS, like mobile devices, old screen readers and text browsers. Also, as far as page history is concerned, the title Wikipedia:Main Page is problematic: it was the original title of the Community Portal, but now that is very difficult to figure out because of a page move to a very bad title which can only be undone by developers. I have filed bug 13729 to get the revisions where the page was moved to the Community Portal undeleted. If the move goes ahead, the page move revisions mentioned in bug 13729 should be undeleted and moved to the right place, and Wikipedia:Main Page and its talk page should be moved to a subpage of Wikipedia:Historical archive, so it becomes marginally easier to follow talk page conversations like this one by just following old links, logs and history. This may seem trivial, but there is no point in losing page history just because of a namespace conflict that wasn't even thought of four years ago. Graham87 16:23, 19 July 2008 (UTC)
  • The links will get updated to counter the effects of the page move on screen readers (I'll help with this). And remember that when visiting the site from http://en.wikipedia.org/ users are automatically taken directly to the main page. —Remember the dot ^(talk) 18:56, 19 July 2008 (UTC)
  • As for the deleted page history, I agree that it should be moved to a subpage of Wikipedia:Historical archive. —Remember the dot ^(talk) 19:01, 19 July 2008 (UTC)
• Oppose - We're going to turn tens (hundreds?) of thousands of direct links into links to a redirect so we can have different text in the little tab (which we can change, and I believe did change in the past, using JavaScript) and to provide a minor convenience to people who download all the articles but don't want the main page (I don't think its been confirmed that most people who do this don't want the main page either)? I really don't see the point. Mr.Z-man 18:47, 19 July 2008 (UTC)
  • The JavaScript hack was even worse of a hack than the hack the developers rejected. The redirect will be transparent like the German Wikipedia has, and links will be migrated over. And Answers.com, for one, does not want our main page. —Remember the dot ^(talk) 18:56, 19 July 2008 (UTC)
    • As far as I can tell, the JS hack was replaced by a change to MediaWiki:Nstab-main, but when this was reverted for performance reasons, the JS hack wasn't put back in. So there was never even a discussion about leaving the tab as "article" AFACT. The JS hack was just a few lines of code, I can't imagine it was causing any issues. The bug was WONTFIX'd because it was deemed unnecessary (by 2 developers) to add such a feature to the core MediaWiki code just for a couple projects like ours, not because it was a horrible hack. As for migrating the links, how is this planned to be done? Mr.Z-man 21:00, 19 July 2008 (UTC)
      • Please reread the last two comments to bug 14267:

Comment #12 From Simetrical 2008-07-02 01:02:18 UTC

Reusing [[MediaWiki:Mainpage-description]] is definitely the wrong way to go
about this.  Reusing messages is usually a bad idea.  It's perfectly plausible
to want something different in the nstab and the sidebar, e.g., "Back to Main
Page" might be appropriate for the sidebar but not the nstab.  Also, if the
main page is in a namespace whose nstab description is appropriate, say
"project page" or just "page", there's no reason to change it, so any change
should be strictly optional.

Do keep in mind that with the default messages, there's no problem at all.  The
default nstab for namespace 0 is "page", which is totally appropriate for the
main page.  If enwiki wants to create problems for themselves by changing what
namespace 0 is supposed to contain and then refusing to actually stick to their
decision by leaving the main page there, that's not something we need to
consider supporting in software, IMO.  If they think the extra X lines of
JavaScript are superior to adjusting their other customizations, that's their
decision as site admins.  Lots of people do stupid stuff with the software --
we don't have to support it just because it happens to be a big wiki.  In the
software as shipped, this is a non-issue.

Suggest WONTFIX.

Comment #13 From ^demon 2008-07-02 01:11:56 UTC

(In reply to comment #12)
> ...If enwiki wants to create problems for themselves by changing what
> namespace 0 is supposed to contain and then refusing to actually stick to their
> decision by leaving the main page there, that's not something we need to
> consider supporting in software, IMO...

I agree with you fully here. Like I said, this comes down to being a hack.

> Suggest WONTFIX.
>

You've convinced me. Marking as such.

As you can see, the developers clearly viewed adding special behavior for the main page as a hack and furthermore called the JavaScript hack "stupid". JavaScript is not a good solution here because it won't work for screen readers, text-only browsers, and search engines, and it also adds a very large about of overhead compared to changes in page content or changes in MediaWiki.

Anyway, I can help clean up the links using AWB, and if that proves too overwhelming then I can write up a script or a bot to do the job for me. —Remember the dot ^(talk) 23:23, 19 July 2008 (UTC)

So a couple people dislike the Javascript hack, instead of not caring, we're going to move the page, then run a script to make thousands of edits to update all the incoming links. I would hardly call a handful of lines of Javascript (which is cached anyway) a large amount of overhead. I'll ask again what I asked before: Have there been any complaints or comments from readers, such as on Talk:Main Page about the tab? I haven't seen any. This seems like a bit of an imaginary problem. As far as people downloading all of Wikipedia and not wanting the main page, how many are there? I just don't think this is worth the trouble. The benefits are minimal to non-existent, and one of the benefits doesn't even benefit Wikipedia directly. Mr.Z-man 23:40, 19 July 2008 (UTC)

But that's just the thing: you won't have to go through any trouble. Main Page will continue to work as before, and I will be working to transition the links over to Wikipedia:Main Page anyway. You just have to sit back and relax.

Another benefit is that moving the page to the Wikipedia namespace would also allow us to create an article at the location Main Page should the need ever arise. It's not a problem right now, but it could become one in the future. —Remember the dot ^(talk) 23:50, 19 July 2008 (UTC)

• Oppose, the main page belongs in the mainspace along with the rest of the reader-facing encyclopedia pages. Project space is for pages that are related to the internal workings of the project. Christopher Parham (talk) 18:59, 19 July 2008 (UTC)
  • It's a technical issue; readers aren't even going to notice... —Remember the dot ^(talk) 19:01, 19 July 2008 (UTC)
    • zee yellow background is pretty noticable.Geni 00:01, 20 July 2008 (UTC)
      • What do you mean? —Remember the dot ^(talk) 06:34, 20 July 2008 (UTC)
        • I believe there are certain configurations to allow the background of project pages to appear a different colour. --.:Alex:. 18:56, 3 August 2008 (UTC)
• Oppose, basically agree with Z-man. And Remember the dot, as much as you insist that this is just a "technical issue," it's a much-debated and very contentious topic here, and I doubt you'll get consensus to make it happen. -Elmer Clark (talk) 20:19, 19 July 2008 (UTC)
  • Why is it so contentious? Nothing's going to break, nothing's going to be deleted, and we would pick up a couple of improvements. —Remember the dot ^(talk) 23:23, 19 July 2008 (UTC)
• Oppose. (now Neutral on Portal:Wikipedia.)Now support Portal:Wikipedia following the implementation of Bug 15007. Even if we were to move it, it's not a "project" page (i.e., one that deals with the administration of Wikipedia), it's a portal page.--Father Goose (talk) 22:01, 19 July 2008 (UTC)
  • It's easier to move it to the Wikipedia namespace than to the Portal namespace because it enables us to be more consistent with other Wikimedia projects that do not have a Portal namespace. The German Wikipedia, for example, has their main page in the Wikipedia namespace, and it would be good for consistency if we did the same. —Remember the dot ^(talk) 23:23, 19 July 2008 (UTC)
    • If consistency were our goal, we'd be pressuring de.wiki to move their main page back to mainspace, which is where most Wikimedia projects keep it.--Father Goose (talk) 07:37, 20 July 2008 (UTC)
• Comment - without reading earlier post, I can assure you this has been brought up several times, and either rejected or closed as no consensus on each occasion. With all due respect, RTD, this is almost certainly the wrong venue; wouldn't this be better as a(nother) requested move or at VPP? The Evil Spartan (talk) 23:46, 19 July 2008 (UTC)
• Oppose, headache-causing solution looking for a problem. Titoxd^{(?!? - cool stuff)} 01:59, 20 July 2008 (UTC)
• Oppose — Not only would this proposal cause a number of technical headaches if implemented (omitted here for succinctness), but it also has questionable benefits: "project page" is not much better than "article" (indeed, I prefer "article" as it introduces the interface nicely for readers) and excluding the Main Page from an article dump is a trivial task. Further, it seems to me to be semantically less correct as well: as Father Goose mentions, Wikipedia-namespace pages are, semantically, for the administration of Wikipedia rather than for Wikipedia's content: the Main Page is much more of a content page regardless of its special status as pseudo-content. Personally I think the ideal would be to make the Main Page a Special-namespace page through an extension of some sort (while still using the name "Main Page"), but that's beyond the scope of this discussion. {{Nihiltres|talk|log}} 03:14, 20 July 2008 (UTC)
• Oppose even if it was moved to the project space the title "Main Page" would always have to be a permanent redirect to the new main page just due to that fact that there are millions of on wiki and off wiki links to it and since the title of the page is not viewable except in the url it would really not change a thing. In short its useless work for the devs. - Icewedge (talk) 03:17, 20 July 2008 (UTC)
• Support [edit: I support SamuelWantman's alternate proposal, below, instead] - There is nothing encyclopedic about the "Main" page. It is merely there to highlight the accomplishments of the project that is Wikipedia as a whole. If someone were to create a "Most interesting articles about topic X" page, it would quickly get moved from the article namespace. SharkD (talk) 03:24, 20 July 2008 (UTC)
  • I've changed my support to the Portal:Wikipedia proposal, below. SharkD (talk) 05:59, 20 July 2008 (UTC)
    • "Not encyclopedic"? Have you even looked at the page? Just because it does not have citations does not mean it is not encyclopedic. I see loads of encyclopedic information that changes every day. It is, if anything and as was mentioned above, a psuedo-article. In fact, it's almost a preface to articles. --.:Alex:. 19:12, 3 August 2008 (UTC)
      • A pseudo-article? No, it's nothing at all like an article. It's exactly like a portal, because that's what it is. —David Levy 19:26, 3 August 2008 (UTC)
• Comment Wouldn't this make the title say 'Wikipedia:Main Page' rather than 'Main Page'? Isn't that, you know, much uglier than 'Main Page'? — Werdna • talk 08:04, 20 July 2008 (UTC)

Arbitrary break to the first mention of Portal:Wikipedia

• Oppose Wikipedia:Main Page, might support Portal:Wikipedia I don't think it is a administrative page, so it does not belong in Wikipedia space. It is the portal to all of Wikipedia, so why not call it that? -- ☑ SamuelWantman 05:43, 20 July 2008 (UTC)
  • You're idea is intriguing, and I think it would be beneficial to, in addition, garner more attention toward portals, as a whole. I think if Wikipedia were refactored to project a more of a "Portal" atmosphere (e.g., wherein visitors' first destination when entering Wikipedia is a portal of some sort), it might be better. SharkD (talk) 06:03, 20 July 2008 (UTC)
    • Considering how much support the idea is getting, I have gone on record as supporting my suggestion! -- ☑ SamuelWantman 08:38, 27 July 2008 (UTC)
• Support, but I expect we won't do this until the day we need to have an article about a novel called Main Page. I encourage every novelist out there to write one to force us to do this move. Kusma (talk) 09:09, 20 July 2008 (UTC)

  To make it clear, I support moving out of article space, and don't really care whether the main page ends up in Wikipedia space or in portal space. Kusma (talk) 06:09, 24 July 2008 (UTC)

• Support It's not an article. Taking it out of article space is long overdue. The "it's not broken" parochialists need to think about those who use our data dumps. — Hex (❝?!❞) 10:03, 21 July 2008 (UTC)
• Support The Main Page being in article-space is causing problems; there are more places where the Main Page has to be special-cased than you might think. (For instance: the 'cite this article' link in the sidebar, edit counts, the number of articles has to have 1 subtracted from it to allow for the main page, the namespace tab says 'article' by default unless fixed with JS (and the devs refused to fix it on the server because it would cause too much load), bots will treat the Main Page as if it were an article unless special-cased, and so on. Besides, think about which deletion process would be used to delete the Main Page: surely, it should be MfD, not AfD!) This isn't a difficult change to make, several other Wikimedia wikis have done it already, and the old name will continue to work (we can put a redirect there). --ais523 15:26, 21 July 2008 (UTC)
• Support: per ais523. --MZMcBride (talk) 15:33, 21 July 2008 (UTC)
• Support Portal:Wikipedia The Main Page doesn't really belong in either article space or Wikipedia space (as noted by others). However being in portal space does seem appropriate. Portal:Wikipedia sounds much better than Portal:Main Page and is exactly what the page would be -- a portal to Wikipedia. -- Imperator3733 (talk) 16:47, 21 July 2008 (UTC)
• Comment I don't like how Portal:Wikipedia moves all the content down to accomdate for the Portal:Wikipedia title. If that could be gotta rid of, then I'd probably support (weakly). –xeno (talk) 02:26, 23 July 2008 (UTC)
  • Done, just bypass your cache and it should be gone. —Remember the dot ^(talk) 03:04, 23 July 2008 (UTC)
    • Kindof nitpicky, but the background is blueish whereas the mainpage background is white. As such the background for "In the news" kinda bleeds together. –xeno (talk) 03:12, 23 July 2008 (UTC)
      • Everything in the Portal namespace has that slight blue tint...perhaps we should simply make all portal pages have a white background? —Remember the dot ^(talk) 03:29, 23 July 2008 (UTC)
        • I don't visit portal pages enough to make an informed statement on that. –xeno (talk) 03:31, 23 July 2008 (UTC)
        • The color of that specific page can easily be changed from blue to white via CSS. But yeah, given the fact that a portal is part of the encyclopedia proper (as opposed to the surrounding project), it probably is a good idea to change the default color from blue to white. —David Levy 03:47, 23 July 2008 (UTC)
          • I like the blue color. Please don't change it. SharkD (talk) 08:25, 25 July 2008 (UTC)
• Strong support. Portal:Wikipedia is a perfect name that would simultaneously resolve several issues (incorrect namespace, incorrect tab label, and the common complaint that the term "main page" is a misnomer). It also would help new users to understand our namespace setup (including the fact that only articles should lack a prefix) and draw more attention to the portal namespace.
  Arguments against a move are based on the incorrect beliefs that the current title causes no problems and that a move would be difficult to handle. (In actuality, Main Page would function as a redirect, and a bot could repair all of the double redirects in a matter of moments.) This really would be a significant improvement, and I don't see any real downside. —David Levy 03:47, 23 July 2008 (UTC)
• Support Portal It does seem to be a portal, more than anything else. Really I don't think the main page is quite like anything else; strictly speaking it should probably have its own namespace all to itself, but that might be pushing people's patience. I would note here that I don't really care about the technical issue the original proposer brought up — I have my own software to write and don't have time to care about MediaWiki internals. I think users should not see Main Page as an article, because it isn't about any concept standardly called Main Page. --Trovatore (talk) 04:01, 23 July 2008 (UTC)
• Question - Is there any reason that the redirect notice hasn't been taken off the main page anyways? Because if this change is made, then redirects like Portada will no longer show as redirects. If we don't want them to show, then why hasn't this already been fixed? If we do, then what do you propose to do about it after the move? ~ JohnnyMrNinja 04:43, 23 July 2008 (UTC)
  • I'm not sure...it was removed last November following these notes. When we first start transitioning, it would probably be better to simply transclude Portal:Wikipedia back into Main Page, making Main Page take on whatever content is in Portal:Wikipedia without it being an actual redirect. After a few months and we're sure everyone's comfortable with Portal:Wikipedia, we could make it into a real redirect and the "redirected from..." text would serve to encourage people to update their links to Wikipedia. —Remember the dot ^(talk) 04:55, 23 July 2008 (UTC)
    • Ps. The original AN thread that led me to remove the hiding code is archived here. —Ilmari Karonen (talk) 05:14, 23 July 2008 (UTC)
      • BTW, a sysop might want to take a gander through [21] the current redirects to the MP, as I'm sure a few don't need to be there. ~ JohnnyMrNinja 20:18, 23 July 2008 (UTC)
• Strong support. Moving the Main page to portal space also makes a stronger case to use a more inclusive portal design that incorporates aspects of the encyclopedia and the community that develops it. With the proper sprucing up for a consistent layout and palette, the main page redesign proposal, RichardF2, just as easily could be located at Portal:Wikipedia. RichardF (talk) 16:53, 23 July 2008 (UTC)
• Support per David Levy and Trovatore. At this point, I honestly can't see any further valid objections to this outside of I(DONT)LIKEITs. —Dinoguy1000 16:54, 23 July 2008 (UTC)
• Question - So, it seems pretty clear that a consensus for Portal:Wikipedia is forming. At this point, what exactly is the rest of the proposal? If I am clear, Portal:Wikipedia will be transcluded on the main page for a period of time, however long is felt is needed to make people comfortable. People will use bots or whatever to convert all the old links to the new links. Then the main page will then be redirected to P:WP. The redirect may or may not be hidden. Did I miss anything? ~ JohnnyMrNinja 17:35, 23 July 2008 (UTC)
  • Wouldn't a redirect be better than transclusion? SharkD (talk) 17:47, 23 July 2008 (UTC)
    • Not at first, if the idea is a "seamless" transition. If it is transcluded first, then every thing that links to it can be fixed before it is redirected with little headache. ~ JohnnyMrNinja 20:03, 23 July 2008 (UTC)
  • JohnnyMrNinja: No, there is not necessarily a consensus forming. That those who have opposed above the "Portal:Wikipedia" line have not reiterated their opposes below the line does not invalidate their opposition to such a change. {{Nihiltres|talk|log}} 19:37, 23 July 2008 (UTC)
    • Okay, but many of the arguments against the move were negated with the new title, as the main page is a portal, not an article or project page. My basic point was, a lot of people are now supporting this proposal, but as the proposal has changed, we should clarify what it is exactly. ~ JohnnyMrNinja 20:03, 23 July 2008 (UTC)

• Support. Should've been there in the first place if you ask me. It it's moved there, we could have an article about main pages.
• Still oppose, as it is still a solution looking for a problem (we can change the tab name for all mainspace articles to "page" and nobody would blink), and per Tim Berners-Lee's eloquent reasoning on this here. Even if we changed the name of the page, http://en.wikipedia.org/wiki/Main_Page would need to continue being an access point to the Main Page, negating the possible benefits. Titoxd^{(?!? - cool stuff)} 09:10, 25 July 2008 (UTC)
• Support- the Main Page does not belong in the article namespace and I don't think it belongs in the Wikipedia namespace either. I think Portal:Wikipedia is the perfect place. It fits the conventions of Wikipedia perfectly. Scottydude _talk 00:02, 27 July 2008 (UTC)
• Oppose I have to agree with Titoxd on this one, it's just a solution looking for a problem. I like the Portal namespace idea much better than the Wikipedia namespace idea, but I still see absolutely no valid reason to make any changes. As Titoxd also points out, most people will still be using Main Page if such a change was implemented. All for the sake of changing the tab. --.:Alex:. 19:12, 3 August 2008 (UTC)

"All for the sake of changing the tab"?! I can only assume that you haven't bothered to read the discussion. —David Levy 19:26, 3 August 2008 (UTC)

Oh I have all of it, but at the end of the day the tab is what it all boils down to and seems to be the only real benefit (which in itself is still trivial). I can think of a lot more actual negative effects it would have as opposed to these trivial benefits. I see absolutely no solid reason to change it and that is where I stand on this issue. --.:Alex:. 19:33, 3 August 2008 (UTC)

Benefits of far greater significance have been cited. I'm at a loss as you how you could arrive at the conclusion that this is all about the bloody tab.

Could you please elaborate on the "negative effects" that this change would have? —David Levy 19:38, 3 August 2008 (UTC)

Firstly, I don't buy the aforemented benefit that "Portal:Wikipedia" would be less confusing than "Main Page". If I were someone who had never been on Wikipedia before, I would find Portal:Wikipedia much more confusing than the self-explanatory Main Page. Sure, those that dig a little deeper and have a strong interest in a particular subject will come across Portals, but why should casual readers who may just want to look one or two things up have to learn what a Portal (in the Wikipedia sense) is? Main page has the obvious strong connotation that it is basically the main page or index of the English Wikipedia. Also, the fact Main page would be a permanent redirect says it all to me really. I'm opposed. You cannot sway me on this one. --.:Alex:. 19:48, 3 August 2008 (UTC)

1. You needn't agree with other people's arguments, but you shouldn't misrepresent them. Your claim that the proposed move would be "all for the sake of changing the tab" conveyed that "changing the tab" is the sole justification behind the proposal. That's flagrantly false.

2. No one is arguing that readers would instantly gain a better understanding of the page's nature from the title "Portal:Wikipedia" than they do from "Main Page"; we're noting that the latter confuses their understanding of Wikipedia itself (not of this specific page). For many people, this is their first exposure to the site, and it's rather unfortunate that we start them off with an incorrect page title in an incorrect namespace.

3. I still don't see how "Portal:Wikipedia" is remotely difficult to understand. No one expects new users to possess immediate familiarity with our "portal" namespace, and no such knowledge is required; "portal" is a common English word meaning "an entrance or a means of entrance." Why would someone fluent in English not interpret "Portal:Wikipedia" to mean "an entrance to Wikipedia"?

4. I still await your citation of "a lot [of] negative effects" that the proposed move would cause. —David Levy 20:16, 3 August 2008 (UTC)

Having the main page hosted in article space never confused me; in fact, I never gave any thought to it until remember the dot raised it as an issue here. I can see how it causes minor problems for bots and other things that deal with the entire mainspace as a whole, but I doubt it's caused problems for regular users.

My claim about the page title "Portal:Wikipedia" is not that it's "hard to understand", but that it's awkward and non-intuitive. I can only think of two cases where the title is a factor, but they're important ones: web search results and bookmarks. "Wikipedia, the free encyclopedia" is a good title for a bookmark to Wikipedia's front page; "Portal:Wikipedia - Wikipedia, the free encyclopedia" is not such a good title. Yes, people could get used to it, but why choose an awkward title in the first place? Yes, portal means door, but "Portal:Wikipedia - Wikipedia, the free encyclopedia" really doesn't say to me "this is the front page of Wikipedia". "Main Page - Wikipedia, the free encyclopedia" does, and just "Wikipedia, the free encyclopedia" does even more. I click on that, I know I'm going to Wikipedia. I may know that "portal" means "door" (though it has stronger sci-fi/fantasy connotations to me), but if I see that in a page title, I would think, "that can't be the front page... who would use a weird title like that?" That really would be my first reaction.

There's probably nothing more we could say to each other about the page title, but let me ask you this: do you actively oppose having the page title be just "Wikipedia, the free encyclopedia"? I personally can support the move to portal space, but not if it comes at the price of giving the front page what I consider to be a really strange title.--Father Goose (talk) 08:55, 4 August 2008 (UTC)

• Strong support - the main page is a portal; this makes perfect sense! — Jack (talk) 02:02, 4 August 2008 (UTC)
• Strong support either Portal: or Wikipedia:. Just get it out of the articlespace; it's an embarrassment. Skomorokh 11:48, 5 August 2008 (UTC)
• Support, provided a redirect exists. -- _{Escape Artist Swyer} ^{Talk to me} _{The mess I've made} 19:30, 7 August 2008 (UTC)
• Neutrality - caught between the cross-fires of the preservation of the "Main page" title and the conventional correctness of the Portal: space. -- Anonymous Dissident^Talk 10:47, 8 August 2008 (UTC)
• Oppose - the main reason for doing this seeems to be the convience it offers to other sites that want to mass-grab Wikipedia articles but not the Main Page. I think we should organise the site based on what offers the greatest convenience and familiarity to our users rather than commercial mirror sites. After all, if having the Main Page in the articles dump is such a problem for them, why can't Answers.com just add "If pages.has_key("Main Page"): del pages["Main Page"]" or the equivalent in whatever language their grab script uses? Cynical (talk) 16:23, 8 August 2008 (UTC)
• Oppose "Portal: Wikipedia"; Support "Wikipedia: Main Page". For one thing WP:MAIN is consistent with the naming conventions for other in-house and Wikipedia-based pages (such as Wikipedia: Village Pump). "Portal" is not a term in wide use in Wiki, and I would even go so far as to argue that despite attempts to make the concept something of widespread use in the world in general, it simply hasn't caught on. I agree with the idea of making the make title more specific, but I feel WP:KISS should apply. 23skidoo (talk) 22:36, 8 August 2008 (UTC)
• Oppose, as usual. As was already mentioned above, this seems to be a perennial solution in search of a problem. This project is, or is supposed to be, for our readers, and I've yet to see any compelling reason this would serve their interests. Should we assume that all people, including thousands of casual, technically unsavvy users, will understand namespaces from the get-go? Do we think many of our readers really give a damn what a silly little tab says? Why break thousands of incoming links? Why is a JS hack to remove the redirect text any better than a JS hack to change the tab text? What does this have to do with building an encyclopedia? – Luna Santin (talk) 21:08, 13 August 2008 (UTC)

Also move Wikipedia:Community portal to Portal:Wikipedia community?

• Comment / expanded proposal. I was thinking. If it makes sense to move the Main page to portal space, then it really makes sense to move Wikipedia:Community portal to portal space. Saying that, now seems to be an excellent time to take advantage of the current Main page redesign discussions and pull together these top-level pages into a coordinated redesign. As a proof-of-concept demonstration, Wikipedia:2008 main page redesign proposal/RichardF2, can be used to illustrate the direction this top-level Wikipedia portal can take. The final version would need consensus on content, layouts and palettes. Some of the key points follow.
  • Move Main Page to Portal:Wikipedia.
  • Move Wikipedia:Community portal to Portal:Wikipedia community.
  • Tie the two pages together with a common, tabbed, box and palette style.
    • Use Portal:Wikipedia as “The encyclopedia” main navigation page. Its role is to present
      • the primary topical navigation structure for articles as presented by the Portal:Contents subpages, and
      • the full range of featured, timely and developing content.
    • Use Portal:Wikipedia community as “The community” main navigation page. Its role is to present
      • the primary navigation structure for key project pages, and
      • the hub for locating timely project information and resources.

RichardF (talk) 02:25, 24 July 2008 (UTC)

• • Very strongly oppose - The Community Portal is not a portal as it intended for editors only. Putting it on the Main Page would be exactly the type of self-reference that we must avoid on the user-side. Regardless, this idea is an entirely different one than whats going on here, and for the sake of developing consensus please keep the topic on moving the Main Page only. ~ JohnnyMrNinja 03:20, 24 July 2008 (UTC)
    • I can appreciate your position, but I must respectfully assert that attempting to pull together disperate discussions on changing the Main page is on topic. I made my point and I'll leave it at that. RichardF (talk) 03:54, 24 July 2008 (UTC)
  • I also oppose moving Wikipedia:Community portal to Portal:Wikipedia community. The use of the portal namespace is for perusing Wikipedia's encyclopedic content -- tables of contents, basically. The community portal is a project page, and is appropriately hosted in project space, regardless of having the word "portal" in its name.--04:20, 24 July 2008 (UTC)
    • I agree, and I suggest (as I did once before) that Wikipedia:Community portal be moved to a different title in the Wikipedia namespace (without the word "portal"), thereby eliminating the implication that it relates to the pages in the Portal namespace. How about Wikipedia:Community gateway? —David Levy 07:25, 24 July 2008 (UTC)
      • If I were going to create a signature portal for Wikipedia with two tabs - one for the encyclopedia and one for the project/community, I would use the style of naming conventions on other tabbed portals. The second page would use the same language as the tab. So, this other page would be called either Portal:Wikipedia/Project or Portal:Wikipedia/Community. If Wikipedia:Community portal stays in project space, the new page would have to link/transclude/duplicate relevant sections. If Wikipedia:Community portal moves to portal space, I would use one of the above subpage names. RichardF (talk) 14:44, 24 July 2008 (UTC)
        • Just a point of clarification. Conceptually, Portal:Wikipedia community and Portal:Wikipedia/Community mean the same thing to me. If this proposal actually got implemented, Portal:Wikipedia/Community probably is the preferred syntax. RichardF (talk) 15:34, 24 July 2008 (UTC)
      • I once read somewhere that the two main ways any web page/site can increase its traffic is to be both an authority and a hub for its core topics. If that's not the primary function of a Wikipedia portal, then I'm not sure why we bother having any. I really don't care so much about the names of these two pages as I do their functions. If Wikipedia is going to have a signature portal, then it should have a constellation of sections about the encyclopedia and a constellation of sections about the community working on the project, just like every other portal. The primary rational for moving Main Page to Portal:Wikipedia IMHO, is to serve that end. That's why this expanded proposal is "on topic." RichardF (talk) 14:24, 24 July 2008 (UTC)
• Support Portal:Wikipedia and Wikipedia:Community. RichardF's proposal makes sense, but while the Main Page is set up like a portal, the "Community Portal" really isn't one, as it is intended for editors and not readers. Renaming the Main Page to Portal:Wikipedia will really help to spotlight portals and familiarize new users with them, and renaming the Community Portal to Wikipedia:Community will prevent confusion over calling it a portal. The Transhumanist 02:43, 30 July 2008 (UTC)
• Support Portal:Wikipedia and Portal:Wikipedia community. per The Transhumanist, GDonato (talk) 15:08, 24 July 2008 (UTC)
• Comment. If the Main page moves to portal space, then it should be designed to serve the dual functions of a portal - for readers and editors.

Portals are pages intended to serve as "Main Pages" for specific topics or areas. Portals may be associated with one or more WikiProjects; unlike WikiProjects, however, they are meant for both readers and editors of Wikipedia, and should promote content and encourage contribution. ...

The idea of a portal is to help readers and/or editors navigate their way through Wikipedia topic areas through pages similar to the Main Page. In essence, portals are useful entry-points to Wikipedia content. — Wikipedia:Portal

RichardF (talk) 16:50, 24 July 2008 (UTC)

• Oppose Portal:Wikipedia community SharkD (talk) 08:28, 25 July 2008 (UTC)
  • I didn't give a reason before. I'll add now that I agree with JohnnyMrNinja's reasons. SharkD (talk) 22:06, 26 July 2008 (UTC)
• Oppose - Portals are for readers too; they should have encyclopedic content that meets the core content policies. Unless its a portal about the Wikipedia community as an encyclopedic subject, it should be in Wikipedia-space (though Wikipedia community is just a redirect, so it still shouldn't get a portal even if there was some encyclopedic content). Mr.Z-man 22:10, 26 July 2008 (UTC)
• Portal: is a content namespace, and probably should not be used for project purposes. – Luna Santin (talk) 21:10, 13 August 2008 (UTC)

Why not Portal:Main Page?

That's what some other wikis use (in their own language). (oh, and I support moving it into the portal namespace in any form) --Random832 (contribs) 20:14, 23 July 2008 (UTC)

It is literally true, and (I think) looks better. Also, Portal:Wikipedia puts it right in line with naming conventions. To the uninitiated, Portal:Wikipedia makes more sense than Portal:Main Page (it's a portal to the main page?). Wikipedia:Main Page looks like "Wikipedia - Main Page" or something, so that makes sense. The only reason (that I can see) to favor Portal:Main Page over Portal:Wikipedia is for nostalgia. ~ JohnnyMrNinja 20:25, 23 July 2008 (UTC)

"Main Page" doesn't comply with our style guidelines, and while "Main page" is an option, many users have commented that this term doesn't accurately describe the page's nature. —David Levy 20:20, 23 July 2008 (UTC)

• Oppose to all. The main page is just the main page; while technically in article space, I feel it does not belong in any other namespace. Any change that will place it in Portal: or Wikipedia, while still showing the same URL, is non-sensical and changes nothing with regard to the viewer. It also potentially creates headaches when editing. — Edokter • Talk • 14:34, 24 July 2008 (UTC)
  • I probably haven't been clear enough - here is how the proposal would be implemented:
    1. The main page would be moved to Portal:Wikipedia. Portal:Wikipedia would be temporarily transcluded back into Main Page, so that the two pages work identically while we move the links to the main page to Portal:Wikipedia.
    2. After the links have been transitioned and everyone is comfortable with Portal:Wikipedia (perhaps about a month after step 1), Main Page would be changed to a simple redirect to Portal:Wikipedia.
  • So the URL will change like you wanted: http://en.wikipedia.org/ will point to http://en.wikipedia.org/wiki/Portal:Wikipedia. And when editing Portal:Wikipedia, "Editing Portal:Wikipedia" is prominently displayed, so editing should still be straightforward and not very confusing. —Remember the dot ^(talk) 01:39, 25 July 2008 (UTC)

Back to discussing Portal:Wikipedia

• Support - I'm much happier with the new proposal. There are no page history concerns, and, as pointed out on my talk page, once the redirect from Main Page to Portal:Wikipedia is implemented, it will affect everyone equally. The move will also increase many people's portal talk edits, which seem to be absolutely essential for passing RFA. :-) Graham87 06:28, 26 July 2008 (UTC)
• Oppose I don't think there should be a namespace listed in the page's title on the main page. For instance, Wikipedia would appear on Google as "Wikipedia:Main Space - Wikipedia, the free encyclopedia" which is not friendly at all. Gary King (talk) 06:49, 26 July 2008 (UTC)

  If you google "Wikipedia", the first link that comes up is just "Wikipedia". The second is "Main Page - Wikipedia, the free encyclopedia". That would become "Portal:Wikipedia - Wikipedia, the free encyclopedia" under this proposal. I agree that's not the most user-friendly name. Are there better options?--Father Goose (talk) 07:48, 26 July 2008 (UTC)

  Actually, it wouldn't even become that, because when you're just casually viewing the page we have it tweaked to just display "Wikipedia, the free encyclopedia". This should be much more friendly and intuitive for people bookmarking the page. Go try it out for yourself! —Remember the dot ^(talk) 16:54, 26 July 2008 (UTC)

  I believe that tweak is done via javascript, and Google ignores it. (See "portal%3Awikipedia+-+wikipedia" this search.) "Portal:Wikipedia" is a good choice from a technical viewpoint, but is still a hideous page name/title. Unless we can get the page title hardcoded as "Wikipedia, the free encyclopedia", I'm drifting from neutral back toward oppose on this.--Father Goose (talk) 09:57, 27 July 2008 (UTC)

  What's so bad about the title "Portal:Wikipedia"? I fail to see how it's even slightly objectionable, let alone "hideous." I definitely would prefer that Google users see "Portal:Wikipedia - Wikipedia, the free encyclopedia" (an introduction to our portal namespace) instead of "Main Page - Wikipedia, the free encyclopedia" (a title that violates both our naming conventions and our namespace conventions, thereby encouraging users to do so with pages that they create). —David Levy 10:18, 27 July 2008 (UTC)

  I can tolerate it in the URL (URLs are notoriously ugly), but in the page title, it is unnecessary, weird jargon. You and I may be wikiheads, but the rest of the world is not going to look at a link named "Portal:Wikipedia - Wikipedia, the free encyclopedia", and think, "oh, that must be the front page". "Main page - Wikipedia, the free encyclopedia" is reasonably recognizable for what it is, as would be just "Wikipedia, the free encyclopedia". (However, I doubt Google will parse the page-fixing javascript -- if the devs agree to hard-code a special page title for Portal:Wikipedia, that would take care of my concerns.)

  It's not that users' access to Wikipedia will be disrupted by its front page having a "weird title", but why face them with a weird title at all? If Microsoft used the name "Portal:Computer" in Windows, they'd be a laughingstock. (As it is, it took them all these years to finally figure out "My Computer" is stupider than "Computer".) We shouldn't be introducing users to a weird titling scheme when they just want to browse the site. We should be trying to show them page titles that make sense to them instead of one that is chosen for our own weird technical reasons. The fact that the front page is a "portal" or a "specially-handled article" or any other special status within the MediaWiki software is something we want to make invisible to most users. We might move it to portal space for technical reasons, but let's keep the technical stuff behind a panel.--Father Goose (talk) 10:19, 28 July 2008 (UTC)

  I strongly disagree with both your assessment of the title and your assessment of what readers should see.
  I don't regard "Portal:Wikipedia" as remotely "weird." A new reader won't (and needn't) immediately understand the concept of "namespaces," but it's obvious that such a title refers to a portal to Wikipedia. (Even if someone is unfamiliar with our specific use of the term "portal," it's a common dictionary word.)
  I agree that readers needn't be exposed to "technical" stuff, but that isn't what this is. It's a reader-oriented setup that assists in site navigation. We want to introduce readers to our basic naming conventions (or at least not greet them with a page that doubly misleads them in this respect). I contend that immediate exposure to the portal namespace would be beneficial and that exposure to the blatantly incorrect title "Main Page" is detrimental. —David Levy 12:02, 28 July 2008 (UTC)

  Portal is the namespace I always forget exists. I see portal links everwhere, and it's like water off a duck's back. I have never really looked at one, let alone edited one. I think this naming would bring new people more in line with the idea of a portal being the way to navigate WP, and will bring a lot more attention to Portals in general. ~ JohnnyMrNinja 08:55, 29 July 2008 (UTC)

  Google's cache of Portal:Wikipedia was made on the 21st, before the title-tweaking code was added on the 23rd. We should wait a while and see if Google's next cache refresh solves the problem. —Remember the dot ^(talk) 22:48, 27 July 2008 (UTC)

• Comment Wouldn't it have to be Portal:English Wikipedia? Phlegm Rooster (talk) 08:52, 26 July 2008 (UTC)

  No, that's covered by the en. at the beginning. To people reading and searching in English, this is the only one they really see. ~ JohnnyMrNinja 09:49, 26 July 2008 (UTC)

• Support - Portal namespace is "user-facing" and appropriate for a page that provides an overview of encyclopedic pages in article namespace. Naively, newcomers will expect to find our main page in portal namespace, since the main page isn't an encyclopedic article! (sdsds - talk) 22:00, 27 July 2008 (UTC)
• Comment Is there anything else that we need to consider about moving the main page to Portal:Wikipedia? Will it effect Google page rankings? What templates will need to be changed? Are there any bots that will be effected? -- ☑ SamuelWantman 23:40, 27 July 2008 (UTC)
• Oppose move. This has been debated so many times, and it always seems more like a solution in search of a problem than an actual solution to an actual problem. I even see people arguing above that it's OK to move the Main Page, because we'll leave a permanent redirect and everything will be fine...why move the page at all if a permanent redirect will be left in its place? Call it historical inertia, or whatever you like, but I don't see any real benefit to moving the Main Page. The mainspace is for readers, as is the Main Page; it may not be an article, but its current location works well. I find Mr.Z-man's comments throughout the above sections persuasive, as the supposed benefits of moving the page aren't particularly overwhelming. - auburnpilot talk 19:40, 30 July 2008 (UTC)
• Oppose This is definitely looking like we're trying to fix something that isn't broken. It's worked fine for years, hasn't caused any problems, and moving the Main page been discussed numerous times before. Juliancolton ^{Tropical Cyclone} 22:03, 30 July 2008 (UTC)
  • The more complete list of benefits is kind of scattered throughout the above discussion. For reference, implementing this proposal would do the following:
    • The top-left tab would read "portal" instead of "article".
    • People who want to make copies of Wikipedia, such as people who provide computers to schools in Africa that can't get Internet access, would have an easier time separating actual articles from project content which they don't want to copy. Because the content of the main page changes dynamically from day to day, it would take quite a bit of work to make the main page work and keep working on an offline copy of Wikipedia. Thus, since the main page won't actually work by default, it's probably best to exclude it from copies of Wikipedia article content by default.
    • The "cite this page" link in the sidebar would be hidden from screen readers and text-only browsers, and the sitewide CSS would no longer have to contain a special declaration to hide it.
    • The article count shown at Special:Statistics would be accurate instead of being 1 higher than the actual number of articles on Wikipedia. {{NUMBEROFARTICLES}} would also be accurate instead of being off by one.
    • Statistics about Wikipedia articles would be more accurate and not slightly skewed by statistics about the main page that are likely to get mixed in.
    • It would be generally easier to write bots and other automated scripts because developers would not have to worry about having to write special code for the main page, ever.
  • I hope this helps clarify things a bit, if nothing else. —Remember the dot ^(talk) 04:13, 31 July 2008 (UTC)

That's incredibly weak reasoning. The article count is off by one? It says article at the top of the page? A "cite this page" link exists? I really don't think its much trouble to exclude a single page (the Main page) from off-line versions, so I'm not exactly worried about those schools in Africa receiving copies of Wikipedia with a static Main Page. Seriously. None of these so called "benefits" are the least bit convincing. - auburnpilot talk 04:50, 31 July 2008 (UTC)

It boils down to it simply making it easier all-around to deal with the main page from a technical standpoint. What reasons are there to not switch, since most users won't notice anyway? True, Main Page will have to stay a redirect for the forseeable future, but in time the redirect will be used less and less until it is only rarely used and can be deleted. —Remember the dot ^(talk) 05:07, 31 July 2008 (UTC)

I agree that some of those rationales are weak, but the proposal itself is quite strong. The simple fact that we currently greet readers with a page located at the wrong title (because it doesn't comply with our naming conventions) in the wrong namespace is reason enough for change. (This can only mislead users, thereby hindering navigation and increasing the likelihood of pages being created with incorrect titles and in an incorrect namespace.) That we have the opportunity to expose many more readers to our portals is another tremendous benefit.

The only argument against the proposed move seems that the current setup isn't so bad. But the mere fact that it's tenable doesn't justify not making an improvement (however modest). It's clear that it would cause no harm, so what's the problem? —David Levy 20:08, 31 July 2008 (UTC)

No, another argument is that having our "front page" named "Portal:Wikipedia" would be more confusing to the public than having it named "Main Page". Using a special hard-coded title would counter this problem, at least to my satisfaction, though it's not yet clear if the devs would be willing to do this. (I remain unconvinced that the javascript-based approach will be adequate.)--Father Goose (talk) 00:09, 2 August 2008 (UTC)

Google's cache updated and you're right, Google doesn't process the JavaScript. I've removed the JavaScript and filed bug 15007; hopefully the developers will give us a better way to do this. —Remember the dot ^(talk) 02:38, 2 August 2008 (UTC)

Feature has been implemented. Woot.--Father Goose (talk) 02:19, 9 August 2008 (UTC)

Has anyone other than you argued this, Father Goose? I respect your opinion, buy you haven't addressed my counterargument that it's the current setup that conveys confusing information to the public (and the proposed setup actually would help readers to better understand Wikipedia). —David Levy 18:00, 2 August 2008 (UTC)

OK, I've submitted a MediaWiki patch at bugzilla:15007. If implemented, this patch will enable us to customize the main page's <title> text however we like. —Remember the dot ^(talk) 03:18, 6 August 2008 (UTC)

While I don't think this is a reason not to rename, I do feel that whatever the Main Page is called, it should only be titled "Wikipedia, the free encyclopedia" as this is the basic entry-point. ~ JohnnyMrNinja 08:29, 5 August 2008 (UTC)

• Support. "Portals are pages intended to serve as "Main Pages" for specific topics or areas. Portals may be associated with one or more WikiProjects; unlike WikiProjects, however, they are meant for both readers and editors of Wikipedia, and should promote content and encourage contribution." — Wikipedia

If Portal:Wikipedia doesn't make sense, then Portal namespace doesn't make sense. RichardF (talk) 14:26, 1 August 2008 (UTC)

• Support (I think I said this above somewhere as well); the Main Page being where it is at the moment causes lots and lots of little problems, and I can't think of much of a good reason not to move it to the right namespace. (For instance, I wonder how many people put pages in the wrong namespace because they don't understand how namespacing works? Putting the Main Page in the right place would set a good example.) --ais523 17:19, 4 August 2008 (UTC)
• Oppose all these proposals. This is just searching for a problem where there isn't one. How anyway is the current location of the Main Page unintuitive to newcomers? Deamon138 (talk) 20:54, 4 August 2008 (UTC)
  • Comment The current location does not help newcomers learn about the different namespaces. The article namespace, which is what Main Page is in, is for articles, which Main Page is not. Also, several issues have already been brought up that would be fixed by this change. -- Imperator3733 (talk) 19:10, 5 August 2008 (UTC)
• Support The spirit of Wikipedia:Avoid self references should be reason enough to move the Main Page out of article space. Moreover, it'll help open up awareness of the greater community to casual readers. Myself personally, I wasn't even aware of all this until I clicked on a TfD link one day. --NickPenguin_(contribs) 02:24, 5 August 2008 (UTC)
• Oppose this offers no benefits and as it stands, there are no cons to having the main page where it is. The proposal to move the page and have Main Page redirect to Wikipedia:Main_Page is just as non-conformist as having the main page in the article space, given that cross-namespace redirects are a criteria for deletion. ~ AmeIiorate _{U T C} @ 09:48, 5 August 2008 (UTC)
  • Comment Several benefits have already been pointed out and discussed. There are also no reasons for not doing this other than the fact that this is how things are right now (which I do not think is a valid reason). As for redirecting Main Page to Portal:Wikipedia (the current proposal for the move target), this will only happen several months after the page has been moved and a bot has fixed all the current links to Main Page (until then Portal:Wikipedia will be transcluded onto Main Page). There really aren't any reasons to not do this, and several reasons to do it. -- Imperator3733 (talk) 19:10, 5 August 2008 (UTC)
• Support the gradual move to Portal:Wikipedia, per many of the reasons above. I agree that there's not overwhelming evidence to support this, but there's no reason for us to annoy bot writers (I can also see a bot writer forgetting about this and causing some issues...though this would probably only happen if the bot was run without approval), give humanitarian workers another thing to keep on their minds, and falsify stat counters (I'm sure the average number of edits to articles is slightly higher than it should be because of the main page, for example) by refusing to move the main page to a more isolated namespace. People seem to understand that this has to be very gradual—I doubt the redirect from Main Page would ever be removed unless something notable called "Main Page" sprung up—which is good. I'm sure the majority of users would not even notice the change, since "Portal:Wikipedia" would not even prominently be displayed on the page. Ideally, the developers would be willing to modify the <title> tag for us to read "Wikipedia, the free encyclopedia" as mentioned before, and the page ranking on Google would not be affected. If nothing else, it would end this perennial proposal. :) —Pie4all88 (talk) 22:11, 5 August 2008 (UTC)
• Support - I believe the main page should be moved to Portal:Wikipedia, or if not that then at least somewhere out of the article namespace - simply because the main page is not an encyclopedia article.--h i s ^{s p a c e} _{r e s e a r c h} 17:04, 7 August 2008 (UTC)

• Actually, considering it now, I like Portal:Main better than Portal:Wikipedia, because the latter suggests that the portal is full of information about Wikipedia itself, when it's actually full of information about Wikipedia's articles. Either way, though, those are better than leaving the main page in the article namespace, because it is not and will never be an article. I disagree with the "if it ain't broke, don't fix it" idea - Wikipedia has always been about perfecting and improving itself, and the community tends not to settle for second best in most circumstances.-h i s ^{s p a c e} _{r e s e a r c h} 17:09, 7 August 2008 (UTC)

• Oppose- Historical inertia rules. :) Have read the discussion and still see no benefit for this move. Only more work and an uglier (longer) url for the main page. Garion96 (talk) 10:17, 8 August 2008 (UTC)

• A URL that is 3 characters longer? That makes it ugly? --NickPenguin_(contribs) 22:58, 8 August 2008 (UTC)

Why not simply to Portal:Main

It will keep with the existing naming convention for portals—compare with Portal:Contents. Ruslik (talk) 12:29, 7 August 2008 (UTC)

Y'know, that makes even more sense than Portal:Wikipedia. Okay, start the poll over again!--Father Goose (talk) 07:33, 8 August 2008 (UTC)

Portal:Main seems inorganic and unintuitive, compared even to Portal:Main Page. I'd almost rather have it at Index.html. I do not believe that there is a Portal naming convention guideline (?), but even so I doubt a portal about Wikipedia would ever exist as that would go against the desire to not be self-referential. ~ JohnnyMrNinja 08:29, 8 August 2008 (UTC)

Portal:Main should be a portal about the Main, a river in Germany. Kusma (talk) 09:54, 8 August 2008 (UTC)

There isn't a single Portal on Wikipedia about a river. Neıl ☄ 10:10, 8 August 2008 (UTC)

Yet! ~ JohnnyMrNinja 10:17, 8 August 2008 (UTC)

That is a good point. And why keep the word "main" in the title, except for nostalgia sake? --NickPenguin_(contribs) 22:55, 8 August 2008 (UTC)

Without the "Main" in "Portal:Main", it would be "Portal:". The colon there is silly and random. So then it would be "Portal". But that would just be in article space, which defeats the whole point of moving the Main Page out of article space. Deamon138 (talk) 23:17, 8 August 2008 (UTC)

That's not what I meant, tho it's probably how it sounds. I meant that if we are going move to a portal, why would we need to characterize it as the "main" place to be, when there are clearly many other ways to approach the encyclopedia? Wikipedia is big enough and has enough quality articles that now we need to improve the way we introduce readers into subjects, and portals are the way to do this. --NickPenguin_(contribs) 23:24, 8 August 2008 (UTC)

My two cents: While Portal:Wikipedia might be stretching our naming conventions a bit, it is certainly not as much of a stretch as having the main page as an article. —Remember the dot ^(talk) 04:06, 9 August 2008 (UTC)

'Support and will someone please hand Father Goose a WP:TROUT? How the hell does it make more sense to have a main page as a general article, which violates all rules, guidelines, and common sense, than as a "Portal" to the rest of wikipedia? PXK ^T /_C 01:20, 11 August 2008 (UTC)

Um, I support moving it to the Portal namespace (especially now that the devs have implemented a customizable "main page" title). (And in fact I was the first to suggest the Portal namespace.) I'm still not sure whether I like "Portal:Wikipedia" or "Portal:Main" better, though. But thanks for the trout!--Father Goose (talk) 05:26, 11 August 2008 (UTC)

• Oppose, trivial and unnecessary. Stifle (talk) 10:43, 11 August 2008 (UTC)

Make it Special:Random or Special:BlankPage

Why is the community maintaining this ever-changing page anyway? It's binding lots of editor and reader time without contributing anything to Wikipedia. The fact that no proper name for this page can be found emphasizes this. If the user would miss an important link usually found on the main page, that link should be added to the navigation. --91.96.47.52 (talk) 19:20, 11 August 2008 (UTC)

Archive?

Time to archive. It's 1/2 the page and creating loading errors for me. Should I move it to Wikipedia:Village pump (technical)/Archive 43 or Wikipedia:Village pump (proposals)/Persistent proposals ? -- Quiddity 23:06, 13 August 2008 (UTC)

Mass File Upload with Summary info

I still have not ventured into the bot realm so I don't know about writing something that would accomplish this, so bear with me, please. I am hoping to port a travel orb template with images from another wiki; it consists of about 200 png images of country flags that have been photoshopped behind an orb face, sort of like a small round button. Uploading these files will take a while by hand, and I wondered if there was a method by which they could be uploaded en masse with the summary text being standardized for them? The filenames are the country names (not abbreviations), so the process could use the filename (minus .png extension) in the summary. Any ideas will be appreciated. Thanks!  Tigey   ^{Talk   E-Mail}  19:02, 7 August 2008 (UTC)

See the list of file upload tools at Wikimedia Commons. Graham87 16:03, 8 August 2008 (UTC)

Ahh, My thanks!  Tigey   ^{Talk   E-Mail}  21:19, 9 August 2008 (UTC)

Link to Special:Newpages but a few pages in?

I have recently been on Special:Newpages a lot, partly to add speedy delete templates where necessary, and partly do look for potential WP:DYK candidates. However, I always turn bot and patrolled edits off and have 500 results per page. On top of that, I like to browse Special:Newpages starting at page 2 or 3 so as to try to avoid speedily deleting pages that have just appeared and which might consequently still be under construction. However, when I copy the URL of such a page - for instance, http://en.wikipedia.org/w/index.php?title=Special:NewPages&offset=20080801212507&limit=500&hidepatrolled=1&hidebots=1 - and paste it again after a while, I can see that it sticks to the same range of results rather than a particular page of results on Special:Newpages; i.e. the range of articles it shows is static and not dynamic, unlike the main Special:Newpages page itself.

My question, then, is this: is it possible to have a URL which takes you straight to page 2, say, or page 3 of Special:Newpages with the filters which I have indicated above applied, and which consequently shows the current second or third page of Special:Newpages and automatically updates itself? If so, please post that URL here!

Thanks in advance.

P.S.

I had originally posted this over at VPA but was advised to repost here given the lack of responses over there.

It Is Me Here (talk) 18:59, 6 August 2008 (UTC)

No, that's not how offsets work. Offsets are by timestamp, for efficiency reasons. The offset in the URL you give is 20080801212507, i.e., 2008-08-01 21:25:07. You can manually edit the offset to be half an hour ago (or whatever) if you like, maybe using a script. Otherwise, you have to click. —Simetrical (talk • contribs) 16:06, 7 August 2008 (UTC)

I see - so there's no "&page=x" or anything that you can stick on the end of it? It Is Me Here (talk) 16:19, 8 August 2008 (UTC)

No. —Simetrical (talk • contribs) 21:17, 10 August 2008 (UTC)