Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Tama1988 (talk | contribs) at 06:53, 16 November 2008 (Scrap Template:Copyedit, or at least explain how it's useful). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

  • Read this FAQ page for a list of frequent proposals and the responses to them.
  • If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
  • If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
  • If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

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

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)

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)[reply]

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#Naming convention which is where the latest round of this discussion started. Anyone I've forgotten? Andrewa (talk) 14:28, 18 October 2008 (UTC)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
Agreed. But the arguments at Talk:Khufu#Article name took a very different view. Andrewa (talk) 02:49, 23 October 2008 (UTC)[reply]
We have equivalent guidelines already, this would tidy things up. Doug Weller (talk) 20:08, 24 October 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I agree that
  1. machine translations are completely unacceptable, even as a first draft.
  2. translators must be competent not just linguistically but also on the subject matter.
  3. sources given in the original language must be checked
  4. 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)[reply]

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)[reply]

WP:DASH

Please read the discussion at Wikipedia_talk:Manual_of_Style#Categories.

This concerns the sections at WP:MOS concerning the "dash", and whether it should be applied to category-space.

The section makes a presumption that automatic redirects may be made (as is typical in mainspace, and other spaces).

But that isn't the case in category-space. We're limited to soft-redirects there. (And there seem to be concerns about a certain bot. See the discussion for more information.)

So realistically, if this section is applied, then we'd be duplicating every category which has a "dash" in it's name.

And also, having category redirects means that they are bluelinks. Which means that they have the potential to be categorised themselves, which can cause issues, which may not be noticed by the casual observer.

And further, the whole point of categories is navigation (as noted at WP:CAT). So forcing category names to make it more difficult for those who don't have an "en dash" on their keyboard, would seem to be a hindrance to navigation.

Therefore, I'd like to propose that categories be an exception to WP:DASH. So in categories, the hyphen is to be the preferred punctuation used. - jc37 07:20, 4 November 2008 (UTC)[reply]

  • Responses to the above arguments in turn:
  1. The redirects are handled by the bot, User:RussBot. No specific concerns have yet been offered about how this bot works - it seems to do the job well.
  2. Duplication would indeed occur, as it does with articles. But if the proposal is accepted, then we should probably duplicate the categories anyway, to allow for the people who – reasonably – expect dashes there.
  3. The possibility of redirects being themselves categorised applies to all redirects, and is not a significant problem anyway.
  4. The navigation problem is solved by the redirects – if it isn't solved already by inbuilt search-box functionality, which I suspect it is.--Kotniski (talk) 16:57, 4 November 2008 (UTC)[reply]
Kotniski: Sorry but you don't seem to understand how category redirects work. (Or rather, how bad they work.)
--David Göthberg (talk) 18:19, 4 November 2008 (UTC)[reply]
Well, whose fault is that? I keep asking for explanations, and don't get any. I therefore naturally conclude that these "problems" are simply someone's invention. Tell me what they are and I'll probably change my opinion.--Kotniski (talk) 15:58, 5 November 2008 (UTC)[reply]
There is really no such thing as a category redirect. All that exists is the template {{Category redirect}} which allows those who have clicked on category A to read text suggesting that they click further to category B. This is much weaker and less useful than a true redirect would be - another case which the developers could fix, but have not. Septentrionalis PMAnderson 19:26, 5 November 2008 (UTC)[reply]

Straw Poll

Oppose (prefer en/em dashes)

  • Oppose and support stating explicitly in the appropriate guidelines that dashes should be used when style requires it. The problems claimed to exist with dashes in category names appear to be imaginary. Use of hyphens instead will lead to inconsistency with article names and other article text, causing not only an inferior output for readers, but leading to hypercorrections (or mis-pastings) on the part of more literate or intuitive editors. --Kotniski (talk) 09:34, 4 November 2008 (UTC)[reply]
    Considering the concerns of others at the discussion, I'm not sure how you can assert that the problems are "imaginary". - jc37 10:16, 4 November 2008 (UTC)[reply]
    Well, all the concerns I know of have been answered. If there are real problems, let's hear them.--Kotniski (talk) 13:29, 4 November 2008 (UTC)[reply]
  • Oppose If the possible lack of RussBot longevity is that much of a concern, soft redirects from the hyphenated titles are sufficient, so there is really no need for an exception from MOS:DASH for category names. However, if something did happen to RussBot, it would not be that much trouble for someone else's bot to take up the task. The bot source is even available, so all that would be needed is for someone to install pywikipedia and start running it. Anomie⚔ 21:55, 4 November 2008 (UTC)[reply]
  • Oppose. Categories should never be an exception to any naming guideline, they are part of the encyclopedia and should conform to the same naming guidelines as articles. Also: the lack of a particular character on certain users' keyboards should not be taken into account in any naming guidelines, naming guidelines should be about using the correct names, regardless of whether or not any particular user can type them. MTC (talk) 16:59, 5 November 2008 (UTC)[reply]
  • Oppose—it's possible to fix the problem, and we have an acceptable, though not ideal, solution in place at the moment. Allowing the preferable em/en dashes in category space for now will help ease the transition later to a better category redirect system, and avoids conflicts with article names or obtuse exceptions from the Manual of Style for category pages. {{Nihiltres|talk|log}} 17:21, 5 November 2008 (UTC)[reply]
  • Oppose. Editors who read WP:DASH, or are creating categories named after articles with en-dashes, will create the en-dash-named categories anyway, so the efficacy of category redirects is not a reason to support. That leaves consistency of style as the primary reason to have the en-dashes. — Arthur Rubin (talk) 18:58, 6 November 2008 (UTC)[reply]
    If this proposal achieves consensus, WP:DASH would be updated to reflect this. And it would also mean that renaming the categories would fall under speedy. So the categories would be consistent. - jc37 19:11, 6 November 2008 (UTC)[reply]
    Yes, with each other (which would at least be an improvement over the present situation). But it would be even better for them to be consistent with article space (not just for appearance, but because people are likely to copy and paste "between" these two spaces).--Kotniski (talk) 09:52, 7 November 2008 (UTC)[reply]

Support (prefer hyphens)

  • Support - Until category redirects work as they should (automatically categorizing into the target category), they should be something to be avoided, not proliferated. Mr.Z-man 17:51, 4 November 2008 (UTC)[reply]
  • Support The proposed system of relying on a bot is too jury-rigged for my liking. If we could get a built in function in MediaWiki to do this, I would be ok with en/em dashs in categories. MBisanz talk 17:59, 4 November 2008 (UTC)[reply]
  • Support - I type in category names from the keyboard all the time, and I don't have an en dash on my keyboard. And it makes it harder to copy and paste the category names. (Yes, some of us are stuck with old computers with bad operating systems, pardon me for not being able to afford a new computer.) But most importantly, if/when RussBot stops working the category redirect system goes from somewhat broken to very broken, so we can not rely on category redirects. But even when the bot is running there are some problems with category redirects, thus it is better to not rely on redirects. --David Göthberg (talk) 18:19, 4 November 2008 (UTC)[reply]
  • Support until category redirects work. Dendodge TalkContribs 22:03, 4 November 2008 (UTC)[reply]
  • Support I don't see the real need for em dashes or en dashes in the first place. Reywas92Talk 22:10, 4 November 2008 (UTC)[reply]
  • Support Things should be human-typeable unless easy ways around it exist. When the redirection is fixed, then we can use dashes. Shoemaker's Holiday (talk) 07:03, 5 November 2008 (UTC)[reply]
  • Support Given the way that categories are redirected, the inability (or unwillingness) to use en/em dashes when assigning categories creates far more problems than any benefit gained through compliance with WP:DASH. Alansohn (talk) 15:40, 5 November 2008 (UTC)[reply]
  • Support hyphens until category redirects automatically categorize articles into the correct category. Relying on a bot is problematic, and using hyphens eliminates that. --Kbdank71 16:10, 5 November 2008 (UTC)[reply]
  • Comment: It would be more helpful if those voting, instead of repeating arguments that have already been apparently refuted, could address why they think the refuations are wrong. Then we might actually get somewhere. This isn't an issue to be solved by counting votes; it involves actual technical problems that we should be working together to identify and (if possible) solve. Just counting how many people believe what unsupported claim doesn't seem a very constructive way of proceeding.--Kotniski (talk) 16:13, 5 November 2008 (UTC)[reply]
    • "Apparently" being the key word there. I don't think you have refuted any argument. You continue to say we should rely on technical solutions to a problem, technical solutions that require more work for editors, readers, Russ, and now the devs, when a much simpler solution would be to use a typeable hyphen in category names. I'm sorry, but I still don't buy the "for style" argument to force everyone to jump through all these hoops. --Kbdank71 16:39, 5 November 2008 (UTC)[reply]
      • More work? Hoops? For whom? Editors can still type hyphens if they're that lazy (I wonder what these same editors do when a dash is required in an article they're writing?); readers can certainly type hyphens on the (very rare) occasions they might type a category name; and the bot owner and the devs won't be doing any extra work on account of hyphens and dashes, as the issue of category redirects is a much wider one. I know some people don't consider "style" to be important, or would prefer the whole of WP to be in ASCII, but the community has long decided it wants the encyclopedia to follow a good and consistent style of English using the full range of available characters, and we should be prepared to make (at least very minor) sacrifices to maintain that valuable goal. (And we shouldn't be using this specific category issue as a vent for our views about punctuation in general if we know them to be against community consensus.) --Kotniski (talk) 17:40, 5 November 2008 (UTC)[reply]
  • Support. I don't see why we need dashes in the first place. I'm not convinced by the "for style" argument; I think dashes are ugly and that they shouldn't be used at all unless they're specifically being discussed; we should aim to use "real" characters from the ASCII set whenever possible for usability, not sprinkle these kind of flourishes throughout the project. Celarnor Talk to me 17:33, 5 November 2008 (UTC)[reply]
  • Affirmative. It's in UTF-8, but I don't see any need to use it when there's a perfectly good ASCII equivalent available. I don't think it adds any benefit; in fact, I think it's more ugly than a hyphen, so I don't really see any reason to do this. Celarnor Talk to me 17:52, 5 November 2008 (UTC)[reply]
  • Support. Requiring dashes would make it more difficult for readers to use and consult categories to the extent that a "category redirect" is worse than a real redirect and to the extent to which redirects from hyphen to endash fail to exist. Typing in [[category:Foo[hyphen]Bar]] and getting nowhere, when [[category:Foo[dash]Bar]] exists and would have been titled with a hyphen without this rule, is the worst possible outcome. Doing all this for a debatable typographical nicety is uncalledfor. Septentrionalis PMAnderson 19:32, 5 November 2008 (UTC)[reply]
Category redirects do exist and do work though, as is continually being explained. They don't even rely on a bot. The bot is required only to move pages out of the redirected category to the target one (on the rare occasions that editors declare the category using the wrong name).--Kotniski (talk) 11:57, 6 November 2008 (UTC)[reply]
Show me an example of their "working", please; the ones I've seen don't really work. Septentrionalis PMAnderson 18:32, 6 November 2008 (UTC)[reply]
Well, there are two types of redirect - hard and soft. Hard ones work normally; soft ones require an extra click. Category:Poland topics is an example of a soft one; its previous incarnation (see the history, before the bot changed it) was an example of a hard one. There seems to be a belief (possibly founded on the same sort of superstition that we've seen in this debate, but possibly there's a genuine reason for it) that the redirects that the bot handles have to be soft ones. This means one extra click for readers, on the very rare occasions that they may type a category name into the search box and that category is redirected. Is this what you mean by not working? Or is it the fact that there's a time delay between an article's being added to the "wrong" category and its being moved to the correct one? If the rare extra click is felt to be a problem, then the best solution would be to push for hard redirects (with a message on the target page - this should be there anyway - that there may be additional pages temporarily categorized at [hard link to redirected cat]). The other problem - the time delay - has already been raised of course, and it's best solved (if it's felt to be significant) by editors' putting articles in the correct category to start with. Entering a dash isn't really a big deal (I imagine all serious editors who write stuff in English are used to it by now); indeed, when you're copying and pasting a phrase from article text, the dash is more likely and more natural.--Kotniski (talk) 10:12, 7 November 2008 (UTC)[reply]
"Entering a dash isn't really a big deal" - yes it is. The thing you seem to be forgetting is that categories are not content-space. They are merely intended to be used for navigation purposes. So ease of use for navigation trumps style. - jc37 20:02, 7 November 2008 (UTC)[reply]
It's "reader-facing" (i.e. intended for readers to look at, and hence part of the Wikipedia product), so style is important. With maintenance categories, intended for editors, I don't care so much, but for those used by readers, we should make an effort (and it really is only a tiny effort - indeed for many editors it would be more of an effort to remember or find out that we have different rules for categories than for other things, and to change dashes to hyphens when they do copy-and-paste).--Kotniski (talk) 09:59, 8 November 2008 (UTC)[reply]
  • Support. For usability, ease of navigation and editing, I prefer hyphens to en-dashes in nearly all contexts. I realize there is a typographical distinction that some people feel is important, but frankly I see little value in that distinction where it interferes with editing. In most contexts, I'm more comfortable with the use of em-dashes, which provide a greater degree of distinctiveness, though without true redirects those also seem problematic for categories. Dragons flight (talk) 19:59, 5 November 2008 (UTC)[reply]
  • Support; the use of hyphens improves usability for editors and readers while being equally clear, unambiguous, and aesthetically appealing. Considering the extra problems caused by the use of en-dashes, one would expect there to be an actual reason for their use in place of hyphens, yet none has been put forward. Christopher Parham (talk) 00:40, 9 November 2008 (UTC)[reply]
Do people actually read the previous debate before voting? The reason is good English style and consistency with article names and article text. And the "extra problems" have been shown to be mainly an illusion (at least, there may be slight inconveniences, but they apply just as much to the use of hyphens where many editors would expect dashes).--Kotniski (talk) 08:27, 9 November 2008 (UTC)[reply]
From a style perspective I'm fine with the hyphen. It is equally clear, equally attractive, completely unambiguous, etc. There is no actual reason to recommend against its use. I'd be happy to ensure consistency by moving article titles. No editors would "expect" dashes in my view, since everyone is very familiar with the natural use of the hyphen in this situation, so I see that as a non-issue. Christopher Parham (talk) 23:07, 9 November 2008 (UTC)[reply]
You think "no" editors know or pay any attention to what it says in the Manual of Style? Maybe you don't, but I think the vast majority of serious editors - at least, of those of the type we would like to encourage - do know what it says there and try to follow it, and expect it to be followed.--Kotniski (talk) 17:30, 10 November 2008 (UTC)[reply]
I am deliberately not taking the current MOS guidance into account; current decisions shouldn't be bound by poor decisions of the past. Rather, past decisions should usually be amended to reflect the new, improved judgment of today. Were there no MOS, editors would be unsurprised to see hyphens since that is a normal, clear, and attractive way of presenting English text. Christopher Parham (talk) 23:19, 10 November 2008 (UTC)[reply]
  • Support. Category redirects don't work and implementing the illusion of them creates far greater problems than the supposed cosmetic problems of the hyphen. older ≠ wiser 23:27, 9 November 2008 (UTC)[reply]
    Go on then, why is it an "illusion" that category redirects work? I presume you have read the remainder of this discussion, which seems to have established that they pretty much do work.--Kotniski (talk) 17:30, 10 November 2008 (UTC)[reply]
    While I appreciate that that's your interpretation, I'm not seeing that in the responses/comments from the coders (and others) who have commented thus far. And "pretty much do work" doesn't necessarily equal "they work". - jc37 17:33, 10 November 2008 (UTC)[reply]
    So in what way do you continue to think that they don't work? And what makes you so confident that they aren't needed if we use hyphens instead of dashes? Perhaps we should divide this issue into two questions: 1) dashes or hyphens? 2) redirects or redlinks? The two questions are independent (despite what many seem to assume) and I think we're quite close to establishing what the arguments on both sides are in each case.--Kotniski (talk) 17:41, 10 November 2008 (UTC)[reply]
    Kotinsky, No, I've not seen that this discussion has established that category redirects "work" in any useful way. older ≠ wiser 18:32, 10 November 2008 (UTC)[reply]
    Well, all the claims that they don't have so far been rebuffed. If you know of other ways in which you think they fail to work, let's hear about them. --Kotniski (talk) 13:15, 12 November 2008 (UTC)[reply]
    "Rebuffed" is an excellent word. But then, another way to accurately portray your comments might be: "I'm ignoring others' good faith concerns, and merely want what I want." If you feel that I'm mischaracterising your comments, please feel free to clarify. - jc37 01:00, 13 November 2008 (UTC)[reply]
    Very good point Jc37. Category redirects are broken because they do not work in the way any sensible user would expect them to work, and they require a bot to correct the kludgey misbehavior. That, to me, is not acceptable to make into a recommended standard. older ≠ wiser 12:43, 14 November 2008 (UTC)[reply]

Other opinions

  • Use "hyphens" everywhere. The English language only needs one punctuation mark in the form of a horizontal line. Why waste brain cycles trying to remember which length of line is correct, or fixing "errors" by switching between characters that look pretty much exactly the same? Let's all just use the button that's already on our keyboards, and use "-" for everything. -- Beland (talk) 17:51, 6 November 2008 (UTC)[reply]
  • That's not the issue being discussed here, though. WP has a very well established consensus about the use of hyphens and dashes in general, based on the fairly unanimous recommendations of respected English style guides. Personally I would change some of the rules we apply (not insisting on dashes for "disjunction", for example), but more important than the details is that once we have these rules, we should apply them consistently. --Kotniski (talk) 17:35, 10 November 2008 (UTC)[reply]

Comment on poll so far

seems to me that most of the votes are invalid, since they assume that redirects dont work, when in fact they do. But if we don't trust the bot to do it, let's ask the devs to build it in to the system (it can't be that dififcult). Propose suspending voting until we get a reply from the devs as to how long this would take (unless someone knows of such an idea's having been proposed/rejected already).--Kotniski (talk) 08:14, 5 November 2008 (UTC)[reply]
Looks like the issue is one that's come up before - see Bugzilla 3311 (and vote for it, if you believe that has any effect). Seems the issue is solvable, but no devs are in any hurry to do it. But still, we have a perfectly efficient bot to tide us over, and as Anomie points out, if Russ stops running it then someone else can take over. (And the redirects continue to work even without the bot - the bot is only needed for moving any articles that happen to be put into the other category.) So these alleged "problems" seem to boil down to just one - if an article is placed in one of these categories by an editor who doesn't know when dashes are required or is in too much of a hurry to paste/java-ize one in, then it won't show up on the target page until the next bot run (typically 24 hours max.). But even if this is considered a significant argument, let's remember that it works the other way round too - if the article is added by an editor who doesn't know about the hyphen-only policy or makes the category declaration by pasting the phrase in from elsewhere, then we're back in the same situation.--Kotniski (talk) 13:42, 5 November 2008 (UTC)[reply]
You've said this repeatedly. And yet those above still disagree with you.
Huh?? Let them speak for themselves - none of them have responded to me yet. K
In the discussion that led to this, you said you were waiting for User:Davidgothberg to comment. He now has. (As have several other coders.)
Another huh?? I was waiting for them to comment by explaining the "real problems" with the bot. It seems so far there aren't any (except that it might stop working; but then someone else can take over). K
And no, it doesn't work "the other way round". If an editor uses the dash instead of a hyphen, then the category is simply renamed. No need to duplicate mountains of categories with category redirects. - jc37 14:09, 5 November 2008 (UTC)[reply]
A third huh?? Who's going to rename the category? (OK, maybe the red link might be a warning cue to the editor, but who's to say he won't react by creating the redlinked category - or just giving up and deleting the cat declaration - instead of searching for the hyphenated one?) And we're not talking "mountains" of anything here - the number of redirects involved would be very small compared with the number WP has already, and redirects cost hardly anything anyway.--Kotniski (talk) 14:48, 5 November 2008 (UTC)[reply]
Kotniski: No, it doesn't take only 24 hours for the bot to move a page from the soft redirected category to the correct category. First of all the bot has a "standoff period", among other things to prevent it from mass editing pages if a category redirect is changed erroneously. That is, to give humans the chance to correct the redirect before the bot edits all those pages. As far as I know that "standoff period" is one week. Then the Wikipedia servers run category list updates as a low priority job, which means that during periods of high server load it can take up to a week before a page is visible in the right category. And this happens more often than most people think. That makes it a total of up to two weeks before a page is visible in the right category, provided the bot is up and running. If the miscategorising is due to a template, then it often takes more than three weeks before most of the pages are shown in the right category. And in the template case, for pages that get no visitors, it can take "forever". But for now I'll skip the long and complex explanation why that is so.
Regarding "invalid votes": Now that is very undemocratic of you, claiming that the votes you disagree with are invalid. We have already explained some of the technical issues here, and we already have linked you to the more in-depth discussions of the problems over at Template talk:Category redirect. Your failure to understand the technical issues at hand is your problem, not ours. But this is tricky stuff, so I don't blame you for not understanding. Instead I blame you for not accepting that you do not understand.
Remember, categorisation is a technical tool. It is not pretty article text. But I guess your next target will be to demand that we use Unicode symbols, instead of ASCII, in template and javascript programming, right? That is, ≠, ≤, ≥, − and ×, instead of !=, <=, >=, - and *. I wonder if there is a Unicode symbol for a long equal sign? The symbol we use for equal comparisons, what we in ASCII write as "a == b". Perhaps it is called "em equal"? :))
By the way, to avoid most of the technical problems we should perhaps ask the devs to make it so the category system interprets hyphen, en dash and em dash as the same symbol? So it doesn't matter which one we use. And that would be helpful even if/when they have fixed the other issues with the category redirect system.
--David Göthberg (talk) 19:57, 5 November 2008 (UTC)[reply]
Well, {{#expr}} was recently changed to recognize − in addition to -. Anomie⚔ 22:17, 5 November 2008 (UTC)[reply]
There's U+2263, which is the symbol for "Strictly equivalent to"; I guess you could use that for a long equals.  :) Celarnor Talk to me 22:12, 5 November 2008 (UTC)[reply]
OK David, thank you for finally explaining what you think the problems are. (Even the most intelligent of us can't understand things we're not told.) (And I don't know what you're going on about with Unicode in programming - obviously no-one's proposing that.) But I still don't see that the problem you cite - the standoff one - is applicable in this case. It's a problem that occurs once, when you change the name of any category. It will likely occur, for example, when categories are changed from dashes to hyphens according to the proposal. It isn't a problem that (as far as I can see) affects the later maintenance of redirected categories, so I don't see its relevance to this debate. When I change a page's category I always seem to see it in the new category straight away, so I don't see that in practice there is much delay in the updates happening (and if anyone's in that much of a hurry to get their article categorized, they can spend the extra five seconds it takes to enter the dash symbol to start with). Problems with templates I do understand (I'm not as totally ignorant as I might appear), but again, that's not very relevant, since I imagine the number of existing templates that impose hyphen-for-dash categories much be close to zero (for maintenance categories I can accept hyphens, since they're hidden from readers), and any new templates so created can be created with the dash already in place. --Kotniski (talk) 11:48, 6 November 2008 (UTC)[reply]

WP:DASH – Summary so far

Category redirects behave as follows:

  1. Going to the redirected category page takes you to the target page, just as with any other redirect.
  2. If the redirect is formatted as #REDIRECT [[Category:foo]], the redirected category will show up as a subcategory of Category:foo.
  3. If the redirect is formatted as #REDIRECT [[:Category:foo]], the redirected category will not show up as a subcategory of Category:foo.
  4. Pages placed into the redirected category are not automatically placed into the target category.
  5. To fix #4 above, User:RussBot periodically moves those pages into the target category. If RussBot ever stops working, it would be trivially easy for anyone else to run a new bot doing the same thing.

Supporters of the proposal to make an exception to WP:DASH cite the following reasons:

  1. Item #5 above is not sufficient to counter the trouble that #4 causes, as the correction is not done instantly.
  2. RussBot does not empty newly-redirected categories until 7 days after the last edit. This may lead to several weeks' delay in updating the pages in pathological cases.
  3. It is easier to type a hyphen on standard keyboards.
  4. WP:DASH should be overturned completely, not just with respect to categories.

Supporters also make the following nonsense arguments:

  1. "Category redirects are broken." Too vague. This could be referring to supporting reason #1, but it could also be that people believe that behavior #1 is not the case or that they are unaware of behavior #3.
  2. "It results in unnecessary duplication of redirects." This happens with all non-category pages that WP:DASH applies to too.
  3. "Redirected categories are not redlinks". This happens with all non-category redirects too.
  4. "People might enter the hyphenated version into the search box or url". That is what redirects are for.
  5. "There is no such thing as a category redirect." This is false.
  6. "All category redirects must be soft redirects." This is false from a technical standpoint.
  7. "I don't trust RussBot." There is no reason not to trust it. If the slightest bot downtime is that much of an issue, duplicate bots could be run concurrently.
  8. "Categories are not content." Some are not, but many are.

Opponents of the proposal cite the following reasons:

  1. Item #5 is sufficient to counter #4.
  2. Categories that are part of the encyclopedia (as opposed to maintenance categories) should follow the same style guidelines as the rest of the encyclopedia.
  3. The proposed exception would cause category names to not match the corresponding article names, when there is a correspondence.
  4. Dashes are easy to enter using the buttons at the bottom of the page, or by copying and pasting the category name.
  5. RussBot's 7-day cooldown is irrelevant. The person creating the new redirect should empty the old category before redirecting it.

Opponents also make the following nonsense arguments:

  1. "Category redirects are not broken." Too vague. This could be referring to opposing reason #1, but it could also be completely ignoring behavior #4.

Frankly, I find much of the previous discussion confusing. We have three options being discussed above: "Everything uses dashes", "Everything except categories uses dashes", and "Nothing uses dashes". People !voting "oppose" are choosing the first option, but people !voting "support" may be choosing the second or the third, and it's often impossible to determine which. Anomie⚔ 21:17, 12 November 2008 (UTC)[reply]

You've got the category redirects wrong. Categories are not redirected with #REDIRECT [[:Category:foo]]. They use soft redirects, as is used at Category:Manchu people. You are not automatically taken to the target category. --Kbdank71 21:39, 12 November 2008 (UTC)[reply]
Have you actually tried it? It works fine. Whether or not the feature is commonly used at this time is irrelevant. Anomie⚔ 23:58, 12 November 2008 (UTC)[reply]
From a technical standpoint, yes it works. But usability-wise, it doesn't work at all. Say Category:Manchu people was a hard redirect. You go there, it automatically takes you to Category:Manchus. It works fine, right? Now edit an article and add it to Category:Manchu people. Save it. If you click on Category:Manchu people in the article, you are instantly taken to Category:Manchus, but the article isn't there, because it's sitting in Category:Manchu people. Your casual reader isn't going to understand what happened. So, the soft redirect. It is extremely relevant as to why hard category redirects are not used. --Kbdank71 00:10, 13 November 2008 (UTC)[reply]
Hence RussBot. Anomie⚔ 01:28, 13 November 2008 (UTC)[reply]
And as you summarized above, RussBot does not empty newly-redirected categories until 7 days after the last edit. And speaking of the summary, did you have anything to add to it, or are you still confused? --Kbdank71 01:39, 13 November 2008 (UTC)[reply]
And as I summarized above, RussBot's 7-day cooldown is irrelevant. The person creating the new redirect should empty the old category before redirecting it. I was hoping that by summarizing that it would help the discussion move forward instead of continuing to go around in circles. Anomie⚔ 02:40, 13 November 2008 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
Unless the Foundation shuts a Wikipedia down for lack of content. Dendodge TalkContribs 22:01, 7 November 2008 (UTC)[reply]
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)[reply]

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)[reply]

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 TalkContribs 10:14, 8 November 2008 (UTC)[reply]
Kotniski:How (except in name) would that differ from the current situation? Algebraist 10:52, 8 November 2008 (UTC)[reply]
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)[reply]

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)[reply]

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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 -- Mentisock 10:08, 8 November 2008 (UTC)[reply]

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. MrZaiustalk 09:44, 13 November 2008 (UTC)[reply]

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)[reply]

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)[reply]

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. Reywas92Talk 02:29, 10 November 2008 (UTC)[reply]

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)[reply]
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)[reply]

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)[reply]

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

Wikipedia SSML (speech synthesis) webservice

This is, I guess, a feature request for wikipedia.

It could be potentially useful if wikipedia could provide a service for people to use which returned a SSML Speech Synthesis Markup Language representation of an article instead of the webpage.

I'm imagining a really convenient, voice controlled program for Windows, Mac, or Linux where one asks the computer about some topic, and the computer searches wikipedia. For example, "Computer, what's Buddhism?" or "Computer, look up New York City." Then the program uses the webservice to get an article's SSML, which it can then feed to the OS's voice synthesis engine, which then reads the 'article' to you.

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)[reply]

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

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)[reply]

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)[reply]
"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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]
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. Reywas92Talk 18:57, 12 November 2008 (UTC)[reply]
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)[reply]
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)[reply]
I don't know about Myspace, but on Facebook you are sharing just a link to the article, which shouldn't be a problem. Reywas92Talk 21:03, 12 November 2008 (UTC)[reply]
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)[reply]

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. MrZaiustalk 09:37, 13 November 2008 (UTC)[reply]

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

What has happened? When I click on a red link, I am taken to an edit page where I can create the article. It hasn't always been like this, has it? I think this is dangerous because it is inviting new users to create articles, which they do not know how to do. There is a link to WP:YFA, but it does not stand out very well. Clicking on a red link should go to a This Page Does Not Exist page, from which the page can be started. Leading directly to an edit page leads to an increased amount of badly-written and non-encyclopedic articles from new users. Reywas92Talk 17:33, 12 November 2008 (UTC)[reply]

As far as I know, it has always been like this (though I believe we no longer allow anonymous IPs to start articles, the one change I can think of). - Jmabel | Talk 18:27, 12 November 2008 (UTC)[reply]
it is inviting new users to create articles, which they do not know how to do - Did I miss a memo? When did we stop encouraging new users to edit? I was under the impression that WP:BOLD was a guideline. If the article is non-encyclopedic, we shouldn't be linking to it as if the articles are unencyclopedic, its likely the topic is as well. As for "badly written" - we're not on a deadline (and MoS noncompliance is not the same as bad writing), we should be encouraging people to learn by experience, not demanding perfection from the first edit. Mr.Z-man 19:11, 12 November 2008 (UTC)[reply]
As Jmabel pointed out, you're only going directly to the edit page because you are registered and autoconfirmed, as others are not able to create the page. Try logging out and then clicking the link. -- Jao (talk) 21:18, 12 November 2008 (UTC)[reply]
I see, but that's for unregistered. Are you sure that only autoconfirmed see it? Registered but not autoconfirmed can still create articles. Thanks for the response, Mr. Z-Man. I hadn't thought through it all the way, that the pages we link to in the first place should already be encyclopedic. I must try to be less critical sometimes. My response is that experience can be obtained from editing pre-existing articles, not necessarily in creating new ones that require much more attention.
Right, I should have checked first; new accounts can create articles, only IPs cannot. -- Jao (talk) 22:04, 12 November 2008 (UTC)[reply]
When did we decide we didn't want new users to write new articles? Celarnor Talk to me 01:55, 13 November 2008 (UTC)[reply]

I think this is dangerous because it is inviting new users to create articles, which they do not know how to do.

This is a wiki. Wikis are about radical openness. You don't need special authority or permission or skill to create a new article, you just do it, and if you mess something up, somebody will fix it for you. That's the point of a wiki! If you are uncomfortable with this concept, you are free to find another place to edit. — Werdna • talk 13:29, 14 November 2008 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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 (UTC)
This is a good idea, and I endorse ais523's idea of a "manuallyconfirmed" group. {{Nihiltres|talk|log}} 23:16, 12 November 2008 (UTC)[reply]
It's a good idea, but I suggest a slightly shorter name Dendodge TalkContribs 23:21, 12 November 2008 (UTC)[reply]
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 SoWhy 23:29, 12 November 2008 (UTC)[reply]
Technically we can take autoconfirmed out of the $wgImplicitGroups array to make it grantable I think. FunPika 23:31, 12 November 2008 (UTC)[reply]
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)[reply]
Yes, if it's no longer in $wgImplicitGroups, it would be grantable, and removable. Celarnor Talk to me 08:18, 13 November 2008 (UTC)[reply]
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." MrZaiustalk 09:40, 13 November 2008 (UTC)[reply]
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. --Nate1481 09:49, 13 November 2008 (UTC)[reply]
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 SoWhy 11:00, 13 November 2008 (UTC)[reply]
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. --Nate1481 11:23, 13 November 2008 (UTC)[reply]
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)[reply]
Just ask the IP to create an account. =Nichalp «Talk»= 10:42, 13 November 2008 (UTC)[reply]
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. SoWhy 11:00, 13 November 2008 (UTC)[reply]
4 days, 10 edits, 1 confirmed e-mail id. Not too long IMO. =Nichalp «Talk»= 11:39, 13 November 2008 (UTC)[reply]
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)[reply]
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)[reply]
So their editcount and registration time would be wrong for forever? Mr.Z-man 23:16, 13 November 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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 [1], 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)[reply]
Yes I know what you mean about the labels cluttering the map Count Blofeld 15:25, 13 November 2008 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
No that would slightly violate their copyright.Geni 03:42, 14 November 2008 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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. -- Mentisock 10:55, 14 November 2008 (UTC)[reply]

The preview also omits section edit links, so you can't tell if they bunch or not. Algebraist 12:11, 14 November 2008 (UTC)[reply]
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. -- Mentisock 13:35, 14 November 2008 (UTC)[reply]

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)[reply]
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)[reply]

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)[reply]

  • 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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]

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)[reply]

Moving search box to the top of the sidebar

Additional input is sought. Please see this discussion:

Public Black Background version of Wikipedia

Hi! I haven't edited for a long time, and I never had much involvement with community issues, so I apologize if my question seems odd here.

Is there a way to access Wikipedia with a black background on it without having to log in? (almost like how we can go to mobile.wikipedia.org if we're using iPods or Blackberries.) I use the black background and green text setting on my preferences, but I'm just wondering if I can use it without logging in. (I tend to be obsessed with saving energy all the time...) =)

Google has a similar format on Blackle if you don't get what I mean.--Dem393 (talk) 19:52, 15 November 2008 (UTC)[reply]

Blackle only saves power for people using CRT monitors. For people using LCD monitors, there's no difference between black and white in terms of power use: the backlight is always on. --Carnildo (talk) 00:52, 16 November 2008 (UTC)[reply]
CRT monitors are generally box-shaped, right?--Dem393 (talk) 03:13, 16 November 2008 (UTC)[reply]

P: and T: Pseudospaces

According to [2] and [3], the Pseudospaces for T: and P: all redirect to Templates and Portals. I propose that the developers code these pseudospaces into the namespace system as they did for WP: and WT: to move these pages out of the article space and into the proper Template and Portal spaces. No functionality will be lost, nor will searches or use be altered. MBisanz talk 03:09, 16 November 2008 (UTC)[reply]

No harm done, but what advantages does this bring? — Werdna • talk 05:35, 16 November 2008 (UTC)[reply]

Scrap Template:Copyedit, or at least explain how it's useful

Hosei University is a pathetic little stub of an article. However, I think (or I delude myself) that what very little it does say, it says competently enough. Meanwhile, I'm open to complaints that no, it doesn't.

By adding a very few characters, another user recently made it start A This article or section needs copy editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now. A how-to guide is available. (November 2008). He and I have been discussing this (look 2/3 way down the page) to little effect, other than to establish that the beef is (beefs are) in style rather than grammar, cohesion, tone or spelling.

Let's suppose for a moment that this or some other article is indeed a stylistic nightmare, making the informative content (locutionary force?) of the template thoroughly deserved. Right then, I'd like to know:

  1. How this template helps the potential readers of the article.
  2. How this template is of more help to potential editors of the article than would be served by something similar (but preferably more informative) on its talk page.
  3. What other benefit this template has to anyone.

Note that I have no objection either (i) to being told (even brusquely) that I've committed stylistic solecisms, or (ii) to the conspicuous placing atop articles of templates such as Template:Unreferenced. For the first, you'll have to take my word for my assertion that I'm thick skinned. The second is one of a number of templates that serve to alert readers potentially lulled into credulity by burnished, pseudo-encyclopedic prose that they are being suckered. By contrast, if an article requires copyediting, literate readers will likely realize this for themselves, and even if they don't IMHO won't be informed or fortified by being so informed. Tama1988 (talk) 06:53, 16 November 2008 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=252113258"