This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
To help work out what editors are doing, and find editing patterns, I propose a new technical implementation that only allows submission of edits with an edit summary. Dendodge| Talk Contribs 12:27, 18 October 2008 (UTC)
I would like to see “study guides” made available. In their simplest form a specialized wiki page would list existing articles in a logically-progressive order. For example, a study guide to physics would begin listing articles on simple machines, basic math, etc, and progress through Newton’s laws, optics, electricity, etc. and eventually cover a typical high school physics curriculum. It would then go on through calculus and college level topics and finally branch out into many specialty fields.
The goal is to provide a roughly linear path a student could follow through existing Wikipedia articles to attain proficiency in a chosen field. A secondary goal is to provide Wikipedia editors insight into the completeness of the available articles.
A more complete study guide would link existing articles with narrative text placing each into useful context.
Because the study guides themselves are wiki pages, they would continue to grow and improve as do the content pages. -- Lbeaumont ( talk) 00:00, 22 October 2008 (UTC)
As noted recently in the "view undeleted" discussion, there are tools which can be a "big deal", and which shouldn't be given out as if they are "no big deal".
That said, I think we have an environment in which most admin actions can be "undone", and in which we (hopefully) don't promote those with a lack of discernment to adminship.
(For example, we have WP:DRV for deletions, and WP:RPP for protections. Though for blocking, it's spread through the sub-pages of WP:AN, and elsewhere.)
However, probably the most controversial ability of an admin is the ability to block another user.
And most of the cries of "admin abuse" occur (accurately or inaccurately) in relation to the ability to block/unblock.
Also, there is the issue that the "block log" of a user seems to be quite a bit more of a "big deal" than a page log. Especially since these logs are typically not edited. (While noting that additional logs may be placed to help clarify.)
If there is anything that should be "unbundled" from the administrator group of user-rights, it's the block-related user-rights. (For purposes of discussion, let’s call this the "blocker" package.)
Imagine how many times that we hear: "They're great editors, but their use of tools when blocking/unblocking..."
Consider if it was possible for Arbcom to suspend the block-related abilities from an admin, while allowing the rest of their abilities to remain. Everyone, including the encyclopedia itself, would benefit.
And consider those individuals who've lost adminship in the past merely due to usage of block-related tools, but was considered to be trusted to use the other admin tools. That person might be more easily able to re-attain adminship by merely not requesting the additional block-related user-right package.
And imagine those wiki-gnomish editors who feel that adminship is just too much of a "third-rail" for their ability to edit? So another benefit is that that more Wiki-editors may come out from lurking.
This also may be of interest to those proposing "provisional" or "trial" adminship. One could request adminship without requesting the ability to block/unblock. And later, request the "blocker" user-rights.
This wouldn't require any additional bureaucracy. Simply add a line to each RfA: "I am also requesting the 'blocker' user-rights" or "I am not requesting the 'blocker' user-rights at this time". (or some such).
Oh, and as an added bonus, it also should help decrease the contention at RfA somewhat.
So anyway, those are just some of the many reasons to suggest this.
And one final thing:
Since all the people who currently have these tools went through an RfA in which those commenting presumed that they would have these tools, if these user-rights are unbundled from adminship:
All users who currently have the "administrator package" of user-rights, would immediately be given the "blocker" package.
This should also help prevent opposition from those who might be concerned that their current "abilities" would be changed in any way.
Here are the user-rights that I think should be placed in a new user-group called "blocker":
What does that leave in the adminship package? A lot. (See Special:ListGroupRights.) Most of which involve the ability to review/edit almost anything content-related (save oversight), and the ability to help editors to contribute (such as account creator).
I welcome your thoughts. - jc37 03:58, 11 October 2008 (UTC)
I'm going to try to re-explain, based on the confusion below (and elsewhere).
The proposal is to split the single package of user-rights that admins receive from one package to being grouped in two packages.
The process for bestowing those rights need not change whatsoever.
That includes RfA, or whatever other process bestows user-rights.
I've listed the reasons why this would be useful several times already, but to summarise, it's to provide options for those who might wish to contribute more to wikipedia, but do not wish what some see as the "burden" of having the block-related user-rights.
We should allow for that option.
And a reminder: If this proposal is implemented, current admins would not lose the right to block. This is merely modifying the package user-rights in the software, not modifying any user-rights that admins already have. And the "blocker" group would be granted by bureaucrats on en:Wikipedia, just as these rights always haves been.
And to make it clear: this proposal is not about giving non-admins the ability to block!
So adminship, and the RfA process would not change, but the following options (among others) would be possible:
This is just about providing options.
As someone said below, Let's free the wikignomes. - 12:02, 13 October 2008 (UTC)
I think this is probably not a great idea. Blocks can be very controversial, and the ability to remove someone (temporarily or permanently) from the community should be decided on the basis of community trust. Protects, on the other hand (as I said above), are much more trivial in terms of controversy and ease of undo. Prince of Canada t | c 06:56, 11 October 2008 (UTC)
(ec)Difficult issue. Essentially it involves splitting not only responsibility, which here is given on trust, but also accountability to the community. Admins are given the mop on the basis of being able to exercise judgement in a number of dimensions. I feel that to dilute that would not only create an unnecessary layer of bureaucracy (in more than one way; consider the effect on WP:AN and WP:ANI- would we need yet more pages for such limited reviews?); additionally, there would undoubtedly arise conflicts due to this separation of functions. The ability to delete pages is perhaps the least contentious here, but again, understanding of policy is paramount and I perceive little difference between the judgement required for that, and the exercise of discretion in blocking. If we would trust some editors to properly assess a CSD, arguably we should also trust them to know when, and for how long, a vandal should be blocked. Accordingly, i remain to be convinced. -- Rodhull andemu 00:13, 12 October 2008 (UTC)
I'm going to try to re-explain, based on the confusion above (and elsewhere).
The proposal is to split the single package of user-rights that admins receive from one package to being grouped in two packages.
The process for bestowing those rights need not change whatsoever.
That includes RfA, or whatever other process bestows user-rights.
I've listed the reasons why this would be useful several times already, but to summarise, it's to provide options for those who might wish to contribute more to wikipedia, but do not wish what some see as the "burden" of having the block-related user-rights.
We should allow for that option.
And a reminder: If this proposal is implemented, current admins would not lose the right to block. This is merely modifying the package user-rights in the software, not modifying any user-rights that admins already have. And the "blocker" group would be granted by bureaucrats on en:Wikipedia, just as these rights always haves been.
And to make it clear: this proposal is not about giving non-admins the ability to block!
So adminship, and the RfA process would not change, but the following options (among others) would be possible:
This is just about providing options.
As someone said above, Let's free the wikignomes. - jc37 09:39, 13 October 2008 (UTC)
So, I see poor JC37 getting a might frazzled here-- let's try this approach.
Consider the tool to change a page from unprotected to semi-protected. This is a tool that has very little potential for damaging the encyclopedia. Whether the change is justified or unjustified, it is temporary, easily reversed, and will not affect 99% of our editors.
On the other hand, consider the power to edit protected pages and templates. This is a very dangerous tool that, in the wrong hands, could result in widespread vandalism all across the project.
Now surely the level of trust we must to have in someone to let them semi-protect a page isn't the same level of trust we must have in someone to let them edit protected templates.
Right? -- Alecmconroy ( talk) 07:50, 12 October 2008 (UTC)
I don't tend to see blocking as especially contentious. Bad blocks are usually quickly overturned and unlikely to happen too often before dispute resolution is introduced. I tend to view the ability to semi-protect as on a par with blocking. If the right was handed out liberally the whole encyclopaedia would be indefinitely semi-protected within a very short time. Protection, and the ability to edit protected pages, take experience to do properly, without locking out valuable unregistered editors. The ability to distinguish a content dispute from vandalism, edit-warring from wikification, to judge the balance of positive to negative edits, to know when an edit has consensus or not, a user has expended all their unblock requests, or whether a title is so implausible that it needs salting, all involve the same judgment as blocking and are just as likely if not more to drive away new editors. I accept the ability to edit protected pages, especially templates, would be a useful right to dispense to trusted editors, but I don't see why this can't go through a RfA. -- zzuuzz (talk) 14:10, 12 October 2008 (UTC)
The block/unblock permission is not the most dangerous permission in the 'sysop' package. For reasons I won't discuss (e-mail me if you're curious), there is another permission available without Foundation approval that has the capacity to cause almost irreperable damage to the site. If I had any doubt about an admin candidate's trustworthiness, or if their judgement was called into enough question to suggest withdrawing certain permissions, blocking is not the ability I would remove. While I sympathise with the idea of the OP, trying to separate the 'Big Three' of block, delete and protect, is unlikely ever to gain much traction. They are all awesomely powerful in their own way if used improperly; it is simply not possible to say that one is less or more dangerous than the rest. I would fully endorse splitting up the 'sysop' package to allocate more of the genuinely minimal rights in a more open and accessible fashion, but the Big Three must remain together, and loss of trust in one must necessitate a loss of trust in all. Happy‑ melon 18:04, 13 October 2008 (UTC)
It seems like there's a couple different types of "trust" floating around that are often getting conflated. One version is "trust not to be malicious"-- when a user has been around for a certain amount of time, kept their nose clean, invested some serious time in the project, and generally seemed to have the right temperament, I "trust them not to be malicious", and I'd be willing to give them any tools that could help the encyclopedia but could be misused by a malicious user to the detriment of the encyclopedia.
But, there's a whole other different sort of trust that's a higher level of trust, above and beyond the "trust not to be malicious". Before I'd be willing to give someone blocking ability, it's not sufficient just for me to "trust them not to be malicious". I would only support giving the power to block established users to someone who I "trust to have excellent judgment about complex matters". Being good-faith is not enough to be an admin-- you have to actually be good at using the tools.
Because we've just been using the word "trust", we've conflated these two meanings, and that's what's getting lost in these discussions of relative dangerousness of tools. We consider what the tools could do in malicious hands and recognize, correctly, that all are quite dangerous. But what's missing is that all the tools are NOT of equal difficulty.
There's a very large, large population of users who I "trust not to be malicious". There's a lot of people I trust to use the "semi-protect a page" or "block an ip editor" power. There's a much smaller population that I "trust to be good at using the 'block established editor' power". I may trust all of the editors to try their best-- but for some people, for the complex tools, their best just won't be good enough.
It would be nice, someday, if we could recognize the distinction. If someone, without having been malicious, nonetheless proves unable to use a particular tool, it would be nice if arbcom could let them still keep the tools they HAVE been able to successfully use-- rather than face an all-or-nothing choice. -- Alecmconroy ( talk) 11:30, 14 October 2008 (UTC)
Why don't we do it more like the current rollbacker system?
I took a look at the list over at Special:ListGroupRights, and that is a lot of things that an admin can do. Just cutting out the blocking still leaves so much that we still must have the RfA process for those users.
So I suggest doing it the other way around. If say 4 admins marked a user as trusted that user would be able to do some semi-risk tasks. And I think that it should be enough that one admin marks the user as not trusted to remove the tools from the user.
Let's identify some tasks that are fairly low risk:
This would mean that no RfA process would be needed for those users. Thus much less bureaucratic.
-- David Göthberg ( talk) 14:01, 12 October 2008 (UTC)
Is there a way for there to be a Special:Log/newbies like there is a [1]? It would be quite useful for tracking new things going on; blocks on newbies, moves (does "Grawp" ring a bell?), etc. Thanks, ~ Troy ( talk) 02:06, 21 October 2008 (UTC)
There is a bot proposal to remove autoformatted dates and leave solitary years alone. Please see Wikipedia:Bots/Requests for approval/Cleanbot. Regards Lightmouse ( talk) 13:19, 21 October 2008 (UTC)
One of the most impressive thing about Wikipedia is how many language editions there are of it, as listed on List of Wikipedias by language, and also at Category: Wikipedias by language. There are, according to the the Wikipedia article, 262 languages in which one can read Wikipedia. I am in favour of keeping the list as it is; but could the category be organised more hierarchically, so that is grouped more hierarchically? At the university where I teach, students seem, in general to find the university's intranet easier to navigate if icons are arranged in folders. In the same way, would the category be better organized if we had, say, separate categories to list, for example, African language Wikipedias, South-East Asian language Wikipedias, American language Wikipedieas, European language Wikipedias and so on and so forth? ACEOREVIVED ( talk) 19:44, 23 October 2008 (UTC)
Thank you John, although my proposal above was only a suggestion that we categorise, not necessarily that we categorise according to countries -we could, for example, have a category "Indo-European languages" and then a category "Semitic languages" and then a category, say, "Austronesian languages". Just a suggestion. ACEOREVIVED ( talk) 20:31, 24 October 2008 (UTC)
I would like some editors who have a better mathematics education than I, and perhaps some professional scientists (if they have the time, which I realize they don't) to please consider re-activating WikiProject General Audience. 69.140.152.55 ( talk) 01:49, 28 June 2008 (UTC)
Please see discussion here. 69.140.152.55 ( talk) 23:09, 24 October 2008 (UTC)
Alright, so I haven't gotten annoying on Wikipedia on years, but I've noticed something and a lot of other users are getting bugged about it, too. It's the whole "humans rule the world" idea. No, bugs do. Or maybe algae... Anyway, it has to do with articles being mostly focused on humans. This, of course, is biased. Articles, such as "life expectancy" are focused on humans. No! The focus needs to be taken away from humans. At best, the article should be downsized and humans should be a subsection or another article in itself. What am I trying to say here? Articles are biased because they refer more to humans than other species. -- Cyberman ( talk) 05:23, 17 October 2008 (UTC)
Let's just nominate humans for deletion -- Ron Ritzman ( talk) 13:28, 17 October 2008 (UTC)
I agree with Cyberman in a general way, but I think it should be noted that when readers come here, they will most likely be looking for information on humans and that most editors are human and thinking in human terms when they make additions. Wikipedia's anthropocentrism can be dealt with gradually with the addition of information about non-humans. No reason to panic about it. Abyssal ( talk) 18:06, 17 October 2008 (UTC)
I think this is getting a little out of hand without realising why we don't want systemic bias... — Werdna • talk 22:47, 20 October 2008 (UTC)
What's systemic bias got to do with presenting a neutral point of view, Aditya? The reason we try to avoid systemic bias is because we want our articles to be useful to anyone who reads them. We don't want people in Australia reading an article on Supreme Courts without some reference to courts other than the US Supreme Court.
Systemic bias is conveniently a non-issue in terms of "anthropocentrism", because we don't have very many non-human readers citation needed... — Werdna • talk 10:20, 25 October 2008 (UTC)
I brought this up at WP:VPP yesterday (and have so far received no responses), but it occurred to me that I probably listed it in the wrong place, since it is not a policy proposal but a "how to" guide, like the others in the category. I'm hoping to be able to officially launch this soon.
This guide has been under development since October 1st and publicized since that time at various appropriate forums, including VP. It has been publicized at Wikipedia talk:Images and media for deletion, Wikipedia talk:Image use policy, and WT:CSD. It is currently linked at Wikipedia:Deletion policy#Processes, Wikipedia:Guide to deletion, Wikipedia:Deletion guidelines for administrators#See also and Wikipedia:Image use policy#Deleting images. It has also since October 2nd been listed at RfC, here. I think it has received sufficiently widespread exposure, and so far all feedback has been essentially positive. (One fellow, here, objected to actual deletion policy, but as this document is only a compendium of deletion practice, I pointed him to the appropriate forum to discuss his concerns.) Discussion has primarily centered around specifics of wording; there seems to be general consensus that the compendium is useful. Any further feedback or guidance in launching this would be helpful and greatly appreciated...right down to some guidance on at what point "proposed" is removed. :) -- Moonriddengirl (talk) 12:04, 24 October 2008 (UTC)
See Wikipedia talk:Babel/Levels#Should the descriptions be made clearer? -- Army 1987 (t — c) 12:35, 25 October 2008 (UTC)
It is impossible to go through this list [3]. It needs a contents section that allows you to click a letter or number such as on List of biochemistry topics 89.204.247.134 ( talk) 13:40, 25 October 2008 (UTC)
It is my belief that there are far too many pages dedicated to encouraging and educating people on how to maintain and contribute to Wikipedia. The number of pages on this subject causes disorganization. Between Wikipedia:Contribute, Wikipedia:Community portal/Opentask, Category:Wikipedia maintenance, and Template:Resources for collaboration, in which many of the pages repeat each other, I think the information should be synthesized and combined into one page. Voyaging (talk) 18:01, 25 October 2008 (UTC)
I have been thinking that the wording of the current Primarysources template misses a key aspect of how primary sources might be used problematically. An article can misuse, overuse, or overemphasize primary sources even if it also references plenty of independent ones. I have raised the issue at the template's talk page, but that doesn't seem to get much activity. PSWG1920 ( talk) 22:51, 25 October 2008 (UTC)
While I understand this might not add to everyone's use, I would find it useful to have the option to have a cursor as crossed vertical and horizontal lines (lengths of 1/4 inch to full screen at my selection) with the lat & Lon numbers in either deg. min. sec. or dec. deg. attached to the vert and hor lines and at a distance to leave the intersection clear to view. This should be an option a user could select, among others, just so the average user should no be too annoyed with Me. Art—Preceding unsigned comment added by 24.190.246.208 ( talk • contribs)
I have been trying to find a template to show that a discussion has been reopened. I was pointed to {{ relisted}} which in my original case was suitable. But what if it is not to reach a consensus but for a general discussion.
I therfore created afterwards {{ reopened}}, which could act as this to generally say that it has been reopened e.g. from an archive, or as an alternative to relisted.
What do people think?
Am i on the right page to discuss this?
Simply south ( talk) 19:56, 26 October 2008 (UTC)
Don't know if this is a technical issue or just a policy one, but I really cannot see a reason why we shouldn't require autoconfirmation before allowing uploads. There really isn't a good reason why someone's first contributions would be uploading images and a large number of images that have problems are because people don't know anything about Wikipedia, let alone something as complex as our image policies. -- Ricky81682 ( talk) 22:39, 26 October 2008 (UTC)
When searching for something, and the text field brings up suggestions, some of those suggestions are the same except for capitalization, but some of those redirect to others of those; for example, type enough of "Albert Einsten" and it suggests "Albert einstein" [sic], which is nothing more than a redirect to the first of the two; how about eliminating these redirects from the suggestion field? OneWeirdDude ( talk) 02:54, 26 October 2008 (UTC)
When you click on a red discussion tab, I think you should be taken to the new section window (i.e. with a heading box; as if you'd pressed +) instead of just the normal edit window (as if you'd pressed ). It would just help new users in creating new discussion pages in case they were not sure how many = signs they needed. It Is Me Here ( talk) 18:17, 26 October 2008 (UTC)
The following just occurred to me--
Is there any way we could get some small minority of the Wikipedia community to have access to the sorts of databases any typical university would have-- things like JSTOR and Fulltext Science Journals, etc?
I have no clue how much such things cost, except to note that the cost is small enough that most university libraries are capable of providing it for all students.
I think it would be very useful to the project, in creating new articles on the latest in science, if we could provide that kind of access to some small sliver of the project-- either the foundation paying, or getting some large university library system to let us "piggyback" by them donating the access to the project.
Any thoughts on whether this might theoretically be feasible, and if so, how it could come to pass? -- Alecmconroy ( talk) 06:55, 27 October 2008 (UTC)
This is a proposal for an interface change in relation to categories as seen at the bottom of each page. I don't know if this is the right place for this, and if not redirection would be appreciated.
I would like to see dots such as "•" or similar to replace the "|" that seperates the categories, for aesthetics reasons. It is much easier on the eyes, as the wouldn't be any confusion between "1"s, "I"s and so forth. Many templates now use dots instead of |'s. The Windler talk 09:50, 30 September 2008 (UTC)
There seems to be some support and various suggestions. Which suggestion will get the task done. I don't understand some of the suggestions. The Windler talk 02:01, 1 October 2008 (UTC)
It is possible to do this via the following user script, without the need to make any global changes:
addOnloadHook( function (){
var cat_div = document.getElementById('mw-normal-catlinks');
cat_div.innerHTML = cat_div.innerHTML.replace(/\|/g,'•');
});
- SigmaEpsilon → Σ Ε 01:53, 3 October 2008 (UTC)
Gah. I see |'s used throughout the software, and I like it that way. Yes, this issue is primarily about personal preference, so please don't quote WP:ILIKEIT to me. I oppose this proposal as given unless I can be convinced that it won't disrupt the consistency of the interface, as other interface elements use pipes (|'s), as MZMcBride notes, and the effective change would only change category separators. Until it becomes a personal preference option, I don't think this should be changed. {{ Nihiltres| talk| log}} 04:51, 3 October 2008 (UTC)
About consistency of the interface: As far as I can tell, only "internal" pages use the | as a separator. In mainspace, the dot is the more commonly used separator. As example, take a look at the Main Page! -- Kildor ( talk) 08:34, 3 October 2008 (UTC)
I support the change from pipe to dot, a dot is more ergonomic and also helps site consistency. If somebody wants to keep the pipe for whatever reason, he can use the user script. Cacycle ( talk) 15:30, 3 October 2008 (UTC)
So what happens now???? The Windler talk 02:43, 6 October 2008 (UTC)
Please get rid of the bullets: they are far too bold, drawing the eye from across the page. Use either midpoints, which are acceptable typographic separators, or vertical lines, which are common link separators on websites (although it's true that they can slow down reading by looking like figure 1's, small l's, or capital I's).
Please follow two millennia of writing conventions rather than trying out new ideas. If you don't believe me, see what the expert says: search in Bringhurst (book) ( Amazon) for bullet (p 304), “used chiefly as a typographic flag . . . to mark items in a list, or . . . to separate larger blocks of text,” and midpoint (p 313), “an ancient European mark of punctuation, widely used . . . to separate items in a horizontal line”. Thanks. — Michael Z. 2008-10-09 05:40 z
Here's my summary of the discussion above (please correct any mis-/missing attributions). Note that there is a difference between middots and bullets (see the "Dot size reference list" section here). The OP suggests a dot rather than a bullet, so it would be helpful if this could be clarified.
Some general remarks to comments above in this section: 1. The current bullets are problematic with certain fonts, therefore we will most probably use an unobtrusive bold middot (·) instead. 2. It is the pipes which are inconsistent with the current Wikipedia styles (e.g. as agreed upon for templates), not the dots. 3. All anonymous users (our main audience) use monobook as well as the vast majority of registered users. I do not think that some minor aesthetic issue for the minuscule fraction of users of other skins should prevent us from fixing it for all other users. 4. There will almost certainly not be a gadget for such a minor issue that can easily be changed with one line of code on the monobook.js page as described above. Cacycle ( talk) 14:45, 10 October 2008 (UTC)
li:before { content: }
, which does resize the bullet with text. Using border-left is suitable for generating the vertical line, and works in MSIE, too, so it could be a useful default behaviour. No one seems to worry about Wikipedia's ubiquitous blue unordered-list bullet getting resized, so maybe this won't be a problem here, and of course with CSS a registered editor could change the separator. In browsers which support CSS3 background-size, the bullet's size can be specified in ems, which should resize with the text display (I haven't tested this). —
Michael
Z. 2008-10-10 21:01 z:before
and :after
selectors, it's not going to work (And in fact, it does fail miserably in IE7 on another computer I happened to have handy here). Reports are that IE8b2 does support them, finally.
Anomie
⚔ 02:10, 13 October 2008 (UTC)
div#mw-normal-catlinks a+span {}
might be used to select the first child in this case—would that work in MSIE? But anyway, if we can change the HTML to create an unordered list, can't we just add a class to the first item anyway? —
Michael
Z. 2008-10-14 18:08 z
As some people imply above; there should be no "character" separating such items; because separators are presentational, not data. The items should be in a list (i.e. use OL
or UL
; plus LI
HTML elements, and should be visually separated with a (CSS-applied) background image or border. This is good practice; both semantically and for improved accessibility and usability. See also earlier discussion of this issue, still to be resolved, at
Wikipedia talk:Accessibility#Horizontal lists.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 19:47, 12 October 2008 (UTC)
display: none;
applied. Better to use existing techniques to make the page accessible to people using today's (and yesterday's) screen readers than to propose future changes. —
Michael
Z. 2008-10-21 07:36 zI think it is possible. I whipped up an example which seems to work: Semantic category listings for Wikipedia.
There is a presentation glitch in the way MSIE draws borders on inline elements which wrap—I may have a clean workaround, but it's much too late to test it tonight. — Michael Z. 2008-10-21 07:08 z
I would propose that Wikipedia adopt a 'Valued' or 'Quality' images department. The images that garner this status on Wikipedia would have to be tagged with a different template to the Valued or Quality image seals, in order to distinguish between them. I suggest that images that receive this status should be highly encyclopedic images, although not necessarily of excellent quality. Images that illustrate a point in an exemplary manner, for example, could be nominated as these 'Encyclopedic Images'. There would obviously be problems, for example: who defines an image as being encyclopedic or the most valuable of a large group of images? What scope should or could an image be nominated within? Thus, a vote of consensus would be required. I think the initiation of such an area would benefit Wikipedia. Diagrams, sounds and various other media could also be included in this. I would be willing to draw up a draft for the page; however, the decision must first be made. What does the community think? Elucidate ( parlez à moi) Ici pour humor 08:21, 23 October 2008 (UTC)
We are now standardising the colours for several of the system warning notices such as MediaWiki:Editingold and MediaWiki:Protectedpagewarning. Everyone is welcome to join in the discussion and have their say over at Template talk:Fmbox#New type?.
-- David Göthberg ( talk) 15:16, 25 October 2008 (UTC)
I'd like to mass remove
And any other simlar icon usage from the main space where their usage is similar too [9] using WP:AWB as per Wikipedia:Manual_of_Style_(icons)#Help_the_reader_rather_than_decorate any opinions ?
I Agree. See Design#Terminology ( old diff, sense is prevailing now), which has one adamant defender. 96.50.4.248 ( talk) 19:14, 27 October 2008 (UTC)
Ten More at Multimedia ( diff). Ugly suckers. 96.50.4.248 ( talk) 18:58, 28 October 2008 (UTC)
I've been mulling this over recently... One can set their watchlist (as well as RC) to generate a list of articles that have been changed that are collapsed by javascript, with one link of 'all changes' today, and by using the javascript, can pick and choose which 'diff' or 'cur' to work from.
What I'm proposing is that, like an email list, one can set an opt-in option on their preferences to allow them to be emailed when a page they were watching was changed. However, to reduce the number of emails any one person would receive (I can only imagine for the people who watch thousands of pages...), this option would provide the changes in a digest type format, rather than as separate emails. This would enable people to keep track of their watchlist while away, or allow people to view their watchlist (a day late) from their email rather than by logging on. Of course, this would also (only) work if they supply their email, but special:emailuser works only in such a way, and there is the opt-in for messages to be sent when your talk page is changed.
For example...
We have in the header: Watchlist changes for 2008-8-28 (or what not. Also to be sent out at the time [below] one day later)
A slightly alternate form would be:
I'm not quite sure on what time these emails would be sent out by the server, though I'm leaning toward 0:00 <local time> where local time is the time offset specified by the user for watchlist and recent changes.
Thoughts? -- Izno ( talk) 05:46, 28 October 2008 (UTC)
There is a watchlist RSS feed available at http://en.wikipedia.org/w/api.php?action=feedwatchlist . Configuration is as follows:
Parameters: feedformat - The format of the feed One value: rss, atom Default: rss hours - List pages modified within this many hours from now The value must be between 1 and 72 Default: 24 allrev - Include multiple revisions of the same page within given timeframe.
from http://en.wikipedia.org/w/api.php
Any decent mail program supports RSS, so emailing shouldn't really be necessary. MER-C 10:41, 28 October 2008 (UTC)
I'm sure that a page for recent redirects would prove to be useful, especially for spotting and reverting vandalism. A lot of Grawps' IP socks just redirect pages to nonsense, /b/tards are prone to do the same, and it's not uncommon for the usual vandals to simply redirect a user talk page as a form of Harassment. Any thoughts? ~ Troy ( talk) 23:54, 23 October 2008 (UTC)
Just wanted to put in a word for Wikipedia to start using ReCaptcha for our verification captcha. It's a community-driven information-technologic project like Wikpedia and I think it would be good for our karma.
This content was a direct copy from http://recaptcha.net/learnmore.html - we can't have copyvios here any more than the mainspace. Follow that link above to read what Jengod's talking about. Happy‑ melon 20:05, 28 October 2008 (UTC)
Just something to think on. Thanks for reading. jengod ( talk) 16:47, 28 October 2008 (UTC)
reCAPTCHA's audio captcha is also trivially breakable. A MediaWiki extension is already available, but its activation on Wikimedia projects has been repeatedly refused by Brion Vibber and Tim Starling on the grounds of it not being free software, the dependence on an external site, and the lack of security of its audio captcha. — Werdna • talk 14:10, 29 October 2008 (UTC)
I'd like a new template created to enable tagging of articles that excessively use " Ibid." references — a practice that is discouraged in our footnotes guidelines because of the difficulty involved in keeping such references consistent over time (some articles, such as English Reformation, don't even use it properly). A full-text search for "ibid" turns up dozens of articles that could use such a tag. Dozens more use the equally problematic op. cit. and loc. cit. (these are also misused in some articles). I think this is prevalent enough (and will no doubt continue to be prevalent enough, even after the current instances are fixed) to warrant the creation of one or more templates (and associated category/-ies) to alert interested editors to such articles. I'd like to leave it to someone else, however, to choose the title and format of the template, since I don't have a lot of experience in creating these kinds of templates here on Wikipedia. Anyone interested? - dcljr ( talk) 21:01, 24 October 2008 (UTC)
---As John Broughton suggests in the 7th paragraph I copy this here from the technical village pump---
Hello: I think that many people like me look for information in different Wikipedias (different editions/languages of it). I believe that not few people, to save time, use the offered (in one of the first code lines, that begins with <link rel="search") search engine plug-ins for the browsers. If Firefox is used each plug-in comes with an icon (in this case a W). The problem is that, as the icons of the different Wikipedias are all the same, it happens to me often that I search in a Wikipedia that I didn't want to look for. I think that this could easily happen to more people. The solution is easy: to put a flag in a corner of the icon: for example the one of Italy for the Italian Wikipedia. Thanks, -- Edupedro ( talk) 22:29, 26 October 2008 (UTC)
site:en.wikipedia.org
for the English Wikipedia. You can even
create a "smart keyword" in Firefox so that you don't have to type as much. (Also, I think that the "W" icons you mention are actually part of the Firefox browser, rather than something provided by the Wikimedia Foundation; if so, it's somewhat pointless to make a suggestion on this page.) --
John Broughton
(♫♫) 14:44, 27 October 2008 (UTC)←I'm thinking this probably isn't the greatest idea. It's just an invitation to drama and arguments over using the 'right' flag. Plus, I just don't see many people using it--and those who would, probably already know, or know where to ask, how to change favicons. [ roux ] [ x 23:33, 29 October 2008 (UTC)
Another option could be to precede or superimpose the W logo with a little language code. These could be created using a tiny pixel font, 5 pixels or so tall. — Michael Z. 2008-10-30 16:49 z
DE.W
EN.W
WPT
The last one needs a 1-px white outline for the language code, so it's clearly readable over the W. — Michael Z. 2008-10-30 16:55 z
Currently nominators of featured sound candidates follow a practice of nominating and then supporting ('voting for') their own nominations (see for example here). This is also done on WP:FPC where the expression used is 'support as nominator'.
This has been an issue on WP:FSC because of the lack of transparency (to put it minimally) in the process of reviewing candidates.
So, I propose this 'nominate and support' ('support as nominator') practice be discontinued. Nominators in future should only nominate, and other editors should support (or oppose or whatever). -- Klein zach 01:00, 24 October 2008 (UTC)
This is the text at WP:FSC:
If a nomination is listed here for at least 14 days with three or more supporting declarations and the general consensus is in its favor, it can be added to a Wikipedia:Featured sounds list.
The requirement appears to be nomination + 3 supports = 4 'votes'. It's not. It's really 3 'votes'. -- Klein zach 00:42, 26 October 2008 (UTC)
Now then, my thoughts. 3 votes, including the nominator's, has been what's required for the entire history of WP:FSC, as a review of the archives will show. So, including the nominator in the count of three is the default, and changes would need consensus. I do not think that we have sufficient voters to justify an increase to 4 - in practice, this will only serve to increase the already somewhat excessive time that it takes to get enough people to review. (Featured sounds, due to still having relatively low numbers of voters, only has a minimum time period, not a maximum.)
I do not know what Kleinzach considers the "lack of transparency" at FSC. It certainly could benefit from more people, but I don't see any aspect that isn't transparent and above board. Shoemaker's Holiday ( talk) 04:47, 28 October 2008 (UTC)
That leaves the problem of determining the "general consensus" in favour of promotion. Here are two examples taken from this month's files:
They were promoted and immediately removed to the archive - examples (to answer Shoemaker's Holiday's question) of the lack of transparency in the WP:FSC process. Anyone involved would have assumed that these files would not be passed, but they were! -- Klein zach 02:51, 29 October 2008 (UTC)
Kleinzach is forum shopping. He failed to get consensus at FSC talk and rejected two compromise solutions. It is disappointing to see him raise the matter here in this manner: using examples as if no other remedy were possible, yet neglecting to note that I have specifically offered to nominate any of my own featured sounds for delisting if any editor disagrees with the closer's decision. It's surprising to see this turn of events (Wikisource and featured picture nominations kept me busy for several days); not sure what to make of this subthread--shall I open a delisting nomination now? Durova Charge! 03:35, 2 November 2008 (UTC)
This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
To help work out what editors are doing, and find editing patterns, I propose a new technical implementation that only allows submission of edits with an edit summary. Dendodge| Talk Contribs 12:27, 18 October 2008 (UTC)
I would like to see “study guides” made available. In their simplest form a specialized wiki page would list existing articles in a logically-progressive order. For example, a study guide to physics would begin listing articles on simple machines, basic math, etc, and progress through Newton’s laws, optics, electricity, etc. and eventually cover a typical high school physics curriculum. It would then go on through calculus and college level topics and finally branch out into many specialty fields.
The goal is to provide a roughly linear path a student could follow through existing Wikipedia articles to attain proficiency in a chosen field. A secondary goal is to provide Wikipedia editors insight into the completeness of the available articles.
A more complete study guide would link existing articles with narrative text placing each into useful context.
Because the study guides themselves are wiki pages, they would continue to grow and improve as do the content pages. -- Lbeaumont ( talk) 00:00, 22 October 2008 (UTC)
As noted recently in the "view undeleted" discussion, there are tools which can be a "big deal", and which shouldn't be given out as if they are "no big deal".
That said, I think we have an environment in which most admin actions can be "undone", and in which we (hopefully) don't promote those with a lack of discernment to adminship.
(For example, we have WP:DRV for deletions, and WP:RPP for protections. Though for blocking, it's spread through the sub-pages of WP:AN, and elsewhere.)
However, probably the most controversial ability of an admin is the ability to block another user.
And most of the cries of "admin abuse" occur (accurately or inaccurately) in relation to the ability to block/unblock.
Also, there is the issue that the "block log" of a user seems to be quite a bit more of a "big deal" than a page log. Especially since these logs are typically not edited. (While noting that additional logs may be placed to help clarify.)
If there is anything that should be "unbundled" from the administrator group of user-rights, it's the block-related user-rights. (For purposes of discussion, let’s call this the "blocker" package.)
Imagine how many times that we hear: "They're great editors, but their use of tools when blocking/unblocking..."
Consider if it was possible for Arbcom to suspend the block-related abilities from an admin, while allowing the rest of their abilities to remain. Everyone, including the encyclopedia itself, would benefit.
And consider those individuals who've lost adminship in the past merely due to usage of block-related tools, but was considered to be trusted to use the other admin tools. That person might be more easily able to re-attain adminship by merely not requesting the additional block-related user-right package.
And imagine those wiki-gnomish editors who feel that adminship is just too much of a "third-rail" for their ability to edit? So another benefit is that that more Wiki-editors may come out from lurking.
This also may be of interest to those proposing "provisional" or "trial" adminship. One could request adminship without requesting the ability to block/unblock. And later, request the "blocker" user-rights.
This wouldn't require any additional bureaucracy. Simply add a line to each RfA: "I am also requesting the 'blocker' user-rights" or "I am not requesting the 'blocker' user-rights at this time". (or some such).
Oh, and as an added bonus, it also should help decrease the contention at RfA somewhat.
So anyway, those are just some of the many reasons to suggest this.
And one final thing:
Since all the people who currently have these tools went through an RfA in which those commenting presumed that they would have these tools, if these user-rights are unbundled from adminship:
All users who currently have the "administrator package" of user-rights, would immediately be given the "blocker" package.
This should also help prevent opposition from those who might be concerned that their current "abilities" would be changed in any way.
Here are the user-rights that I think should be placed in a new user-group called "blocker":
What does that leave in the adminship package? A lot. (See Special:ListGroupRights.) Most of which involve the ability to review/edit almost anything content-related (save oversight), and the ability to help editors to contribute (such as account creator).
I welcome your thoughts. - jc37 03:58, 11 October 2008 (UTC)
I'm going to try to re-explain, based on the confusion below (and elsewhere).
The proposal is to split the single package of user-rights that admins receive from one package to being grouped in two packages.
The process for bestowing those rights need not change whatsoever.
That includes RfA, or whatever other process bestows user-rights.
I've listed the reasons why this would be useful several times already, but to summarise, it's to provide options for those who might wish to contribute more to wikipedia, but do not wish what some see as the "burden" of having the block-related user-rights.
We should allow for that option.
And a reminder: If this proposal is implemented, current admins would not lose the right to block. This is merely modifying the package user-rights in the software, not modifying any user-rights that admins already have. And the "blocker" group would be granted by bureaucrats on en:Wikipedia, just as these rights always haves been.
And to make it clear: this proposal is not about giving non-admins the ability to block!
So adminship, and the RfA process would not change, but the following options (among others) would be possible:
This is just about providing options.
As someone said below, Let's free the wikignomes. - 12:02, 13 October 2008 (UTC)
I think this is probably not a great idea. Blocks can be very controversial, and the ability to remove someone (temporarily or permanently) from the community should be decided on the basis of community trust. Protects, on the other hand (as I said above), are much more trivial in terms of controversy and ease of undo. Prince of Canada t | c 06:56, 11 October 2008 (UTC)
(ec)Difficult issue. Essentially it involves splitting not only responsibility, which here is given on trust, but also accountability to the community. Admins are given the mop on the basis of being able to exercise judgement in a number of dimensions. I feel that to dilute that would not only create an unnecessary layer of bureaucracy (in more than one way; consider the effect on WP:AN and WP:ANI- would we need yet more pages for such limited reviews?); additionally, there would undoubtedly arise conflicts due to this separation of functions. The ability to delete pages is perhaps the least contentious here, but again, understanding of policy is paramount and I perceive little difference between the judgement required for that, and the exercise of discretion in blocking. If we would trust some editors to properly assess a CSD, arguably we should also trust them to know when, and for how long, a vandal should be blocked. Accordingly, i remain to be convinced. -- Rodhull andemu 00:13, 12 October 2008 (UTC)
I'm going to try to re-explain, based on the confusion above (and elsewhere).
The proposal is to split the single package of user-rights that admins receive from one package to being grouped in two packages.
The process for bestowing those rights need not change whatsoever.
That includes RfA, or whatever other process bestows user-rights.
I've listed the reasons why this would be useful several times already, but to summarise, it's to provide options for those who might wish to contribute more to wikipedia, but do not wish what some see as the "burden" of having the block-related user-rights.
We should allow for that option.
And a reminder: If this proposal is implemented, current admins would not lose the right to block. This is merely modifying the package user-rights in the software, not modifying any user-rights that admins already have. And the "blocker" group would be granted by bureaucrats on en:Wikipedia, just as these rights always haves been.
And to make it clear: this proposal is not about giving non-admins the ability to block!
So adminship, and the RfA process would not change, but the following options (among others) would be possible:
This is just about providing options.
As someone said above, Let's free the wikignomes. - jc37 09:39, 13 October 2008 (UTC)
So, I see poor JC37 getting a might frazzled here-- let's try this approach.
Consider the tool to change a page from unprotected to semi-protected. This is a tool that has very little potential for damaging the encyclopedia. Whether the change is justified or unjustified, it is temporary, easily reversed, and will not affect 99% of our editors.
On the other hand, consider the power to edit protected pages and templates. This is a very dangerous tool that, in the wrong hands, could result in widespread vandalism all across the project.
Now surely the level of trust we must to have in someone to let them semi-protect a page isn't the same level of trust we must have in someone to let them edit protected templates.
Right? -- Alecmconroy ( talk) 07:50, 12 October 2008 (UTC)
I don't tend to see blocking as especially contentious. Bad blocks are usually quickly overturned and unlikely to happen too often before dispute resolution is introduced. I tend to view the ability to semi-protect as on a par with blocking. If the right was handed out liberally the whole encyclopaedia would be indefinitely semi-protected within a very short time. Protection, and the ability to edit protected pages, take experience to do properly, without locking out valuable unregistered editors. The ability to distinguish a content dispute from vandalism, edit-warring from wikification, to judge the balance of positive to negative edits, to know when an edit has consensus or not, a user has expended all their unblock requests, or whether a title is so implausible that it needs salting, all involve the same judgment as blocking and are just as likely if not more to drive away new editors. I accept the ability to edit protected pages, especially templates, would be a useful right to dispense to trusted editors, but I don't see why this can't go through a RfA. -- zzuuzz (talk) 14:10, 12 October 2008 (UTC)
The block/unblock permission is not the most dangerous permission in the 'sysop' package. For reasons I won't discuss (e-mail me if you're curious), there is another permission available without Foundation approval that has the capacity to cause almost irreperable damage to the site. If I had any doubt about an admin candidate's trustworthiness, or if their judgement was called into enough question to suggest withdrawing certain permissions, blocking is not the ability I would remove. While I sympathise with the idea of the OP, trying to separate the 'Big Three' of block, delete and protect, is unlikely ever to gain much traction. They are all awesomely powerful in their own way if used improperly; it is simply not possible to say that one is less or more dangerous than the rest. I would fully endorse splitting up the 'sysop' package to allocate more of the genuinely minimal rights in a more open and accessible fashion, but the Big Three must remain together, and loss of trust in one must necessitate a loss of trust in all. Happy‑ melon 18:04, 13 October 2008 (UTC)
It seems like there's a couple different types of "trust" floating around that are often getting conflated. One version is "trust not to be malicious"-- when a user has been around for a certain amount of time, kept their nose clean, invested some serious time in the project, and generally seemed to have the right temperament, I "trust them not to be malicious", and I'd be willing to give them any tools that could help the encyclopedia but could be misused by a malicious user to the detriment of the encyclopedia.
But, there's a whole other different sort of trust that's a higher level of trust, above and beyond the "trust not to be malicious". Before I'd be willing to give someone blocking ability, it's not sufficient just for me to "trust them not to be malicious". I would only support giving the power to block established users to someone who I "trust to have excellent judgment about complex matters". Being good-faith is not enough to be an admin-- you have to actually be good at using the tools.
Because we've just been using the word "trust", we've conflated these two meanings, and that's what's getting lost in these discussions of relative dangerousness of tools. We consider what the tools could do in malicious hands and recognize, correctly, that all are quite dangerous. But what's missing is that all the tools are NOT of equal difficulty.
There's a very large, large population of users who I "trust not to be malicious". There's a lot of people I trust to use the "semi-protect a page" or "block an ip editor" power. There's a much smaller population that I "trust to be good at using the 'block established editor' power". I may trust all of the editors to try their best-- but for some people, for the complex tools, their best just won't be good enough.
It would be nice, someday, if we could recognize the distinction. If someone, without having been malicious, nonetheless proves unable to use a particular tool, it would be nice if arbcom could let them still keep the tools they HAVE been able to successfully use-- rather than face an all-or-nothing choice. -- Alecmconroy ( talk) 11:30, 14 October 2008 (UTC)
Why don't we do it more like the current rollbacker system?
I took a look at the list over at Special:ListGroupRights, and that is a lot of things that an admin can do. Just cutting out the blocking still leaves so much that we still must have the RfA process for those users.
So I suggest doing it the other way around. If say 4 admins marked a user as trusted that user would be able to do some semi-risk tasks. And I think that it should be enough that one admin marks the user as not trusted to remove the tools from the user.
Let's identify some tasks that are fairly low risk:
This would mean that no RfA process would be needed for those users. Thus much less bureaucratic.
-- David Göthberg ( talk) 14:01, 12 October 2008 (UTC)
Is there a way for there to be a Special:Log/newbies like there is a [1]? It would be quite useful for tracking new things going on; blocks on newbies, moves (does "Grawp" ring a bell?), etc. Thanks, ~ Troy ( talk) 02:06, 21 October 2008 (UTC)
There is a bot proposal to remove autoformatted dates and leave solitary years alone. Please see Wikipedia:Bots/Requests for approval/Cleanbot. Regards Lightmouse ( talk) 13:19, 21 October 2008 (UTC)
One of the most impressive thing about Wikipedia is how many language editions there are of it, as listed on List of Wikipedias by language, and also at Category: Wikipedias by language. There are, according to the the Wikipedia article, 262 languages in which one can read Wikipedia. I am in favour of keeping the list as it is; but could the category be organised more hierarchically, so that is grouped more hierarchically? At the university where I teach, students seem, in general to find the university's intranet easier to navigate if icons are arranged in folders. In the same way, would the category be better organized if we had, say, separate categories to list, for example, African language Wikipedias, South-East Asian language Wikipedias, American language Wikipedieas, European language Wikipedias and so on and so forth? ACEOREVIVED ( talk) 19:44, 23 October 2008 (UTC)
Thank you John, although my proposal above was only a suggestion that we categorise, not necessarily that we categorise according to countries -we could, for example, have a category "Indo-European languages" and then a category "Semitic languages" and then a category, say, "Austronesian languages". Just a suggestion. ACEOREVIVED ( talk) 20:31, 24 October 2008 (UTC)
I would like some editors who have a better mathematics education than I, and perhaps some professional scientists (if they have the time, which I realize they don't) to please consider re-activating WikiProject General Audience. 69.140.152.55 ( talk) 01:49, 28 June 2008 (UTC)
Please see discussion here. 69.140.152.55 ( talk) 23:09, 24 October 2008 (UTC)
Alright, so I haven't gotten annoying on Wikipedia on years, but I've noticed something and a lot of other users are getting bugged about it, too. It's the whole "humans rule the world" idea. No, bugs do. Or maybe algae... Anyway, it has to do with articles being mostly focused on humans. This, of course, is biased. Articles, such as "life expectancy" are focused on humans. No! The focus needs to be taken away from humans. At best, the article should be downsized and humans should be a subsection or another article in itself. What am I trying to say here? Articles are biased because they refer more to humans than other species. -- Cyberman ( talk) 05:23, 17 October 2008 (UTC)
Let's just nominate humans for deletion -- Ron Ritzman ( talk) 13:28, 17 October 2008 (UTC)
I agree with Cyberman in a general way, but I think it should be noted that when readers come here, they will most likely be looking for information on humans and that most editors are human and thinking in human terms when they make additions. Wikipedia's anthropocentrism can be dealt with gradually with the addition of information about non-humans. No reason to panic about it. Abyssal ( talk) 18:06, 17 October 2008 (UTC)
I think this is getting a little out of hand without realising why we don't want systemic bias... — Werdna • talk 22:47, 20 October 2008 (UTC)
What's systemic bias got to do with presenting a neutral point of view, Aditya? The reason we try to avoid systemic bias is because we want our articles to be useful to anyone who reads them. We don't want people in Australia reading an article on Supreme Courts without some reference to courts other than the US Supreme Court.
Systemic bias is conveniently a non-issue in terms of "anthropocentrism", because we don't have very many non-human readers citation needed... — Werdna • talk 10:20, 25 October 2008 (UTC)
I brought this up at WP:VPP yesterday (and have so far received no responses), but it occurred to me that I probably listed it in the wrong place, since it is not a policy proposal but a "how to" guide, like the others in the category. I'm hoping to be able to officially launch this soon.
This guide has been under development since October 1st and publicized since that time at various appropriate forums, including VP. It has been publicized at Wikipedia talk:Images and media for deletion, Wikipedia talk:Image use policy, and WT:CSD. It is currently linked at Wikipedia:Deletion policy#Processes, Wikipedia:Guide to deletion, Wikipedia:Deletion guidelines for administrators#See also and Wikipedia:Image use policy#Deleting images. It has also since October 2nd been listed at RfC, here. I think it has received sufficiently widespread exposure, and so far all feedback has been essentially positive. (One fellow, here, objected to actual deletion policy, but as this document is only a compendium of deletion practice, I pointed him to the appropriate forum to discuss his concerns.) Discussion has primarily centered around specifics of wording; there seems to be general consensus that the compendium is useful. Any further feedback or guidance in launching this would be helpful and greatly appreciated...right down to some guidance on at what point "proposed" is removed. :) -- Moonriddengirl (talk) 12:04, 24 October 2008 (UTC)
See Wikipedia talk:Babel/Levels#Should the descriptions be made clearer? -- Army 1987 (t — c) 12:35, 25 October 2008 (UTC)
It is impossible to go through this list [3]. It needs a contents section that allows you to click a letter or number such as on List of biochemistry topics 89.204.247.134 ( talk) 13:40, 25 October 2008 (UTC)
It is my belief that there are far too many pages dedicated to encouraging and educating people on how to maintain and contribute to Wikipedia. The number of pages on this subject causes disorganization. Between Wikipedia:Contribute, Wikipedia:Community portal/Opentask, Category:Wikipedia maintenance, and Template:Resources for collaboration, in which many of the pages repeat each other, I think the information should be synthesized and combined into one page. Voyaging (talk) 18:01, 25 October 2008 (UTC)
I have been thinking that the wording of the current Primarysources template misses a key aspect of how primary sources might be used problematically. An article can misuse, overuse, or overemphasize primary sources even if it also references plenty of independent ones. I have raised the issue at the template's talk page, but that doesn't seem to get much activity. PSWG1920 ( talk) 22:51, 25 October 2008 (UTC)
While I understand this might not add to everyone's use, I would find it useful to have the option to have a cursor as crossed vertical and horizontal lines (lengths of 1/4 inch to full screen at my selection) with the lat & Lon numbers in either deg. min. sec. or dec. deg. attached to the vert and hor lines and at a distance to leave the intersection clear to view. This should be an option a user could select, among others, just so the average user should no be too annoyed with Me. Art—Preceding unsigned comment added by 24.190.246.208 ( talk • contribs)
I have been trying to find a template to show that a discussion has been reopened. I was pointed to {{ relisted}} which in my original case was suitable. But what if it is not to reach a consensus but for a general discussion.
I therfore created afterwards {{ reopened}}, which could act as this to generally say that it has been reopened e.g. from an archive, or as an alternative to relisted.
What do people think?
Am i on the right page to discuss this?
Simply south ( talk) 19:56, 26 October 2008 (UTC)
Don't know if this is a technical issue or just a policy one, but I really cannot see a reason why we shouldn't require autoconfirmation before allowing uploads. There really isn't a good reason why someone's first contributions would be uploading images and a large number of images that have problems are because people don't know anything about Wikipedia, let alone something as complex as our image policies. -- Ricky81682 ( talk) 22:39, 26 October 2008 (UTC)
When searching for something, and the text field brings up suggestions, some of those suggestions are the same except for capitalization, but some of those redirect to others of those; for example, type enough of "Albert Einsten" and it suggests "Albert einstein" [sic], which is nothing more than a redirect to the first of the two; how about eliminating these redirects from the suggestion field? OneWeirdDude ( talk) 02:54, 26 October 2008 (UTC)
When you click on a red discussion tab, I think you should be taken to the new section window (i.e. with a heading box; as if you'd pressed +) instead of just the normal edit window (as if you'd pressed ). It would just help new users in creating new discussion pages in case they were not sure how many = signs they needed. It Is Me Here ( talk) 18:17, 26 October 2008 (UTC)
The following just occurred to me--
Is there any way we could get some small minority of the Wikipedia community to have access to the sorts of databases any typical university would have-- things like JSTOR and Fulltext Science Journals, etc?
I have no clue how much such things cost, except to note that the cost is small enough that most university libraries are capable of providing it for all students.
I think it would be very useful to the project, in creating new articles on the latest in science, if we could provide that kind of access to some small sliver of the project-- either the foundation paying, or getting some large university library system to let us "piggyback" by them donating the access to the project.
Any thoughts on whether this might theoretically be feasible, and if so, how it could come to pass? -- Alecmconroy ( talk) 06:55, 27 October 2008 (UTC)
This is a proposal for an interface change in relation to categories as seen at the bottom of each page. I don't know if this is the right place for this, and if not redirection would be appreciated.
I would like to see dots such as "•" or similar to replace the "|" that seperates the categories, for aesthetics reasons. It is much easier on the eyes, as the wouldn't be any confusion between "1"s, "I"s and so forth. Many templates now use dots instead of |'s. The Windler talk 09:50, 30 September 2008 (UTC)
There seems to be some support and various suggestions. Which suggestion will get the task done. I don't understand some of the suggestions. The Windler talk 02:01, 1 October 2008 (UTC)
It is possible to do this via the following user script, without the need to make any global changes:
addOnloadHook( function (){
var cat_div = document.getElementById('mw-normal-catlinks');
cat_div.innerHTML = cat_div.innerHTML.replace(/\|/g,'•');
});
- SigmaEpsilon → Σ Ε 01:53, 3 October 2008 (UTC)
Gah. I see |'s used throughout the software, and I like it that way. Yes, this issue is primarily about personal preference, so please don't quote WP:ILIKEIT to me. I oppose this proposal as given unless I can be convinced that it won't disrupt the consistency of the interface, as other interface elements use pipes (|'s), as MZMcBride notes, and the effective change would only change category separators. Until it becomes a personal preference option, I don't think this should be changed. {{ Nihiltres| talk| log}} 04:51, 3 October 2008 (UTC)
About consistency of the interface: As far as I can tell, only "internal" pages use the | as a separator. In mainspace, the dot is the more commonly used separator. As example, take a look at the Main Page! -- Kildor ( talk) 08:34, 3 October 2008 (UTC)
I support the change from pipe to dot, a dot is more ergonomic and also helps site consistency. If somebody wants to keep the pipe for whatever reason, he can use the user script. Cacycle ( talk) 15:30, 3 October 2008 (UTC)
So what happens now???? The Windler talk 02:43, 6 October 2008 (UTC)
Please get rid of the bullets: they are far too bold, drawing the eye from across the page. Use either midpoints, which are acceptable typographic separators, or vertical lines, which are common link separators on websites (although it's true that they can slow down reading by looking like figure 1's, small l's, or capital I's).
Please follow two millennia of writing conventions rather than trying out new ideas. If you don't believe me, see what the expert says: search in Bringhurst (book) ( Amazon) for bullet (p 304), “used chiefly as a typographic flag . . . to mark items in a list, or . . . to separate larger blocks of text,” and midpoint (p 313), “an ancient European mark of punctuation, widely used . . . to separate items in a horizontal line”. Thanks. — Michael Z. 2008-10-09 05:40 z
Here's my summary of the discussion above (please correct any mis-/missing attributions). Note that there is a difference between middots and bullets (see the "Dot size reference list" section here). The OP suggests a dot rather than a bullet, so it would be helpful if this could be clarified.
Some general remarks to comments above in this section: 1. The current bullets are problematic with certain fonts, therefore we will most probably use an unobtrusive bold middot (·) instead. 2. It is the pipes which are inconsistent with the current Wikipedia styles (e.g. as agreed upon for templates), not the dots. 3. All anonymous users (our main audience) use monobook as well as the vast majority of registered users. I do not think that some minor aesthetic issue for the minuscule fraction of users of other skins should prevent us from fixing it for all other users. 4. There will almost certainly not be a gadget for such a minor issue that can easily be changed with one line of code on the monobook.js page as described above. Cacycle ( talk) 14:45, 10 October 2008 (UTC)
li:before { content: }
, which does resize the bullet with text. Using border-left is suitable for generating the vertical line, and works in MSIE, too, so it could be a useful default behaviour. No one seems to worry about Wikipedia's ubiquitous blue unordered-list bullet getting resized, so maybe this won't be a problem here, and of course with CSS a registered editor could change the separator. In browsers which support CSS3 background-size, the bullet's size can be specified in ems, which should resize with the text display (I haven't tested this). —
Michael
Z. 2008-10-10 21:01 z:before
and :after
selectors, it's not going to work (And in fact, it does fail miserably in IE7 on another computer I happened to have handy here). Reports are that IE8b2 does support them, finally.
Anomie
⚔ 02:10, 13 October 2008 (UTC)
div#mw-normal-catlinks a+span {}
might be used to select the first child in this case—would that work in MSIE? But anyway, if we can change the HTML to create an unordered list, can't we just add a class to the first item anyway? —
Michael
Z. 2008-10-14 18:08 z
As some people imply above; there should be no "character" separating such items; because separators are presentational, not data. The items should be in a list (i.e. use OL
or UL
; plus LI
HTML elements, and should be visually separated with a (CSS-applied) background image or border. This is good practice; both semantically and for improved accessibility and usability. See also earlier discussion of this issue, still to be resolved, at
Wikipedia talk:Accessibility#Horizontal lists.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 19:47, 12 October 2008 (UTC)
display: none;
applied. Better to use existing techniques to make the page accessible to people using today's (and yesterday's) screen readers than to propose future changes. —
Michael
Z. 2008-10-21 07:36 zI think it is possible. I whipped up an example which seems to work: Semantic category listings for Wikipedia.
There is a presentation glitch in the way MSIE draws borders on inline elements which wrap—I may have a clean workaround, but it's much too late to test it tonight. — Michael Z. 2008-10-21 07:08 z
I would propose that Wikipedia adopt a 'Valued' or 'Quality' images department. The images that garner this status on Wikipedia would have to be tagged with a different template to the Valued or Quality image seals, in order to distinguish between them. I suggest that images that receive this status should be highly encyclopedic images, although not necessarily of excellent quality. Images that illustrate a point in an exemplary manner, for example, could be nominated as these 'Encyclopedic Images'. There would obviously be problems, for example: who defines an image as being encyclopedic or the most valuable of a large group of images? What scope should or could an image be nominated within? Thus, a vote of consensus would be required. I think the initiation of such an area would benefit Wikipedia. Diagrams, sounds and various other media could also be included in this. I would be willing to draw up a draft for the page; however, the decision must first be made. What does the community think? Elucidate ( parlez à moi) Ici pour humor 08:21, 23 October 2008 (UTC)
We are now standardising the colours for several of the system warning notices such as MediaWiki:Editingold and MediaWiki:Protectedpagewarning. Everyone is welcome to join in the discussion and have their say over at Template talk:Fmbox#New type?.
-- David Göthberg ( talk) 15:16, 25 October 2008 (UTC)
I'd like to mass remove
And any other simlar icon usage from the main space where their usage is similar too [9] using WP:AWB as per Wikipedia:Manual_of_Style_(icons)#Help_the_reader_rather_than_decorate any opinions ?
I Agree. See Design#Terminology ( old diff, sense is prevailing now), which has one adamant defender. 96.50.4.248 ( talk) 19:14, 27 October 2008 (UTC)
Ten More at Multimedia ( diff). Ugly suckers. 96.50.4.248 ( talk) 18:58, 28 October 2008 (UTC)
I've been mulling this over recently... One can set their watchlist (as well as RC) to generate a list of articles that have been changed that are collapsed by javascript, with one link of 'all changes' today, and by using the javascript, can pick and choose which 'diff' or 'cur' to work from.
What I'm proposing is that, like an email list, one can set an opt-in option on their preferences to allow them to be emailed when a page they were watching was changed. However, to reduce the number of emails any one person would receive (I can only imagine for the people who watch thousands of pages...), this option would provide the changes in a digest type format, rather than as separate emails. This would enable people to keep track of their watchlist while away, or allow people to view their watchlist (a day late) from their email rather than by logging on. Of course, this would also (only) work if they supply their email, but special:emailuser works only in such a way, and there is the opt-in for messages to be sent when your talk page is changed.
For example...
We have in the header: Watchlist changes for 2008-8-28 (or what not. Also to be sent out at the time [below] one day later)
A slightly alternate form would be:
I'm not quite sure on what time these emails would be sent out by the server, though I'm leaning toward 0:00 <local time> where local time is the time offset specified by the user for watchlist and recent changes.
Thoughts? -- Izno ( talk) 05:46, 28 October 2008 (UTC)
There is a watchlist RSS feed available at http://en.wikipedia.org/w/api.php?action=feedwatchlist . Configuration is as follows:
Parameters: feedformat - The format of the feed One value: rss, atom Default: rss hours - List pages modified within this many hours from now The value must be between 1 and 72 Default: 24 allrev - Include multiple revisions of the same page within given timeframe.
from http://en.wikipedia.org/w/api.php
Any decent mail program supports RSS, so emailing shouldn't really be necessary. MER-C 10:41, 28 October 2008 (UTC)
I'm sure that a page for recent redirects would prove to be useful, especially for spotting and reverting vandalism. A lot of Grawps' IP socks just redirect pages to nonsense, /b/tards are prone to do the same, and it's not uncommon for the usual vandals to simply redirect a user talk page as a form of Harassment. Any thoughts? ~ Troy ( talk) 23:54, 23 October 2008 (UTC)
Just wanted to put in a word for Wikipedia to start using ReCaptcha for our verification captcha. It's a community-driven information-technologic project like Wikpedia and I think it would be good for our karma.
This content was a direct copy from http://recaptcha.net/learnmore.html - we can't have copyvios here any more than the mainspace. Follow that link above to read what Jengod's talking about. Happy‑ melon 20:05, 28 October 2008 (UTC)
Just something to think on. Thanks for reading. jengod ( talk) 16:47, 28 October 2008 (UTC)
reCAPTCHA's audio captcha is also trivially breakable. A MediaWiki extension is already available, but its activation on Wikimedia projects has been repeatedly refused by Brion Vibber and Tim Starling on the grounds of it not being free software, the dependence on an external site, and the lack of security of its audio captcha. — Werdna • talk 14:10, 29 October 2008 (UTC)
I'd like a new template created to enable tagging of articles that excessively use " Ibid." references — a practice that is discouraged in our footnotes guidelines because of the difficulty involved in keeping such references consistent over time (some articles, such as English Reformation, don't even use it properly). A full-text search for "ibid" turns up dozens of articles that could use such a tag. Dozens more use the equally problematic op. cit. and loc. cit. (these are also misused in some articles). I think this is prevalent enough (and will no doubt continue to be prevalent enough, even after the current instances are fixed) to warrant the creation of one or more templates (and associated category/-ies) to alert interested editors to such articles. I'd like to leave it to someone else, however, to choose the title and format of the template, since I don't have a lot of experience in creating these kinds of templates here on Wikipedia. Anyone interested? - dcljr ( talk) 21:01, 24 October 2008 (UTC)
---As John Broughton suggests in the 7th paragraph I copy this here from the technical village pump---
Hello: I think that many people like me look for information in different Wikipedias (different editions/languages of it). I believe that not few people, to save time, use the offered (in one of the first code lines, that begins with <link rel="search") search engine plug-ins for the browsers. If Firefox is used each plug-in comes with an icon (in this case a W). The problem is that, as the icons of the different Wikipedias are all the same, it happens to me often that I search in a Wikipedia that I didn't want to look for. I think that this could easily happen to more people. The solution is easy: to put a flag in a corner of the icon: for example the one of Italy for the Italian Wikipedia. Thanks, -- Edupedro ( talk) 22:29, 26 October 2008 (UTC)
site:en.wikipedia.org
for the English Wikipedia. You can even
create a "smart keyword" in Firefox so that you don't have to type as much. (Also, I think that the "W" icons you mention are actually part of the Firefox browser, rather than something provided by the Wikimedia Foundation; if so, it's somewhat pointless to make a suggestion on this page.) --
John Broughton
(♫♫) 14:44, 27 October 2008 (UTC)←I'm thinking this probably isn't the greatest idea. It's just an invitation to drama and arguments over using the 'right' flag. Plus, I just don't see many people using it--and those who would, probably already know, or know where to ask, how to change favicons. [ roux ] [ x 23:33, 29 October 2008 (UTC)
Another option could be to precede or superimpose the W logo with a little language code. These could be created using a tiny pixel font, 5 pixels or so tall. — Michael Z. 2008-10-30 16:49 z
DE.W
EN.W
WPT
The last one needs a 1-px white outline for the language code, so it's clearly readable over the W. — Michael Z. 2008-10-30 16:55 z
Currently nominators of featured sound candidates follow a practice of nominating and then supporting ('voting for') their own nominations (see for example here). This is also done on WP:FPC where the expression used is 'support as nominator'.
This has been an issue on WP:FSC because of the lack of transparency (to put it minimally) in the process of reviewing candidates.
So, I propose this 'nominate and support' ('support as nominator') practice be discontinued. Nominators in future should only nominate, and other editors should support (or oppose or whatever). -- Klein zach 01:00, 24 October 2008 (UTC)
This is the text at WP:FSC:
If a nomination is listed here for at least 14 days with three or more supporting declarations and the general consensus is in its favor, it can be added to a Wikipedia:Featured sounds list.
The requirement appears to be nomination + 3 supports = 4 'votes'. It's not. It's really 3 'votes'. -- Klein zach 00:42, 26 October 2008 (UTC)
Now then, my thoughts. 3 votes, including the nominator's, has been what's required for the entire history of WP:FSC, as a review of the archives will show. So, including the nominator in the count of three is the default, and changes would need consensus. I do not think that we have sufficient voters to justify an increase to 4 - in practice, this will only serve to increase the already somewhat excessive time that it takes to get enough people to review. (Featured sounds, due to still having relatively low numbers of voters, only has a minimum time period, not a maximum.)
I do not know what Kleinzach considers the "lack of transparency" at FSC. It certainly could benefit from more people, but I don't see any aspect that isn't transparent and above board. Shoemaker's Holiday ( talk) 04:47, 28 October 2008 (UTC)
That leaves the problem of determining the "general consensus" in favour of promotion. Here are two examples taken from this month's files:
They were promoted and immediately removed to the archive - examples (to answer Shoemaker's Holiday's question) of the lack of transparency in the WP:FSC process. Anyone involved would have assumed that these files would not be passed, but they were! -- Klein zach 02:51, 29 October 2008 (UTC)
Kleinzach is forum shopping. He failed to get consensus at FSC talk and rejected two compromise solutions. It is disappointing to see him raise the matter here in this manner: using examples as if no other remedy were possible, yet neglecting to note that I have specifically offered to nominate any of my own featured sounds for delisting if any editor disagrees with the closer's decision. It's surprising to see this turn of events (Wikisource and featured picture nominations kept me busy for several days); not sure what to make of this subthread--shall I open a delisting nomination now? Durova Charge! 03:35, 2 November 2008 (UTC)