Wikipedia:Village pump (proposals)/Archive 38

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

Village pump (proposals) archive

This page contains discussions that have been archived from Village pump (proposals). 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 · 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

Easier instructions for making articles

I have noticed over and over again that many n00bs have no idea how to create a new article, and most of the time end up creating it in userspace. We also get plenty of cases like this where the user has written out the article but doesn't know where to put it. As many times as I've instructed users on how to make articles, I've come to realize — I don't think we have a guide to making articles that clearly has a button with "create your article here" or somesuch. Usually I just end up giving them a red link to work with so they can turn it into their article. Do we have one that I've overlooked? Ten Pound Hammer and his otters • ^{(Broken clamshells • Otter chirps • HELP)} 14:53, 29 October 2008 (UTC)

Nope, we don't - that appears to be by design. The original idea was to encourage people to create articles on topics redlinked by other topics, so that new articles are never orphaned, and spurious unneeded articles are discouraged. In practice, these days, it's much more common for people to be interested in creating articles on topics of interest to them not linked by other articles. Should we encourage this, or is the current mechanism better? Dcoetzee 17:56, 29 October 2008 (UTC)

I definitely think that we should have a page that explicitly shows how to create a new page, so long as we make it clear that the user should check to see that a page on that subject doesn't already exist. Ten Pound Hammer and his otters • ^{(Broken clamshells • Otter chirps • HELP)} 23:50, 29 October 2008 (UTC)

Users asking at the help desk are usually directed to Wikipedia:Your first article which includes the section Wikipedia:Your first article#How to create a page. PrimeHunter (talk) 00:09, 30 October 2008 (UTC)

It never really took off, maybe because it's still to an extent at the drawing board stage, but I thought and still think that the Wikipedia:Article wizard was a great idea, and if it is completed and placed in the interface in a way that drives people to create articles using it, could be a great boon to Wikipedia.--Fuhghettaboutit (talk) 03:11, 30 October 2008 (UTC)

Yes, something like that would be very helpful. Ten Pound Hammer and his otters • ^{(Broken clamshells • Otter chirps • HELP)} 23:18, 2 November 2008 (UTC)

Deletions (afd)

Hi, the afd pages seem to be over 100 entries per day now. I was looking at a deletion discussion about the article on science (ology) of the effect of astro something on human culture. I can't remember the name and I have tried keywords I knew were in the discussion. I have gone over several archives and searched stuff like "ology afd" etc. Does the afd (or other lengthy active listing categories) require a specific and ambiguous search capability? And, does anyone recall this debate as I would like to find the article or the debate.... ~ R.T.G 15:25, 3 November 2008 (UTC)

Would that have been Wikipedia:Articles_for_deletion/Astrosociology_(2nd_nomination)?--Aspro (talk) 18:49, 3 November 2008 (UTC)

Wikipedia:Articles for deletion/List of sciences ending in -logy mentions astrology. PrimeHunter (talk) 02:11, 4 November 2008 (UTC)

Thanks, I actually found it after a while. I'm trying to undelete it but it's seeming unlikely. ~ R.T.G 02:23, 4 November 2008 (UTC)

Additional featured portal director

Please see Wikipedia_talk:Featured_portal_candidates#Additional_Featured_portal_director. Cirt (talk) 22:36, 3 November 2008 (UTC)

Proposed: That Jimbo should have the powers he currently has.

Recently, I've heard a couple of people speculate that Jimbo's role on English Wikipedia lacks consensus. I suspect this is false-- I think there is strong consensus for his role. But admittedly, we don't actually have a policy that specifies this.

So I'd call for eyes at: Wikipedia:Project Leader, where I've attempted to just spell out what his special role currently is.

In particular:

Did I miss any of the powers Jimbo has?
Jimbo's current role does have consensus, right? A few dozen voices of support before the arbcom election would be helpful in clarifying that yes, Jimbo should in fact have the appointment powers that he has. --Alecmconroy (talk) 06:23, 4 November 2008 (UTC)

New User Group - moveconfirmed

I've been noting the Grawp-type vandalism for the past few months. I have noted that often, Grawp will undo 10 random edits from Recent Changes and go immediately on a spree. Now often, undoing 10 edits in a row will not be noticed by RC patrollers until it is too late and Grawp has gotten his .5 milliseconds of fame. Unfortunately, Grawp's edits are preserved in the edit history for all eternity, so I figured that we might as well get a way to try to stop them before they happen.

I propose that we spin off the "Move pages (move)" right from autoconfirmed and make it into a new usergroup that the database automatically gives after a certain number of edits, as autoconfirmed is currently handled. However, if this is to be effective, moveconfirmed has to have a slightly higher barrier to it, so I propose that any user who has edited for more than 4 days and has more than 25 edits can move a non-full-move-protected page.

So...critiques? Comments? Concerns? NuclearWarfare ^{contact me}_{My work} 22:19, 30 October 2008 (UTC)

This is a good modification to my suggestion a few sections above. I'd say 50 edits (really, how many brand new users need to move pages and can't find someone to do it?)--extending the limit ensures the gr*wp style 'innocuous' edits are more likely to be noticed, if they can even be bothered to make that many. Or maybe 25 if it can be set to mainspace- and unreverted only. [ roux ] [x] 22:24, 30 October 2008 (UTC)

Why will 25 edits make more of a difference than 10? It will be a little more work, but Grawp has shown that he doesn't mind 10 edits. 100 edits might make a difference, but that's going to be more harm than good. If the edits made were actually helpful, I might support this, but they're often just pointless edits to a userpage. There are better options that will have less negative impact on legit new users. Mr.Z-man 22:30, 30 October 2008 (UTC)

The problem is that the move right is one that we want relatively new users to have. If we increase the threshold to 25, Grawp will simply undo 25 edits from recent changes and keep moving. When we consider a system to oppose vandalism, the highest priority must be given to the idea that the system should not be game-able. As it stands, we have a highly game-able system on the technical level, and a virtually ungame-able system on the human level: it's easy to get autoconfirmed, but hard to avoid being blocked on a Grawp-spree. As your proposal involves only a minimal increment to the difficulty of gaming the system at the technical level, I don't see the point of its implementation—especially as it increases the barriers for those who edit in good faith. The ideal system would block all bad-faith vandalism with no false positives, and let through all good-faith newbies who simply can't format wikitext the way we prefer: it would be ungame-able. If only we could build it… {{Nihiltres|talk|log}} 22:38, 30 October 2008 (UTC)

At what point does the administrator time spent fixing cut-and-paste pagemoves exceed the time spent fixing pagemove vandalism? Pagemove vandalism is easy: just hit the "rollback" and "delete" buttons a few times. Cut-and-paste moves are a good bit harder. --Carnildo (talk) 22:53, 30 October 2008 (UTC)

The Abuse filter is coming, I promise! — Werdna • talk 00:01, 31 October 2008 (UTC)

[citation needed] --MZMcBride (talk) 00:04, 31 October 2008 (UTC)

This is an interesting proposal, although I would prefer that the move right requirements be 4 days plus approximately 20-25 unreverted, non-revert edits in the main namespace. I can't think of many examples where this would be a problem to legitimate editors, and would prevent Grawp from simple reverting edits. It might require a change to the software, however. -- Imperator3733 (talk) 14:38, 31 October 2008 (UTC)

If we had a user group intermediary to autoconfirmed and rollback, (for example 'surveyors' in the context of flagged revisions), an effective and non-obtrusive method would be to delay page moves from autoconfirmed users pending verification by a user in this group. Cenarium ^Talk 18:33, 31 October 2008 (UTC)

I think what's required is for there to be a gap between making the 10 edits and getting autoconfirmed. If there is no gap then there is no time for anyone to determine if the edits were good or not (trying to automate that bit is asking for trouble). How about changing autoconfirmed (for both semi-protected edits and moves) to 4 days total since registering, 10 edits and 24 hours after the 10th edit? It would require some coding work, of course. --Tango (talk) 14:09, 3 November 2008 (UTC)

No more barriers to new users please. the skomorokh 15:34, 4 November 2008 (UTC)

Proposal for new wiki

I suggest that a new wiki is made-a wiki for all minor wiki's. This is because I saw StructulWiki. I think that there should be a wiki for all minor wiki's.--DJackD (talk) 08:42, 5 November 2008 (UTC)DJackD 06:41 p.m. 05/11/08 (GMT+10)

This is the place for making proposals about the English Wikipedia, not for proposing the creation of new wikis. Algebraist 11:44, 5 November 2008 (UTC)

Please see m:Proposals for new projects with instructions. Meta is the central place for Wikimedia projects; Wikipedia is just one of many hundred projects. Best, PeterSymonds (talk) 11:53, 5 November 2008 (UTC)

User:Apovolot/Expert peer review

See User:Apovolot/Expert peer review proposal. Apovolot (talk) 01:10, 6 November 2008 (UTC)

Link. [ roux ] [x] 01:23, 6 November 2008 (UTC)

A New Skin

I just thought of something. All Wikia wikis use a real new modern skin, known as Monaco. Maybe Wikipedia should upgrade into that. It has many new features, including fly-out menus, wider articles and much more. HK22 ^{Talk to me!} 03:24, 6 November 2008 (UTC)

Proposal: New article creation limits/autoconfirm change

I've had an idea for (somewhat) reducing the insane flow of BS vanity/attack/nonsense/nocontext pages. It's a two-pronged approach:

1) Raise the autoconfirm threshold to 10 days/100 edits. 2) Require page creation by non-autoconfirmed users to run through WP:WIZARD or one of its equivalents (there's a better one, but I've mislaid the link).

This has a bunch of benefits:

Immediately reduces Gr*wp-style get-ten-edits-then-poo-on-WP pagemove vandalism; I doubt that anyone involved with that--or /b/--is going to bother with 100 productive edits just to poo on things. Even if they do, it's a net benefit to the project;
Will help reduce the creation of insta-dumb pages by driveby people with too much time on their hands; 2-3 minutes to fill out a few fields is (I think) a sufficient barrier to entry for the casual doofi. The less-casual won't be dissuaded by anything short of an electric shock, so we're sort of SOL there;
Doesn't provide much more of a barrier to entry than a CAPTCHA for IPs;
Helps train new users in basics of MOS, formatting, etc.

Thoughts? [ roux ] [x] 05:37, 26 October 2008 (UTC)

I definitely oppose the idea of increasing the autoconfirm threshold. We just increased it from 4 days to 4 days/10 edits a few months ago. I remember there being some concern back then about new users being driven off by the edit requirement before they have the ability to create articles. Raising the requirement to 100 edits would, IMO, drive away too many potential users to be acceptable. I would, however, prefer that the threshold be 4 days/10 undeleted/unreverted edits. That minor change would not affect users making positive contributions to the encyclopedia, and would make it harder for vandals to gain the ability to move pages. This might require a change to the software, however.

As far as requiring new pages to be run through something like WP:WIZARD, I think that also has the potential to drive new users away. I would suggest simply making a more noticeable link to MOS in the edit area (preferably with the ability to turn off that notice in preferences for the more experienced users). -- Imperator3733 (talk) 06:28, 26 October 2008 (UTC)

I strongly disagree with such a high autoconfirm limit, but I strongly support some sort of limit, maybe even only three edits and no time requirement. But this is serious. I'm sick of ~60% of all new articles being made by users as their first and only edit, and ~90% of them being spam, attack, unsourced, non-notable, and/or OR. There needs to be a higher limit to create new articles, and it does not need to be as huge as that proposed, but there must be something. Reywas92 ^Talk 15:39, 26 October 2008 (UTC)

Are you saying that you think the autoconfirm limit should be just 3 edits? If so, that would be lower than the current limit, which conflicts with your comment about wanting to raise the limit. In case you don't know already, users must be autoconfirmed (currently 4 days/10 edits) in order to create new pages, move pages, or edit semi-protected pages. -- Imperator3733 (talk) 17:29, 26 October 2008 (UTC)

No, the current autoconfirm should stay as it is. I didn't quite realize that the proposal was actually two completely different proposals. On 1) I oppose; the current autoconfirm for editing protected pages, etc. is fine. On 2) I also oppose because we already know by experience that a forced Wizard does not always work, though an optional one can. I support a second autoconfirm that only applies to article creation. It doesn't have to be long, but there must be more than allowing any registered user with zero idea how to do anything on WP to create articles that the rest of us must deal with. Reywas92 ^Talk 18:02, 26 October 2008 (UTC)

I support the idea. 100 edits may be too much, but something like 20-50 edits is good. There should also be a mechanism to stop new users from making more than 10 edits to a page within half an hour. This would make it completely obvious whether it's a vandal account trying to attain the autoconfirmed requirements because they would switch pages. A new series of warning messages could be developed, and this could be a blockable offense. The result would be zero page move vandalism and better articles. --Pwnage8 (talk) 23:49, 26 October 2008 (UTC)

There was extensive discussion in May about raising the autoconfirm threshold. As a result, it was changed from 4 days/0 edits to 4 days/10 edits, with a majority of editors (but not enough for a rough consensus) in favor of 7 days/20 edits. So 10 days/100 edits is absolutely a non-starter; please drop that part of the proposal.

As for whether non-autoconfirmed editors should be able to create new pages in mainspace/articlespace, it would really be helpful to have some data. For example, of the x thousand new articles created on a given day, what percentage are created by non-autoconfirmed editors, and of those, what percentage are deleted or turned into redirects to previously existing articles, within (say) a week?

Finally, it's impossible to come up with any requirements that will absolutely prevent move vandalism, short of requiring admins to do all page moves (which we certainly don't want). The objective of increasing the autoconfirmed threshold was simply to make it more costly (in terms of time) for a vandal to get a new account to autoconfirmed status, and to make it more obvious (by looking at the edit pattern) that an account doing move vandalism had been created solely for that purpose. As many other editors have pointed out, making it harder for editors to qualify to do something does reduce vandalism, but the cost is that good editors aren't able to do useful things (for a while, at least), and may be sufficiently discouraged as to simply stop editing. In short, there is alway a cost-benefit tradeoff; the goal is to find that point where benefits most exceed costs. -- John Broughton (♫♫) 14:22, 27 October 2008 (UTC)

I am aware of the cost-benefit tradeoff. I support the idea of raising the autoconfirmed requirements because I think it would be a net benefit. Editors who are interested in contributing to this encyclopedia would stick around long enough to attain them, and vandal accounts would be outed through their editing pattern. If someone makes a new account for the sole purpose of making an article on themselves or their favourite non-notable band, then maybe discouragement is the way to go! --Pwnage8 (talk) 16:44, 27 October 2008 (UTC)

I support the x non-reverted edits rule and the wizard for one's first new page. It Is Me Here (talk) 14:25, 27 October 2008 (UTC)

Proposal 2 only - We could just try the latter. Goodness knows we could use some backlog reduction at Special:NewPages. Sometimes it seems that there are just a few of us there for a job that requires dozens. I estimate (blindly) that 3/4 pages is never patrolled. Even cutting that by 1/3 would be great. NuclearWarfare ^{contact me}_{My work} 02:52, 28 October 2008 (UTC)

God, no. Autoconfirm as it is already has near-draconian requirements; at this point, and any higher ones, it's just going to drive away legitimate users. As I said in the last autoconfirmation-raising debate, it is a trivial task to write a grammar bot in Perl/Ruby/Python and have it make minor corrections at rates high enough that these kinds of limits don't matter. All they do is hurt new editors who don't understand why they aren't "good enough" to meaningfully contribute (i.e, edit semi-protected articles, which is a growing subset of articles, and are also generally the ones drawing the most attention). Celarnor ^{Talk to me} 18:58, 1 November 2008 (UTC)

As the worst of the vandalism is page moves, would putting the move limit to a second auto-confirm longer & later make sense, most newbies don't move pages so this would not scare anyone off, especially if the move tab was hidden or linked to WP:requested moves. --Nate 14 81 15:26, 6 November 2008 (UTC)

Add Wiktionary link to left sidebar

I would like to propose adding a link to our sister project Wiktionary in the sidebar on the left of all Wikipedia pages. Right now our only link to Wiktionary is from the bottom of the main page. Wikipedia uses a rich vocabulary. Making it easier to look up unfamiliar terms that are not blue-linked would aid our readers. I would suggest adding Wiktionary to the toolbox. The navigation area might also be appropriate, but adding a line there would move the search box lower, and that might might be too much of a change in our overall look. To those who might question adding a link to Wiktionary and not to other sister projects, I would point out that we do link to other projects from articles where there is relevant content on the sister project, but Wiktionary is of potential use to a reader of any article. --agr (talk) 20:23, 28 October 2008 (UTC)

Oppose; as all the other links in the sidebar are, naturally, internal links. Every external link on the project is careful to indicate that it is indeed taking readers elsewhere, either with the external link icon or by explicit statement "on wiktionary", "at wikispecies", etc. There is no need to add such a confusing 'hole' through which readers can inadvertantly leave en.wiki. Anywhere a valuable link to wiktionary could be made, of course, there is nothing to stop you doing so, within reason. Happy‑melon 20:33, 28 October 2008 (UTC)

Oppose, please, no clutter to non-reliable links. SandyGeorgia (Talk) 20:35, 28 October 2008 (UTC)

Most of our links are to Wikipedia, which is no more reliable than Wiktionary. Quite possibly less so; many of our Single Purpose Accounts would find nothing to do on Wiktionary. I don't see the force of this objection. Septentrionalis PMAnderson 22:10, 28 October 2008 (UTC)

The point of SandyGeorgia's comment is that it's considered a good general principle in web design that a reader should have some warning when they're leaving a site. If they're expecting an internal link and get an external link they can become disoriented. Dcoetzee 04:13, 29 October 2008 (UTC)

I would support the ability to add a template that adds an "other projects" sidebar link to Wiktionary where relevant, but outside of that, I don't think it would be as relevant as you think it would be. EVula // talk // ☯ // 20:41, 28 October 2008 (UTC)

No more sidebar clutter please. Incidentally, "unfamiliar terms" should be blue-linked; if to Wiktionary then with [[wikt:term]]. -- Fullstop (talk) 23:50, 28 October 2008 (UTC)

I have been editing on Wikipedia for 4 years and I have never seen a link to Wiktionary in an article. Can you point to a policy or guideline that says that? We routinely transwiki articles deemed to be no more than dictionary definitions to Wiktionary. When this is done, as far as I have seen, links to the transwikied page are deleted. --agr (talk) 19:31, 29 October 2008 (UTC)

There are many, though usually within the lead section. Search for wikt to find 700+ instances. (Though, I expected to find more than that. I find these useful, and think they should be officially encouraged)

However, I can't find any kind of guidance on when they should/not be used. Should probably be discussed (or any discussion linked to from) Wikipedia talk:Wikimedia sister projects and/or Wikipedia talk:InterWikimedia links. -- Quiddity (talk) 22:20, 6 November 2008 (UTC)

Thanks for finding those examples. That there are only 700+ instances in 2.6 million articles supports my point that such links are rare. And many of the examples are specialized uses such as links to foreign words, as in "Lakshmi or Mahalakshmi (pronunciation: [ləkʂ.miː]; Sanskrit: लक्ष्मी lakṣmī) is the Hindu goddess of wealth and prosperity." But even if wikt links were expanded a thousandfold, we would still be in the position of trying to anticipate what will be unfamiliar to our readers. I would suggest that this is the wrong approach. Every word on Wikipedia would be linked to Wiktionary. A mechanism where the reader could highlight a word and then click a lint to find that word in Wiktionary would be best. What I am proposing, a sidebar link to Wiktionary, is less than ideal but simpler and could be implemented immediately.--agr (talk) 00:06, 7 November 2008 (UTC)

There's also {{Wiktionary}} (more than 10,000 transclusions), {{Wiktionary-inline}} (about 50 uses), {{Wiktionarycat}} (about 200 uses), {{Wiktionarypar}} (about 10,000 uses), {{Wiktionarylang}} (about 100 uses), {{Wi}} (about 500 uses), and a handful of templates with only a few uses. Mr.Z-man 01:41, 7 November 2008 (UTC)

bugzilla:708. — Werdna • talk 14:08, 29 October 2008 (UTC)

I support this too.

Interwiki links under “languages” are a precedent for sidebar links to other wikis. In fact, adding a “projects” box above languages, and having a format for including sidabar project links would reduce the hideous clutter of sisterlink boxes. Maybe adding a colon puts a link in the sidebar, e.g. [[:wikt:entry]]

A standard external link icon could clearly show that the link is external, as opposed to [[wikt:]] links, which do not. But this wouldn't really be necessary, anyway. —Michael Z. 2008-10-29 20:04 z

Couldn't this be done programmatically? If the article exists on a sister, a link is autogenerated. If not, not. Requires no behavioural changes to editors, just deletion of extant sisterproject boxes in See Also & EL sections, something that would be trivial with a bot. [ roux ] [x] 20:24, 29 October 2008 (UTC)

Maybe, but it would need some smarts, and probably shouldn't add entries without supervision. For example, Wiktionary entries follow normal capitalization rules, so we have wikt:banana but wikt:Ukraine. In some cases the link may have a different name, like Regina, Saskatchewan may link to wikt:Regina.

But anyway, adding a bot is a secondary consideration, which would follow anything we determine about sidebar links. —Michael Z. 2008-10-29 21:18 z

A similar system is used in Lithuanian Wikipedia. For example, lt:Europa has such links (the relevant box in sidebar is "kituose projektuose"). Templates like lt:Šablonas:Vikicitatos or lt:Šablonas:Vikižodynas are used to indicate the articles that should have such links. --Martynas Patasius (talk) 23:45, 31 October 2008 (UTC)

I don't think internal vs external vs sister site is the important issue. The question should be what is most useful to our readers. Do we have a way to tell how often the side bar links are used? If so, I would propose trying a Wiktionary link for 6 months and see how it does.--agr (talk) 14:02, 2 November 2008 (UTC)

Enable mw:Extension:Nuke

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Seems to be consensus (85% supporting) and this discussion has been open for over 1 month. The bug to have this enabled has already been filed (see bugzilla:15783). No need to continue discussing this. - Rjd0060 (talk) 03:23, 8 November 2008 (UTC)

Meta recently had a poll that passed that permits small wikis to enable the mw:Extension:Nuke. Due to its size, the English Wikipedia was not included in the poll and the decision has been left to us locally if we would like to enable such a feature.

In short, nuke permits administrators to delete all the recent pages created by a single user. This feature would be especially useful with grawp and spammers and would be easier on the servers than current deletion scripts used by admins to fight grawp (as well as more accurate). So I'd like to start a local poll on the question of enabling the nuke extension here.

Support enabling

Obviously. MBisanz ^talk 12:16, 25 September 2008 (UTC)
This would be very advantageous for admins and developers alike; both reducing server lag and helping with the mass reversion of spammers and vandalbots. — ^.^ ^{[citation needed]} 12:55, 25 September 2008 (UTC)
Sounds like a good idea with no obvious negatives. -- Imperator3733 (talk) 16:35, 25 September 2008 (UTC)
Looks good to me. Shereth 16:43, 25 September 2008 (UTC)
I agree, this could be very helpful. Mr.Z-man 16:53, 25 September 2008 (UTC)
Support, definitely. - Rjd0060 (talk) 17:07, 25 September 2008 (UTC)
Support; nuke it from orbit, it's the only way to be sure. --—— Gadget850 (Ed) ^talk - 17:12, 25 September 2008 (UTC)
Mwawhawhawhawhaw... er, I mean Support... :D Happy‑melon 17:23, 25 September 2008 (UTC)
Giving nukes to 1500 random people on the internet? What could possibly go wrong? Support henrik•talk 18:00, 25 September 2008 (UTC)
Support. --MZMcBride (talk) 18:41, 25 September 2008 (UTC)
Though I'd be even happier if there was an un-nuke option as well. EVula // talk // ☯ // 21:41, 25 September 2008 (UTC)
I'd like to amend my comment to say that I definitely think that a seven day limit would be a fantastic way of limiting inadvertent (or even malicious) abuse of the tool. EVula // talk // ☯ // 00:51, 30 September 2008 (UTC)
Support. I've always wanted to have my own nuclear weapon. So long as I don't have to have the demon core on my desk as well.-gadfium 22:08, 25 September 2008 (UTC)
Support, as long as I get to keep the football. Waltham, The Duke of 03:23, 26 September 2008 (UTC)
Support, per MBisanz (talk · contribs). Cirt (talk) 12:46, 26 September 2008 (UTC)
Support Seems like a good enough idea. –Juliancolton ^Tropical ^Cyclone 12:52, 26 September 2008 (UTC)
Support, this would be very helpful (and Grawp will die of radiation poisoning). ff m 12:57, 26 September 2008 (UTC)
Support with some upward limit on pages created. Protonk (talk) 18:57, 26 September 2008 (UTC)
And when it supports uploads, it'd be great on imagevio uploaders as well. MER-C 13:21, 27 September 2008 (UTC)
Support but I really think the software should be scripted to allow un-nuking with the same amount of work. It can't be that hard to code a reverse-option, all it has to do is undelete a list of articles which are hopefully logged to have been nuked. Or aren't they? I really think there ought to be a nuke log if they aren't. So Why 13:35, 27 September 2008 (UTC)
Support as a valuable tool against vandalism and spam, but at the same time if this is a problem, why not just put a common-sense restriction on article creation for new accounts, something like 1 article per day for the account's first 30 days or 100 edits, whichever comes last. Andrew Lenahan - Starblind 18:27, 27 September 2008 (UTC)
Support, provided that the tool is in fact limited to what is in the recentchanges table (as discussed below) - that is, is limited to new pages created by an editor in the past 30 days. With that limit, a rogue or compromised account isn't likely to be able to do much damage before being de-sysopped. -- John Broughton (♫♫) 00:44, 28 September 2008 (UTC)
Support, with John Broughton's proviso to limit the period to 30 days. In practice, that could even be reduced to 7 days or even less, since a spate of spurious creations is likely to be noticed by someone relatively quickly. Horologium (talk) 01:11, 28 September 2008 (UTC)
Support though a limit to 30 days would be good. Hut 8.5 11:03, 28 September 2008 (UTC)
Support but I do like the idea of some sort of time limit (Broughton/Horologium) Scotty dude _review 13:10, 29 September 2008 (UTC)
Support, ~~provided that the nuke button is big and red~~ ;P. Seriously, though, this is a good idea. I agree that a limit to 30 days would be a good idea. _Talk Islander 10:17, 1 October 2008 (UTC)
Support with limit. And yes, an un-nuke option would be handy there too. Garion96 (talk) 12:01, 1 October 2008 (UTC)
support With the understanding that Nuke will be used only for the most blatant of vandalism and not in other situations. JoshuaZ (talk) 17:21, 5 October 2008 (UTC)
— Werdna • talk 00:45, 11 October 2008 (UTC)
Qualified support: I approve of the addition of this extension so long as a) it is only used on blatant vandalism (e.g. Grawp) and b) that there be a corresponding "un-nuke" feature available to all admins at time of installation (even if this feature has to be JavaScript added to Sysop.js). We already have the potential to do this with scripts, so adding it to the software is relatively trivial. My concerns are largely because of how it should be used rather than because it should not be used. {{Nihiltres|talk|log}} 07:10, 19 October 2008 (UTC)
Support provided that there's a strict policy on its usage, as I'm sure there will be. ╟─Treasury§Tag►contribs─╢ 07:20, 19 October 2008 (UTC)
Support - We give admins delete rights, this is just saving them the button-mashing. An "undo" ought to be available, obviously. Pseudomonas_(talk) 10:06, 19 October 2008 (UTC)
Support if there will be a strict "don't use unless you have to" policy. NuclearWarfare ^{contact me}_{My work} 00:53, 20 October 2008 (UTC)
Support -- even if just to fight grawp and similar nasty things. Further justification: nuke as an "Admin" ability won't hurt anyone that doesn't already fear Admins. --Kuzetsa (talk) 22:56, 22 October 2008 (UTC)
Yet another powerful tool to add to the administrative toolbox - all in all, one that could greatly benefit the site. But use cautiously, or else the nuke could leave radiation behind. ;) Master&Expert (Talk) 05:43, 25 October 2008 (UTC)
Support Wizardman 20:30, 25 October 2008 (UTC)
Support—Tony (talk) 02:58, 28 October 2008 (UTC)
Support - simplifies the messy stuff. "Undo Nuke" would be a good safety measure, of course. --Ckatz^chat _spy 17:04, 28 October 2008 (UTC)
Support - this is just a more efficient way of doing something currently done with scripts. Undo would be nice, but if abused it can be undone by a script (and the responsible admin punished). This is a rare situation, so this is okay. Dcoetzee 01:14, 30 October 2008 (UTC)
Highly useful tool. – How do you turn this on (talk) 18:10, 3 November 2008 (UTC)

Oppose enabling

Pending un-nuker or equivalent. We must have balance in the force. -- Ned Scott 03:28, 26 September 2008 (UTC)
Far too open to accidental misuse (or even deliberate misuse, in the unthinkable event that we ever get an admin who is less than entirely scrupulous in his regard for policy). DuncanHill (talk) 23:05, 26 September 2008 (UTC)
Why are we letting a hypothetical situation that has never happened (to the best of my knowledge) stop us from effectively undoing situations which are all too common? EVula // talk // ☯ // 00:41, 30 September 2008 (UTC)
I hope that's sarcasm... --NE2 02:38, 6 October 2008 (UTC)
Echo the above. Considering the huge problem that it will produce when misused (and it will get misused, just as every other tool does), I'd rather not have it granted at all. Celarnor ^{Talk to me} 10:34, 6 October 2008 (UTC)
We make too many mistakes as it is. DGG (talk) 00:29, 30 September 2008 (UTC)
"Pending un-nuker or equivalent" as stated above -- Philcha (talk) 09:01, 6 October 2008 (UTC)
Too open to abuse, weak community oversight, difficult to undo, etc. Too many negatives, not enough benefit. Celarnor ^{Talk to me} 10:31, 6 October 2008 (UTC)
Per Ned, there needs equally automated way to revert this. — CharlotteWebb 11:02, 6 October 2008 (UTC)
Per DGG. Giggy (talk) 08:11, 14 October 2008 (UTC)
Same as Ned and DGG. If an Admin went rouge or his account was compromised Nuke would make it possible for him to kill the popular pages, the main page, the sandbox, and all he wants in a couple of minutes, which would crash wiki and take a lot more time to restore than Grawp's moves. If it's possible to undo the nuke with a couple of clicks I will support.--Yamanbaiia^{(free hugs!)} 11:01, 19 October 2008 (UTC)
No it wouldn't. It can only delete pages created in the last 30 days. It can't delete anything that can't already be deleted. I think there's some misunderstanding about what this actually does... Mr.Z-man 02:11, 23 October 2008 (UTC)
I didn't know that, mw:Extension:Nuke and this discussion is all I've seen about Nuke. I also didn't know that there already is a special script that allows admins to mass delete pages, which IMO makes of this an avoidable discussion. I don't oppose Nuke anymore.--Yamanbaiia^{(free hugs!)} 20:55, 23 October 2008 (UTC)

Questions

Since we've just had several issues with admins recently, including socks, and an arbcomm case, I'd like to know how easy it would be to reverse this. So, would these also be undeletable as a group? - jc37 17:24, 25 September 2008 (UTC)

It would be added as a right to the admin group. Seeing as admins already have a large number of rights at Special:ListGroupRights and this feature can be duplicated by external software, there is really no more risk to an rogue admin with this tool than there is to an admin without it. Just that non-rogue admins will have an an easier time cleaning up with it. MBisanz ^talk 18:04, 25 September 2008 (UTC)

Let me clarify: If User:nuker (an admin) "nuked" three pages with the tool, is there an "un-nuke" version of the tool for undeleting all three simultaneously (the way they were deleted), or would they have to be undeleted one at a time?

This becomes even more "fun" when hundreds of pages are "nuked". - jc37 18:09, 25 September 2008 (UTC)

Currently, no, Mediawiki doesn't have an Un-Nuker, but many admins do have scripts that will do the same thing. So basically we'd be replacing Script-based Deletion and Script-based Undeletion with Software-based Deletion and Script-based Undeletion. MBisanz ^talk 18:16, 25 September 2008 (UTC)

Mk. Thank you for the clarification. While (presuming the trend continues) this is likely to pass, I think I'll stay neutral. Thanks again. - jc37 18:23, 25 September 2008 (UTC)

I don't know why jc37 finds this disagreeable, but I consider the parallel with real-world nukes quite poetic. :-) Waltham, The Duke of 03:23, 26 September 2008 (UTC)

Well, since you asked : )

A key thing about the existing "tools" on the wikis is that there is something of a "balance". Any action can potentially be undone by another action of presumably equal effort.

Well, that "balance" has been gradually changing as new scripting tools and extensions and so on have been added. The speed at which someone can take an action is not necessarily the speed at which someone can undo the action any more.

And even Arbcomm has spoken out in several decisions regarding fait accompli (which is a fair amount of what such tools can potentially be). Imagine that someone is bold and moves every article of a certain topic to a name of their preference, even though those articles were a part of a larger topic, and follow a different convention, and consensus is that this should be reverted. Now unless one also has AWB (which should not be presumed), then undoing this could be quite a task. And this is just one example. I honestly have seen far more examples of "personal preference pushing" using tools than we really should see.

And so if we now allow admins to mass delete pages, but there isn't a counter for other admins to undo that action, well, I think you see my concern.

That said, I'm doing some backflips bending over backwards to WP:AGF, and am attempting to hope for the best. And I do understand the value of admins having the ability. Hence staying neutral. - jc37 09:40, 26 September 2008 (UTC)

I'm inclined to share Jc37's concerns. Also, what is the definition of "recent edits" here? And does it only delete pages that have only one contributor or will it also delete pages that others have edited? What, for example, would happen if a rogue admin attempted to nuke in short order the articles created by Rambot and other editors with large numbers of contributions? The available documentation is not very clear about such things. older ≠ wiser 14:30, 26 September 2008 (UTC)

If this proposal is adopted, it should only be given to admins who pass RfA after its introduction, as RfA's prior to that will not have examined the candidate's perceived trustworthiness with such a powerful tool. Also, how about watchlisting this? It is a proposal for a massive change to admins' tools. DuncanHill (talk) 23:17, 26 September 2008 (UTC)

No it isn't, its not giving them the ability to do anything that they can't already do. Right now they'd have to go to Special:Newpages, filter it to show articles by the user in question and delete those pages. Mr.Z-man 15:38, 27 September 2008 (UTC)

Recent edits means everything that's in the recent changes (database) table. Entries in the table are set to expire after 30 days. MER-C 13:46, 27 September 2008 (UTC)

Is that documented somewhere? There is only the barest mention of "recent edits" at mw:Extension:Nuke. I'd be less concerned over implementing this if the scope is limited to only the past 30 days. older ≠ wiser 22:49, 27 September 2008 (UTC)

No, not really. If you can understand (at least vaguely) PHP, in getNewPages(String username) (view source) - which returns the list of pages to be nuked - it does a query against the recentchanges table. The lifetime of table entries is governed by $wgRCMaxAge, which is set to 30 * 86400 seconds = 30 days. MER-C 06:55, 28 September 2008 (UTC)

Thanks. Any clarification about my other main concern -- does this nuke only pages where there was one editor, or does it not check whether there were other editors? older ≠ wiser 16:53, 28 September 2008 (UTC)

I don't know. Sorry. MER-C 09:59, 29 September 2008 (UTC)

I am not a code-person, but it is enabled at Commons, so maybe a an admin from there can explain that question. MBisanz ^talk 17:07, 29 September 2008 (UTC)

I think if the developers can create a rollback feature for nuke, then that would be great. An admin can view the "nuke" log, and click on the rollback button, much like rollbackers rollbacking a page from the page's history page because of vandalism, it would work and look the same way. It would be a great idea to the developers. Techman224^Talk 02:57, 11 October 2008 (UTC)

See bug 15942. MER-C 02:47, 12 October 2008 (UTC)

Hm. Looks like this is going to be enabled. Now, what's the name of that bot that created 20,000 pages again? *requests adminship* -- Gurch (talk) 21:02, 30 September 2008 (UTC)

If you think that would work, you don't understand how Nuke works. — Werdna • talk 22:49, 20 October 2008 (UTC)

Alternate proposal

Since we are (rightly) worried that no easy way to "undo" this mess exists and we have had admin issues in the past. Let's instead give the nuke rights to 'crats. They are, right now, the vice presidents of the wikipedia world (presiding over the senate and going to state funerals). This gives us an easy way to have the functionality but restrict it to a very trusted group of people. Protonk (talk) 18:19, 26 September 2008 (UTC)

But this would be a fundamental change in the nature of what a 'crat does. The basic maintenance of the 'pedia, in the form of deletions/protections/etc is the domain and duty of administrators, and tools to that effect should pertain to them. If we do not trust administrators as a whole with a tool that pertains to administrative actions, then we should just not have the tool to begin with, rather than delegating admin duties upward. Shereth 18:29, 26 September 2008 (UTC)

That's fair. Protonk (talk) 18:56, 26 September 2008 (UTC)

As a bureaucrat, I don't think the nuke tool should be put solely in our hands (obviously we would have it as admins); our job is to ascertain community consensus, and our duties tend to involve user right modifications (promoting admins and other 'crats, bot flags), with renaming being outside of that. Nuking vandals is totally outside what we were chosen for, and limiting its scope to a dozen or so editors would severely limit its abilities (in a bad way). EVula // talk // ☯ // 18:14, 30 September 2008 (UTC)

18:46, 4 October 2008 (UTC)

Give it to Oversighters? There's usually one or two online at any given time and they're responsible, easy-to-reach and concerned with protecting the site from user-based abuse. ╟─Treasury§Tag►contribs─╢ 17:30, 5 October 2008 (UTC)

That's a much, much better idea. I don't like the idea of well over a thousand people retroactively having a new ability this strong granted to them. Celarnor ^{Talk to me} 10:33, 6 October 2008 (UTC)

If it's not too late for an idea, might I suggest implementing a new access level (perhaps called the "nuclear club") that has access to the nuke. Admins could be promoted to nuke status by bureaucrats based on input from both the admins and the community at large. Horselover Frost (talk) 08:40, 11 October 2008 (UTC)

Wikipedia doesn't need more bureaucracy and levels. I do agree with giving this feature to Oversighters for the reasons given by User:TreasuryTag.--Yamanbaiia^{(free hugs!)} 11:05, 19 October 2008 (UTC)

I would similarly support a nuke version that was restricted to "trusted" persons, but absolutely no variant of the nuke system that would be usable by anyone. --Kuzetsa (talk) 23:00, 22 October 2008 (UTC)

Admins already have access to a variant of Special:MassDelete through a script. Nuke is really no more dangerous than that. Enabling it for all admins shouldn't bring any extra problems. PeterSymonds (talk) 23:05, 22 October 2008 (UTC)

Bureaucrats aren't necessarily trustworthy - I don't, for example, see why someone like User:Cprompt, who was promoted in 2004 and has not once used bureaucrat rights, should get Nuke over someone who passed RFA the other month unanimously. Oversighters is probably a good idea, but most oversighters aren't active vandal fighters - Nuke would primarily be used to delete spam pages that were created en-masse. – How do you turn this on (talk) 18:15, 3 November 2008 (UTC)

Giving it to oversighters makes sense to me as does giving to to 'crats, having as a general adding power it would need an additional restriction such as no page with edits by more than 5(?) loged in users, or maxing out at 100 articles, would stop mass deletions buy rogue admins --Nate 14 81 15:15, 6 November 2008 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WP:Write for dummies

The original goal of Wikipedia, I believe, was to have an article on everything people would want to know about. With the English project going on 3 million articles, I think that goal has more or less been accomplished. Our attention should now turn to making the encyclopedia useful.

Far too many articles, even those on elementary topics, are largely or completely incomprehensible to general readers. Some articles, instead of having the complicated stuff at the bottom (or in more-specific articles), have high-level gobbledegook sprinkled from top down. Some use wikilinks as an excuse not to define important terms, forcing readers to go on a wild goose chase across Wikipedia in a vain attempt understand the first article. Some incorporate complex mathematical formulas that are gibberish to 99% of people.

There used to be a wikiproject called General Audience, but it's inactive. I think the problem was just too enormous for a single wikiproject to solve.

I think what we need to do is push people to incorporate comprehensibility into every Wikipedia article. (That is not to say that every article must be comprehensible by a general audience; rather, every article should be understood by those likely to read it.)

I think one way to do this would be to require what I call a "dummies test" before any article can become a good article. A dummies test is the opposite of peer review. Instead of soliciting opinions from experts on the topic, a dummies test calls for the judgement of potential readers who are *not* well-versed in the topic. For example, a dummies test for Baseball would call for people who don't know the rules of baseball to see if they can understand the article. For some complex topics, the dummies might be undergraduate students in the same field rather than just anyone, but in all cases, the dummies should be people not familiar with the topic.

Dummies would provide feedback from the point of view of likely readers. After all, people usually turn to encyclopedias when the don't know something. If the dummies cannot understand the article, it doesn't become a good article.

It should be apparent that by "dummy," I don't mean a literally stupid person but rather a "dummy" in the spirit of the "... for Dummies" books, which explain topics from the very basics up, just like Wikipedia should.

Some other things we can do include allowing the "too technical" tag to be placed on the article itself rather than the talk page and improving the Wikipedia:Make technical articles accessible page. I would also like to resurrect the General Audience project with the priority of making every article whose topic is basic enough to be included in World Book comprehensible to the average person.

Personally, I think "Wikipedia articles are aimed at and should be written for people who aren't already familiar with the topic" should be considered an important part of the Wikipedia pillar "Wikipedia is an encyclopedia." "Write for dummies," therefore, should be an important policy and not simply a style guideline. -- Mwalcoff (talk) 01:19, 3 November 2008 (UTC)

I certainly don't think something so subjective should ever become policy. That is a stylistic issue, and is appropriately dealt with as a stylistic guideline (and it already is, at MTAA). If it becomes a policy, then there's quite a bit of risk that goes along with editing technical articles, since for the first time in Wikipedia's history, sanctions could be applied for stylistic purposes, which seems like unnecessary overkill.

I don't think that MTAA has much room to be improved, honestly, without damaging the content which it governs. In fields like mathematics, you just can't understand until you understand the fundamentals upon which it is based; for example, looking at some basics, you can't express derivatives accurately without assuming knowledge of limits, and you can't really understand integrals until you understand derivatives. This kind of chain gets pretty big for subjects in multivariable calculus, and there's only so much simplification you can perform without damaging the content, and I think that a lot of articles on logic and higher mathematics are already on the wrong side of that line, and any kind of "improvement" of the kind you describe almost always invariably damages the article, at least in my experience. Celarnor ^{Talk to me} 02:09, 3 November 2008 (UTC)

I like the general sentiment. I followed a link to gauge theory earlier and it looked to me like most of the article was written in Ancient Sumerian, even though I'm familiar with the basic gist of quantum theory, at least (I'm not too stupid, I swear!

). I'm not sure adding some more bureaucracy to the GA process is the best idea, though. GA is bad enough as it is in my view, and basically needs to be started over from scratch to fulfill its original intention of being a light-weight process for marking "good enough" articles. Bringing back the WikiProject might be a good idea, and we can always stand to recruit more expert editors. I also like the idea of writing introductions, like Introduction to genetics. —Slowking Man (talk) 03:36, 3 November 2008 (UTC)

Understanding gauge theory requires that you understand the basics of quantum mechanics as well as quantum field theory, Dynamical systems theory, quantum electrodynamics, and obviously calculus up to series and integrals.

In mathematics, I've heard a lot of undergraduates say that Wikipedia explained derivatives to them far better than the textbook; I've also heard the same about series and limits. I think it's able to do that because the article doesn't trip over itself trying to cater to people trying to read about derivatives who haven't the slightest clue what a limit is. There are ideas you just can't effectively communicate without prerequisite knowledge. Of course, a person who wanted to understand gauge theory and not just read some half-assed description of it, could easily read up on quantum mechanics, QED, QFT and DST, and then follow the logical progression. Celarnor ^{Talk to me} 12:56, 3 November 2008 (UTC)

Right, there are certainly some topics that should assume a degree of prerequisite knowledge. But there are a lot of articles that should not assume prerequisite knowledge that are still quite opaque. I would suggest that anything most people might encounter in daily life, or read about in the newspaper, should have a comprehensible Wikipedia article. Same thing with any topic you'd find in World Book. It's also worth keeping in mind that because Wikipedia is not paper, there's no need to try to cram upper-level information into an introductory article. The upper-level information can be put into a more-specific article linked to in the main article.

One of the problems may be that some editors don't understand that Wikipedia should be accessible; they see it simply as a compendium of their knowledge rather than as something to be useful. (This is part of the larger problem of editors editing for themselves rather than for readers.) For example, one editor of the article on e (mathematical constant), when challenged on the article's incomprehensibility, replied that if people don't understand it, they could go read a popular book on the topic and then come back and read the Wikipedia article! He didn't understand that as an encyclopedia, Wikipedia should be the first place you go to get the most basic information, and then you can go read a book if you wish to learn in more depth.

That's why I think we could include a few words in the first pillar of Wikipedia along the lines that Wikipedia is intended to provide information to people who aren't already familiar with a topic. You'd think this would be obvious, but apparently it needs to be spelled out.

I'm wary of the concept of "introduction" articles, although I think they're well-intended. In my opinion, the main article genetics should be the "introduction" article, with more-complex information included in subsidiary articles. -- Mwalcoff (talk) 13:48, 3 November 2008 (UTC)

I actually agree with the editor at the article on e. If something is incomprehensible to you, then you should probably read up on the prerequisites so you can fully understand it. Dumbing it down would be a disservice to our readers; If we do as you like, then the article on e would become either ridiculously huge as it tries to cater to every level of reader, or become something as completely useless as "e is a mathematical constant roughly equivalent to 2.71". For e to really mean anything to you, you have to understand how it was arrived at and what it really means (which means you need to understand limits). Celarnor ^{Talk to me} 17:23, 3 November 2008 (UTC)

I can see what the editor is saying about e article. Perhaps we should have some sort of page header like

{{User:Gnevin/sandbox1|read=Limits and Pi}}

Gnevin (talk) 21:48, 3 November 2008 (UTC)

I like that, but I think it could be a bit smaller. 21:26, 3 November 2008 (UTC)

To reply to your other point(s), I don't agree that Wikipedia should be the first place to go to get basic information. If you want everything simplified, there's another project with that in mind; it's called Simple Wikipedia.

I think you're a little disoriented about the way in which Wikipedia is organized; we do provide information to people who aren't familiar with a topic. You can easily learn what antiderivatives are and how they work by reading Wikipedia. You're just not going to find that all out by reading the article on integrals, and rightly so; for someone with no history in calculus, introducing them would require us to write about derivatives, tangent lines, limits, functions, all the way back to basic algebra, all in that one article. That's inane. We can and do provide information on the topic; you can read all about the requisite mathematical knowledge and skills at tangent line, limit, function, etc. There's no need to extend definitions given in other articles all over the project like that just for the sake of it.

The alternative solution, is of course, to present information in a way that someone doesn't need to know about the requisite information. Of course, then we lose accuracy, precision and conciness; describing things in technical terms is the best way to achieve those things. If valuing accuracy, precision and conciseness (e.g, describing derivatives for what they are, "the slope of a tangent line at a single point" vs "the value of the change in the y axis divided by the change in the x axis a line drawn against another line in such a way that it only touches one part of the line") requires that we try to point readers to the material that they need to understand first, then fine. I don't have a problem with that; that's how people learn anyway.

Ultimately, I think this kind of things comes down to whether you want to cater to a reader who wants to understand something, or a reader who wants a quick summary of things; as a member of the former group, I hate to see articles dumbed down to the point where its next to useless with the point of making it accessible to someone who just wants a quick definition.

I think the "introduction to x" articles are a good compromise; they don't cause the damage associated with dumbing down to the main article, and they provide a place where requisite material can be summarized and simplified for someone who is only interested in a quick definition or summary and isn't really interested in the material. And it makes sense; if you just want an introduction to genetics, and aren't looking to really understand it, that would be the place to go. The answer certainly isn't dumbing down the main article on genetics to that level. Celarnor ^{Talk to me} 21:31, 3 November 2008 (UTC)

Such as

{{User:Gnevin/sandbox2|read=Limits and Pi}}

Gnevin (talk) 21:48, 3 November 2008 (UTC)

As an example, the 'e' article would not be dumbed down by adding extra sections explaining it to a less technical audience. Everyone with sixth grade math ought to be able to get the general concept of e and its importance, to decide whether they want to learn more about its technical meaning, by learning Newton's calculus. 'e' is a much simpler thing than the approach of the article suggests.

Discouraging a lightweight explanation like this is as strange as requiring that a reader fully understand medieval canon and common law before reading the basics of Henry VIII's biography.

The alternative is the reader with sixth grade math comes away with the impression that 'e' is not important at all; that it is not a critical part of the jigsaws of maths, engineering, social science, and human history, but instead only of interest to mathematicians that like tangents; and gains no motivation to go learn more about the underlying principles. A tragic result for the mission of an encyclopedia.

I don't think the GA criteria are a place to watch for this, as GA is too heavy for its purpose as it is. I am not sure why parts of the math and physics topics in Wikipedia have drifted away from accessibility, as I have not noticed this trend in history, religion, economics, medicine, zoology or many other areas of the encyclopedia I have explored. Maybe there are clues there.

--Hroðulf (or Hrothulf) (Talk) 23:54, 3 November 2008 (UTC)

We used to have what were called prerequisite boxes that did exactly what Gnevin suggests above. For some reason, they never caught on.

I think it is possible to be both complete and comprehensible, especially considering we are not paper. Your garden-variety general encyclopedia like World Book and Americana (if they still make that) manages to explain things in a simple way without compromising on accuracy. Then you've got Britannica, which is written for a more-educated audience and goes into a bit more depth, and finally you have encyclopedias on a particular subject, which assume the most prerequisite knowledge. The great thing about Wikipedia is we can be World Book and Britannica and "The Encyclopedia of Calculus" all in one place because we're not paper! I suggested some time ago that articles be written for the least knowledgeable likely audience. For many articles, this would be the general reader; for others, it would be undergraduates in a particular field or perhaps only career specialists in a field. -- Mwalcoff (talk) 00:58, 4 November 2008 (UTC)

Mwalcoff, did you mean Template:Prerequisites? If so, I like the idea of listing prerequisites for complex articles. As mentioned above, it reduces the need to try to cram everything into one article, while being more direct than a standard text link. It is also similar in concept to what people are used to with, say, university courses. Thoughts? --Ckatz^chat _spy 01:15, 4 November 2008 (UTC)

Yeah, that's what I meant. -- Mwalcoff (talk) 02:22, 4 November 2008 (UTC)

There is already a tag indicating that an article may have insufficient context for those unfamiliar with a subject, as has been given to the article on transpersonal business studies. Perhaps another tag could be created for those articles which contain too much jargon? In some ways, lets be thankful for those articles that are written in a technical style as opposed to a journalistic, anecdotal, magazine-like or personal style that would be highly inappropriate for printed encyclopaedias. ACEOREVIVED (talk) 22:20, 4 November 2008 (UTC)

What's wrong with using the introduction as laymen-accessible? This is currently the case at pi, and e. Since the majority of that kind of article is useless to someone who doesn't understand the base mathematical concepts, why not just do that? Celarnor ^{Talk to me} 23:04, 4 November 2008 (UTC)

I think before we determine what actions will help make articles more comprehensible, we have to determine what, exactly, is Wikipedia's policy on comprehensibility. I'm going to move this discussion to the policy part of the Village Pump. -- Mwalcoff (talk) 05:42, 7 November 2008 (UTC)

It is already our policy that articles should not require pre-requisite knowledge. Where this has not been followed then articles should fail GA/FA and it would be good to test for this explicitly, as suggested. Maths articles are the worst offenders and my impression is that this is due to them being owned by professional mathematicians who are used to and prefer a Bourbaki style of elegant purity and precision. I see a similar process taking place in medical articles as professionals move in and transform articles to use their preferred jargon such as Myocardial infarction rather than Heart attack. Since our role is to be the encyclopedia that anyone can edit, we should push back such professional elitism and the for Dummies theme is a good, existing slogan for this. Colonel Warden (talk) 13:21, 7 November 2008 (UTC)

- It's impractical to declare "no article should require prerequisite knowledge", when we know perfectly well that many topics do require a significant amount of background knowledge. This applies not only to mathematics, but to all the sciences, and to music, and to many other fields. We don't expect every article that mentions a key (music) to include a definition of what a key is, nor do we expect that every article that mentions a mathematical term to include a definition of that term. Each article should be written for a reader who almost understands the prerequisite material, to ensure the largest possible readership.
  Although many complaints about articles being poorly written or too technical are valid, others are simply the result of readers expecting all articles to be instantly accessible with no work on the part of the reader. That is an impossible standard. An ironic aspect of complaints about accessibility is that for many truly complex topics, such as spectral sequence, WP is far more accessible to an undergraduate student than the graduate-level texts that actually discuss the topic. No other encyclopedia includes material at this level. — Carl (CBM · talk) 13:31, 7 November 2008 (UTC)

I agree that impractical to declare "no article should require prerequisite knowledge". We need to define the target level of assumed prior knowledge. In the similar discussion at Wikipedia:Village_pump_(policy)#Comprehensibility_of_articles I suggested the default target level should be "averagely-literate 12-year-old", and that the budern of proof should be on editirs and reviwers to show that more complex or technical language or presentation was necessary.

e (mathematical constant) is a good example of a bad approach - I was taught about e at school, and none of us (including 2 who are now maths professors) would have understood e (mathematical constant) at age 15. --Philcha (talk) 15:16, 7 November 2008 (UTC)

Turn off display of in-line cites by default

Visual clutter in WP articles by bluelinks and redlinks is greatly exacerbated by in-line cites. As I understand it, short of glaringly obvious statements (the earth orbits the sun), each and every assertion of fact must be referenced with an in-line cite, which appears as a superscript number after the statement that links to its footnote.

It is physically painful to read a text riddled with in-line cites. No paper encyclopedia and, for that matter, no book that I have ever seen employs such a level of footnoting.

On the other hand I understand the need for the in-line cites, as they are a partial safeguard against the insertion of misinformation by anonymous or pseudonymous editors.

Hence my proposal to turn off the display of in-line cites in Wikipedia articles by default, to be complemented by the placement of a "toggle switch" near the top of a page that allows the readers to turn on display with a single mouse click.--Goodmorningworld (talk) 14:15, 3 November 2008 (UTC)

I like the idea of being able to disable in-line citations (especially for printing, etc), but I don't think it should be disabled by default. Not everyone may realize how to turn it on and off, and it would be difficult for inexperienced users to be able to verify content and what not. Celarnor ^{Talk to me} 14:52, 3 November 2008 (UTC)

I'm emphatically against this proposal. If this hurts you physically, you might want to see a shrink for your psychosomatic problem. Given how we have to fight for cites, and especially in-line cites, this proposal is a very bad idea. - Denimadept (talk) 14:57, 3 November 2008 (UTC)

Agreed. Citations are too important to hide away behind an opt-in system. --Tango (talk) 15:07, 3 November 2008 (UTC)

Strongly against, even as an option. Why in the world are the authors required to annotate each meaningful statement? you may find it's useless, but seeing a long reference section without anchors in the text is even larger nonsense. Now consider some wisehead accidentally switches references off and starts inserting {{unreferenced}}s or even {{prod}}s for the lack of citations... NVO (talk) 10:08, 4 November 2008 (UTC)

You could reduced the visual impact by adding some code to your user style sheet (at User:Goodmorningworld/monobook.css). For example,

sup.reference a { display:none }

Should hide them completely.

If you use a modern browser, (i.e. not MS Internet Explorer), you could add the following, which will render citation references less conspicuous until you mouse over a paragraph, allowing you to still find and click them. To hide them completely, change “#CCC” to “transparent”.)

/* hide inline reference citations */
p sup.reference a { color: #CCC; }
p:hover sup.reference a { color: #002BB8; }
p:hover sup.reference a:visited { color: #5A3696; }
p:hover sup.reference a:active { color: #FAA700; }

Let me know if you have any problems. —Michael Z. 2008-11-03 15:19 z

Thank you, I will try it later and report back to you. However, even if it works it would be a "selfish" solution because it would help only me and whoever happens to be reading here. So I maintain my proposal as before. (A possible compromise that I have not thought about enough yet might be to add your code as an option to the "Gadgets" tab in "my preferences".)--Goodmorningworld (talk) 15:42, 3 November 2008 (UTC)

By default makes little sense, given the stringency of WP:Verifiability and WP:Reliable sources. As a gadget that could turn it off, I don't think this request is that necessary either, given that you can indeed modify your style sheets... I'm curious as to whether or not a javascript version would allow for more per-article control than the css version does. --Izno (talk) 17:10, 3 November 2008 (UTC)

I oppose this suggestion in the strongest possible terms, per the reasons already cited. Wow.. this is just a spectacularly bad idea. Sorry, Goodmorningworld, but there's just nothing good about implementing this for all users. [ roux ] [x] 17:16, 3 November 2008 (UTC)

Footnotes are an accepted part of any respectable academic writing, and for good reason. While I wouldn't oppose giving those readers who don't want them enabled the option of hiding them (however that might be accomplished, technically speaking), notes should absolutely default to 'on'. TenOfAllTrades(talk) 22:19, 3 November 2008 (UTC)

I agree with all of that, but keep in mind that multiple footnote references in a row, each surrounded by square brackets, wouldn't be accepted in any academic writing, or indeed in any print publication at all. The presence of footnotes is acceptable, but the current implementation doesn't come close to a respectable typographic standard. —Michael Z. 2008-11-03 22:45 z

I don't actually think our format is totally out there. Properly we ought to be comparing ourselves to the online versions of academic journals. Looking at the HTML versions of major journals reveals a number of different styles for references. Some of the 'big guns' among science journals are Science, Nature, Cell, and PNAS.

Science and PNAS use full-height numbers, enclosed in round brackets: Lorem ipsum (2) dolor sic amet (3,4).
Nature uses superscripted numbers (unbracketed), but with a very wide font to aid clickability: Lorem ipsum^{2 1} dolor sic amet^2 2, 2 3.
Cell uses author and date in round brackets, with square brackets demarcating multiple references: Lorem ipsum (Smith and Wesson, 2005) dolor sic amet ([Jones et al., 2006], [Simpson, 2007]).

From what I've seen, most online journals follow one of those three formats. Our style isn't totally insane compared to the existing web standards, and it isn't markedly more intrusive. I'd be happy to see Nature-style wide fonts instead of the square brackets, but as long as we're using superscripted numbers we need some way to make the links easily clickable. TenOfAllTrades(talk) 23:24, 3 November 2008 (UTC)

Do these all use links for the citation references, or just text? I'd be curious to learn what humanities journals use, too. —Michael Z. 2008-11-04 16:12 z

Yes, all the notes are hyperlink anchors to the references list at the bottom of the page. TenOfAllTrades(talk) 17:00, 4 November 2008 (UTC)

Most interesting, Tenofalltrades, thank you for that information. I went and looked at all four of these online journals. Science and Nature, unfortunately, do not offer any free articles online, but Cell and PNAS do. Both of the latter two are nicely done and eminently readable, in my opinion. However, the density of in-line cites in them is much less than what I am told is required for WP articles. There is a reason for that: The people publishing in scientific journals generally are PhDs, they are publishing under their names (not pseudonyms), they are putting their reputations on the line, and the articles are peer-reviewed. Additionally, their readership can be expected already to know much of the information that is not specifically referenced.

Now, I am not arguing for doing away with the requirement for in-line cites in WP articles. It is essential as a partial (but not sufficient) safeguard for ensuring compliance with the encyclopedia's rules. I've said this before but it bears repeating.

Looking at my own article Bethmann family, however, I am struck by how ugly it is made by the zillion in-line cites cluttering it up; and this is after receiving advice on how to make it look better.

In books, footnoting systems range from same-page, where a superscript number points to a footnote at the bottom of the page, to end-of-book note "collections". Then there are the "almost-no-footnotes-at-all" authors, like Niall Ferguson, who provides a footnote once in a blue moon and expects you to take his word for the rest of the information. My favorite system is not to have any cites in the text at all, but with endnotes appearing at the back of the book like so:

Page 173: "...when Mozart refused, Salieri confided to his tubist that he would like to see the little upstart dead..." Memoirs of Josef von Oompah, p. 24, Vienna 1821. Page 175: "...

and so on. Alright, it is now time for me to check out the software solutions recommended by people in this thread.--Goodmorningworld (talk) 19:58, 4 November 2008 (UTC)

Thanks for the info. (Endnotes are found at the end of a section or book, by the way, as opposed to footnotes on each page.) The Ferguson style looks attractive; who is the publisher? Another little-used but very slick style is sidenotes, where each note hangs in the margin next to the main text, with or without a marker. Seen in Bringhurst (book)—you may be able to see examples in Amazon's in-book search.[1] And of course there is Harvard style, with a text reference in round brackets.

Yeah, our requirement is to footnote more thoroughly than a professional, peer-reviewed publication. Yet, because we aim at a broad audience rather than academics, the footnotes are going to be used less, on average. So they should be made less visually prominent than they are in a printed publication, or online academic article (yet still easy to access). —Michael Z. 2008-11-04 23:21 z

To be clearer, the system of keeping the text of the book pristine and completely free of cites while collecting "endnotes" at the back of the book in the form of repeating a snippet of text from the book (and the page number on which it appears) followed by the reference, is not used by Ferguson but in books such as "Genius" by James Gleick. Ferguson is the one who uses a footnote only once in a blue moon, see his book "War of the World". I am just feeling discouraged right now at how an article that I spent so much time on will look to an unsuspecting reader; if I would not want to read the article due to the clutter from in-line cites, then how can I expect others to?--Goodmorningworld (talk) 15:44, 5 November 2008 (UTC)

I could see making the reference links bigger/full-height, so older people can see and click on them w/o having a nervous breakdown. - Denimadept (talk) 23:52, 3 November 2008 (UTC)

That can be easily done with personalized CSS. So can hiding the footnote links entirely. I expect de-bracketing them can be also. Perhaps there should be gadgets for some of these options? Algebraist 10:38, 4 November 2008 (UTC)

It just occurred to me that many older people with sight issues may not know CSS coding methods. :-) - Denimadept (talk) 17:52, 5 November 2008 (UTC)

Which is why I suggested making a gadget. Algebraist 11:41, 6 November 2008 (UTC)

Comment I copied Michael's CSS for making cites faint and created this userscript for Greasemonkey users to experiment with. (BTW I'm a script-beginner) Tested on en: and fr: wikipedias' Modern and Monobook skins. Users can toggle the "hide" via Greasemonkey and reloading the current wikipedia article. This shows before and after snapshots. I myself prefer the cites to be always visible, but I am interested in any gadgets that can improve their appearance and provide a choice to users. -84user (talk) 15:57, 4 November 2008 (UTC)

The problem with very faint or invisible cites is that they leave gaps in the text, especially when there are several in a row. These are arguably as intrusive as the original links. Display:none solves this, but then the text rewraps if they are toggled on, so that's not a great solution either.

Unfortunately, the link text created by Cite.php[2] is just the bracketed number, so there's no way to use simple CSS to hide or change the brackets. A valuable feature request would be to generate the brackets with CSS or add a span to pick them out, but there's no evidence that there is any active development going on. —Michael Z. 2008-11-04 16:12 z

I tried adding classes to the brackets at MediaWiki:Cite reference link; it wasn't feasible (bumped the page size up by 20% in some cases!). Happy‑melon 17:22, 4 November 2008 (UTC)

Ooh, I didn't know this was an available feature. There should be some possibility to make this work.

It's certainly not necessary to clutter the HTML with yet another class. Just a span or other element will do, and then CSS can select it using something like sup.reference a span {}. —Michael Z. 2008-11-04 19:52 z

Got it: to completely hide the brackets, you can now use sup.reference a span { display: none; } (caveat: testing in progress). —Michael Z. 2008-11-04 19:59 z

Not to be annoying, but this adds a lot of HTML... What about sup.reference {display:none;} followed by sup.reference a {display:inline !important;} instead ? I think that would do the same, and you would not require the span's to be added to the references. Not tested, but I see no reason why it should not work. --TheDJ (talk • contribs) 12:04, 6 November 2008 (UTC)

Doesn't work, unfortunately - the brackets are part of the link title so can't be separated like that. I also oppose the addition of this HTML; there is too little to be gained from bulking up the rendered output so hugely. Happy‑melon 12:47, 6 November 2008 (UTC)

Let me clarify:

I have already added a plain span surrounding each bracket in a reference citation. This doesn't add much HTML (Wikipedia's HTML is already quite heavy, and I can probably think of a dozen ways to remove much more code, which is actually redundant, than this adds). The article Bethmann family gets boosted from 98,239 bytes to 101,229 B (by 2,990 B, or 3.0%). If this is a problem, then I can cut the increase in half by placing the span around the content, and making the CSS slightly more complex.

The methods of hiding or modifying the citation display will now add no additional HTML, since they go into your user style sheet (e.g., mine is at User:Mzajac/monobook.css).

sup.reference { display: none; } will hide the references completely
sup.reference a span { display: none; } will hide the brackets completely
In my own style sheet I have implemented code which makes the references look just like printed book references in black. Multiple consecutive references are separated by commas (still buggy). To help find them, the references get underlines when you mouse over a paragraph. (Tested in Safari, Firefox, Opera; won't work on MSIE)

—Michael Z. 2008-11-06 16:39 z

More comment: I found there already exists userstyle "Wikipedia - hide reference links" for Stylish users on Firefox. For balance, inspired by Denimadept's comment above, I created the style "Wikipedia - bolder inline cites". Since discovering it, I recommend using Stylish instead of Greasemonkey for styles. -84user (talk) 19:31, 4 November 2008 (UTC)

You can already use the wikEd editor gadget to fade inline citations (check wikEd in your Wikipedia Preferences under Gadgets and click the button). Cacycle (talk) 00:17, 5 November 2008 (UTC)

Solving the wrong problem?

I had a look at Bethmann family, one of the articles mentioned above as having disruptively intrusive footnotes. I agree, particularly for readers not used to academic writing, the flow and appearance of the text are interrupted by wikilinks and footnotes. However, this may not be a problem of over-citation or of poor footnote format. One wonders if, perhaps, by trying to develop technical tools to make footnote links less visible we aren't just papering over less-than-ideal editing and style choices. Take this paragraph from Bethmann family:

Konrad left his hometown for an apprenticeship in Eisleben. ^[16] He served as Münzwardein in Dömitz (Mecklenburg),^[17] then was appointed in 1683 Münzmeister to the Princess of Nassau-Holzappel in Cramberg on the Lahn river,^[18] followed by his appointment in 1687 as Münzmeister with the German Order of Knights in Friedberg, and in 1692 as Münzmeister for the Archbishopric and Electorate of Mainz^[19] in Aschaffenburg^[2]^[7].

It's chock full of factual information, but surely we must be able to present it better. The paragraph is spliced together with commas. Nearly every title and location is wikilinked. Every fact has a footnote link.

What I see is essentially a bulleted list or timeline that's missing its line breaks. Compare:

(Undated) Started appreticeship in Eisleben ^[16]
(Undated) Served as Münzwardein in Dömitz (Mecklenburg)^[17]
1683: Appointed Münzmeister to the Princess of Nassau-Holzappel in Cramberg on the Lahn river^[18]
1687: Appointed Münzmeister with the German Order of Knights in Friedberg^[19]
1692: Appointed Münzmeister for the Archbishopric and Electorate of Mainz in Aschaffenburg^[2]^[7]^[19].

Identical information with nearly identical words, but now it's clear that it's an ordered list of events and milestones. The footnote links don't distract, because they're all at the end of lines and out of the way (but still clearly linked to their text). Whitespace, bullets, and bolding make obvious the separations between events and their order in time.

I'm not saying that the bulleted-list method is the only way to present this information, nor even that it's the best. (Nor even that it's close to the best....) I am saying that the problem isn't necessarily always with the footnote links. In the passage above, the footnote links add visual clutter, but they're definitely not the only problem (and probably not the major problem).

Without getting into wholesale rewriting of articles, flow and appearance can often be improved by simple steps like modest trimming of wikilinks and consolidation of footnote links. Wherever a footnote appears inside a sentence, consider whether it would be harmful to move it to the end of the sentence. Give thought to moving it all the way to the end of the paragraph. If a footnote appears right at a comma, check to make sure that it's not flagging a run-on sentence. If the links are coming fast and furious, it may signal that additional prose is necessary. Don't be afraid to employ paragraph breaks.

Here's one last stab at the paragraph. I don't know anything about the subject, so I don't dare try to extensively rewrite or expand.

Konrad left his hometown for an apprenticeship in Eisleben; he later served as Münzwardein in Dömitz (Mecklenburg)^[16]^[17]. In 1683, he was appointed Münzmeister to the Princess of Nassau-Holzappel in Cramberg on the Lahn river^[18]. He became Münzmeister with the German Order of Knights in Friedberg in 1687. Finally, in 1692 he was elevated to Münzmeister for the Archbishopric and Electorate of Mainz in Aschaffenburg^[2]^[7]^[19].

It could still certainly stand some improvement, but at this point I don't think that the footnote links are a significant stylistic problem. I suspect that many situations where the footnote syle is perceived to be a problem could be remedied by judicious editing. This is not to say that the technically-minded shouldn't offer our readers the option to view our material differently, but rather a caution to our editors that we need to write well, and carefully. TenOfAllTrades(talk) 15:33, 7 November 2008 (UTC)

All good points. Another thing we could do to reduce the visual impact is consolidate strings of consecutive notes into a single note, which would reduce the gap-toothed look of running text, and shorten the list of notes. I don't believe any print publication packs multiple reference numbers together the way we do. —Michael Z. 2008-11-07 16:19 z

Food for thought, thanks. If you look at footnote ^[18] in the article, it already consolidates three separate references into a single footnote. Moving the footnote link to the end of the sentence: I may be misinformed, but I thought that you put a footnote where it relates to the item of information. Hence I put footnote ^[16] right after Eisleben and not at the end of the sentence, because the note corroborates only that item of information and not the entire sentence.

Bulleted lists and timelines, I'm not sure they are considered good writing.

But I agree that some problems could be ameliorated by judicious editing and reformating.--Goodmorningworld (talk) 17:04, 7 November 2008 (UTC)

My point with the bulleted list was not necessarily that a bulleted list would be preferable to prose in this instance, but rather that this paragraph really was just a bulleted list masquerading as prose. I agree that a bulleted CV isn't necessarily the format that one wants for a biographical article, but we shouldn't pretend that removing the bullets and putting the same text into a paragraph is good writing either. (Mind you, we also should be aware that we enjoy a certain degree of extra flexibility working in an electronic medium, and we can be open to judicious use of non-prose elements if it helps us to present material more clearly and effectively.)

Footnote placement is a matter of judgement, and I agree that care should be taken when moving a note. Nevertheless, I don't think it's unreasonable to write something along the lines of "In 1978, Bob moved to New York, where he worked as a greengrocer.^[1]^[2]", where note 1 gives the date that Bob moved to New York, and note 2 provides information about his occupation. (If a footnote doesn't make sense at the end of a sentence, sometimes it may indicate that the sentence is trying to accomplish too much.) Footnotes should be proximate to the statements that they support, but whether or not they must be at the exact word in the sentence will depend on context. TenOfAllTrades(talk) 17:36, 7 November 2008 (UTC)

(ec)All other published reference works follow a progressive writing and editing process that invariably culminates with little style tweaks like these. That's not possible in a dynamic project like Wikipedia where no article is ever "finished" and so no 'final style tweaks' are possible. In particular, combining references in the wikitext is an unbelievably stupid thing to do: what happens if when the article is edited and reorganised, moving phrases apart and adding or removing both content and sources. Facts must be kept with their references in order to facilitate this continual improvement process, and references must be kept as discrete as the facts they corroborate. We will never be in a position where we can place style over content (nor should we). By no means am I saying that the output references need necessarily render in the discrete, overt fashion that they do now - I am strongly in favour of some modification to the cite system that will detect 'blocks' of references and render them in one unified reference section (so all the reference links contained within just one set of brackets). That, I suspect, will involve a change to the underlying MediaWiki extension, although it might be possible with CSS3 and/or JS. But whatever methods we use for applying pretty rendering onto the underlying code, that code must remain focused primarily on easily maintaining the verifiability of the content while facilitating easy modification, reorganisation, and alteration. Happy‑melon 17:48, 7 November 2008 (UTC)

ROBLOX

I seriously think that a page named ROBLOX should be created in the vast realms in Wikipedia because there is NO OTHER PAGE RELATING TO IT(except for gaming review sites) that includes information in the game and the wiki (ROBLOX Wiki) has very little information and cannot be edited.So please create it. NHL09addict (talk) 03:54, 8 November 2008 (UTC)

Wikipedia content is created by its users who are interested enough in a subject to write an article on it. You are just such a user, interested in the subject and with the technical ability to create an article. Please see Wikipedia:Your first article. Alternatively, you can go to Wikipedia:WikiProject Video games/Requests and submit a request for creation, though there's no guarantee that anyone will take up the task.--Fuhghettaboutit (talk) 11:35, 8 November 2008 (UTC)

See Wikipedia:Articles for deletion/Roblox. It was decided back in May that there were no reliable sources to create an article from. If you can find some, then create an article in your own User space and once you feel it's ready for primetime, list it at WP:DRV. Little Red Riding Hoodtalk 01:53, 9 November 2008 (UTC)

Real-time vs. turn-based gameplay deletion

So I think that Real-time vs. turn-based gameplay should be deleted as soon as possible. The entire article is filled with opinions (Turn-based games are difficult to master, Sitting around and waiting for turns to end is boring, etc...). Yes it has many sources, but there is no point of having a source of an opinion. And this article just doesn't fit in wikipedia, there already exists a real time games and a turn-based games article so why should you compare these two in one article?--Megaman en m (talk) 00:11, 9 November 2008 (UTC)

You should list the article at WP:AfD if you think it should be deleted. -- Imperator3733 (talk) 00:16, 9 November 2008 (UTC)

Alright thanks, I couldn't find my way around.--Megaman en m (talk) 00:16, 9 November 2008 (UTC)

Towards New proposal policy

Many community members strongly disagree with the current policy. We are proposing a modification of languages criteria to star a wikimedia project, with a community draft]. feel free to contribute with your opinion:

thak you, very much. — Crazymadlover—Preceding undated comment was added at 20:56, 25 September 2008 (UTC).

Scale sizes on images as addition to resolution.

From Freenode/#wikipedia <KordeX> hello, i have a suggestion for image handling: the scale automaticly to be calculated from size like 16:9 and so on. It would display on page-page just next to HeightxWidth This is a very easy patch for the base. (Mikko Kortelainen)—Preceding unsigned comment added by 87.93.143.223 (talk) 22:38, 2 October 2008 (UTC)

Comments in fundraiser banner

I don't know if the local enwiki here can change this, but I really liked last year's fundraising banner because it included comments from donors. As you can see here, when someone makes a donation online they can leave a comment about Wikipedia/media. Last year's fundraising banner had a script so a random comment would be there every time you refreshed the page. I think this helped attract donors, and if possible we should change the banner to include this again. Reywas92 ^Talk 02:29, 10 November 2008 (UTC)

That would definitely be an improvement over that ridiculously huge thing that we have now. Celarnor ^{Talk to me} 18:05, 10 November 2008 (UTC)

I also liked last year's banner better. Does anyone know why they made this year's banner so ridiculously big? -- Imperator3733 (talk) 23:08, 10 November 2008 (UTC)

Basic policy additions

Is it possible to add more functionally to Wikipedia. Perhaps there are occasions where many people disagree on an event and wikipedia seems to take the party line. An example of this is the TWA 800 crash.

Obviously I disagree with your policy of accepting the government's position in the TWA 800 crash but rather than argue that point I choose to argue to set up a process where discussions on subjects that inspire differing opinions could be made. Presently you offer an alternative theories page but this becomes a posting of alternative thought. What we need is a active listing of isolated facts with supporting documentation which may lead in new directions.

Arydberg (talk) 21:23, 5 November 2008 (UTC)

WP:NPOV would be your answer, and specifically, WP:NPOV#Undue weight. We take the "main party line" because that is both what is the most accepted and the most verifiable by reliable sources. What you are suggesting is that we take the facts and use those to jump to conclusions that we ourselves come to, which breaks yet another policy: that of WP:no original research. If you would like to specifically address any one of those policies, then visit their talk pages and start a discussion. I forewarn you, however: Your requests are unlikely to be fulfilled. --Izno (talk) 21:32, 5 November 2008 (UTC)

Yup. Also, Wikipedia is not a few of the things such an approach would imply, especially, not a soapbox or discussion forum. Our policy is not “accepting the government's position.” It is to reflect a neutral point of view. If a minority opinion is significant to the subject, then it should probably be mentioned, and identified as such.

What Arydberg is proposing is a radical departure from the Five Pillars, and probably won't get much traction. —Michael Z. 2008-11-05 22:02 z

Wikipedia used to allow fringe theories, but we only pay them lip service now (see FRINGE); this doesn't seem to be exactly what you're thinking about, though. What you're proposing is more like a forum for original research, which isn't part of the goal of an encyclopedia, and as such, isn't something that we're likely to do. Celarnor ^{Talk to me} 22:06, 5 November 2008 (UTC)

You have read the linked article TWA Flight 800 alternative theories? There are eight theories listed here with a critical analysis of each. --—— Gadget850 (Ed) ^talk - 16:09, 12 November 2008 (UTC)

Proposal for a new tab on talk pages

I was wondering if it would be possible to add a new tab (like the "project page", "discussion", "history", "edit this page", etc.) on the talk page for articles for a list of potential sources that could be included in the article. In the past, I have posted random news articles I come across on the article's talk page since I didn't have have time to include it in the article myself. Often times, it is archived and no one knows it exists since they are unlikely to look in the archives. I have also seen numerous other editors list potential sources that are located in various parts of the talk page (in the archives and under separate headings). However, if we had a separate tab within the talk page for "sources to be used in the article" (a better name can be found no doubt), editors can post reliable sources they think should be incorporated into the article in one uniform place. There would be no need for discussions on this page (that can be resumed at the regular talk page), as it would just be a list of potential sources from web sites, books, journals, videos, etc. Editors then could quickly go to this tab and find the sources to include in the article. As sources are incorporated into the article, they could be checked off to alert other editors of their inclusion. In addition, it would provide a great framework to start with if somebody stumbles on the article and wants to improve it.

I'm not sure how much coding this would take or the burden it would place on the servers, but I just wanted to propose it now rather than down the line as the encyclopedia continues to grow. The tab could be stand alone like the "history"/"edit this page", or be a separate tab within the talk page (that could be accessed by something like Talk:Articlename/Sources). I don't think this will complicate the page, and even if a new tab couldn't be created, perhaps somebody can think of another way to list all potential sources rather than under random, separated headings. As we continue to stress including reliable sources, a central area that lists a large number of potential sources would be beneficial in expanding and sourcing our current articles. --Nehrams2020 (talk) 23:50, 10 November 2008 (UTC)

Or you could just create a Further reading section. Uncle G (talk) 15:53, 11 November 2008 (UTC)

You can include this in a to-do list on the talk page. --—— Gadget850 (Ed) ^talk - 15:57, 12 November 2008 (UTC)

It's not the worst idea I ever heard, but I'm against it because I'm against adding bells and whistles. I think that only really important things should be institutionalised. You need an "edit this page" tab, and links to the "discussion" and "history" pages are pretty important too. This feature is not on that level of importance. New editors are faced with enough junk already. We're trying to draw people in, not baffle them. November 2008, La la ooh.

Obtrusive banner

I propose to change the current fund raiser banner so that after clicking the hide link it would change into a text-only message. People already donating their spare time to improve this site and to keep this place running are getting increasingly angry because of that obtrusive not-hideable banner. Many editors see it as an insensitive lack of appreciation of their hard work. Please see Wikipedia:Gadget/proposals| to get a feeling about the frustration! However, instead of making points by putting banner hiding gadgets online without discussion and adding user interface system messages I would like to see a centralized and open discussion here. Cacycle (talk) 15:30, 7 November 2008 (UTC)

It isn't up to us to change them, and changes will likely be undone by the people running the fundraiser. If you'd like to have this discussion, it should happen on Meta, at m:Talk:Fundraising 2008/design drafts, not here - as the en.wikipedia community has no direct control over the banners. - Rjd0060 (talk) 15:41, 7 November 2008 (UTC)

Thankfully, that gadget (call it IAR, an emergency measure, whatever; it was obviously direly needed; removing it was probably not a good idea on behalf of whoever did that) was able to get rid of it for registered users. I don't really see what the problem is at this point. Celarnor ^{Talk to me} 20:14, 7 November 2008 (UTC)

It has to be activated by each user who does so, and by doing so they've indicated that they've already seen it - even from an OFFICE point of view I honestly don't see the harm in it. Orderinchaos 00:59, 8 November 2008 (UTC)

I think there's some conspiracy with websites adding big obstrusive banners on their pages: last.fm has just added a big ad, youtube, in trying to detect an IP's country, has put a big notice and WP with fundraising. O_o -- Menti sock 10:08, 8 November 2008 (UTC)

On a related note, if you check the "I already donated, now get out of my face" box in your preferences, will it suppress future fundraiser banners? I've been extremely reluctant do so, fearing just that. I would certainly like to be able to axe the big monstrosity of an ad, though, if it wouldn't affect the next one. MrZaius^talk 09:44, 13 November 2008 (UTC)

SHARING WIKIPEDIA ARTICLES

Many online newspapers allow one to post the said article of interest to Facebook, MySpace, etc. as well as send the article to a friend. I believe this would be beneficial to Wikipedia as well. Thank you.

Posting a Wikipedia article to Facebook or MySpace (unless you wrote it all yourself) would typically be a copyright violation. - Jmabel | Talk 18:28, 12 November 2008 (UTC)

How? Wikipedia's licensing allows it to be freely distributed, provided Wikipedia is credited, or something like that. This has come up here a few times before, and I have no reason against it. Others said it is unnecessary and it is not hard to share an article yourself. Reywas92 ^Talk 18:57, 12 November 2008 (UTC)

I think sharing an article link would be much more better than allowing to share an entire article. This way, more people can encouraged to read the article after coming to website and even contribute to the encyclopedia. Currently I think this feature there only for FAs on main page a link on each article to do so would be nice. --GPPande talk! 20:21, 12 November 2008 (UTC)

Yes to GPPANDE.

Reywas92, just crediting Wikipedia is not enough, you also need to post the GFDL license, which is not going to happen at Facebook or MySpace. - Jmabel | Talk 20:27, 12 November 2008 (UTC)

I don't know about Myspace, but on Facebook you are sharing just a link to the article, which shouldn't be a problem. Reywas92 ^Talk 21:03, 12 November 2008 (UTC)

I suspect that in practice one only needs to post a link to the GFDL, not the full text of it; that's well within the possible for Facebook & MySpace. --Tagishsimon (talk) 01:34, 13 November 2008 (UTC)

User:gppande points out a couple of important reasons to just link to the article, but I'd like to point out a perfectly permisible middle ground. Just drop Printable version of the article, in its entirety/with the GFDL link, in an iframe on whatever site you're trying to include it in. That way it's dynamically updated, but it bears the same dynamically updated license link. MrZaius^talk 09:37, 13 November 2008 (UTC)

Do the sites in question have an end-user agreement which asserts any site-owner's rights to member-posted information? If so, then posting text from Wikipedia might not be allowed by Wikipedia's GFDL. No problem with links to articles, of course. —Michael Z. 2008-11-14 16:25 z

Allowing administrators to grant autoconfirmed status

I'm not sure of the technical feasibility of this, but what do people think about allowing administrators to mark accounts as autoconfirmed? I ask because I recently semi-protected a page due to egregious BLP violations. When I did that, I also locked out a good faith I.P. contributor. I would like to be able to allow that I.P. to immediately edit the protected page, such as by having them create an account that I would immediately flag as autoconfirmed, but I can't currently do this. Thoughts? Sarcasticidealist (talk) 19:15, 12 November 2008 (UTC)

I think it is the way inwhich the auto-confirmed status is granted (mainly that it cannot be revoked by anyone), that makes it difficult to turn into a userright. Although a dev would probably know better. MBisanz ^talk 19:18, 12 November 2008 (UTC)

Technically, sure it would be possible to create another group with the autoconfirmed right, and allow admins to assign that group, or possibly even assign the autoconfirmed group. -Steve Sanbeg (talk) 20:52, 12 November 2008 (UTC)

It would be technically possible, and pretty easy, to create a group, like "manuallyconfirmed" or something, which had all the same rights as autoconfirmed; developers would add it after seeing a consensus somewhere like here. And I support the idea as well, although I doubt it would be used very much. --ais523 21:58, 12 November 2008 (U T C)

This is a good idea, and I endorse ais523's idea of a "manuallyconfirmed" group. {{Nihiltres|talk|log}} 23:16, 12 November 2008 (UTC)

It's a good idea, but I suggest a slightly shorter name Dendodge Talk^Contribs 23:21, 12 November 2008 (UTC)

How about "manconf"? ;-) Great suggestion btw :-)

On a side note the software should be scripted to remove the group automatically once the account reaches autoconfirmed status, else we'd need an admin-bot to clean up all those unneeded manually-confirmed accounts. Regards So Why 23:29, 12 November 2008 (UTC)

Technically we can take autoconfirmed out of the $wgImplicitGroups array to make it grantable I think. FunPika 23:31, 12 November 2008 (UTC)

I vaguely recall that this is or was already under discussion "somewhere".

Anyway, if this is enabled (which I don't think I'd oppose), should we presume that the reverse - removal of autoconfirmed - would also be possible? - jc37 01:51, 13 November 2008 (UTC)

Yes, if it's no longer in $wgImplicitGroups, it would be grantable, and removable. Celarnor ^{Talk to me} 08:18, 13 November 2008 (UTC)

You wouldn't want to remove it. You'd want this to become a trinary state. On/Off/Prohibited - There's little to no reason to un-autoconfirm a user and then allow it to automatically happen again without administrator's review. It's a little silly to say "X edits are enough to get autoconfirmed status, but 2*X are necessary for this guy, cause he screwed up at edit X+1." MrZaius^talk 09:40, 13 November 2008 (UTC)

Would making it removable be a bad thing? It could be used as a step down from a block and to help enforce topic bans. --Nate 14 81 09:49, 13 November 2008 (UTC)

How would that help enforce such bans? Semi-protecting articles solely to lock out editors without autoconfirmed-status is against protection policy. And even if it is semi-protected anyway, then there is no reason to enforce the ban in this way. A topic ban is to allow people to work on other parts of the project like all other users. Removing autoconfirmed to enforce a topic ban would cripple their ability to work on articles that are unrelated but semi-protected or need to be moved, thus actually removing any reason to only topic ban at all.

That said, I do not think removing autoconfirmed from the $wgImplicitGroup variable will be a good idea because that would also mean that we need to create a new, manual way to assign this status to thousands of new editors that meet the criteria. What will it be? An admin-bot to change rights continually? Or do we re-write the code to make it automatic but grantable? Wouldn't it easier to just create a new usergroup that get's removed automatically when the software upgrades an account to autoconfirmed? Regards So Why 11:00, 13 November 2008 (UTC)

I have not idea about the technical sides, Just to clarify my thoughts on topic bans, it was where that the key articles that someone gets banned from are already semi-protected as IPs & socks have been warring over them as well, not to semi-protect articles to block that user. --Nate 14 81 11:23, 13 November 2008 (UTC)

Removing it from the list of implicit groups wouldn't make it removable. Auto-promoted groups don't work that way. You could only manually remove it from users where it was manually granted and it would only actually remove them from the group if they didn't meet the autoconfirm requirements. It'll show up on Special:Userrights, but unless the user had it manually granted it will be unchecked regardless of whether or not they are actually autoconfirmed. Someone could probably write an extension for manual autoconfirm removal similar to how AbuseFilter and TorBlock work though. Mr.Z-man 23:16, 13 November 2008 (UTC)

Just ask the IP to create an account. =Nichalp «Talk»= 10:42, 13 November 2008 (UTC)

Point is that creating an account does not instantly transfer auto-confirmed status to the account, leaving the IP in the same state for the next days to come. So Why 11:00, 13 November 2008 (UTC)

4 days, 10 edits, 1 confirmed e-mail id. Not too long IMO. =Nichalp «Talk»= 11:39, 13 November 2008 (UTC)

I think there should be an automated message from Wikipedia to the newly created user's talkpage. Currently this message is manually posted by good wikipedians. The message should contain the usual guidebook of Wikipedia and how to edit. At the bottom of the message, there should small explanation on which article are still out of reach as user is not auto-confirmed. The user can use this time to go through some basic WP:policies and understand them so that once auto-confirmed he/she would have the right mindset. If the user is serious about WP and wants to help himself and serve community better then he would surely like it and follow it. Auto-confirmation is small driving exam test which every serious editor can pass with flying colors. No harm in keeping it, but if removed, lot many precious article can meet with accidents. --GPPande talk! 14:23, 13 November 2008 (UTC)

Autoconfirmed is supposed to show they've been around enough to have at least some review of their edits; making someone who you already know is OK stop what they're doing for a few days to get autoconfirmed seems contrary to the spirit of that; it would be nice if someone could vouch for them by setting their initial time/edit count to some reasonable value so they can continue on, although that would require some development work. -Steve Sanbeg (talk) 21:08, 13 November 2008 (UTC)

So their editcount and registration time would be wrong for forever? Mr.Z-man 23:16, 13 November 2008 (UTC)

It depends what you mean by their. If that means a person, then yes, if anyone edits anonymously their edit count is probably wrong forever, although this change would at least make it a little more accurate. If they is the database entry, then technically this would make the edits associate more with the person than the name, thus more wrong. But I'd expect even the most severely editcountitis affected wouldn't be too concerned about crediting someone with a few (say, 10) edits that were made prior to registration to avoid disrupting something they're working on. I'm not saying this is the only way to do it, but it seems more in the spirit of confirming users than having to manually auto-confirm then somehow remove an extra confirmation later on. -Steve Sanbeg (talk) 00:13, 14 November 2008 (UTC)

What if they didn't edit from an IP? They could be a respected user from another project. Or what if their IP edits are mixed in with a bunch of other people's on the same IP? I just don't see why we would purposely introduce what would in any other circumstance be seen as a database error. Mr.Z-man 17:36, 14 November 2008 (UTC)

Not a fan of this idea. The example scenario, a good-faith IP getting screwed by semi-protection, isn't impacted by this proposal at all; we can't assign anonymous users to usergroups (imagine the fun of assigning a permission to an IP of a good editor, only to have it dynamically swap out to a vandal; good times!). The requirements for attaining autoconfirmation are so low that I don't see why we'd need to assign the right to anyone. EVula // talk // ☯ // 21:19, 13 November 2008 (UTC)

Sorta too late, Brion created the "Uploader" group for this purpose last night, he hasn't assigned yet which gourp (admins or crats) can give it out, but stewards can grant it. MBisanz ^talk 21:21, 13 November 2008 (UTC)

19:15 12 November to 21:19 13 November... glad there was so much time for discussion. :) EVula // talk // ☯ // 21:23, 13 November 2008 (UTC)

Uploader gives extra privs for uploading files, this thread is about allowing someone to edit semi-protected pages if they're manually confirmed. I don't see any overlap between this discussion and that group. -Steve Sanbeg (talk) 00:16, 14 November 2008 (UTC)

Um, I think I've commented previously on a similar discussion that this might be desirable and feasible, especially considering the ability of the abuse filter to revoke autoconfirmed status (and the subsequent need to re-grant it). We might have an 'autopromote override' system. — Werdna • talk 13:27, 14 November 2008 (UTC)

I had a need for this functionality a few days back when my new bot account was unable to edit the semi-protected page it was supposed to be archiving. Granting the bot flag removes this problem but a bot in a trial period isn't given the flag. I ended up removing the protection from the page which so far has worked, aside from one incident of vandalism, but I think a way to autoconfirm accounts is necessary. ~ User:Ameliorate! ^{(with the !) (talk)} 04:43, 15 November 2008 (UTC)

Preview comments

Can MediaWiki put "Preview Remember that this is only a preview; your changes have not yet been saved!" etc. outside the normal page? As it is preview never shows the user an absolutely truthful version of how the page could look like because the notice always changes the layout a bit. I end up having to preview the page again without the alterations to compare the modified page with the original. -- Menti sock 10:55, 14 November 2008 (UTC)

The preview also omits section edit links, so you can't tell if they bunch or not. Algebraist 12:11, 14 November 2008 (UTC)

Yeah, and another one that I just remembered: it doesn't process substitutions (in the edit window, not the actual previewed page). That may be because they're only dealt with when the page is truly parsed but as it is substituted templates can't be experimented with without saving the page first. -- Menti sock 13:35, 14 November 2008 (UTC)

Guidelines for editnotices

See Wikipedia_talk:Editnotice#Guidelines_for_editnotices, where I propose to create guidelines on the use of editnotices. Cenarium ^Talk 22:23, 14 November 2008 (UTC)

Moving search box to the top of the sidebar

Additional input is sought. Please see this discussion:

MediaWiki talk:Sidebar#Moving search box above navigation --Timeshifter (talk) 04:32, 15 November 2008 (UTC)

Policy on edits that rely on translations of other Wikipedias

A reasonably conjecture is that many of the edits in the English Wikipedia rely on other websites, and this this could indeed include Wikipedias in other languages. However, if any entry were simply a direct translation of Wikipedia in another language, surely this could be called plagiarism. On the other hand, if an entry has simply - - in addition to using other sources - uses another language Wikipedia for guidance, I consider that acceptable. However, does Wikipedia already have a policy on requests for translations of other Wikipedias? Before there was an an article on Hjalmar Sunden in the English Wikipedia, there was one in the Swedish Wikipedia. I would like to use the latter for guidance in edits tot the former, but I do not speak Swedish. Note well that as my piece on Hjalmar Sunden has used other resources, and contains information not in the Swedish entry, it is not plagiarism. How about a category of "Wikipedia articles influenced by other language Wikipedias?"ACEOREVIVED (talk) 21:47, 27 October 2008 (UTC)

Copying text from wikipedia, in any language, is neither copyright violation nor plagiarism, as long as proper attribution is given to the authors of the wikipedia article. There is a thriving community of interwiki translators who take extensive articles in one language and translate them into other languages where the article is either weak or nonexistent. There is absolutely nothing wrong with this as long as proper attribution is maintained. However, no wikipedia can be considered to be a reliable source as required by WP:RS and WP:V, so it is not ok for wikipedia articles in any language to use other wikipedia articles as references or sources. You can quite legitimately use the same original references as the foreign-language article (although they're likely to be in a foreign language also, and english-language sources are preferred if available), but simply citing the article itself as a source is not acceptable. I hope this clarifies things. Happy‑melon 22:05, 27 October 2008 (UTC)

No, I would not consider a translation of a foreign language Wikipedia article into English to be "plagiarism." Like Happy-melon said, there is a thriving community of interwiki translators. Look at Wikipedia:Translation, Wikipedia:Pages needing translation into English, Category:Wikipedia articles needing translation, etc. You can propose a page be translated from Swedish to English at Wikipedia:Translation/*/Lang/sv. --Pixelface (talk) 23:15, 27 October 2008 (UTC)

Many thanks for your quick responses, you have answered my question extremely well.Many thanks, ACEOREVIVED (talk) 23:59, 27 October 2008 (UTC)

To clear something up, all content on any of the Wikipedias (regardless of language) is content released the Gnu Free Documentation License. As long as information relevant to the license and access to the top 5 contributors is retained, you can't "plagarize it" in the sense that you're thinking. It's free content. Celarnor ^{Talk to me} 15:23, 28 October 2008 (UTC)

I think the issue is framed incorrectly; we should never be translating from another Wiki, per WP:V, because Wikipedia is not a reliable source. Edits to wiki should be based on reliable sources; editors adding text should be accessing the original sources, and should be able to read those sources in their original language. Translations from other wikis violate our core WP:V policy, unless the original sources are accessed, read, understood. SandyGeorgia (Talk) 20:42, 28 October 2008 (UTC)

There have been problems with editors doing Google translations of articles from other wikis, and other foreign-language articles, and starting new articles from those translations, even though the contributor who starts those articles here is not fluent in the language. Machine-generated translations are not reliable. Perhaps more to the point, an editor who cites a source in essence vouches that he or she has consulted the source. Other wikis are not reliable sources (just as Wikipedia itself is not a reliable source), and no article should rely on sources that the editor has not consulted. This is not an issue of plagiarism or copyright; it is a question of reliable sources. (And direct translations of text from copyrighted sources are derivative and therefore violate copyright.) Kablammo (talk) 20:55, 28 October 2008 (UTC)

I think both of the above make a few assumptions that aren't true; that other Wikipedias do not cite RS, and that a source in another language is somehow inherently unverifiable; none of these are true. You also seem to ignore that people can perform translations rather than machines, and that someone who can translate the content of an article can also read the sources. None of the other Wikipedias lack a policy regarding the reliability of sources; naturally, they have different names, but they all exist. Secondly, as a corollary of the first, that isn't the case. Even so, upon translation, the translator can omit a non-RS source if it somehow exists. Third, there is nothing in the verifiability policy that says sources are unverifiable solely based on being of a language other than english. Assuming the availability of sources in the native language, yes, those should be used, but there's nothing wrong with citing a non-native source if a native one is unavailable.. Celarnor ^{Talk to me} 12:37, 29 October 2008 (UTC)

Celarnor, I suspect you may be misreading what I wrote. Yes, other Wikis (and en.wiki as well) are not reliable sources; that is not questioned by anyone who understands WP:V. Translating from a non-reliable source, without consulting the reliable sources that the text is based on, violates WP:V. If that's what these translations groups are doing, it should stop. I did not say that sources in another language are not reliable: in fact, since I speak and read fluent Spanish, I often use them. I said that original reliable sources (not Wiki text) need to be consulted when translating. All text added to en.wiki should be based on a reliable source, whatever language; wikis are not reliable sources. Translating from a wiki, without consulting the original sources, amounts to adding text that is based on a non-reliable source. If a translator has consulted the original sources, in whatever language, by all means, translate those sources and add text based on them. But don't translate from a non-reliable source (a Wiki), and assume that the original sources are correctly represented in the non-reliable Wiki. Contemplate SayWhereYouGotIt: if you got it from a Wiki, that's what you should be citing to, and we don't cite to non-reliable sources. Wikis are not reliable sources. You need to consult and translate from the original sources that the other Wikis used. SandyGeorgia (Talk) 18:45, 29 October 2008 (UTC)

The mere fact that an idiomatic translation of an article exists in another language doesn't preclude the compliance of that article in another language; the point is that they have to be based on reliable, verifiable sources. The rest doesn't matter; the question here was whether or not such a translation would constitute plagarism, which doesn't exist between GFDL-licensed projects. Celarnor ^{Talk to me} 18:53, 1 November 2008 (UTC)

Machine-generated translations are not reliable; translations by one fluent in the language may be, and are acceptable. Consultation of sources by one fluent in the language is acceptable; reliance on intermediate sources (i.e., other wikis), or machine-generated translations from those sources, is not. By all means we should encourage accurate and idiomatic translations from other wikis, but those translations should be made by someone competent to do so, and who has checked all sources used. Additional relevant discussion can be found at this FAC. Kablammo (talk) 19:29, 29 October 2008 (UTC)

Naturally; no one's advocating machine-driven translation, so I don't know exactly what you're trying to get at. I just wanted to make sure that no one got the impression that there was any sense of 'plagarism' between GFDL-licensed projects. The RS/V issues are secondary to that, but non-existent assuming the translator isn't just doing a word-for-word translation and copying in the references. Celarnor ^{Talk to me} 18:53, 1 November 2008 (UTC)

I agree that

machine translations are completely unacceptable, even as a first draft.
translators must be competent not just linguistically but also on the subject matter.
sources given in the original language must be checked
if any sources cannot be checked for whatever reason, they must not be cited.

Oh, and translations from other Wikis are not plagiarism if proper attribution is made, as stated by others above.--Goodmorningworld (talk) 14:58, 7 November 2008 (UTC)

Despite having much respect for SandyGeorgia over the years, I think he is completely wrong when he says, "we should never be translating from another Wiki, per WP:V, because Wikipedia is not a reliable source". One might as well say "Don't edit [or refactor any material from] any articles in the English Wikipedia, because the previous version was not a reliable source". The fact that the preliminary work on an article was done in a different language does not make it ipso facto any less reliable than if it had been done in English.

Much as the history records the edits made in the English-language version of the article, at the time of translation there should be explicit notice (either in a summary or—my preference—in the references section indicating that the article is based in part on a version in another Wikipedia, which should ideally be referred to with the specific version that was used (although that gets tricky, because in languages I know well I've sometimes found myself doing cleanup in the foreign-language wiki in conjunction with translating). - Jmabel | Talk 18:23, 12 November 2008 (UTC)

The distinction here is between treating the previous article as a source, and treating it as a starting point, which must be sourced in itself. I think we really mean the latter here. — Werdna • talk 09:33, 16 November 2008 (UTC)

Temporary lifting long-term semi-protection of featured articles

Hi - I would like to discuss the issues raised here - of temporarily lifting long-term semi-protection of featured articles. What I am concerned about is that many country FAs have had semi-protection for as long as a year. The reasons for semi-protection are very practical, but I fear that such long-term, un-reviewed protection is preventing anonymous IPs and new users from contributing to the most visible, popular articles on Wikipedia. I feel that this is violating the letter and spirit of WP:PROTECT#Semi-protection - as practical as the measure may seem, I feel that unless it is condoned by this policy, an un-reviewed long-term semi-protection only ends up keeping new users locked away. It is important to preserve the quality of FAs, but it also hinders the freedom to contribute new information, and in many ways begins to violate the spirit of WP:OWN and WP:BOLD, as the fewer regular users, despite best intentions, get the best access and control over content to the point of suspecting any kind of new edit. Autoconfirmation is not an excuse, given that a new user may easily be turned off, and that the policy doesn't say that autoconfirmation is a permissable excuse. I am proposing that there should be a periodic review of semi-protection, and the semi-protection should be lifted for at least a few days to check if the conditions that caused it continue to exist. Shiva (Visnu) 09:27, 12 November 2008 (UTC)

This makes sense to me, a rolling review so that any protection is reviewed annually would be a good plan. --Nate 14 81 14:06, 12 November 2008 (UTC)

The problem lies in high profile country pages such as India, where if left open, would rapidly deteriorate unless active editors watch each and every edit. It's not humanly possible to keep a watch on average, 20 edits per day to determine the suitability of inclusion. The text that is included in pages such as India have come about after megabytes of discussion, choosing to focus on summary style and removal of listy content. Anon editors do not know this: If they feel something is missing, they would simply add the content, remove NPOV stuff on Kashmir, and make ignorant edits such as converting Delhi to a state. Such edits require a constant attention. As volunteers, we should not be spending time in checking each and every edit. RC patrol can only verify vandalism, they are not in a position to weed out subtle vandalism, which remains on the page for months. Do see this article about subtle vandalism on the India page. While wikipedia is open, I also feel that contributions of editors who have put in months of labour debating and discussing content inclusion and NPOV should not be wiped away in a single shot. When the India page was open to editing, and few were watching, it was dragged to FARC twice. We cannot be expected to then leave personal life commitments, return and see what has gone wrong and redo all the hours of work. It's not my or anybody's obligation to do so. But it is disheartening. The protection is working positively in my opinion. We require registration to create a new article, that is IMO more putting off. =Nichalp «Talk»= 07:39, 13 November 2008 (UTC)

Your arguments are made from the practical point of view - nothing wrong with that, except it is not enshrined in policy. This means that (a) we are risking the violation of the exact policy of semi-protection usage, the right to boldly improve articles and create a sort of ownership amongst those regular editors, who may end up pushing the newer editors out; and (b) making popular articles inaccessible to first-time users.

We are all volunteers, and I guess we don't take any rewards anyway. How does aversion to the deterioration of FA building work prove more important than protecting Wikipedia's accessibility to newer people, or enforcing existing policy? That's a bit going against WP:OWN, despite best intentions - we are assuming contributions from new users to be inherently negative, and its a bit condescending to assume that they will not know anything about FAs; that's no safeguard, since autoconfirmed users I guess are susceptible to the same. I suppose all articles, regardless of FA status, are exposed to the same risks. The problem is that popular articles are what new users first try to get. You (Nichalp) had earlier pointed out how India was one of the most-read, so imagine the reaction of new people trying to experience Wikipedia for the first time. Here I speak with first-hand experience just 2-3 weeks before.

What I want to do is that an article like India, which has been under semi-protection for 1 year, should be un-protected and observed for 4-5 days to ascertain the risk from vandalism and arbitrary addition of large data. That's all - I don't think this is demanding of anybody, nor does it really violate your otherwise sound arguments. What I am asking is the proper freedom, as is supposed to be. I can only suggest that this practical concern be enshrined in WP:PROTECT if this is to continue. Shiva (Visnu) 19:12, 13 November 2008 (UTC)

"Your arguments are made from the practical point of view - nothing wrong with that, except it is not enshrined in policy. This means that (a) we are risking the violation of the exact policy of semi-protection usage" - Following the spirit of the policy (ie, the common sense, practical reasoning behind the policy) to help the project is more important that following it to the letter for the sole reason that "policy says so."

"How does aversion to the deterioration of FA building work prove more important than protecting Wikipedia's accessibility to newer people, or enforcing existing policy? " - 99%+ of Wikipedia visitors will never edit, not because the pages they look at are all protected, they just don't edit. A stable-ish, non crappy article that only a few tens of thousands of people can edit is better than an unstable article full of vandalism and unsourced and incorrect information, especially if we're going around calling it "featured" (though not all indef semi-protected articles are FAs or even GAs, bitch for example).

"What I want to do is that an article like India, which has been under semi-protection for 1 year, should be un-protected and observed for 4-5 days to ascertain the risk from vandalism and arbitrary addition of large data." - Just look at the page history. If its still getting fairly frequent vandalism while semi-protected, its probably a sign that unprotection would be a bad idea, if not, unprotection might work. Mr.Z-man 18:22, 14 November 2008 (UTC)

To the tune of Auld Lang Syne Flagged Revs, Flagged Revs, Flagged Revs, Flagged Revs. Flagged Revs, Flagged Revs, Flagged Revs. Flagged Revs, Flagged Revs, Flagged Revs, Flagged Revs. Flagged Revs, Flagged Revs, Flagged Revs. — Werdna • talk 13:34, 14 November 2008 (UTC)

I think this should be handled under the standard protection policy. FAs shouldn't be protected just because they're FAs. If they get vandalized, perhaps protect a little quicker than normal, but not protected just because. I'm unprotecting India to see what happens. 137.246.207.202 (talk) 17:51, 14 November 2008 (UTC)

Who says people are protecting FAs just because? Look at the protection log, India was protected because at the time, almost all the anon editors were adding vandalism or spam, which is covered by the protection policy. The fact that it was an FA was not mentioned at all. And I'm not sure what you mean "I'm unprotecting India to see what happens" - anons can't unprotect pages... Mr.Z-man 18:22, 14 November 2008 (UTC)

Maybe he was logged out. I have seen recently examples of FAs being semi-protected, while it were only minimal or no recent vandalism, or because other similar FAs were semi-protected. We should beware of this kind of rationales, but it's not the case for India. We may indeed use flagged revs for this kind of articles. Cenarium ^Talk 22:52, 14 November 2008 (UTC)

Shiva, I don't know which is worse, keeping anons from adding text or reverting an anon for reasons such as "suspected vandalism" or "article is written in summary style, does not belong in a FA" Aren't such reasons more putting off? Two country FAs I wrote: Nepal and Bhutan have lost FA status. Do you support such a scenario where A FA article is kept for open editing only to lose it's status because there is no "human review & verification"? Once an article reaches an FA, ideally it should be at a plateau. Now, despite being semi-protected, the article still suffers from petty vandalism today and edits by editors who wish to add anything they feel is absent without stopping to think that it does not fit in. =Nichalp «Talk»= 15:35, 16 November 2008 (UTC)

India is #74 ranked for this month =Nichalp «Talk»= 15:41, 16 November 2008 (UTC)

Again, all above arguments are sound. What I am asking is that such long-term protection should be lifted for a little while to test the waters and see if a serious threat of vandalism still exists. I don't think it is appropriate to not review a semi-protection for over a year. As for what happens to FA status, I think its natural to demand continuing maintenance and vigilance from contributors - articles like India, Nepal and Bhutan are high-interest, country FAs, so it is necessary to be more vigilant than with some less prominent topic. As you say, if India is the 74th most popular article, it may turn new people off for not being able to edit despite Wikipedia's claim of being a "free encyclopedia anyone can edit" - naturally we know this is still true, but long term semi-protection without review is more-or-less restrictive in a bad way. Shiva (Visnu) 18:12, 16 November 2008 (UTC)

Yes, but if I nominate 30 featured articles, I cannot check the diffs ever 30 mins for each of the articles to see if it is in line. That would be putting off wouldn't it? Anyone can edit the encyclopedia, its just that to edit high priority pages, an account is necessary. Don't we already require an account for the creation of new pages? Coming back to the point, what is it that you hope to happen if the protection is removed? A net positive or negative? If the protection is lifted would you be willing to undertake a survey of each edit by IPs and unconfirmed users? =Nichalp «Talk»= 19:24, 16 November 2008 (UTC)

To Mr. Z Man - the problem is that this un-reviewed, long-term semi-protection does not merely extend or exceed, but actually ends up contradicting WP:PROTECT - now I assume that when this policy was made, it considered all issues and is relevant to all articles, FAs in all situations. Given that your arguments are very practical, I suggest that it would be right to try to enshrine long-term semi-protection of FAs in policy as acceptable - that's another way to look at this. Shiva (Visnu) 18:22, 16 November 2008 (UTC)

Maybe we should rewrite that policy to include such cases. =Nichalp «Talk»= 19:24, 16 November 2008 (UTC)

An article like George W. Bush could possibly be unprotected shortly after the next president is sworn in, but a quick glance at the history should indicate a "test unprotection" would likely be futile. Who's to say it hasn't been reviewed? There's no formal process for protection review, except possibly WP:RFPP, which isn't archived. I just looked at the history for George W. Bush and decided unprotection would be silly, did I not just review it? I think you seem to be mixing several issues together. Not all of the indef-semiprotected articles are FAs, not all FAs are indefinitely semiprotected. There's no reason to protect an FA just because its an FA. If its a high-profile FA that's getting frequent vandalism, it would be protected just like any other high-profile article getting frequent vandalism. The fact that its an FA has little or nothing to do with it. The protection policy already covers long-term semiprotection for severeal reasons and the reason given for protecting India fits within this, so I don't see why policy need to be changed. Mr.Z-man 19:17, 16 November 2008 (UTC)

A Wiki Atlas project

Hi. I do a lot of work on geographical articles and I find our map resources quite disappointing. All good encyclopedias have an atlas but I find the Wiki Mini Atlas of a poor standard and often inaccurate with a poor quality background that is sub standard of wikipedias intended high standards. I think that we should have a more advanced atlas with enhanced satellite imagery. Would anybody support a sister project WikiAtlas or a new area of wikipedia which attempts to draw up a proper atlas as we see in book format but more advanced and to improve it to an extent that we have high quality maps and decent satellite imagery? The closest thing we have on the web at present to a formal atlas is the MSN encarta atlas but this as we know is dated. As the wiki project is devoted to information services it seems highly strange that we haven't got a decent world atlas as a reference point as part of the project. Count Blofeld 11:58, 13 November 2008 (UTC)

Wouldn't that project be duplicating the efforts of OpenStreetMap? Wikiminiatlas really should support displaying maps from OpenStreetMap—don't ask me how come it doesn't. Hemmingsen 12:26, 13 November 2008 (UTC)

Ok, first of all WikiMiniAtlas has a fullscreen button for quite some time now, secondly high quality geodata is not easy to come by. The projection of the Openstreetmap data is different from the WMA. I have been working on a new WikiMiniAtlas, which has the ability to display openstreetmapo data [3], but due to severe time constraints on my part this isn't quite finished yet. The main beef I have with OSM is the labeling on the map. I'd like the labels to come from Wikipedia. THis allows for multilingual maps in the WikiMiniAtlas. Having the OSM labels (some in undecipherable typesets) clutters the map. --Dschwen 15:23, 13 November 2008 (UTC)

Yes I know what you mean about the labels cluttering the map Count Blofeld 15:25, 13 November 2008 (UTC)

OpenStreet Map uses Flash. And the speed and resource hungry application that was, was putting off for me. =Nichalp «Talk»= 12:55, 13 November 2008 (UTC)

The wikimini atlas is useful for a quick check, but it isn't of a high quality nd the sort of formal atlas you;d expect from wikipedia. Note OpenStreetMap has been edited in a way that places in east asia for instance in like Vietnam have "foreign" lettering and are not recognisable in English. Count Blofeld 12:38, 13 November 2008 (UTC)

Ideally, we should be duplicating what Google Earth/Maps do. Make high resolution SVG maps, maybe 1:1000 scale, and then stitch it together. =Nichalp «Talk»= 12:55, 13 November 2008 (UTC)

Yeah, I like the way Google sets things up. If we had some way of creating a similar database that was completely Wiki-enabled, I'd be all for it. --User:AlbertHerring ^{Io son l'orecchio e tu la bocca: parla!} 14:26, 13 November 2008 (UTC)

Yes I agree Nichalp. The wikimedia project really should be a centre for information on the web and this means developing our own mapping information program within our project rather than relying externally. Ideally we want something so developed that we will increase the traffic towards wikipedia. I'd imagine there are millions of people daily who use google maps, but imagine the benefits if we had one of the most comprehensive mapping facilities on the web and the amount of people it could attract to the project. Some day I envisage detailed satellite maps in 3D on wikipedia with the ability to find landmarks etc within cities and view them in virtual 3D and then click the labels and view their respective articles. Sounds ambitious but not impossible in the future but would be an awesome prospect. But more realistically at present I'd be happy with a just a decent solid 2D atlas within the wiki. Count Blofeld 15:12, 13 November 2008 (UTC)

In my spare time, I've been working on 3D terrain representations of the entire globe based on the heightmap data. Had some minimal success on a small-scale, but with a few other helpers, I could make a programming project of this (other programmers would be needed too), if this was what you had in mind? Fritzpoll (talk) 21:42, 13 November 2008 (UTC)

Yes maps which show contours and topography in 3D if it is possible. I was also thinking about the way in which google are developing 3D maps and how in the future this could be used for encyclopedic purposes to explore cities and terrain on here to increase an understanding from a 3D viewpoint. Perhaps I've been watching too many documentaries in which the eggheads emphasise that the future of the Internet will become increasingly virtual 3D but I don't see why it wouldn't be possible for wikipedia to develop something like google satellite maps in this way if they were willing to invest money and expertise into it. People might say, why do we need any maps at all if we have google maps, there are other sites on the web that offer maps, but it would not only be convenient within the wiki project but would potentially in terms of sheer traffic we could be attracting a significant amount of new people towards wikipedia. Count Blofeld 22:04, 13 November 2008 (UTC)

Well, I can create virtual terrain automatically, but I can't necessarily generate man-made features - we'd need another source or to do it by hand. Perhaps some interested people might be able to help collaborate on a project of this sort. For that kind of thing, we might need a new forum... Fritzpoll (talk) 22:08, 13 November 2008 (UTC)

Well exactly, real details I wasn't realistically thinking about until way into the future, but yes indeed I was thinking about terrain and improving satellite imagery. The first stage I think would be to develop our wiki mini atlas to a higher standard and if necessary set up a wider project to plan it. I know there is a workgroup that already exists who set up the MiniAtlas and a coordinates project. Perhaps it might not be a bad idea to turn it into something more extensive. Either way we need a solid map and the way the Internet and the wiki project is evolving would seme sensible to develop a mapping system which is on par with any other on the web. Basically I am thinking of something like Microsoft Virtual Earth adapted for wikipedia. Count Blofeld 22:13, 13 November 2008 (UTC)

Couldn't we always derive the data of the WMA from Google Maps? ~the editorofthewiki ^{(talk/contribs/editor review)}~ 23:04, 13 November 2008 (UTC)

No that would slightly violate their copyright.Geni 03:42, 14 November 2008 (UTC)

Count Bloefed, what sort of maps are you looking at exactly? Terrain or Road maps? http://www.ngdc.noaa.gov/mgg/topo/gltiles.html is GFDL that is used to produce images like these: Image:India topo big.jpg. It has a high scale that might be worth exploring. =Nichalp «Talk»= 18:33, 14 November 2008 (UTC)

I would not recommend using Globe data for any location which has SRTM data... SRTM has 90-m resolution and has much better accuracy both horizontally and vertically. Blue Marble the Next Generation has 500-m resolution – I'm not sure if there is freely available visual data with higher resolution. – Sadalmelik ☎ 19:33, 15 November 2008 (UTC)

As far as integrating the atlas better with the encyclopedia, one way would be creating Map-namescape on Commons. Then we could use things like [[Map:Sicily-en|right|300px|thumb|Map of Sicily]] here. On Commons, though, there would be no uploaded file Map:Sicily-en. Instead there is description of the map... Something like this:

Background = Topography |
Left = 18 | Right = 20 | Bottom = 18 | Top = 20 |
Projection = Mercator |
Layer1 = Main Roads |
Layer2 = Mountains_1000m |
Layer3 = Cities_50000-en

Of course then one would need to be able to specify things like font sizes, colours, line thicknesses etc... Anyway, when the page containing the map is viewed, the map server on Commons decides what scale of data is best suited for the map (full SRTM or something coarser) based on the area and pixel width of the map. It will the add each layer in turn and generate the bitmap containing the topography, main roads, mountains over 1,000m and larger towns. In addition it will also generate the HMTL code for the corresponding image map, so that clicking on the label Etna takes viewer to article Etna. Both the bitmap and the image map are cached for future uses. Of course that would not be like Google Earth, but I think that's beyond the resources we have. Even this would be a lot of work. – Sadalmelik ☎ 19:33, 15 November 2008 (UTC)

Just use WMA instead of dynmatically generating the map. I made an example a while ago at Template:GeoTemplate/sandbox, which store information in an empty div to initalize WMA.

While we are speculating on the future, I would like to see different season in where the greats lake freeze over the country and then switch to summer to see the scorched deserts of the Midwest. I would like to see the 80s style vectorized earth. I would like to be able to zoom in a Cartogram of my county's election result. The ability to able to overlay maps from commons. I'd like to view animated weather and temperature maps. View rainfall, or just about anything else one would find in an atlas or almanac. — Dispenser 06:17, 16 November 2008 (UTC)

New banner

Look at the new banner in the top of French « Portail de la Littérature » here [[4]]. It's based on a gallery of random pictures. Ask User:Stef48 questions about it.PRA (talk) 09:57, 16 November 2008 (UTC)

How is that different from the random images/articles displayed on portals like Portal:Video games and Portal:Association football? JACO PLANE • 2008-11-16 11:16

It' a gallery, not a single picture.PRA (talk) 11:34, 16 November 2008 (UTC)

They just use more than one random image at a time. We've been doing it for years. Dendodge Talk^Contribs 14:13, 16 November 2008 (UTC)

We watched a lot of Portals (in English and others languages) and we never saw such a banner. Your model is too well hidden. Indicate the way, please.PRA (talk) 15:40, 16 November 2008 (UTC)

We don't normally do gallery banners like that, but it's just like multiple ones of these. Dendodge Talk^Contribs 15:42, 16 November 2008 (UTC)

De gustibus et coloribus non est disputandum , “There’s no arguing about tastes and colors...”PRA (talk) 16:41, 16 November 2008 (UTC)

I hope the randomization of images doesn't allow non-free images to be included in the banner. Little Red Riding Hoodtalk 22:17, 16 November 2008 (UTC)

Those are selected, and obviously 100+ so their copyright has vanished. Cenarium ^Talk 00:45, 17 November 2008 (UTC)

So the process which randomly selects them checks their age? Little Red Riding Hoodtalk 01:07, 17 November 2008 (UTC)

They are randomly selected from the list here, I suppose their copyright status has been checked. Most of them look old and I suppose others have been released in a free license. Cenarium ^Talk 03:05, 17 November 2008 (UTC)

Wikipedia:Naming conventions (Ancient Egyptian)

Wikipedia:Naming conventions (Ancient Egyptian) has existed for more than a year, but is not currently linked to Wikipedia:naming conventions or any other policy or naming convention. Despite being labelled a Naming convention, it does not appear to have been discussed here. The only mention of it elsewhere is in an archived discussion at Wikipedia talk:Naming conventions/Archive 11#Copy-edit tag, which is only marginally relevant.

It has however been adopted by Wikipedia:WikiProject Egypt, and a strong consensus appears to exist among the active members there supporting it.

IMO it should either be adopted by the wider community, and added to the list of guidelines at WP:NC, or rejected, and the {{Wikipedia subcat guideline|naming convention|Ancient Egyptian}} banner removed. Andrewa (talk) 13:40, 18 October 2008 (UTC)

I have linked to this discussion from Wikipedia:Village pump (policy)#Wikipedia:Naming conventions (Ancient Egyptian) and Wikipedia talk:Naming conventions#Ancient Egyptian names, Wikipedia talk:WikiProject Egypt#Wikipedia:Naming conventions (Ancient Egyptian) and Wikipedia talk:Naming conventions (Ancient Egyptian)#Resuming..., and also Talk:Khufu/Archives/2022/April#Naming convention which is where the latest round of this discussion started. Anyone I've forgotten? Andrewa (talk) 14:28, 18 October 2008 (UTC)

In general, guidelines can't overrule policies. That's not a fatal flaw in what you're doing, it just means that as part of the process, you'll want to try to get the exceptions that you mentioned written into WP:NAME. - Dan Dank55 (send/receive) 20:53, 21 October 2008 (UTC)

Yes, exactly, hence the heads-ups at Pump(policies) and Talk:NC. If there's consensus here to adopt this guideline, that would essentially be a policy decision, in that it would imply that the guideline should be linked to from WP:NAME (more commonly called WP:NC in my experience) which is a policy page. The line between policy and guideline is a bit blurred with respect to WP:NC, in that the pages that describe the detailed rules including exceptions are formally regarded as guidelines, but do in a sense overrule policies. There's some control (in the sense of management control) over this in the listing of these overruling naming conventions at WP:NC, and this proposal is essentially about exercising that control. Andrewa (talk) 12:05, 22 October 2008 (UTC)

The comment about 'guidelines can't overrule policies' is misleading. Wikipedia is not a bureaucracy, and existing policies and guidelines tend to serve as documentation of community standards, rather than a prescription of behaviour. Accordingly, if community practice is to use those naming conventions for ancient egyptian, go ahead and use them. — Werdna • talk 09:09, 22 October 2008 (UTC)

Exactly. But I think the time has come to resolve the inconsistency between this guideline and WP:NC. In a sense this has already happened; The (proposed?) guideline has now been retagged as a proposed naming convention, rather than one that is a current guideline. Andrewa (talk) 12:05, 22 October 2008 (UTC)

It is not actually as opposed to policy as it may appear; there are a great many Greek names for the Egyptians that come down to us through Manetho, and have indeed fallen largely out of use since the reading of hieroglyphics began. In several of the cases where, for various reasons, a Hellenized form is still customary (Menes, Ramesses, Apries), we actually do use it, and I have tweaked the guideline accordingly. The only question really at issue, as far as I can see, is whether we should use Cheops or Khufu; and that is largely a question of fact (what is current standard usage?) rather than of policy. Septentrionalis PMAnderson 16:14, 22 October 2008 (UTC)

The real question IMO is whether, indeed, we need this guideline at all; whether it says anything we need to say more clearly than WP:NAME itself does. I'm undecided on that. Septentrionalis PMAnderson 16:16, 22 October 2008 (UTC)

Agreed. But the arguments at Talk:Khufu/Archives/2022/April#Article name took a very different view. Andrewa (talk) 02:49, 23 October 2008 (UTC)

We have equivalent guidelines already, this would tidy things up. Doug Weller (talk) 20:08, 24 October 2008 (UTC)

But that's the whole question... Does it tidy anything up at all? As now modified it just says, follow WP:NC. That's pure instruction creep. The previous content sought to establish an exception, a very strong one (never use the Greek), and one that was seen as very important by members of the relevant Wikiproject, who have accused me and unnamed others of bandying WP:NC in previous discussions.

And there's another issue that we're not even addressing yet, the systematic rather than common naming of tombs, which is a very similar issue and equally heated and which, if this is adopted, can then be raised and quite possibly approved at Wikipedia talk:Naming conventions (Ancient Egyptian) with no further reference to the policy page ay WP:NC which will then be endorsing it by a link. Messy. Andrewa (talk) 19:04, 26 October 2008 (UTC)

I think the address the former question (the naming convention of pharaohs) can be delimited the circumstances by which each rule should apply. While it is not explained there (as yet) part of the reason for occasionally preferring the Greek naming convention is when the name has come down through us primarily through a scholar like Manetho (the first two of PMAnderson's examples — Menes and Ramesses — nicely fit into that category). Things get untidy when we are talking about late-period pharaohs, particularly those who lived into times for other Greek historian (like Herodotus) to chronicle. So we get oddballs like Apries instead of the more Egyptian Wahibre or Wahibre Haibre, which is unfortunately inconsistent with the Egyptian naming conventions used for every other pharaoh of the 26th dynasty. This also goes back to the occasional notable pharaoh as far back as Psusennes I, and though the information doesn't seem to be there, I suspect that the various Orsokons listed in the same time frame are more Greek than Egyptian by name. (Will double-check my sources and report back.)

In summary though, the Ancient Egyptian naming convention is consistent (sans Menes and Ramesses), up until the time of the Third Intermediate Period, at a time when much of later Ancient Egyptian history was conveyed almost exclusively by Greek chroniclers (and carried forward into English) up until the time hieroglyphs were decyphered. It may make sense to revisit the namings given to the later pharaohs for the sake of internal consistency. Captmondo (talk) 19:14, 29 October 2008 (UTC)

It turns out that Orsokon is a legitimate Ancient Egyptian transliteration, even though to my ear it sounds vaguely Greek. And there is a split in the opinions of recent scholars as to whether to use the Greek name for later pharaohs (such as Apries) versus the Ancient Egyptian form (Wahibre for the same pharaoh). I think that in the name of consistency however, it makes more sense to go with the Ancient Egyptian name, as that seems to be the overall trend (witness the Khufu vs. Cheops arguments). I will suggest that the Apries article be renamed to Wahibre instead, and ask for the opinions of those who frequent Wikipedia:WikiProject Ancient Egypt. So in the end, I'll be making an argument for the "no Greek names" side of things, which is not always in line with WP:NC. Captmondo (talk) 18:37, 6 November 2008 (UTC)

I believe that this is a foolish "consistency"; let us dispell the hobgoblin. We should not use Ancient Egyptian for Apries, any more than we do for Anwar Sadat, and for the same reasons: it does not communicate with our readers, or indeed with English speakers in general. I unconditional oppose this outcropping of pedantry. Septentrionalis PMAnderson 18:46, 6 November 2008 (UTC)

My point is well-reasoned, and I can cite at least a couple of recently-published, popular books on the subject that uses Wahibre instead of Apries: Peter A. Clayton's "Chronicle of the Pharaohs" uses the Ancient Egyptian names for all of the pharaohs of the 26th dynasty of Egypt, as does Dodson and Hilton's "The Complete Royal Families of Ancient Egypt". They are both used as textbooks/references for some college courses on the subject, so anyone interested in the subject of these pharaohs these days are likely to start with the non-Greek names. Indeed, with only one other exception (Nekau/Necho, which I would argue should also be changed) for every other pharaoh of that dynasty we use the Ancient Egyptian name rather than the Greek (i.e. Psamtik I instead of Psammetichus, Ahmose II instead of Amasis). The latter is a particularly good example since the original Ahmose I is almost never referenced by the Greek Amasis I.

Consistency is not necessarily pedantry, and I would not characterize it as such.

Going by your Anwar Sadat example I have to wonder if you have mis-characterized the argument: it is not to use the Ancient Egyptian names strictly for the sake of doing so, but because general English usage seems to be favouring those names over the Greek naming conventions that have come down to us. Khufu vs. the Greek Cheops is a good example of that, ditto Khafra over Chephren, or Sneferu over Soris. I suspect that the later hodge-podge of names used for the 26th dynasty of Egypt is because the Late period pharaohs are generally lesser-known that those from earlier eras, and in some cases the Greek name is still prevalent. In keeping with the recent English scholarly trend towards using English transliterations of the original names over those by Ancient Greek scholars, I am arguing that this form of consistency is not pedantry, but in keeping with the overall trend.

And also note that the Anwar Sadat is in fact titled Anwar el Sadat, which is not strictly in keeping with WP:NC either. So in fact a counter-example to your own argument.

So I kindly submit that your "hobgoblin" is fallacious. ;-) Captmondo (talk) 21:32, 6 November 2008 (UTC)

The core questions

OK, let me ask a simple question: Are there any circumstances in which we need a systematic naming convention for the names of articles concerning ancient Egypt, which would be an exception to WP:NC? Let me call that question 1.

There's a related and more specific question: Are there any circumstances in which ancient Egyptian names should be preferred to their Greek-derived traditional names as article names despite the traditional name still being the common name? Let me call that question 2.

I actually think that those are the same question in different terms, for all practical purposes. But that doesn't really matter either way. The pount is, if the answer to either is yes, then we do need a specific naming convention for articles concerning Ancient Egypt... Either just a new paragraph in WP:NC, or a new guideline to which WP:NC is linked.

If on the other hand the answer to both is no, as I'd suggest is the growing consensus here, then there's no need for a new guideline, and the proposed guideline should be rejected.

Cheops/Khufu is not an exception to WP:NC. The case was {eventually) made for Khufu in terms of current English usage. The only relevance of the Cheops/Khufu debate is that it brought attention back to the semi-official status of the (proposed) specific naming convention. Andrewa (talk) 12:25, 1 November 2008 (UTC)

Hmmm, no recent comment. If we're all done, do we now flag the proposed naming convention as rejected? Andrewa (talk) 17:00, 13 November 2008 (UTC)

There is no NC. — Werdna • talk 09:34, 16 November 2008 (UTC)

It seems as though WP:NC is in line with the naming policies for Ancient Egyptian monarchs. A recent proposal to use the Ancient Egyptian name Wahibre for the pharaoh Apries (which is of Greek derivation) was effectively opposed for reasons in line with WP:NC, namely that the Greek-derived name is far more common in English usage.

I think it might be fair to say that the original proposal was meant as an informal guideline within the community of people interested in things Ancient Egyptian on Wikipedia, and no formal change needs to be made to WP:NC to accommodate this. Captmondo (talk) 17:13, 17 November 2008 (UTC)

How to define Wikipedia

If one looks at List of Wikipedias, one wonders whether all entries should really be classified as "Wikipedias" - I have read that most of the entries in the Volapuk Wikipedia were made by a bot and were stubs. The Choctaw Wikipedia has a mere 15 artciles. Should we say that a Wikipedia would need to have a minimum number of articles and cover a good range of topics before it would qualify as a Wikipedia? ACEOREVIVED (talk) 21:16, 6 November 2008 (UTC)

I don't understand your suggestion. Are you proposing that Wikipedias which don't meet some criterion be given a name other than Wikipedia? What name? What number of articles? What measurements define “covering a good range of topics?” —Michael Z. 2008-11-07 17:53 z

Is your suggestion only about reducing or otherwise changing the table at List of Wikipedias? I see you have posted to Talk:List of Wikipedias. PrimeHunter (talk) 18:30, 7 November 2008 (UTC)

Thank you for the responses, and I do see that there are complicated issues here - for example, that if we say a Wikipedia would have to a minimum number of articles (say 50) to be classified as a Wikipedia, that one language edition of Wikipedia would then qualify with 51 articles, another with 49 would not. I also think that it may be misleading to say that the usefulness of a Wikipedia is only to be measured in article number, and not in the range of articles covered (I would advise people here to read the article on Volapuk Wikipedia, which currently gets in the Top 20 on the List of Wikipedias - and surprisingly, beats the Wikipedia in Esperanto). There is somewhere on the web where can read a "List of all the essential articles which any good Wikipedia should have" - do a Google search and type in "list of Wikipedias",and you will see what I mean. Prime Hunter, I am inclined to agree with you that my suggestion is to do with List of Wikipedias - I certainly think that this list needs restructuring. Perhaps this issue is best reserved for the talk page there. Thank you again for the comments. ACEOREVIVED (talk) 21:26, 7 November 2008 (UTC)

I seem to have been referring to the article Wikipedia: Vital articles, which is where Wikipedia: Articles_all_languages_should_have will now be redirected. This is itself has been a controversial entry, as its talk-page reveals (there is a claim there that the list there is too biassed towards social science and philosophy), but at least it helps to avoid the misleading impression that Wikipedia with 1, 050 articles may be better than one with 800 articles. ACEOREVIVED (talk) 21:48, 7 November 2008 (UTC)

See WP:DEADLINE. That a Wikipedia in another language is inactive now bears no meaning on the future. They are doing no harm, and given an infinite amount of time, which is how much time we have to improve Wikipedia, they will eventually come around. --Jayron32.talk.contribs 21:57, 7 November 2008 (UTC)

Unless the Foundation shuts a Wikipedia down for lack of content. Dendodge Talk^Contribs 22:01, 7 November 2008 (UTC)

I don't believe the Foundation ever shuts down a project due to lack of content, they shut it down due to lack of contributors which means vandalism doesn't get cleaned up so the project would become a complete mess if it wasn't locked. --Tango (talk) 13:47, 14 November 2008 (UTC)

Just as a matter of historical interest, does anyone know who decided there should be separate Wikipedias for different languages? By far the more obvious thing to aim for, surely, would be to have a single Wikipedia with different language versions of the articles (as you would have with any other work). Was the power of Babel felt to be too much to overcome?--Kotniski (talk) 10:10, 8 November 2008 (UTC)

That would have led to arguments about which languages should be the default, and talk pages would all have to be in different languages. It's easier on the servers, too. Dendodge Talk^Contribs 10:14, 8 November 2008 (UTC)

Kotniski:How (except in name) would that differ from the current situation? Algebraist 10:52, 8 November 2008 (UTC)

Well, there would be one community deciding controversial issues, things like watchlists would work much better for multilingual editors, and much of the infrastructure (categories, infoboxes, lists of references etc.) could be shared. The software would no doubt have evolved to translate many standard items automatically between languages. It would all be very different (and better, I think, but there's no way to find out now).--Kotniski (talk) 13:44, 17 November 2008 (UTC)

Well, most importantly, these projects are not called "Wikipedia" because they are being actively edited using a wiki process, but because that's their name. A store called Joe's Bakery would still be called Joe's Bakery even if they didn't sell any bread. In the long-term it's hoped they will become true wiki encyclopedias. Dcoetzee 09:34, 9 November 2008 (UTC)

I do not think that any one "decided" that there should be different language editions of different Wikipedias - I think that that is just how things happened. To start a Wikipedia in a new language would mean a complex process where an idea is taken to the Wikimedia Incubator; for example, a proposal to start a Lakota Wikipedia has been made there, and I believe that similar ideas have been made for Filipino and Old Norse Wikipedias. I do not really think that one could accurately say that to have single edition existing in identical format in different languages is what really happens with other sources - take for example, the Bible, which has different editions; or the works of Sigmund_Freud, which, as Bruno Bettelheim pointed out, were given translations into English which were not faithful to the original German. I also know that translations of plays are sometimes not literal translations. ACEOREVIVED (talk) 20:25, 9 November 2008 (UTC)

A Wikipedia is a Wikipedia. Why is a number of articles relevant? — Werdna • talk 13:41, 14 November 2008 (UTC)

An advanced cheatsheet?

Wikipedia currently has plenty of pages which introduce new users to its basic features and markup, such as WP:TUTORIAL and WP:CHEATSHEET. However, I have not seen any user-friendly guides to more advanced Wiki-markup (such as triple brace brackets, IFREQs etc.). These sorts of features (e.g. strings of brace brackets) currently render most advanced templates meaningless to me and hence stop me from being able to contribute to them, even though I'm keen to learn how to. Would it be possible for someone who is currently knowledgeable in their workings to create a guide on how to use them and hence create one's own complex templates? It Is Me Here (talk) 17:07, 9 November 2008 (UTC)

Most of them have their own Help: namespace pages, but a guide would be useful. If no-one else offers to create a guide, I will, but I'm not the most knowledgeable person here. Dendodge Talk^Contribs 19:38, 9 November 2008 (UTC)
- Well, if you could at least start one and add what you know, then that would be very much appreciated. It Is Me Here (talk) 17:50, 10 November 2008 (UTC)
  - Or you could just read the one that we already have which has been around since 2004. ☺ Uncle G (talk) 15:50, 11 November 2008 (UTC)

The Wikipedia:Editor's index to Wikipedia (linked at the main help menu Help:Contents) are the two places to find advanced help. Self help. Help write them, when you found something missing. :) -- Quiddity (talk) 08:26, 15 November 2008 (UTC)

OK, thanks for the links, guys. It Is Me Here (talk) 07:23, 17 November 2008 (UTC)

cricket

i come on here because i have a curious mind. however, when i go to the random article(s), half of them are about cricketers. does anybody really need that many statistics on cricket? is there a way to "combine" them under one heading or subject or something? thanks.

Of the 2,622,933 on wikipedia, 12078 of them are considered to be relevant to the subject of 'cricket', an incredibly small percentage. The random article button is just that, random, so it would not be surprising to get unexpected results with small sample sizes. I just selected ten random articles, and got two footballers, one species, an ancient battle, two albums and one artist, one member of parliament, a radio show and a list of stamp prices :D It takes all sorts to fill an encyclopedia! Happy‑melon 17:27, 14 November 2008 (UTC)

That's almost half a percent; hardly incredibly small (although the perceived 50% of the OP must have been a crazy random happenstance). Cricket is over-represented on the English Wikipedia. The reason for this is that a number of very active contributors focus on the subject (see Wikipedia:WikiProject Cricket). The only reasonable "solution" to this "problem" is pegging in and writing articles on other subjects. In the spirit of countering systemic bias, the problem with Wikipedia is not the topics which we cover well, even when they might seem obscure; the problem is the topics which we don't (yet) cover well. -- Jao (talk) 18:30, 14 November 2008 (UTC)

It's 0.46% to be more precise and I think we at WP:CRIC can be well pleased with that, especially as we still have more redlinks than blue. For example, we've barely touched the 19th century and our coverage of domestic cricket outside England needs a lot of work. This means that, far from being over-represented, cricket is still under-represented but only relatively so. Jao is quite right that the "problem" is with the many other projects that need more recruits and more participation. I would just point out that there is nothing obscure about cricket, which is a global sport played in over 100 countries and has a fan base, especially in the sub-continent, of an estimated 1 billion people. WP:CRIC is one of a few WikiProjects that is setting standards for others to follow. Other advanced projects are WP:MILHIST and WP:FOOTBALL. If anyone wants to know how we go about things, please open a topic at WT:CRIC. If anyone wants to join, please do so at WP:CRICMEM – you'll be most welcome. ---BlackJack | ^{talk page} 07:09, 15 November 2008 (UTC)

Well, I'd say that this billion notwithstanding, cricket does seem obscure to a large number of people, but that could, obviously, be said about any sport. Or perhaps even, it could be said about almost any topic, so it was meant to be taken lightly. -- Jao (talk) 07:38, 15 November 2008 (UTC)

So was the billion :-) I've no idea what the fan base is but it must be a fair few. ---BlackJack | ^{talk page} 22:21, 15 November 2008 (UTC)

If Wikipedia:WikiProject Deletion sorting/Cricket is anything to go by, you are currently gaining redlinks, too. ☺ Uncle G (talk) 15:06, 15 November 2008 (UTC)

True, but those articles were deleted following nomination by a project member. We don't keep stuff just for the sake of it. ---BlackJack | ^{talk page} 16:17, 15 November 2008 (UTC)

By way of comparison, can anyone give some idea of how many articles there are on asteroids? If cricket stats are mind-numbing to some, then there are probably far more people who see little use for the 10000+ articles on asteroids on Wikipedia. but this is an encyclopedia, and there's an endless sea of information out there, so the chances of having 10000 articles on any subject imaginable is probably not that far-fetched (10000 on the geography of the Vatican City State may be pushing it, mind you). Grutness...wha? 23:44, 15 November 2008 (UTC)

You're saying we shouldn't have an article on Third layer, fifth brick from the left of the rear wall of St. Peter's Basilica? :-) Carnildo (talk) 00:49, 16 November 2008 (UTC)

That's the most important topic in Vatican geography - I'm creating the article now! It's where the first ever Pope first banged his head in frustration. Dendodge Talk^Contribs 09:26, 16 November 2008 (UTC)

Wikipedia is not paper. If we can write a sourced, neutral article on a topic, it makes sense to do so. — Werdna • talk 09:30, 16 November 2008 (UTC)

Quite right. And coming back to those cricket articles that the cricket project itself nominated for deletion, the reason we did so was that they were not sourced and not neutral. Which means that as WP:CRIC is a self-regulating as well as an expansionist project, it is not a problem that 0.46% of all WP articles happen to be about cricket.

I should add that we have frequently revised or deleted articles that contravene WP:STATS. Unfortunately, cricket is like baseball in that it lends itself all too easily to "lies, damned lies and statistics", but the approach taken by WP:CRIC is to create narrative articles in which statistics may be a useful supporting medium, usually confined to an infobox.

If anyone is aware of any cricket articles that appear to contravene WP:STATS, please report them to WT:CRIC and we'll deal with them. ---BlackJack | ^{talk page} 09:46, 16 November 2008 (UTC)

Speaking of having a high % of articles on a niche subject originating on a small island, don't we have to many articles on Manga? But seriously, as others have said, can we have to may well sourced articles, especially as cricket is the most popular sport in the country with second highest population in the world... --Nate 14 81 12:01, 17 November 2008 (UTC)

By way of comparison, Wikiproject Baseball has 20460 articles, and Wikiproject Football, 65737. Rmhermen (talk) 17:19, 18 November 2008 (UTC)

^ So I've heard.

[1] So I've heard.

[1]