Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Dodoïste (talk | contribs)
3,461 edits
(2 intermediate revisions by 2 users not shown)
Line 336: Line 336:


I like Vector, but if some IP doesn't, they can suck it up or create an account (yay!). The WMF ''did'' spend a lot of effort on this switch and it's happened. Either change it in your settings or spend some of your own money and time showing why Monobook is better (which it isn't, because it's outdated ugly). <span style="font-family:Georgia;font-size:80%;">'''/[[User:Fetchcomms|<span style="color:#000;">ƒETCH</span>]][[User talk:Fetchcomms|<span style="color:#000;">COMMS</span>]][[Special:Contributions/Fetchcomms|<span style="color:#000;">/</span>]]'''</span> 03:08, 29 September 2010 (UTC)
I like Vector, but if some IP doesn't, they can suck it up or create an account (yay!). The WMF ''did'' spend a lot of effort on this switch and it's happened. Either change it in your settings or spend some of your own money and time showing why Monobook is better (which it isn't, because it's outdated ugly). <span style="font-family:Georgia;font-size:80%;">'''/[[User:Fetchcomms|<span style="color:#000;">ƒETCH</span>]][[User talk:Fetchcomms|<span style="color:#000;">COMMS</span>]][[Special:Contributions/Fetchcomms|<span style="color:#000;">/</span>]]'''</span> 03:08, 29 September 2010 (UTC)

== Add projectwide css to highlight different posts in a discussion ==

Per a discussion [[Wikipedia:Village_pump_(technical)#CSS_for_highlighting_discussion_threads|here]], I would like to propose the addition of some css into [[Mediawiki:Vector.css]] which allows for the highlighting of indented threads in any (Wikipedia- /User- /mainspace- ) talk page discussion, giving an appearance sort of like [[WP:LiquidThreads|LiquidThreads]], but (I feel) less controversial and certainly less forum-like. This effect, seen [[fr:Discussion_Wikip%C3%A9dia:Accueil_principal#Suggestion_d.27une_nouvelle_image_pour_le_Bluebg.png|here]], may be found at [[fr:MediaWiki:Vector.css]], and makes it much easier to see responses and posts from different users, making it an advancement in usability and accessibility. I have added this code to my own vector.css page, and it has been a great help in looking through longer threads. While the drawback to implementing this sitewide is the need to update some talk page templates using indentation, this is only a minor issue and should not stand in the way of helping users who may have trouble focusing on long blocks of text and may also act as a sort of compromise between LiquidThreads supporters and opposers.

Please consider trying out this css for yourself (the exact code is:
{{collapse top}}
<source lang="css">
.ns-1 dd, .ns-3 dd, .ns-talk dd, .ns-5 dd, .ns-7 dd, .ns-9 dd,
.ns-11 dd, .ns-13 dd,.ns-15 dd, .ns-101 dd, .ns-103 dd, .ns-105 dd {
margin:0;
padding:0;
}
.ns-1 dl, .ns-3 dl, .ns-talk dl, .ns-5 dl, .ns-7 dl, .ns-9 dl,
.ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-103 dl, .ns-105 dl {
border-top:solid 1px #a7d7f9;
border-left:solid 1px #a7d7f9;
padding-top:.5em;
padding-left:.5em;
margin-left:1em;
}
.ns-1 dl, .ns-3 dl, .ns-talk dl, .ns-5 dl, .ns-7 dl, .ns-9 dl,
.ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-103 dl, .ns-105 dl,
.ns-1 dl dl dl, .ns-3 dl dl dl, .ns-talk dl dl dl, .ns-5 dl dl dl, .ns-7 dl dl dl, .ns-9 dl dl dl,
.ns-11 dl dl dl, .ns-13 dl dl dl, .ns-15 dl dl dl, .ns-101 dl dl dl, .ns-103 dl dl dl, .ns-105 dl dl dl,
.ns-1 dl dl dl dl dl, .ns-3 dl dl dl dl dl, .ns-talk dl dl dl dl dl, .ns-5 dl dl dl dl dl,
.ns-7 dl dl dl dl dl, .ns-9 dl dl dl dl dl, .ns-11 dl dl dl dl dl,
.ns-13 dl dl dl dl dl, .ns-15 dl dl dl dl dl, .ns-101 dl dl dl dl dl,
.ns-103 dl dl dl dl dl, .ns-105 dl dl dl dl dl,
.ns-1 dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl,
.ns-1 dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl dl dl
{ background:#f5faff; }
.ns-1 dl dl, .ns-3 dl dl, .ns-talk dl dl, .ns-5 dl dl, .ns-7 dl dl, .ns-9 dl dl,
.ns-11 dl dl, .ns-13 dl dl, .ns-15 dl dl, .ns-101 dl dl, .ns-103 dl dl, .ns-105 dl dl,
.ns-1 dl dl dl dl, .ns-3 dl dl dl dl, .ns-talk dl dl dl dl, .ns-5 dl dl dl dl, .ns-7 dl dl dl dl,
.ns-9 dl dl dl dl, .ns-11 dl dl dl dl, .ns-13 dl dl dl dl, .ns-15 dl dl dl dl,
.ns-101 dl dl dl dl, .ns-103 dl dl dl dl, .ns-105 dl dl dl dl,
.ns-1 dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl,
.ns-1 dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl dl,
.ns-1 dl dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl dl dl dl
{ background:white; }
</source>
{{collapse bottom}}
and that goes in [[Special:MyPage/skin.css]]). It works fine on Monobook, although the colors may need to be tweaked for that skin, but I think that this change will only be aid in readability after one gets used to seeing it. <span style="font-family:Georgia;font-size:80%;">'''/[[User:Fetchcomms|<span style="color:#000;">ƒETCH</span>]][[User talk:Fetchcomms|<span style="color:#000;">COMMS</span>]][[Special:Contributions/Fetchcomms|<span style="color:#000;">/</span>]]'''</span> 03:35, 29 September 2010 (UTC)
:Fine by me, as long as it can be disabled in personal CSS. [[User:Access Denied|<font color="red">Access Denied</font>]]&nbsp;<sup>[[User talk:Access Denied|<font color="black">[FATAL ERROR]</font>]]</sup> 03:38, 29 September 2010 (UTC)
::Like I saif before, I support this proposal. This layout is an important usability and accessibility improvement. Especially for people with [[dyslexia]]. This layout used on the french Wikipedia was reviewed by an accessibility expert and another accessibility expert specialized in dyslexia. I can provide translation of their review if people are interested. Kind regards, [[User:Dodoïste|Dodoïste]] ([[User talk:Dodoïste|talk]]) 03:42, 29 September 2010 (UTC)

Revision as of 03:42, 29 September 2010

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
New ideas and proposals are discussed here. Before submitting:

The Creation of Wiki Forum

Dear Wikipedians As a new member of Wikipedia which I find interesting, I noticed there was little interaction with editors, if there is interaction it is very hard to find. I propose that we have a forum, similar to chat rooms in which editors can discuss articles and be able to organise project meetings, discuss wikipedia problems and solve problems together as a community. There is to be monitors that will oversee the discussions and chats, as many as possible and chat rooms with language dictionaries, a visible report tool and a instant response to reports. 'Thank you for listening to my topic. I hope you shall assume good faith and help me in our mission to make Wikipedia a better place to be" Yours Sincerely, RosePetals1

We already have talk pages. Bear in mind that Wikipedia is not a discussion forum. MER-C 10:51, 16 September 2010 (UTC)[reply]
Check out Wikipedia:IRC, in particular see #wikipedia-en on Freenode. Herostratus (talk) 14:27, 17 September 2010 (UTC)[reply]
This technically is a forum. Though once LiquidThreads is rolled out ... ViperSnake151  Talk  16:33, 21 September 2010 (UTC)[reply]

A single place to go for unstructured discussion has advantages (friendly, good for newbies, and encourage all sorts of discussion). IRC kind of does that, but a lot of people don't use IRC (including me). An onwiki single place to go doesn't exist because it would become overloaded with everyone going there (even if only to be directed elsewhere). Imagine WP:ANI multiplied by every other traffic heavy page - the idea of a central place has some appeal, but it's just not workable on wiki. Hence IRC. Rd232 talk 16:55, 21 September 2010 (UTC)[reply]

New etiquette board?

Evidently, there is a proposed new process board for WP:Etiquette or WP:AGF issues, which I stumbled upon by following links at the former guideline this morning. I don't see that this has been widely publicized and felt it might be of interest to those who monitor this board. Please see Wikipedia:Antiquette. --Moonriddengirl (talk) 11:57, 21 September 2010 (UTC)[reply]

  1. Be polite, please and Be civil - When they send out rude comments and not using manners such as "Please", "Thanks", "Cheers", "Sorry", etc. Like for example, when a newbie aor inexperienced editor that is mature and well-behaved that makes a mistake (but doesn't show any bad behaviour), they scold or criticize the editor when the editor didn't even know it was inappropriate. They are just degrading and biting the newcomer.
  2. Give praises when due - When I have been constructive abundantly to the project, I haven't gotten any praises for those good edits, and I would like to know why.
  3. Do not ignore questions - When I see that there are questions (sensible and appropriate questions) that are unanswered.

The Etiquette guideline is not the only guideline people violate. Assume good faith is the other guideline people violate, (fewer times this guideline gets violated than Etiquette) when all these people keep giving offensive myths and other inaccurate scoldings, criticisms, and degrades to good editors.

Remember: If you want to give ANY negative information about another user, also give positive information about that user.

Perhaps, all these users that have been identified as "antiquette" Wikipedians could give explanation why they violated the Etiquette guideline:

  1. (Counterproductive list of users redacted) — Gavia immer (talk) 01:25, 25 September 2010 (UTC)[reply]

Hoping all of you can understand all of this. Thanks. -Porchcrop (talk|contributions) 00:00, 25 September 2010 (UTC)[reply]

Proposal for Wikipedia in American English

If you go to List of Wikipedias, you may notice that although it appears that are many different languages in which Wikipedias exist on the net, some are actually different versions of the same language (there are separate entries there for Bavarian, German and Alemannic - the latter I take to mean Swiss German as opposed to High German). In the same way, do you think we could have two Wikipedias in English - one in U.K. English, one in American English? This would certainly clear up problems such as how to spell "ageing" (ageing in U.K. English, aging in U.S. English - go the article Ageing and visit its talk page and you will see my point. ACEOREVIVED (talk) 23:29, 21 September 2010 (UTC)[reply]

No. ♫ Melodia Chaconne ♫ (talk) 00:06, 22 September 2010 (UTC)[reply]


There is no question that the issue is a perennial irritation and will be for the foreseeable future. I personally despise the spelling aluminium and deplore the Chemistry WikiProject's choice to favor it just because IUPAC does.
But this is a minor point. On the other hand, the loss of expertise on both sides of a split en.wiki project would be anything but minor. We muddle along with WP:ENGVAR; it isn't perfect but it mostly works. --Trovatore (talk) 00:14, 22 September 2010 (UTC)[reply]
It works perfectly fine. The very minor differences between American and British (and Australian, and South African, and Canadian, and etc. etc.) versions of the English language are not really enough to justify the split into seperate Wikipedias. There are a few minor usage differences, and some small differences in vocabulary that do no more than cause a second or two of awkwardness. Articles written in ostensibly "British" English are perfectly understandable to an American reader (or Australian, or Canadian, or Kenyan, or Bermudan, or Jamaican, or...), so there's no impending need to create a new Wikipedia just so one can use the words "petrol" and "lift" while the other uses "gasoline" and "elevator". --Jayron32 00:27, 22 September 2010 (UTC)[reply]
Then you get editors like me that use a hopeless muddle of British and American spellings. To date, the only time I have been absolutely perplexed was when a Haynes manual told me to rub down my engine block with paraffin to get it clean. I had no idea that they meant kerosene, not candle wax.—Kww(talk) 00:45, 22 September 2010 (UTC)[reply]

Regional differences between variants of German are much greater than in English, especially in written form. I'm a native German speaker, and Bavarian description in Bavarian and Alemannish description in Alemannish are sort of decipherable, but barely a word is spelt exactly as in standard German. Rd232 talk 06:34, 22 September 2010 (UTC)[reply]

The regional differences in English are not enough to justify separate versions, nor are we likely to see standardization on one particular national variant. Much as Americans may think they dominate the world, they are only a small fraction of the English speaking world. Besides, as soon as we get American English and British English Wikipedias, we'll have to have Indian English, Singaporean English, Ebonics, Australian English, South African English, and so on, it's not practical for what amount to trivial differences. Triona (talk) 07:05, 22 September 2010 (UTC)[reply]

  • Out there in the real world, people used to read dozens of English-language books, magazines and newspapers that were published on the other side of the Atlantic (or of the world), and got used to most of the variations, with only a minor irritation or grumble here and there. Now they go to different websites. There is a North American BBC site, but I don't think it changes its spelling to U.S., while I don't think CNN Europe changes to British spelling. While an Anglicism or Americanism will periodically remind one where (or by whom) something was written, most of the time you have to be paying specific attention to small details even to notice the national style. [I had to be bilingual in my youth because I crossed from London to New England when I was 6, back again at 8, and then finally back in New England at age 11 (leaving for California at 17). But the differences were usually easily surmounted. If you live in another English-speaking country, you will find how very small the differences really are; they're enough to distinguish, without significantly impairing communication except at the slang or local dialect level which would confuse one at home. The successive introduction of the telephone, gramophone/phonograph, wireless/radio, talking pictures, television, mass air travel and the Internet, plus several wars in which the Anglophones served together, greatly reduced differences in the spoken language, too.] And where there are genuine ambiguities and obscurities, Wikipedia should clarify them (e.g. paraffin/kerosene, faucet/tap)—rather than leave the confusion as some kind of token of authenticity—which I think is a pillar of Wikipedia:National varieties of English, or should be. There are, as yet, no separate Wikipedias for the versions of French, Spanish or Portuguese spoken in the Americas as opposed to their European versions, although there are some very small little-used Wikipedias for Flemish, Walloon, Luxembourgish and Afrikaans. See meta:List of Wikipedias. —— Shakescene (talk) 08:00, 22 September 2010 (UTC)[reply]

Many thanks for all the comments - I see that the proposal soon stimulated an interesting response. I do appreciate that there are probably greater variations in different versions of German than of English, although I do remember reading in a Reader's Digest back in the 1980s that a publisher had already published the Dictionary of U.S. English. ACEOREVIVED (talk) 19:00, 22 September 2010 (UTC)[reply]

  • There's no question that English has dialects. There's always going to be tension between Yanks and Brits on WP over which one is the better one. But we can be better than that; we can overcome these tribal temptations and work on a basis of mutual respect. WP:ENGVAR is an imperfect but mostly workable framework for doing so.

    Certainly others have made other choices. There are two Norwegian Wikipedias — two, for a language without a huge speaker base, but mutually comprehensible with Swedish! I haven't looked at them much, but their depth of coverage must surely suffer enormously. The better choice would be to merge with Swedish WP and come up with a SCANDVAR guideline to work over the rough spots. --Trovatore (talk) 19:15, 22 September 2010 (UTC)[reply]

  • No need to rely upon your memory. There's an encyclopaedia around here, wherein you can read all about Noah Webster. ☺ Uncle G (talk) 19:34, 22 September 2010 (UTC)[reply]

One minor point on the English-is-more-mutually-intelligible-than-German debate, that coincidentally I was just talking about at User talk:TFOWR: I have, on quite a number of occasions, seen articles listed for deletion as "patent nonsense" simply because they were written in Indian English. If there's ever a split, which I doubt, that would be where it is most likely to occur, I conclude from experience. Indian English writers seem to have the hardest time at the English Wikipedia, and are the largest group most often overlooked in the perennial British/U.S./Commonwealth/American discussions. Uncle G (talk) 19:34, 22 September 2010 (UTC)[reply]

No, please for the sake of my sanity! As a Brit who moved to the US 15 years ago at the age of 35, I have enough problems figuring out which version of English I do/should speak/write and for which audience... – ukexpat (talk) 19:56, 22 September 2010 (UTC)[reply]
The obvious solution is to use Canadian English, given it is a mixture of the two! ;o) Resolute 20:05, 22 September 2010 (UTC)[reply]
You've got your toque on too tight. Go have a butter tart, you'll feel better, eh? :-) --Trovatore (talk) 20:10, 22 September 2010 (UTC)[reply]
Ahh take off, ya hoser! Resolute 20:21, 22 September 2010 (UTC)[reply]
Isn't the obvious solution for those who find the confusion here too much to use Simple English Wikipedia instead :) Dmcq (talk) 21:07, 22 September 2010 (UTC)[reply]

I suspect it is a bigger problem than we think, though I think the solution is a different sort of multi dialect wiki not different wikis per dialect. We aren't as successful at recruiting editors as we once were; Not so much here in the land of warm beer, but definitely in the land with with extra Zs and fewer Us on the keyboards. Our classic routes to recruiting editors were; Newbie spots vandalism and fixes it, submits a new article or fixes a typo. Nowadays the vandalfighting bots and hugglers are getting rid of the vast majority of vandalism before a newbie has a chance; New pages is a newbie biting trainwreck; And we have relatively few genuine typos but loads of things that look like typos to your PCs spellchecker. I fear that we lose too many genuine good faith newbies who find their laborious adding of "ation" to every sixth word on the article on a British King has been reverted with a snarky and unintelligible comment. My preferred solution to this is to put icons on the screen so that people can click on the US, Australian, Canadian, or British flag and have Wikipedia displayed in the dialect of their choice see -Strategy:Proposal:More_multi_dialect_wikis. Or we cld mk txt spk wki Lol ϢereSpielChequers 21:24, 22 September 2010 (UTC)[reply]

We await your solid and 100% accurate contribution to the codebase to automatically and seamlessly translate between the multiple dialects of English. (will it tell me I have an apartment tire? or that a character in a movie elevatored his friend off the floor?) --Golbez (talk) 21:41, 22 September 2010 (UTC)[reply]
I suspect that at some point we might need to do some AWB work to establish which bonnets were hoods and which were hats. But I understand we can have 50,000 rules before we need to upgrade the software, and that would get us a lot more than 90% towards the goal. ϢereSpielChequers 22:21, 22 September 2010 (UTC)[reply]
So out of curiosity, what would the rule for flat vs apartment look like? I think you're making this sound much easier than it actually is. Chinese can switch back and forth because, in my understand, that is primarily an issue of the characters used, rather than the words. --Golbez (talk) 22:33, 22 September 2010 (UTC)[reply]
Flat vs apartment is one of the easier ones, as apartment would display as flat in the English version you could just use AWB or similar to change flat to apartment where the English meaning of flat was used. The vast majority of the differences are as simple as:


English - American English translation
English translation rule American English
Colour = Color
Favour = Favor
centre = center
Flat < Apartment
Pavement =< (except Limestone pavement doesn't change) Sidewalk
Under the bonnet = Under the hood
True that would only do 90% of it easily, and there would be some work involved in getting the other 10% right. But 90% is better than nothing, and judging from the number of people who come here wanting to change things between different versions of English I don't anticipate that there would be a shortage of new editors to do the rest - if anything this could recruit a whole new generation of wikipedians. It does get complicated for words like Fag, and I imagine we'd need some sort of system to store such words as Fag (cigarette) and then display them as fag or smoke. The biggest advantage of that would actually be for the large and growing number of people who use EN Wiki via machine translators, as these are amongst the words that are most likely to throw translators. ϢereSpielChequers 12:09, 23 September 2010 (UTC)[reply]
So we would have to either use another term for "flat tire" (deflated tire?), or we would have to use a template to say {{not-us-english|flat}}, or what? Also, will it know not to change quoted titles? I don't think we should have an article discussing The Colour Purple. Etc etc... what you're suggesting here is machine translation, nothing more, and there's a reason machine translation isn't used on a large, automatic scale. --Golbez (talk) 12:27, 23 September 2010 (UTC)[reply]
You weren't perchance referring to The Color Mauve, now, were you? ;-) — Ah, the benefits of a trans-Atlantic childhood ! (everything that you learnt so well in one school or from one group of friends was of course absurdly wrong in the next.) —— Shakescene (talk) 18:05, 23 September 2010 (UTC)[reply]
No, that's why I showed that as a one way rule - Apartment can be displayed as flat to English readers but you can't go the other way for American English readers without marking which meaning of flat you are using, and for words like flat where one meaning predominates you'd probably leave that as the default. Words in quotes would also need to be left, and you'd probably need a {{no translate}} template. I agree that if this was nothing more than a machine translation you'd only get 90% of the job done, and the remaining 10% would require semi-automated editing. But the 90% is probably worth doing in its own right, its the remaining 10% would greatly improve machine translation from EN wiki. ϢereSpielChequers 13:12, 23 September 2010 (UTC)[reply]
Nothing is that simple. "Four apartment buildings were demolished" is rather confusing if it is rendered as "four flat buildings were demolished". dramatic (talk) 07:46, 26 September 2010 (UTC)[reply]
First of all, I apologize for misunderstanding the meaning of your symbols with regard to flat vs apartment. But I disagree with your assertion that it's "worth doing in its own right". What of the sheer effort involved to not only template but maintain the templates for the many millions of words that shouldn't be converted, or could be converted incorrectly? For example, marking every single instance of the word Center in Verizon Center, plus the number of times it's referred to across the Wiki, times the number of other Centers that would be incorrectly converted? No thank you, I'll take an re over an er any day. This is not exactly a solution in search of a problem, but it's certainly one that far outweighs the problem. It's a shotgun brought to kill a flea. --Golbez (talk) 14:31, 23 September 2010 (UTC)[reply]
I think we have very different perceptions as to the size of the task, the potential benefits and who would take on the burden of doing the work. Many millions of words that shouldn't be converted or could be converted incorrectly would mean an average of more than one such anomaly per article. I very much doubt if it would be that high, but I agree that above a certain size a task can become daunting. However I'm not convinced that we have yet quantified the size of the task. As for the benefits, I believe you underestimate both the number of Americans who are thrown by English spellings and especially the amount of machine translation, or machine assisted translation that is already going on. I suspect it would be possible to quantify the number of newbies who leave after an Engvar warning, and someone else will doubtless have other theories as to why our editor base under-represents the USA, Google translate might even be willing to calculate some stats for us as to its use on Wikipedia. As for the sheer effort, this is a volunteer project, so no-one need put effort into this who doesn't think it worthwhile - we could even have a don't care option for those who want to see articles in the dialect they were written in. In my view this is more a few spots of carefully applied lubrication to a machine that has some stiff joints rather than a shotgun to shoot a flea, but if someone can quantify things I'm happy to review my assumptions ϢereSpielChequers 15:09, 23 September 2010 (UTC)[reply]
If you really want to make things friendly for American editors, you can please stop distinguishing "American English" from "English". You can say "British English", "UK English", or "Commonwealth English". Unmodified "English" fully includes American English. --Trovatore (talk) 15:15, 23 September 2010 (UTC)[reply]

Thank you for an interesting discussion - perhaps we should leave things as they are, I can certainly understand American English.ACEOREVIVED (talk) 21:29, 22 September 2010 (UTC)[reply]

arbitrary break number 1

Yes, no one seems to have pointed out yet that if I were really keen to start a Wikipedia in American English, I could go the WikiMedia Incubator (go to List of Wikipedias and see the talk page there). However, I did want to start this discussion here first. I think that the main points from the above discussion can be summarized as follows:

1. Although there are certainly differences between U.K. English and U.S. English, these are probably not as great as the differences between different forms of German. 2. There are already Wikipedias in different forms of English - such as this one versus the Simple English Wikipedia or the Anglo-Saxon Wikipedia (then again, there is the Lowlands Scots Wikipedia - since Lowland Scots and English are intelligible, I shall leae it for others to decide whether this is effectively an English Wikipedia, although I can see the arguments that it is not). 3. The similarities between U.S. English and U.K. English are close enough for us to use the one Wikipedia (after all, it would mean goodness knows how much hard work to shift articles from one to another).


I would also like to add these comments. There are certainly differences between U.K. English and U.S. English, but some U.S. English words are so commonly known in Britain today that some people use them. We could all understand the terms "candies" and "cookies" for sweets and biscuits, and the word "mail" is almost used here as a synonym for post. There are, it is true, some words that have not caught one on this side of the pond (we always say "pavement" and never "sidewalk"). There are some languages that have Wikipedias in different forms of the same language - as one of the above Wikipedians noted, the New Norwegian and Dano-Norwegian Wikipedias - but these are probably justiied. After all, Danish and Norwegian are mutually intelligible, but given that these are quite definitely different languages, they would still need separate Wikipedias.

Thank you again for all the above comments,they are all apppreciated. So, many thanks indeed, ACEOREVIVED (talk) 23:17, 22 September 2010 (UTC)[reply]

But I say "footpath" and never "sidewalk", and if I say "pavement" it's a technical term for the surface of the road. Oh no, we need a separate Wikipedia in New Zealand English! Fortunately, I understand all of the above. dramatic (talk) 07:53, 26 September 2010 (UTC)[reply]
Why should the Americans be the ones to leave anyway? Start one in British English :-). No, don't, really; the status quo has its irritations but is better than any other idea I've heard, a conclusion you seem to have come to as well.
I would point out also that the Wikipedias for small languages such as Plaatduutsch (or however you spell it) or Lowland Scots are a bit different in purpose. They are not really there as the primary reference for speakers of those languages, who surely must be competent in some better known language as well (unless they're subsistence farmers or something, in which case they are not likely major users of online encyclopedias). Rather, those WPs are intended to help advertise and preserve the language in question. Neither American English nor British English needs that sort of help. --Trovatore (talk) 23:25, 22 September 2010 (UTC)[reply]
Excellent point. Rd232 talk 13:02, 23 September 2010 (UTC)[reply]
Funny you should mention Scots. Over at sco.wiki, they've adopted a policy quite different to WP:ENGVAR: the various Scots dialects are deprecated, and a generalied version of Scots is used instead: sco:Wikipedia:Spellin an grammar#Raesons for this policie - "ti dae awa wi arguments ower the richt spellins o words. That wastes time better spent writin new text for airticles." I've tended to be a big fan of ENGVAR here, but the sco.wiki approach has some merit - we're here to write articles, not argue over spelling. The problem here is possibly wider than we might think, as well - it's not just American English vs. "British" English - there are several varieties of English within Britain, with Scottish English being used for Scottish subjects, but not outwith that area. Non-American English includes more than just British English: New Zealand articles are written in an English understood by most Pākehā, with terms that are maybe less familiar to other English speakers. Now, I quite like this, because I quite like the quirkiness of our language. But it's less than clear. New Zealand articles aren't written exclusively for Kiwis. Non-Scots want to learn about Scottish topics. Expecting readers to learn several varieties just to read about different topics seems less than ideal. It's not a huge burden, but it's still a burden. I'm not an American English speaker, though I have a great deal of respect for Noah Webster, but I'd be inclined to accept American English as a standard on en.wiki. However... would it be possible to have some sort of technological magic, where a reader could select their preference (on a page or cookie level, if necessary, so that we don't disenfranchise IPs) and the wikicode {{magic|sidewalk|en-us}} renders as pavement for British English readers? TFOWR 13:23, 23 September 2010 (UTC)[reply]
If we want to make wikitext even harder to get grips with for newbies (and harder to edit for all), then templating every variant word is a great way to go. If one day Mediawiki can separate refs from body text properly, then that approach might possibly one day work for variant words and phrases... but I think the maintenance implications for software developers and Wikipedia editors are being underestimated. Rd232 talk 13:48, 23 September 2010 (UTC)[reply]
I missed the part where I insisted that newbies had to get formatting absolutely perfect! ;-) List defined refs already exists, but that's a different matter entirely. Back on topic, we already use templates for refs and locations, etc, and we currently don't expect perfection from new editors. Article development is iterative: with this template a newbie would write "sidewalk", and a more experienced editor would - instead of changing it to "pavement" ("per ENGVAR") - add the template. I'm not convinced there's much dev work here - some Ajaxy magic to hide/show a div when the setting changes. The real work is for editors (experienced editors, not newbies) who need to maintain a table in a template. But realistically - once the template is set up, how often will it need to be changed? TFOWR 13:57, 23 September 2010 (UTC)[reply]
It's not the expectation of perfection on the part of experienced editors, it's how scary it looks and how complicated to read and understand and edit, and the implication carried from looking at it that it's all very technical and you need to be some kind of expert. The more editing wikitext resembles programming, the more we drive people away. Rd232 talk 19:11, 23 September 2010 (UTC)[reply]

I have no doubt that the way they are doing things at the Chinese Wikipedia would work for us:

  • Global translation rules
  • Supplementary per-article translation rules, so if you use an unusual word that needs translating you just add it to the local translation table
  • Markup to use in the rare cases that the other methods don't work and the translation of a phrase must be hand-coded.

This system would close a few tins of worms and open a few new ones. And I think there is no good solution for the problem of article titles that are in one of the variants. On one hand I think it's cool and would like to see it. On the other hand it seems a lot of effort for very little gain.

There is also the political dimension: In the age of globalisation there is a huge new unifying force for the English language. So far Wikipedia is a significant part of it, because it helps to make editors and readers a lot more familiar with standards of English other than their own. Personally I think that's a good thing and should not be abandoned. But of course it is only tangentially related to Wikipedia's norms and values. Hans Adler 14:22, 23 September 2010 (UTC)[reply]

I think the current rough solution is the best. The risk is that standardising on American English wrecks the ability for people like myself (UK) to contribute - simply because there is no way I will be able to contribute in American English :D (not so much the spelling differences which I could work around but for the colloquialism). Even worse, articles on UK (and other non-US English speaking countries) topics will risk being incomprehensible to readers in those countries - to take a bad example, I doubt "hood" is as widely known as the US version of "bonnet" as you expect. I see this first hand; the company I work for also randomly sells high end outdoor catering appliances - we had to rewrite our entire website prose for the US market because it made no sense to any of you guys :) I think the current implementation is the best - ok so it is not standardised, and without strict policy definition it risks arguments and edit wars over single words. But on the other hand it leniently allows for the right language in the right place, where that does not make sense on a local level then it is easily changed. <joke>(also; we were first :) so if we standardise on anything it should be UK English ;))</joke> --Errant [tmorton166] (chat!) 19:32, 23 September 2010 (UTC)[reply]

Without wanting to get too pompous or pontifical, English has always been an evolving language, sometimes (in my humble opinion) changeing † for the better and sometimes for the worse, and always absorbing an enormous number of outside influences in every generation while discarding other features both "native" and imported. The spread of popular music, film, television and the Internet (as well as physical travel and migration) has only accelerated this process. Pinning down a "British" Wikipedia that Lord Reith would hardly consider acceptable, or an "American" one that would cause Noah Webster to weep, is pretty futile. While the Oxford University Press's U.S. editions do indeed use American spelling and punctuation, most people don't expect to see the Oxford Dictionary of the English Language spelt in a U.S. variant, or the Columbia Encyclopedia in a British one (the Columbia Encyclopaedia). And that's not considering all the recent influences of Caribbean, African, South Asian and East Asian English, plus the influences brought by 1st and 2nd generation Commonwealth immigrants to Britain, Canada and Australasia, and by Hispanic, Asian and Caribbean ones to the United States. Much of that vocabulary, grammar and style, as with most variations in every generation, is of course transitory colloquial street speech that will not last, but some will seep in directly or indirectly; the changes will assimilate so completely that first-year student of philology a century from now will need to do research to recognize their origins. You certainly don't need different editions of Wikipedia to handle all that; just commonsense and a great deal of care to ensure that a word or phrase you're using isn't either obscure or outright misleading to someone in a different country or with a different background. ¶ Because of its nature and origins, Wikipedia will always be written in a strange cosmopolitan semi-popular/semi-academic style, complete with arcane conventions, that no human being would ever use anywhere else, but that's Wikipedia. —— Shakescene (talk) 19:47, 23 September 2010 (UTC) † [I was going to go back to delete the "e", when I realised/realized that this once-common, and not-incorrect, British spelling makes a relevant point.][reply]

That's a good point; unlike many languages (French in particular comes to mind) which have governments which laughably claim ownership over the language and attempt to control it, English has no such authority, and thus grows and changes organically. It's is famously as impure as a cribhouse whore, so why even attempt to pin down two versions, let alone the hundreds that are in use? --Golbez (talk) 19:59, 23 September 2010 (UTC)[reply]
Thanks for reminding me of a point I forgot to make in my sea of other prose: although there have been many attempts to establish one, there is as yet no credible or widely-recognized/recognised (let alone legally binding) English-language equivalent of the Académie Française or the Real Academia Española (which, I learned from Wikipedia, has roughly 20 matching official authorities, one for each of the non-Iberian Hispanophone countries, including an embryo one for the world's second-largest speaker of Spanish, Los Estados Unidos de América. Yet, although there's a Catalan Wikipedia, there is as yet no Latin American or Ibero-Spanish Wikipedia, let alone a Mexican, Cuban or Argentine one.) After decades of wrangling and heart-wrenching, the linguistic authorities in Portugal, Brazil, and the other Lusophone countries finally came to an agreement (almost a treaty) about which accents to keep and which to retire (cf. a similar debate about the evolution of German among the West German, East German, Austrian and Swiss authorities), but even if they had not, I think Portuguese Wikipedia would have remained a single Project. —— Shakescene (talk) 20:16, 23 September 2010 (UTC)[reply]
English has no such body — and a good thing too. Those academies are a terrible idea. They MUST NEVER EVER EVER be tolerated in English. --Trovatore (talk) 01:49, 24 September 2010 (UTC)[reply]

Nonsense suggestion. All these variants of English are easily understandable to anyone with understanding of one. This is hardly like variants of some other languages eg Chinese YellowMonkey (new photo poll) 02:05, 24 September 2010 (UTC)[reply]

  • Just a little philosophical aside- wouldnt it be interesting to split English Wikipedia in two and see how each evolves, not spelling-wise, we already know what changes to each article would occur, but as far as policies, guidelines, consensus-decisions and such. How would different problems, both current and future ones that pop up be handled in each Wikipedia... as it is each language Wikipedia does have different "rules" and policies down to the smallest thing. I would find it interesting in how consensus is reached in each Wikipedia and how they may differ, even in the smallest aspects, after 5, 10, and 20 years.Camelbinky (talk) 01:10, 27 September 2010 (UTC)[reply]
As an Australian English user I can comprehend just about every other version of English. I just note that probably every second day I find myself reverting an incorrect spelling correction, almost always from UK to US English, and almost always by an IP editor (who is never going to read this stuff!) I feel that this Wikipedia, using all versions of English, is actually providing an education to those who don't yet know that there is more than one "correct" form of English spelling out there. HiLo48 (talk) 01:08, 27 September 2010 (UTC)[reply]

arbitrary break number 2

It seems to me that (1) a "main" English wikipedia should exist. (2) And that any variant English wikipedia should be accessed via tabs , like the Chinese wikipedia, which uses tabs for different Chineses. (3) should these come about, a new reviewer flag would be needed so that any new contribution to a dialectal article branch should also be in the main branch article, and that the new dialectal article edit does not go live until the main article is checked for consistency with new facts or imrpovements, but that's quite a bit of work. There would not no auto-sighting on the dialectal versions, going live would require a log entry stating the check was done.

I wouldn't want to read 6 different English variants just go get information, by rereading material over and over again, just because a fact appeared here and not there. 76.66.200.95 (talk) 06:02, 28 September 2010 (UTC)[reply]

A bot platform

I am developing a bot platform and I like to see if the project received wide support before continuing. d'oh! talk 13:30, 23 September 2010 (UTC)[reply]

The idea looks fine. As with any programming project; get some code done first :) One of the things that comes from experience is that it is really realyl easy to design a framework - but building it is another matter :) it just gets left till the spec is perfect. Get hacking with some code and show us what it can do. You will find it progresses a lot faster --Errant [tmorton166] (chat!) 19:35, 23 September 2010 (UTC)[reply]
Good point, I have been developing and I will have something to show off soon. d'oh! talk 12:57, 26 September 2010 (UTC)[reply]

System for Literature

Hey guys, I just stumbled upon this article and saw a potential for all of wikipedia. The article is this The Sorcerer's Apprentice. The poem isn't listed, and i know that it is the norm not to. What I am proposing is a resource on open licensed literature,(in this case it is 14 verses and the author has been dead for over 100 years) that stores the literature so that it can be linked to on the article page. It could be as simple as a (show) button.

What do you guys think?--Iankap99 (talk) 21:24, 23 September 2010 (UTC)[reply]

Protection conflicts - make 'em work like edit conflicts

Maybe I missed it in the archives (I looked).

It seems every day, when I protect an article, there's an occurrence of me and another administrator protecting it at the same time. When each of us pull up the protection form, the log at the bottom shows the article isn't currently protected. But then, inevitably, one of us submits the form first.

It would be real nice if, when I submit the protection form, a message similar to "Edit Conflict" would come up saying that an article protection is already in place, show me the most recent log entry, and ask if I want to override it with my settings. Sort of like what happens when I fail to include an edit summary: I am asked to confirm my submission.

Is there any reason why some sort of notification about protection conflicts between admins couldn't be implemented? ~Amatulić (talk) 21:26, 24 September 2010 (UTC)[reply]

Request for revision deletion page

Recently, {{Copyvio-histpurge}} was nominated for deletion, and it was basically said that it should be replaced with some request page. I agree on this, and thus thought of simply doing some draft myself. So, I was wondering what you think of the general idea and what about the draft I started? I know it's still in the very first beginning, so I'd be happy to hear suggestions. Also, feel free to immediately fix any possible mistakes that you notice on the draft. --The Evil IP address (talk) 22:47, 24 September 2010 (UTC)[reply]

There's an existing, ongoing discussion on the Administrators' Noticeboard, specifically Wikipedia:Administrators' noticeboard#Time for WP:RFRD?. This should probably be merged to that discussion, though of course the original discussion quite possibly should have happened here instead. — Gavia immer (talk) 23:14, 24 September 2010 (UTC)[reply]

Better way to watch for recreated pages

New users sometimes recreate pages soon after they've been speedily deleted. 99% of the time it doesn't resolve the reason for deletion. Watching the deletion log for bluelinks works somewhat, but it would be better to have a more explicit/automated way of watching for this. How about extending Special:NewPages to include the time since previous deletion if any (perhaps with some highlighting of recently recreated ones), or some other way (editfilter/bot/etc)? Or does something like this already exist? Quarl (talk) 07:13, 26 September 2010 (UTC)[reply]

The most feasible way of doing this would be to create a tag for this, I think. Perhaps for exact titles that are recreated within a certain time of each other. I'm not in love with tags, though. Mostly because even if the edit isn't "bad", the tag remains on that edit forever (afaik). Killiondude (talk) 00:21, 27 September 2010 (UTC)[reply]

MY Wikipedia

My Wikipedia By Mark Johnston

What: My Wikipedia

Purpose: Adds personalization, tracking, and meta storage functionality to Wikipedia.

Functionality: Gives users the ability to bookmark, track, and share favorite Wiki pages in easy-to-reference hierarchical structure

Justification: Currently there is no way to bookmark or track visited (or "favorite") Wikipedia pages. A high percentage of Wikipedia users are educators and others who wish to build and maintain a personal knowledgebase online. Giving users the ability to store favorite pages would allow them to build repositories of information that would 1) Assist life students in their personal education journeys; 2) Help users organize information in a manner that suits their learning style; 3) Increase the value of Wikipedia to users; 4) Expand Wikipedia to be more than just a database of information, but one that is meaningful to users based on their unique knowledge needs.

Proof of concept narrative: Place an, e.g., ADD THIS PAGE TO MY LIBRARY button on all Wikipedia article pages. This way people can create their own, custom virtual encyclopedias comprised of only content they select. They would have the ability to create "sets" and within a "set" could reside a hierarchy of custom (or default) "Books" to which they could assign articles. Example:

I create a Set called "Biblical studies" Within this set I create a bunch of Books on various topics (i.e. Good vs Evil)

One day I come across an article about Marquis De Sade. I click the ADD TO MY LIBRARY button. I then am prompted to select a Set and category to assign the article. (i.e. I select Bible Studies for the Set, and "God vs Evil" as the Book). I might further be able to assign an even narrower meta category like "Opponents of Christianity" and keywords such as "sadist" as well.

Then whenever I wanted to access my Set, I would have a page for the set showing all the categories and articles assigned to it. Or maybe I just have a simple search box that I can search by keyword. But in any event it's MY Set and only contains articles I have assigned to it. I can then share my sets and books with others. Thence it adds a social component to Wikipedia too

Sample My Wikipedia page

Welcome back, Don Corleone

MY SETS

Biblical Studies

Indented line:Indented line

New Testament Articles
Old Testament Articles
—Preceding unsigned comment added by 98.255.42.130 (talk • contribs) 23:45, 26 September 2010 (UTC)[reply]

Make Wikipedia:Books in your userspace. Or use Delicious (website) or your browser's bookmark organization tools. --Cybercobra (talk) 23:53, 26 September 2010 (UTC)[reply]
Or register a user and do this on your user page, it is not that hard. Graeme Bartlett (talk) 11:50, 28 September 2010 (UTC)[reply]
Some of the requested features already exist. Registered users have a "watchlist", where they can check recent changes to specific articles of their election. Articles are already included inside a hierarchical structure, the categories (located at the bottom of the page). Personalization is also possible by selecting "Skins", another feature available to registered users.
On the other hand, it's better to have a single article about Marquis De Sade than dozens of articles "belonging" to specific users, as it allows all of them to work toguether, which is always better than many people working on their own. Consider for example that you find a common mistake or misunderstanding in it and fix it. In a single article, you can fix it, explain it at the talk page, and that's it. Otherwise, you would have to repeat the process dozens of times, or worse, fix a single one and leave the others with the mistake. MBelgrano (talk) 12:04, 28 September 2010 (UTC)[reply]
Why does something tell me this may be some sort of homework assignment that someone decided to post here for some reason? ♫ Melodia Chaconne ♫ (talk) 14:01, 28 September 2010 (UTC)[reply]

Copying userrights from sysop to bureaucrat

I would like to see if there are any objections to copying the following userrights from the administrator group into the bureaucrat group:

  • Move pages with their subpages (move-subpages)
  • Not create redirects from source pages when moving pages (suppressredirect)
  • Override the title blacklist (tboverride)
  • Use higher limits in API queries (apihighlimits)
  • Search deleted pages (browsearchive)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)
removed from original proposal as not strictly necessary
  • Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
  • Bypass automatic blocks of proxies (proxyunbannable)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)

This would allow a bureaucrat to perform their duties without requiring a sysop flag. –xenotalk 19:28, 27 September 2010 (UTC)[reply]

Aren't all crats sysops anyway? Is this not a solution in search of a problem? → ROUX ₪ 19:29, 27 September 2010 (UTC)[reply]
The problem is that a bureaucrat can't shed his or her sysop flag without losing abilities required for the job. (And, while no non-sysop has ever been successful at RFB, adminship is not a requisite.) –xenotalk 19:31, 27 September 2010 (UTC)[reply]
I guess I'm not understanding.. why would they need to shed the flag? Also, if it is (theoretically) possible for a non-admin to become a crat, isn't that an argument against adding admin privileges to the crat flag, as then crats would have abilities which the community hasn't approved at rfa? → ROUX ₪ 19:37, 27 September 2010 (UTC)[reply]
I can think of at least two bureaucrats who have considered relinquishing their sysop flag but continuing to perform their duties as a bureaucrat. As for your second sentence - the abilities would have been added prior to any potential successful non-sysop RFB so the participants would know what they were getting into. (This is a bit of a red herring, as it's a highly unlikely scenario. The primary reason is to allow bureaucrats to resign their sysop flag if they so desire.) –xenotalk 19:39, 27 September 2010 (UTC)[reply]
I dunno. I'm not objecting, really, just not understanding why the need to remove the flag. Plus this would set up (even more than already exists) a more explicit 'leveling up' thing. → ROUX ₪ 19:42, 27 September 2010 (UTC)[reply]
I suppose a bureaucrat could simply declare "I am no longer using administrative buttons", but they'd still be there, and (quite likely) people would still request they use them to perform various tasks (unaware of their declaration or otherwise). –xenotalk 19:45, 27 September 2010 (UTC)[reply]
Ah.. so you are suggesting instead of the crat flag being an add-on, it is a phase shift? One or the other? Are there any crats who have stated they will no longer be performing admin duties? → ROUX ₪ 19:48, 27 September 2010 (UTC)[reply]
Not one or the other, and it would not change the current RFB promotion process. But it would give bureaucrats an option to relinquish their sysop flag without losing abilities integral to the bureaucrat role. For your second question - I'm not sure. –xenotalk 19:50, 27 September 2010 (UTC)[reply]
While I understand the need for the additional move privileges and access to view deleted material while performing username changes, why would a bureaucrat who is not trusted by the community with any other access beyond that of a normal user need to bypass IP blocks or use the rollback function? --Allen3 talk 19:54, 27 September 2010 (UTC)[reply]
I must admit, the rollback was something I threw in there to prevent having to have bureaucrat, rollback, but I'll strike it. For the ipblockexempt and proxyunbannable bits, I'll have to ruminate on it to see if I agree that they shouldn't be included (struck for now). FYI the viewdeleted parts are also for evaluating statements made at RFA about candidates' deleted histories. –xenotalk 19:59, 27 September 2010 (UTC)[reply]


For the record, I am one the bureaucrats Xeno is referring to above. I toyed with the idea of just picking up my 'crat flag for awhile and leaving the sysop flag down for awile. Xeno's comments here, though, turned me off to the idea. Just peeked through my logs, I've done one deletion since returning at the beginning of the month, and no blocks. But I have done renames. I've been trying to focus my efforts on article creation at the moment, as that's why I came out of retirement. Useight (talk) 20:02, 27 September 2010 (UTC)[reply]
Is there any harm in a crat just keeping his/her sysop flag even if they don't use it much? I mean, this just sounds sort of weird, and why would a crat really need the option of not having their mop? I don't see any harm for actively editing users keeping their rights, even if they don't use them much. (Now, for users who haven't edited in years, that's a different story.) But I just don't see when this would really be necessary. It's not like being an admin and a crat is hurting you or anyone else, I'd hope. /ƒETCHCOMMS/ 21:40, 27 September 2010 (UTC)[reply]
There are any number of reasons why someone might want to relinquish the sysop rights. Just ask any sysop requesting voluntary removal at meta why they've done it. –xenotalk 02:19, 28 September 2010 (UTC)[reply]

IMO, this is a solution without a problem that will waste both the community's time in discussing it and developer's time in figuring updating sysop and bureaucrat groups everytime updating the sysop group becomes necessary. I mean, I guess we could if we want, but I don't think it is worth it to even bother discussing it. NW (Talk) 21:43, 27 September 2010 (UTC)[reply]

I agree with NW. If a crat wants to stop doing sysop things, they should just stop doing them. Its not like there's a limit on the number of sysop accounts we can have. Mr.Z-man 22:15, 27 September 2010 (UTC)[reply]
While it is not required for a crat to be an admin, I can't imagine the community electing one who isn't. I don't see why a crat would want to stop admin roles either, but eh. He can just stop. Don't see the need for this, per NW. — Rlevse • Talk • 22:55, 27 September 2010 (UTC)[reply]
There are countless reasons why someone might want to give up their sysop rights. It's part of the reason we have a WP:RESYSOP procedure. –xenotalk 02:20, 28 September 2010 (UTC)[reply]

Self evidently pointless. Why on earth do we need this discussion? All 'crats are admins. This is either make-work or a solution in search of a problem. The only time I can see someone getting +crat without +sysop is at a foundation level; in which case it's not the communities problem / issue. Sorry, but this is without value. Pedro :  Chat  23:30, 27 September 2010 (UTC)[reply]

@NW/Pedro: Despite your belief that this is a solution in search of a problem, do you have any specific objection to the proposal? –xenotalk 02:19, 28 September 2010 (UTC)[reply]
This is rather needless. If a crat decides to resign the sysop bit but not the crat bit, then we should start worrying. But really, why would someone bother doing that, as things like viewing deleted pages and whatnot are useful to crats? I don't get why any crat would want to resign their adminship but still want to retain certain abilities (like viewing deleted pages). Either you keep both or none; it's just absurd to bother with the possibility of a non-admin crat. If you don't want to be a sysop but you do want to be a crat, stop using the sysop tools and keep using the crat ones. That seems easy enough. I mean, I understand where this proposal is coming from, but it just seems... weird and without any current application/purpose. /ƒETCHCOMMS/ 03:37, 28 September 2010 (UTC)[reply]
"why would someone bother doing that, as things like viewing deleted pages and whatnot are useful to crats?" Precisely. Right now they couldn't. Do you think they should be permitted to do so; if they desire? Is it such an unreasonable request to add a few words to an array to give them the option? (The future application you speak of) –xenotalk 04:03, 28 September 2010 (UTC)[reply]
In this case, would it be reasonable for a new user right to be created for me, because I don't want the block ability but I like the rest of the stuff? What's wrong with all-or-nothing? I mean, this isn't a big deal, but I just cannot see why on earth anyone would ever bother doing this. Why should they be permitted to do so, if they so desire, but not me? (Why would they so desire?) Seeing deleted pages is part of being a sysop; just ignore the other abilities, no? (If I could, I would revoke from my account the ability to block users, because I don't like doing it.) I mean, can you specify one or two reasonable rationales for why one would wish to be a crat but not a sysop, rather than keeping the sysop bit but not using it other than for seeing deleted pages and such? /ƒETCHCOMMS/ 03:14, 29 September 2010 (UTC)[reply]
Also, if a crat removes their sysop bit voluntarily, can't they give it back to themselves? ~DC We Can Work It Out 03:41, 28 September 2010 (UTC)[reply]
Technically yes; but from a practical standpoint, they should re-request at BN to avoid the appearance of impropriety. –xenotalk 04:03, 28 September 2010 (UTC)[reply]
Sure, why not? I always assumed bureaucrats can do everything admins can do, anyhow (Who would vote for someone as a bureaucrat, but vote against the same person as an admin?). --Conti|✉ 11:07, 28 September 2010 (UTC)[reply]
THIS. --Cybercobra (talk) 15:53, 28 September 2010 (UTC)[reply]

Change default skin back to monobook

I think the reasons for this are pretty obvious. It has a cleaner and simpler look and better usability without the over-the-top nature of the vector skin. Anyone agree with me? Access Denied [FATAL ERROR] 07:14, 28 September 2010 (UTC)[reply]

Nope. --Yair rand (talk) 07:31, 28 September 2010 (UTC)[reply]
Nope. d'oh! talk 07:39, 28 September 2010 (UTC)[reply]
MONOBOOK FOREVER etc. etc. The thing is, the foundation paid loads of money for a new skin, and they are not going to revert the default back because of that fact. I'm sure this topic has several threads in the archives of the various village pumps, if you'd like to do more research on it (you're a little late on the draw). Killiondude (talk) 07:58, 28 September 2010 (UTC)[reply]
I agree, but then I'm still using the windows classic theme. Noodle snacks (talk) 09:27, 28 September 2010 (UTC)[reply]
The Usability Project claims otherwise. I'm just set in my ways and thus personally use MonoBook; setting the preference isn't very hard at all. --Cybercobra (talk) 09:45, 28 September 2010 (UTC)[reply]
I think we should stick with Vector. The reasons are pretty obvious. It has a cleaner and simpler look and better usability. Anyone agree with me? (X! · talk)  · @497  ·  10:56, 28 September 2010 (UTC)[reply]
Yes. Alzarian16 (talk) 11:05, 28 September 2010 (UTC)[reply]
Yes.—Emil J. 11:05, 28 September 2010 (UTC)[reply]
(in case it wasn't clear, the point of my reply was to show how baseless and subjective the arguments were. Personally, I do support Vector. I use it, and I think it's much better looking than Monobook could ever hope to be.) (X! · talk)  · @928  ·  21:16, 28 September 2010 (UTC)[reply]
  • Just revert back yourself. They even provided a helpful button to revert back to monobook on all Wikimedia projects, which was a great help. You can even keep using the former (and better) Wikipedia logo with css. –xenotalk 12:48, 28 September 2010 (UTC)[reply]

Regardless of which skin is default, let the people (and that means unregistered users) decide for themselves which skin they want. Hpvpp (talk) 22:31, 28 September 2010 (UTC)[reply]

I like Vector, but if some IP doesn't, they can suck it up or create an account (yay!). The WMF did spend a lot of effort on this switch and it's happened. Either change it in your settings or spend some of your own money and time showing why Monobook is better (which it isn't, because it's outdated ugly). /ƒETCHCOMMS/ 03:08, 29 September 2010 (UTC)[reply]

Add projectwide css to highlight different posts in a discussion

Per a discussion here, I would like to propose the addition of some css into Mediawiki:Vector.css which allows for the highlighting of indented threads in any (Wikipedia- /User- /mainspace- ) talk page discussion, giving an appearance sort of like LiquidThreads, but (I feel) less controversial and certainly less forum-like. This effect, seen , may be found at , and makes it much easier to see responses and posts from different users, making it an advancement in usability and accessibility. I have added this code to my own vector.css page, and it has been a great help in looking through longer threads. While the drawback to implementing this sitewide is the need to update some talk page templates using indentation, this is only a minor issue and should not stand in the way of helping users who may have trouble focusing on long blocks of text and may also act as a sort of compromise between LiquidThreads supporters and opposers.

Please consider trying out this css for yourself (the exact code is:

Extended content
.ns-1 dd, .ns-3 dd, .ns-talk dd, .ns-5 dd, .ns-7 dd, .ns-9 dd,
.ns-11 dd, .ns-13 dd,.ns-15 dd, .ns-101 dd, .ns-103 dd, .ns-105 dd {
 margin:0;
 padding:0;
}
 
.ns-1 dl, .ns-3 dl, .ns-talk dl, .ns-5 dl, .ns-7 dl, .ns-9 dl,
.ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-103 dl, .ns-105 dl {
 border-top:solid 1px #a7d7f9;
 border-left:solid 1px #a7d7f9;
 padding-top:.5em;
 padding-left:.5em;
 margin-left:1em;
 
}
 
.ns-1 dl, .ns-3 dl, .ns-talk dl, .ns-5 dl, .ns-7 dl, .ns-9 dl,
.ns-11 dl, .ns-13 dl, .ns-15 dl, .ns-101 dl, .ns-103 dl, .ns-105 dl,
 
.ns-1 dl dl dl, .ns-3 dl dl dl, .ns-talk dl dl dl, .ns-5 dl dl dl, .ns-7 dl dl dl, .ns-9 dl dl dl,
.ns-11 dl dl dl, .ns-13 dl dl dl, .ns-15 dl dl dl, .ns-101 dl dl dl, .ns-103 dl dl dl, .ns-105 dl dl dl,
 
.ns-1 dl dl dl dl dl, .ns-3 dl dl dl dl dl, .ns-talk dl dl dl dl dl, .ns-5 dl dl dl dl dl,
.ns-7 dl dl dl dl dl, .ns-9 dl dl dl dl dl, .ns-11 dl dl dl dl dl,
.ns-13 dl dl dl dl dl, .ns-15 dl dl dl dl dl, .ns-101 dl dl dl dl dl,
.ns-103 dl dl dl dl dl, .ns-105 dl dl dl dl dl,
 
.ns-1 dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl,
 
.ns-1 dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl dl dl
{ background:#f5faff; }
 
.ns-1 dl dl, .ns-3 dl dl, .ns-talk dl dl, .ns-5 dl dl, .ns-7 dl dl, .ns-9 dl dl,
.ns-11 dl dl, .ns-13 dl dl, .ns-15 dl dl, .ns-101 dl dl, .ns-103 dl dl, .ns-105 dl dl,
 
.ns-1 dl dl dl dl, .ns-3 dl dl dl dl, .ns-talk dl dl dl dl, .ns-5 dl dl dl dl, .ns-7 dl dl dl dl,
.ns-9 dl dl dl dl, .ns-11 dl dl dl dl, .ns-13 dl dl dl dl, .ns-15 dl dl dl dl,
.ns-101 dl dl dl dl, .ns-103 dl dl dl dl, .ns-105 dl dl dl dl,
 
.ns-1 dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl,
 
.ns-1 dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl dl,
 
.ns-1 dl dl dl dl dl dl dl dl dl dl, .ns-3 dl dl dl dl dl dl dl dl dl dl, .ns-talk dl dl dl dl dl dl dl dl dl dl,
.ns-5 dl dl dl dl dl dl dl dl dl dl, .ns-7 dl dl dl dl dl dl dl dl dl dl,
.ns-9 dl dl dl dl dl dl dl dl dl dl, .ns-11 dl dl dl dl dl dl dl dl dl dl,
.ns-13 dl dl dl dl dl dl dl dl dl dl, .ns-15 dl dl dl dl dl dl dl dl dl dl,
.ns-101 dl dl dl dl dl dl dl dl dl dl, .ns-103 dl dl dl dl dl dl dl dl dl dl,
.ns-105 dl dl dl dl dl dl dl dl dl dl
{ background:white; }

and that goes in Special:MyPage/skin.css). It works fine on Monobook, although the colors may need to be tweaked for that skin, but I think that this change will only be aid in readability after one gets used to seeing it. /ƒETCHCOMMS/ 03:35, 29 September 2010 (UTC)[reply]

Fine by me, as long as it can be disabled in personal CSS. Access Denied [FATAL ERROR] 03:38, 29 September 2010 (UTC)[reply]
Like I saif before, I support this proposal. This layout is an important usability and accessibility improvement. Especially for people with dyslexia. This layout used on the french Wikipedia was reviewed by an accessibility expert and another accessibility expert specialized in dyslexia. I can provide translation of their review if people are interested. Kind regards, Dodoïste (talk) 03:42, 29 September 2010 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=387661236"