Wikipedia:Village pump (proposals)/Archive 17

Source: Wikipedia, the free encyclopedia.

Proposed Policy/Guidline/Something

Howdy, folks. I have proposed that we have ombudsmen on wikipedia, similar to universities and governments. I just started the page, located

here (apologies for the rough draft it's in) and would love community feedback and development. Thanks, all. Bstone (talk
) 02:53, 16 January 2008 (UTC)

Simple English

Sorry for the late reply (previous discussion got archived), but I have finished the test versions of how the formatting may look like for having a Simple English link on our English articles. To the right is what a Simple English section may look like, another version is here, the newest version here, and here is an example of how a template would look at the bottom of an article. I tried hard to make them look as unannoying but viewable as possible. -- penubag  07:06, 30 December 2007 (UTC)

The image that's displayed is best. You could also have it so the link appears only when a corresponding page exists in Simple English. If a page doesn't exist, it could instead ask the user to start or request one. I've been thinking, maybe rename it Kids Wiki, and have stricter discipline against vandals. Or keep it as Simple English, and apply the stricter discipline as a test model. The simple english is less visited so it'd work as a less controversial testing ground for new policies. And if users get fewer strikes, then editors don't have to spend as much time on vandalism there. Also, a user banned from Simple English is still able to post on regular Wikipedia until violations reach their normal limit. --Boozerker (talk) 10:01, 30 December 2007 (UTC)

Yeah, I also like the one that's displayed the best. But I wouldn't go so far as to name it Kid'sWiki, as it might discourage english learners from using it. Let's just leave it at Simple English, with the same policies. -- penubag  22:24, 31 December 2007 (UTC)
I was skeptical about the original proposal, but both the sidebar, and the little template seem discreet enough. Good work!
I don't think renaming it Kids Wiki would be a good idea, it would mean that we would have to steer clear of certain subjects (WP:NOT#CENSOR would probably cease to exist). Remember that many users might simply be non-native speakers of English, and I think that naming it "Kids Wiki" could make them feel excluded. Puchiko (Talk-email) 12:02, 30 December 2007 (UTC)

I find it highly unlikely that a template will be added to every page, but the example in the image seems plausable. A recent change to the main page is that the simple english link was moved to the top of the language bar. Perhaps that could be done, rather than changing the entire layout. Reywas92Talk 20:54, 30 December 2007 (UTC)

I still think that just moving the SE link to the top is not noticable enough for young people, maybe bolding it or having it in a separate box would be better, as I proposed.-- penubag  22:24, 31 December 2007 (UTC)

I like this idea in general. Could it be arranged that the left sidebar image shown above appears if the interwiki link to the Simple English wikipedia is added? I do not think it should be added to all. It should be treated exactly as other interwiki links for the editors but appear above the others in a different format. I think the template for the "See also" section should be the same size as the other boxes for interwiki links included in Wikipedia:Wikimedia sister projects. Indeed one could be added there now. --Bduke (talk) 22:19, 30 December 2007 (UTC)

I don't exactly get what you're saying. You like the idea but it should not be added at all? And for the "see also" template, I originally proposed it but it got shot down due to the concern that it would "clutter" the article with interwiki links.-- penubag  22:24, 31 December 2007 (UTC)
I think what Bduke meant is for the Simple English link to appear only when a corresponding Simple English page exists (otherwise, it shouldn't appear on all pages). However, in such a case, I believe something needs to replace it -- either a red link indicating a Simple version is needed, or a note asking for a volunteer to begin one. --Boozerker (talk) 18:46, 1 January 2008 (UTC)

With the simple English Wikipedia in mind, I recently changed the "in other languages" label to read "languages." I believe that the simple English interwiki links should simply be placed at the top of the list (not separated). I especially dislike the lowercase "e" in "english." —

David Levy
22:35, 30 December 2007 (UTC)

:::I think that just simply moving it to the top of the list is not noticeable enough for young readers to realize it exists. How about this new option I created to the right? This one should address your concern.-- penubag  22:24, 31 December 2007 (UTC)

As a regular editor on Simple Wikipedia, I think that this would be a very good idea. We should give confused students the chance to read from a less complex and in depth source. Say a french student doesn't understand an article on En Wiki, he could just go to the Simple version.
However, there are thousands of editors that would not profit from this add on, so if it happens it should happen as subtly as possible on an article, but not to subtle as to be hidden from the people that really need it.
Gwib (talk) 22:28, 1 January 2008 (UTC)




Am I supposed to submit this to Bugzilla or something? I'm green on these procedures...-- penubag  02:46, 4 January 2008 (UTC)

As a regular editor of Simple English Wikipedia, I like the idea generally. I think it is a good idea to have the interwiki in a separate box (I guess it can be done by creating a special Extension for MediaWiki which is installed on English Wikipedia only). I don't think it is a good idea to have redlinks there. hujiTALK 12:02, 8 January 2008 (UTC)
I am also a regular editor of Simple English Wikipedia and support huji's point. (Personally I would prefer to have "Simple English" in black as it is not necessary to lead people to the Simple English Main Page from each article.) - One might test the red links for a limited time though. If it would attract good editors to SEWP that would be nice. But I think the SEWP should have the right to end this scheme if it attracts too much vandalism. --Cethegus (talk) 12:40, 8 January 2008 (UTC)
I fully agree with Cethegus. I am also a SimpleWiki contributor, and this that this is necessary on ENWP. --
talk
) 02:40, 9 January 2008 (UTC)
I would rather we get rid of Simple English than promote it. It is a useless branch of the English Wikipedia, no other such 'simple' branch exists. It has very little exposure, precisely is because 'simple' conflicts with the goal of an encyclopedia, which is to provide a full description. So we have a redundant, toned down version of the flagship language. What is the point? Prodego talk 02:50, 9 January 2008 (UTC)
Wow, it's good to see a bunch of simple editors backing this up (how did you learn about this proposal?). Prodego, you should not be arrogant, the Simple English WP has great potential, and many uses. Elementary schools may encourage students to use the Simple once it has been fleshed out. It can help children everywhere as well as
ESL's. Just because the Simple does not benefit you, you should not just sign it off, as it may benefit others. -- penubag 
06:52, 9 January 2008 (UTC)

I see no reason why the Simple English article should receive more recognition than other languages. -Halo (talk) 00:30, 11 January 2008 (UTC)

Simple English is still English; the whole point is that it isn't a different language! Waltham, The Duke of 17:59, 11 January 2008 (UTC)
Yeah, and no one is ever going to find that SE link unless we make it stand out, sadly I don't know what I do next in order to get this across; I have enough support from the archives.-- penubag  08:26, 16 January 2008 (UTC)

Restriction

Is there any chance if Jimbo Wales or other's could restrict IP user's from editing and will have to register an account on wikipedia, mainly because the vandalism lately is becoming a bit Over the top and it would make it a lot easier to identify who vandalize articles or userpages because their username will appear. →Yun-Yuuzhan 18:56, 16 January 2008 (UTC)

This has been suggested many times. See Wikipedia:Perennial proposals#Prohibit anonymous users from editing. PrimeHunter (talk) 21:36, 16 January 2008 (UTC)

Wikipedia exists for the readers first - or does it?

Over on

WP:ABOUT that it would be clear that wikipedia aims to be an encyclopaedia first and an editing community second (and as such, the lay reader should come first in all considerations), it seems that enough editors involved in the political discussions on wikipedia consider the editing and politics game to be more vital. Clear consensus on this appears to be needed and set in policy, so as to ensure that all policy discussions properly reflect the intended purpose of wikipedia, whichever one that may be. LinaMishima (talk
) 20:54, 16 January 2008 (UTC)

Wikipedia:Five pillars starts: "Wikipedia is an encyclopedia written for the benefit of its readers.". PrimeHunter (talk) 21:27, 16 January 2008 (UTC)
(ec) I've seen that attitude before. However I'm fairly certain consensus was reached a long time ago that Wikipedia's first goal is to produce an encyclopedia, for the purposes of reading. The editor should generally come second. It's shameful and disheartening when people start forgetting that. Equazcion /C 21:28, 16 Jan 2008 (UTC)
It truly is. Thanks for your inputs. Unfortunately
WP:ENC do not explicitly state that they are policy, even though they are core to defining the rest of policy (and you all know what the gaming editors are like). Furthermore, this brief discussion affirms the point, but finishes strangely. If anyone can find any detailed discussion of this point showing consensus that would be very useful. It seems to me that despite this being obvious in theory to many of us, a more formal statement may still be needed (and may help reduce politics to an extent). LinaMishima (talk
) 23:18, 16 January 2008 (UTC)

There's a lot of silliness involved in playing with funny tags. Don't pay attention to the tags, pay attention to actual current consensus instead.

As to the actual point: do note that wikipedia is a read/write website, so all readers are potential editors, and all editors are potential readers. (So you're shooting yourself in the foot if you claim the other side shouldn't be taken into account ;-) ) --Kim Bruning (talk) 23:28, 16 January 2008 (UTC)

That's just semantics. It's not the individual "person" that we refer to as "the reader". The point of saying Wikipedia is for the reader is to say that Wikipedia is for reading, first and foremost. The "readers" can still be the editors, when they're reading rather than editing. Equazcion /C 23:33, 16 Jan 2008 (UTC)

A wiki is social software, and its purpose to bring contributors together to collaboratively accomplish a task. An interesting quote from

GracenotesT
§ 00:11, 17 January 2008 (UTC)

Good point, but we're not talking about the exclusive servicing of one by the other or about "forgetting" one in favor of the other. The issue is the existence of a simple priority of one over the other, however small, for situations where we need to choose. Equazcion /C 00:15, 17 Jan 2008 (UTC)
You appear to be trying to state that it is editors that bring order to wikipedia and that readers care little for referencing. However, this is a fallacy, based on the assumption that readers view wikipedia as a website first and encyclopaedia second. In almost all media coverage of wikipedia, and most mentions of it's content elsewhere, people focus on it being an encyclopaedia. Being an encyclopaedia means being verifiable, well referenced and with a neutral point of view. Hence the order is in fact a desire of the readership, and what draws readers in. Indeed, the majority of complaints we see about wikipedia from outside support this further - few people care about the level of cruft, it is the level of verification is typically argued about. readers would not comment on this as regularly if it was not so vital to their readership. LinaMishima (talk) 00:22, 17 January 2008 (UTC)
Another fallacy: that the interests of the loudest and most academic readers represent the interests of all of the readers. In the two discussions I linked above, some new users delineate a view contrary to what you argue. The fact is that people approach Wikipedia from many different standards of judgments: some as a website, some as an encyclopedia. The danger of making decisions to appease the hoi polloi is that we have no idea what the majority of them want, or what their motivations are for reading. Notable standards of judgment may or may not mesh with the standards of judgment most readers exercise in evaluating Wikipedia, and we'll likely never know.
Basically: to involve the readership here is a bit of a mistake, since they're too diverse and too silent. (And, in some cases, often what they want is contrary to what we decide. Again, see the examples I linked above; read the thread in the xkcd forums I've linked.) We often see a conflict between what contributors decide and what some readers want, and occasionally this happens when Wikipedia becomes more "encyclopedic". Frankly, though, this topic is only tangentially relevant to how television episode articles should be sourced.
GracenotesT
§ 00:59, 17 January 2008 (UTC)
You are making a few false assumptions once again. Firstly, that readers have to directly be involved for their opinion to be considered at all. However, enough is understood of human motivation and expectation that it is indeed possible to attempt to generalise and sort the loudest opinions from (and this is what wikipedia consensus is about) informed educated comments. For example, it comes as no surprise to me that people prefer spoiler warnings, since they are viewed as a safety feature and even un-needed safety features are typically supported by the general public. They should never have been added in the first place (since one expects spoilers on an encyclopaedia), but once added, their small size typically upset few directly, and people are generally too forgiving of wikipedia for being a work in progress (so ignored the style problems they caused). Similarly, given that wikipedia is known for being an encyclopaedia, and the public trust sources that state this, the public as a whole will assume that wikipedia will be verifiable, neutral and referenced. They also expect that people will not be able to create articles for their friends, since they understand that such close ties result in bias. It really isn't hard to actually go away and find that the weight of research supports the ability to generalise like this. You also assume that I am in favour of trivia, which you might note that I have never stated that I am, and indeed I am against bloated casual trivia sections and non-referenced or verifiable articles of any kind. I should also note that, as I have stated previously, it is taught at high-school level that a project needs a client, and the work a project does is for the client. Wikipedia has only reached it's current level of contributors and fame through those clients, the readership. With regards to how this relates to the debate on TV episodes, it forms the core principle behind some of the emotive beliefs on either side. Without addressing this point first, there is little point discussing the rest (as arguments in the rest require the result of this to base their principles upon). The fact that previously inactive people are slowly commenting on this debate and indeed talking along these lines reveals further that this is a serious issue. LinaMishima (talk) 01:51, 17 January 2008 (UTC)
Regarding the principles of project management, you would be right to state that products within the media, however, typically differ in that they are produced so as to be targeted at an audience (rather than produced for a specific involved client). Note, however, that doing this requires following the desires and opinions of that audience (The sole exception is high level text books, for which the audience expects the author's viewpoint, but once the production team passes a certain size, audience targeting then begins to apply again). LinaMishima (talk) 02:19, 17 January 2008 (UTC)

Mobile Wiki Action

I like to Wiki on my phone, but every time I load a page I have to scroll all the way to the bottom of the page to do a new search or just use the navigation menu. I'm wondering if anyone has already brought up this issue or if anyone is bothered by it at all like I am. I know that Tikiwiki has a mobile version, but I haven't seen anything for Wikipedia other than wapedia, which doesn't let you edit pages. Discussion? --Vapor One (talk) 09:55, 17 December 2007 (UTC)

I find trying to use WP from my blackberry quite hard, it took me the better part of 15 minutes to create a new page starting from not being logged in, partly because of this "have to have the bottom loaded" issue and partly due to the general slowness of executing scripts (that's a device issue rather than WP's fault)... so ya. It would be nice. It would also be quite the project I would expect. (someone probably is going to point out that there already is a version optimized for mobiles or something, you watch) ++Lar: t/c 13:04, 19 December 2007 (UTC)
Well, I hope someone points it out. I like the idea of making contributions on the train rather than sitting adle and enjoying the passong scenery.--Vapor One (talk) 01:15, 25 December 2007 (UTC)
To the best of my knowledge the only page we have optimized for PDA's is
Wikipedia:Main Page alternative (PDA version). But I'm sure there's a script somewhere you can put in your monobook.css or monobook.js. --YbborTalk
17:45, 29 December 2007 (UTC)
Oh, and
Wikipedia:Main Page alternatives (Search Box Only) might be helpful if all you want is a search box. --YbborTalk
17:47, 29 December 2007 (UTC)
Have you tried Opera Mini? Judging from the online simulator, Opera Mini does not suffer from this problem. —Remember the dot (talk) 21:21, 29 December 2007 (UTC)
Thanks for the OperaMini tip. I tried the alternative Wiki Main Page first, but it was the same thing. Yes, I'm aware of wapedia, but it doesn't let you edit. The Opera Mini is the best bet. Thanks again. It works great.--Vapor One (talk) 04:40, 7 January 2008 (UTC)
Actually it's a little buggy. I'll probably just roam around for a better browser. I don't assume that Wikipedia will produce anything compatible with my Mogul.--Vapor One (talk) 04:57, 7 January 2008 (UTC)
Have you also tried http://en.wap.wikipedia.org – mobile optimised live version of Wikipedia that runs on the Hawhaw platform. Works really well for reading; however, it has no login or edit functions. --Breno talk 11:54, 11 January 2008 (UTC)
I usually just
SSH into my server and use the wiki2text script. yea i'm a nerd Towel401 (talk
) 21:03, 17 January 2008 (UTC)

Good articles (GA)

Like featured items (articles, lists, images), I'm just thinking maybe the symbol of GA (inline this) can be put at the top right of every GA. While for delisted GA, we can put inline <- this.
Reason: there may be people who would like to read up some articles yet unsure of the quality of those articles. With a simple glance at the top right, at least this symbol tells him/her that it's good (if it's GA). Anyway, if it's quite a badly-written article, there would've been tags telling the exact problems. Sorry if my suggestion got into the wrong place (and if someone else has already suggested this before). :S — Yurei-eggtart 06:51, 17 January 2008 (UTC)

Your suggestion is in the right place, but ... as you might suspect, this has been proposed and rejected before. See Wikipedia:Templates_for_deletion/Log/2006_March_25#Template:Good_article. The title of the template has been protected after repeated re-creation. szyslak 07:55, 17 January 2008 (UTC)
This is not the usual case of proposed-and-rejected-previously. The discussion is nearly two years old and
good article standards. (In fact, the GA standards page was only created a bare two weeks before the deletion debate.) It would be good for the community to revisit the issue and determine where consensus stands on the issue now. Vassyana (talk
) 09:12, 17 January 2008 (UTC)
I was somewhat disappointed when I saw the first reply, but Vassyana does have a point there. I counted the votes, and this is my result:
  • strong keep - 21; keep - 7; weak keep - 2 (total - 30)
  • strong delete - 7; delete - 25; weak delete - 1 (total - 33)
Counted the bolded texts only, so I might've missed out one or two. Note that there are more "strong keep" votes than "strong delete" votes, but yeah, I do believe some users don't really care about the vote being strong or weak or whatever.
I didn't read most comments but the reason for deletion was because GA was yet to become one of Wikipedia's policy (I don't quite get it though ._.). I'd say it's worth the shot to re-propose this idea per Vassyana. Besides, 30 keep votes vs 33 delete votes, I'd say it was pretty close. — Yurei-eggtart 12:48, 17 January 2008 (UTC)
Counting raw votes is not really a good measure, since in theory judgements are supposed to happen based upon the quality of the arguments put forth. Looking at the content of the delete votes, many are based on older, weaker, nature of GA status, however there is strong argument that GA is not the result of consensus, only a single individual's overview, and that has not changed. It may well be worth debating this again, but I suspect the lack of additional oversight will still be a problem with respect to public announcements of status. LinaMishima (talk) 13:26, 17 January 2008 (UTC)

Lina: Well, I'm counting raw votes to see the difference (ahhh whatever you can say I'm just bored for doing that). Since the result was delete, it was somewhat obvious that the supporters for deletion had stronger points then. The strong arguement you mention can be overcome with this following suggestion (maybe :/): we can change the current GA nomination process - make it work in the same way as FA nomination process. Suggestion: both nomination processes can be merged or something. Articles are reviewed by several editors and they will judge if the nominee becomes FA. Otherwise, they can determine if it's eligible for GA status. — Yurei-eggtart 15:16, 17 January 2008 (UTC)

Just a comment to throw into the mix, but the GA project is in the process of conducting a
sweep of listed GAs to try to address this consistency/oversight issue. I quite like the tag idea, but it also gets raised regularly on the various GA project talk pages, and just as regularly shot down. I'm not sure about the 'delisted' tag either - we'd end up duplicating the top 25% of the article talk page if this is carried to its logical conclusion :P EyeSereneTALK
19:06, 17 January 2008 (UTC)

Cross posted from Wikipedia:Village pump (technical). Please discuss here.

I figured this was the right place to get this discussion going. This is a request that the Labeled Section Transclusion extension be installed on the english wikipedia. This new extension would (it appears) have no conflict with existing extension and have several uses, especially for intermediate to advanced editors.

This extension allows for the selective transclusion of only part of a page or template (defined by <section> tags). Although this can partially be done with <includeonly> and <noinclude> tags, these two do not provide the full capabilities as provided by this extension. In my own editing experience, I have found several circumstances where these tags would have been useful:

  • In creating a Potal, the tags could be used to show a constantly updated 0-section of an article, minimizing the need for manual portal updates.
  • Also in a Portal, these tags would reduced the need for numerous sub-pages. All featured articles, pictures, or whatever could be listed on one page with selective inclusion tags.
  • Templates with intricate features that only create selective display on specific pages/prefixed pages could have their code drastically simplified and reduced.
  • "Configuration sub-pages" used by many community voting and/or maintenance centers could also be drastically simplified.

These are only a few examples of how this new extension could be used (please feel free to add more). I'm not all "hip" on the mediawiki lingo but from my basic coding knowledge, this does not seem to difficult to accomplish. Happy Editing! --omtay38 14:53, 17 January 2008 (UTC)

I would support that- many user pages have copied and pasted a section of editing rules- if only this could be transcluded. On talk pages it would be wonderful to transclude a bit of policy, or a chunk of the page under discussion. In writing geographical articles about a group of neighbouring villages- I could transclude a paragraph about the geology- it would also allow the transcluding of a paragraph that contained all the basic reference for the area. Think of the enhanced user experience and the disc space we could save! ClemRutter (talk) 19:49, 17 January 2008 (UTC)
I, too, would support that. I'd also like to see the lsth component installed, which would enable transclusion of section headings as well as sections marked with <section ... > tags. I have both transclusion extensions on my personal wiki.
Improve
]
22:12, 17 January 2008 (UTC)
This looks extremely useful. I support it being installed on this wiki. I can already think of a major improvement I could make to a template with this! Pyrospirit (talk · contribs) 23:57, 17 January 2008 (UTC)
This would undoubtedly be a nice feature to have, however, at the moment, the person who would be able to review the code and bug test it (User:Tim Starling) is quite busy with the meta:migration to the new preprocessor and a few other projects. Tim's already done some work on the extension and in the new preprocessor parser (see rev:29718 and rev:29292). Due to his current time constraints, it would be best to hold off on this proposal and revive this discussion in a couple of weeks after the new preprocessor has gone live and is running smoothly.
On a side note, anyone interested in testing the new preprocessor and searching for bugs is welcome to help; see here for details. Cheers. --MZMcBride (talk) 02:27, 18 January 2008 (UTC)

Technical: Make it possible to do alerts or reminders??

Sometimes one has to remind oneself to go back and look at an article for some reason a week or so later and just having changes show in my watchlist not sufficient. I guess it's probably too expensive or time consuming or disruptive to try to put such a system in wikipedia, but just an idea. Meanwhile, just occurred to me I'll can do it on my ReminderFox!! Carol Moore 15:26, 15 January 2008 (UTC)CarolMooreDC talk

I have a page in my User space where I store article titles that I want to go back and look at at a later date. Corvus cornixtalk 00:23, 19 January 2008 (UTC)

Equality In Pages of Daughters With Famous Fathers

Would someone who is more expert than I am in the area please compare the pages of Margaret Truman and Caroline Kennedy and explain the radical difference in tone:MT the rich city cousin and CKS the poor country cousin of name respect. Thanks! OlympedeCleves (talk) 16:22, 17 January 2008 (UTC)

My quick read - and perhaps one or both articles have changed in tone since you posted - didn't find that much difference. More importantly, Wikipedia's goal isn't to have a consistent tone ("equality") in similar articles, it's to have all articles comply with relevant policies and standards. (
be bold and fix them, or you can post a note about the problem(s) you see on the article talk page(s), and get comments of other editors. -- John Broughton (♫♫)
22:43, 18 January 2008 (UTC)

Currency conversion

I suggest following the above guidelines, but with this twist. The user would specify in "My preferences" what currency he uses (check box). Editors would invoke a template "currency conversion" with dollars or euros or whatever. The currency conversion template would convert (display to the user) to the users currency, yen or pesos, for example. The conversion would be for a limited number of currencies and values for a specific day - midnight Greenwich or something. Student7 (talk) 15:29, 19 January 2008 (UTC)

current exchange rates are only meaningful for "live" values, for example in an article on a currency itself. But articles typically mention figures for some time in the past, to which a current exchange rate has no relationship. -- Fullstop (talk) 15:53, 19 January 2008 (UTC)
So conv-currency would contain the date? Uh....never mind! Thanks. Student7 (talk) 03:12, 20 January 2008 (UTC)

A considerable problem in science is the proliferation of techniques, usually indicated by rather enigmatic acronyms like EBIC or NEXAFS. I don't think anybody in science still has a reasonable overview of all that is available or what can be done with it, what it requires etc. Wikipedia already has a lot of pages about various techniques but there is no well organized entry into what is for virtually all scientists a rather inaccessible acronym jungle. Wiki could really do science a considerable favor bt making the jungle more accessible. I have tried to categorize -admittedly rather roughly..- what I have found and extended the list of materials analysis methods but I would love to get together people from different disciplines to do this properly. I don't know what would be the best way to proceed. One possibility would be a portal but categories and a more standaridized format for technique pages could also be very useful. I dropped a line here but have since been told that may not be the best place to suggest a portal. I stand corrected but am unsure where I do suggest such things.
Jcwf (talk) 21:14, 19 January 2008 (UTC)

Currency conversion

I suggest following the above guidelines, but with this twist. The user would specify in "My preferences" what currency he uses (check box). Editors would invoke a template "currency conversion" with dollars or euros or whatever. The currency conversion template would convert (display to the user) to the users currency, yen or pesos, for example. The conversion would be for a limited number of currencies and values for a specific day - midnight Greenwich or something. Student7 (talk) 15:29, 19 January 2008 (UTC)

current exchange rates are only meaningful for "live" values, for example in an article on a currency itself. But articles typically mention figures for some time in the past, to which a current exchange rate has no relationship. -- Fullstop (talk) 15:53, 19 January 2008 (UTC)
So conv-currency would contain the date? Uh....never mind! Thanks. Student7 (talk) 03:12, 20 January 2008 (UTC)

auto reminders of namespace / topic bans

Since some users sometimes forget that they're under sanctions such as a namespace/topic ban, I would like to propose, in these cases, adding a simple bit of javascript to their monobook.js that pops up a friendly messagebox [via alert()] if they attempt to edit a page they're not supposed to. —Random832 01:15, 17 January 2008 (UTC)

Is it feasible? Jmlk17 01:18, 17 January 2008 (UTC)

You mean, something like:

var restrictedNamespaces = []; //fill in namespace numbers
var restrictedPages = []; //fill in, in wgPageName form

function isInArray(array, item) {
    if (array.indexOf)
        return array.indexOf(item) != -1;
    for (var elem in array)
        if (elem == item) return true;
    return false;
}

if ((wgAction == "edit" || wgAction == "submit") &&
    (isInArray(restrictedNamespaces, wgNamespaceNumber) ||
     isInArray(restrictedPages, wgPageName)))
        alert("Note: you are banned from editing this page or namespace.")

Requiring this for all topic-banned users might be embarrassing, however, as some are perfectly capable of remembering which pages to edit and not, and might want to view the source of a page. A bug report, also, could be submitted to block certain users on certain pages; it's likely one already exists. Another arguably better way to do this would be with CSS: hide a submit button (input#wpSave) contained within body.page-Controversial_article. I wouldn't insert this in the topic-banned user's CSS/JS unless he/she requests it, just as a courtesy. After all, it's a social ban, not a technical block.

GracenotesT
§ 01:32, 17 January 2008 (UTC)

namespace/topic sanctions are not a server-side feature, and thus the server would not be able to provide this information. Consequently, the usernames of the sanctioned editors would have to be somewhere in the article itself so that Javascript can "find" them. (for instance, <span id="wpSanctionedUsers" name="User:x,User:y,User:z"></span>) -- Fullstop (talk) 18:00, 17 January 2008 (UTC)
The information wouldn't be server-side, though: it would be hard-coded into the user JS/CSS file.
GracenotesT
§ 18:20, 17 January 2008 (UTC)
See also Wikipedia talk:Per-article blocking - a 2005 proposal generally supported by community but (I believe) not considered critical by developers. -- John Broughton (♫♫) 22:48, 18 January 2008 (UTC)
Add a whitelist though. Prodego talk 18:35, 20 January 2008 (UTC)

Block log change proposed

A problem I frequently encounter is that disruptive users create multiple accounts to avoid scrutiny. These users often are not banned after being caught. It isn't very nice to make an active user keep a sock puppeteer template on their user page. Nonetheless, we need to know when a user has had sock puppets, because this affects how we deal with future disruption. When assessing a user conduct issue, we need to know the block history of the user, and also the block history of any sock puppets. Currently, I must rummage around to find all the necessary information. This process could be made more efficient with one simple change.

The idea would be to add a link below the boilerplace text at the top of the block log MediaWiki:Blocklogtext. The link would point to the sockpuppet category associated with USERNAME. When looking at an editor's block log it will be very helpful to see whether the link is red or blue, and if blue, to drill down and see the evidence.

For User:ECW500 the link would be:

Category:Wikipedia sockpuppets of ECW500

For me:

Category:Wikipedia sockpuppets of Jehochman

As you see, this won't take up much screen real estate. The change would improve website usability and help the community by making all the relevant information available via links from a single page. What do you think? Jehochman Talk 21:59, 18 January 2008 (UTC)

Sure, why not? Who has to do what in order for this to happen? -- John Broughton (♫♫) 23:37, 19 January 2008 (UTC)
Not possible with current software.
GracenotesT
§ 04:10, 20 January 2008 (UTC)
You could however do it with javascript. Prodego talk 04:15, 20 January 2008 (UTC)
Very true, but with JavaScript it wouldn't be possible to tell if the category exists or not. Without AJAX or suchlike, that is – in which case, one could just write a user script that adds an asynchronous request-making link to the toolbox, or similar.
GracenotesT
§ 20:13, 20 January 2008 (UTC)

Applying the Blackle concept to Wikipedia, or even giving the user a choice...?

Greetings. I am a big fan of http://www.blackle.com, not only for its environmental idea but for not burning my eyes out of my sockets with intense brightness either. Couldn't this perhaps be applied to Wikipedia? Or, couldn't a user at least be given a choice whether he wants to see the page in white or black in the user preferences? —Preceding unsigned comment added by Droneriot (talkcontribs) 08:18, 19 January 2008 (UTC)

Well I've read somewhere else here that black screens don't actually save electricity. And I think there is an option somewhere around here, but I can't find it right now. Still looking though. MBisanz talk 08:48, 19 January 2008 (UTC)
I think it only saves energy on older CRT monitors; LCDs always have the backlight on, so energy savings would be marginal at best.
Improve
]
09:35, 19 January 2008 (UTC)

This link Wikipedia:Village_pump_(proposals)/Archive_13#Black_Wikipedia should point you to some users who know how to do what your looking for. MBisanz talk 08:54, 19 January 2008 (UTC)

Perhaps we should add this to the "all-too-frequent proposals" section? --Carnildo (talk) 09:07, 19 January 2008 (UTC)
Yep, thats where I looked first for it. Seems to be a good one to add or maybe a WP:BLACK shortcut. MBisanz talk 09:14, 19 January 2008 (UTC)
I think it would be useful to give users a choice - we all have preferred colour schemes, and sometimes some people just want a change. User CSS is too technical for most users, and only helps editors, not "lurkers" and casual users. I suggest a choice of 5 or 6 fixed colour schemes. Philcha (talk) 12:14, 19 January 2008 (UTC)
Wherever you put the list of choices for "lurkers" and casual readers, they are still going to have to find it. User CSS is an option if it's implemented via the Gadgets tab of "my preferences". Or via the Skins tab. -- John Broughton (♫♫) 15:19, 19 January 2008 (UTC)
Black websites are a good idea, but often neglected is the question of what happens to the surplus white pixels. Unless I am convinced that these are redeployed in a humane manner, rather than just dumped into a crowded bit bucket and left to die, I cannot patronise these sites.
And seriously, if anybody wants to develop and make available a dark skin for Mediawiki, feel free. It's open source software. --Tony Sidaway 16:45, 20 January 2008 (UTC)
Brian0918 has one. Prodego talk 00:49, 21 January 2008 (UTC)
What the hell, I made it a gadget, since people seem to like this so much. It should really be a skin, but whatever... Prodego talk 01:01, 21 January 2008 (UTC)

A considerable problem in science is the proliferation of techniques, usually indicated by rather enigmatic acronyms like EBIC or NEXAFS. I don't think anybody in science still has a reasonable overview of all that is available or what can be done with it, what it requires etc. Wikipedia already has a lot of pages about various techniques but there is no well organized entry into what is for virtually all scientists a rather inaccessible acronym jungle. Wiki could really do science a considerable favor bt making the jungle more accessible. I have tried to categorize -admittedly rather roughly..- what I have found and extended the list of materials analysis methods but I would love to get together people from different disciplines to do this properly. I don't know what would be the best way to proceed. One possibility would be a portal but categories and a more standaridized format for technique pages could also be very useful. I dropped a line here but have since been told that may not be the best place to suggest a portal. I stand corrected but am unsure where I do suggest such things.
Jcwf (talk) 21:14, 19 January 2008 (UTC)

Skip to First Edit

This would be a simple feature, though a nice one to have. When viewing the history log of an article, you could click a button to skip to the first edit (or creation of the article). This would help find the creators of articles more quickly, instead of having to endlessly "thumb" through the log to see who created the article. This of course would not be a neccessity, but more of a convenience. Polarbear97 (talk) 02:10, 20 January 2008 (UTC)

Click "Earliest". –Pomte 02:12, 20 January 2008 (UTC)
As in ... "(Latest | Earliest)" at the top of every page history. :) You can use Ctrl-End to then skip to page end. -- Fullstop (talk) 02:46, 20 January 2008 (UTC)
Well, just End should suffice, but yes. Ctrl-End is, AFAIK, only required when editing a document, not viewing it in one of the major browsers. Textareas, yes; pages, no. (Was that sufficiently confusing?)
Improve
]
05:59, 20 January 2008 (UTC)
Ah, I see. Sorry, I did not spot that button before. Thank you for informing me of it. :) Polarbear97 (talk) 17:07, 20 January 2008 (UTC)

Ipblock exempt proposal

Wider audience for commenting requested...


A proposal has started to allow established or trusted editors to edit via Tor, or other anon proxy. This discussion is located at

talk page

The proposed policy in its “needs to be worked on” form is located at

project page Mercury at 20:43, 20 January 2008 (UTC)

Customizable Random Article

Using random article, one comes across a lot of stubs and/or just plain bad articles. Should there not be an option to customize this mechanism to only find articles of a particular rating or higher (A, B, etc.)? Please correct me if there already is. I think such an option would allow people to satisfy their hunger for knowledge in unknown areas much more easily. Ryan M. (talk) 05:40, 21 January 2008 (UTC)

Or to be able to randomize articles based on what category they are in. So then I could find all articles in Category:Physics -- penubag  05:58, 21 January 2008 (UTC)
Exactly. To be able to only receive pages on animals, celestial bodies, religions, etc. would be awesome. Ryan M. (talk) 06:13, 21 January 2008 (UTC)
Random pages from a category are available in the MediaWiki software but are disabled in Wikipedia - see this bugzilla posting. -- John Broughton (♫♫) 14:53, 21 January 2008 (UTC)
I can write a tool on the toolserver to achieve this, if people are interested in it. — Carl (
CBM · talk
)
15:23, 21 January 2008 (UTC)

Portal:Featured content allows you find a random article/list/picture etc of featured quality.-gadfium
18:22, 21 January 2008 (UTC)

Random articles in a category are sort of useless, because must article are in very specific sub-categories, and these aren't well-defined. It would be better to do random articles it based on which WikiProject they're tagged for.--Pharos (talk) 18:28, 21 January 2008 (UTC)

Surely it wouldn't be too hard to script something that chooses a random article in a subcategory? So, if I wanted to learn about a random local celebrity, I could search for anything in Category:People from Furness and I would then be given something from Category:People from Barrow-in-Furness, Category:People from Dalton-in-Furness or one of the others? I don't personally use random article, but I would almost certainly use a tool like this, to help me randomly clean up or just randomly read articles within an area of my interest. J Milburn (talk) 22:31, 21 January 2008 (UTC)
That wouldn't necessarily be hard, but scripting to choose with equal probability from articles in a set of subcategories would be more difficult, and you'd also have to account for loops of subcategories. —Random832 15:38, 22 January 2008 (UTC)

Requested move of
Burma to Myanmar

A potentially contentious request to move is being discussed at

Burma on their watchlists, as I believe this article is "important" enough to warrant such "advertising". — Andrwsc (talk · contribs
) 23:21, 21 January 2008 (UTC)

Previous change previewed when editting an article

The amount of times I have almost forgot to check the last edit only to find it is vandalism! But the 'realise an edit is needed' 'check history/ last change' 'now I can edit it safe I am not hiding a vandal' slows my minor edits down.

So for me it would be ideal when clicking 'edit' that the last change is initially shown above the edit box (maybe with an added undo button), as 'when preview changes' is used. This could work for other editors too, would provide another shield against vandalism, so maybe it would work, not just as an option, but as the standard editting method? Leevanjackson (talk) 00:38, 22 January 2008 (UTC)

Was that first... "section of text"... supposed to be readable? Ryan M. (talk) 02:52, 22 January 2008 (UTC)
I think he (assuming male) means that on several occasion he's edited a page, then realised that the previous edit to the page was vandalism, meaning that RC patrollers and people with the page watchlisted are less likely to notice the vandalism edit. As a result, he'd like it to be that when he edits a page, the previous diff is shown (similar to when you undo an edit, or when you click on "Preview changes", but actually showing what the last diff was rather than your unsaved version). I personally wouldn't want such ability, but maybe someone with a little more JavaScript knowledge than me could suggest something for monobook.js? Confusing Manifestation(Say hi!) 04:44, 22 January 2008 (UTC)
Apologies for the initial gibberish, but Confusing Manifestation was correct in his deciphering of it, I thought it would be usefull to all, but not such a good start on the concensus! Leevanjackson (talk) 18:29, 22 January 2008 (UTC)

Wikipedia:OMBUDSMEN

I have spent time updating and editing the proposal. Would love for folks to give it a new looking over. Bstone (talk) 06:59, 22 January 2008 (UTC)

Template for track listing

Template:Track list and Template:Japanese track list. The basic benefit of this is that it allows parts of the data to be meta tagged, which makes future maintenance easier, and would even allow for the data to be machine readable. I'm not aware of any track listings that contain a large amount of different fields, but if there are then the labeling would also make entering the data easier. The templates also use a hack from the episode list template that makes a table cell pop out if a field is listed, but blank. This is to encourage people to fill in incomplete lists without having to place a placeholder to keep the cell open. Thoughts? -- Ned Scott
22:58, 22 January 2008 (UTC)

See Wikipedia talk:WikiProject Albums#Template for track listing for main discussion thread.