Wikipedia:Village pump (proposals)/Archive 69

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

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Automate stock information through RSS feeds

I asked at Village pump (technical) if this was technically feasible, and it looks like it is. I am not an expert on matters of stock markets, but wouldn't it be possible to use a reliable RSS feed to guide a bot to update Template:Infobox company? We could place a flag like NASDAQ = ????, and we could start on only a few companies to begin with. The bot could update with closing price and stock volume, and the template could automatically generate a company value (assuming that those numbers would equal that, I'm not certain myself). User:Gary King expressed at the above link concern over the amount of edits this would make every day (one for each listed company). I think that one edit per week would be sufficient. Obviously this is not a news site or a stock portfolio site. However, I don't think that there can be any doubt that knowing the approximate value of a company has encyclopedic value. It doesn't need to be up-to-the-minute, but most articles I have seen have out-of-date financial info, some by several years. Many more have financial info with no references, or even no context (Sega is up, but for which year, and compared to what, and who says?). It is painful for editors to try and keep this kind of info up to date, and if there is a reliable second-party RSS feed that gives exact info that bots can use, why not have them use it? ▫ JohnnyMrNinja 07:45, 3 February 2011 (UTC)

I definitely support this, the job of updating stats doesn't seem too popular, so getting a bot to do it is great. However, I do not think daily updates is required, weekly or monthly would be sufficient. Another use could also be to update currencies perhaps. Passionless -Talk 08:15, 3 February 2011 (UTC)

Ok, to make this smoother, I'd like to specify I am proposing that (at the current time) this only happen once a week. If we make it once per month now we will not be able to see how well it is doing, and once a day is probably unnecessary. We can change this aspect later, but this seems like the best increment to start with. ▫ JohnnyMrNinja 08:26, 3 February 2011 (UTC)

Where do you suggest the information be pulled from? For myself, I use Google Finance for my stock symbol formatter, which just converts stock symbols that appear in articles to links to Google Finance. One hurdle would probably be that some companies have more than one stock ticker listed in their infobox—especially the large companies, so I suppose someone would have to mark which stock ticker to use as the "primary" one for the bot? Gary King (talk · scripts) 16:15, 3 February 2011 (UTC)

I see little encyclopedic value in keeping data that is constantly updated. That's what stock market websites are for, and they provide summary over time which is much more valuable. We already have yearly summaries in the infobox. We can add quarterly valuation and have that updated by a bot. But having weekly or even monthly data seems excessive to me. --Muhandes (talk) 16:24, 3 February 2011 (UTC)

Agreed, not sure stocks value is really something of use to us. But I like the idea of automatically doing revenue and other financials that we DO track. Do you have anyone to write the bot? --Errant ^(chat!) 16:28, 3 February 2011 (UTC)

It's not the stock prices themselves I am interested in per se, but the total value of the company (stock price x number of stocks). Surely you would have to agree that the total value of a company is just as encyclopedic as its revenue stream? If once a quarter is all that is desired then that is just as easy as once a month or week. The bot has not been built yet; a bot request will be made once we have decided what it should be doing. As far as RSS feeds, I am not an expert, but every major market has RSS feeds available. I was going to leave that to the bot operator, to see which ones will be best suited for the purpose. At the very least, could we agree that a bot updating the information currently within out scope has value? Because most editors don't like updating that info on the medium to small companies, so it never gets done, and we're left thinking that some company in chapter 11 had a record high quarter. ▫ JohnnyMrNinja 21:23, 3 February 2011 (UTC)

I don't agree value beyond a yearly evaluation (and marginally quarterly) has much encyclopedic value. Consider that the stock value changes momentarily. No matter when you are going to activate the bot, it will take a snapshot of an isolated valuation, detached from the past or the future of that moment. That's sometimes worse than not giving a valuation at all. I'd be all for a bot updating the values already present in the infobox, if such a thing is possible. --Muhandes (talk) 14:35, 4 February 2011 (UTC)

(You probably mean "from moment to moment".) I agree that up-to-the-minutes stock prices are not terribly encyclopedic. However I do agree with Mr N that if we give stock prices, or total values at all, the headline figure should be appropriately up to date, i.e. this month's, this quarter's or this year's. Moreover there is, for me at least, a much bigger issue, in that while "now" is important, it soon becomes "then" and we should not be making the old information inaccessible, nor do we wish to clutter out relatively small article allowance with every stock movement. What I would like to see is, perhaps, annual capitalisation figures. For small companies, or new companies they could sit in the article, for older companies they could go on their own page. This applies to many fields where the numbers, or members, are constantly changing, for example armed strength. I think the gmail page is regularly updated with he amount of space avaiable. Rich Farmbrough, 15:27, 4 February 2011 (UTC).

To address Johnny's interest, valuation of a company (which I agree, is probably interesting) does not change from moment to moment in any meaningful way. Any kind of live updating is probably excessive for this purpose. We usually determine the market valuation of a company when there is a major event such as an IPO, a bankruptcy, a buyout, or a similarly large investment made in one fell swoop by a single party. While this is still a snapshot, it at least represents a statistically significant and long-term reference point. These events are almost always covered in reliable sources and can be accurately documented in the body of the article. They should suffice as a static ballpark figure for the sake of a WP article and only need to be updated when another major event occurs. The daily, weekly, monthly, even annual stock movements are either too small to be worth updating, or too volatile to be reliable information for whatever period is measured. It's a catch-22, and that's just the nature of the market. I don't object to the idea of having a continually updated stock price, but it doesn't seem worth the amount of automated edits that it is going to generate. If this could be done via some external method, like having a client script pull the live price from some other source, rather than writing the updates directly into the article, I would consider that to be more viable from a maintenance standpoint. Ham Pastrami (talk) 22:38, 5 February 2011 (UTC)

Expiry of watchlist items

I would like an additional feature whereby watchlist items have an expiry time. I.e. when adding an item to the watchlist, I would like to be able to specify that it expires (be removed from my watchlist) in x days. Of course the default for expiry would be infinite, and therefore not function differently to the current system. I edit many articles, and feel responsible to address concerns on a talk page soon after my edits, however after a decent interval, other edits will make my having to respond less important. I'm finding it impossible to keep track of pages when too many get placed on my watchlist, so I have to delete articles manually from time-to-time anyway. This proposal would help to automate that manual process. I suspect people running bots and scripts will also benefit from an expiry feature.  GFHandel.   07:05, 15 January 2011 (UTC)

If it would be feasible to install such a feature then I would be sure to use it often as I also will make a minor edit, and then watchlist the page to see if I get any comments about it, but never return to the page again, and after awhile have to manually remove it anyways, but can't keep track of what pages I edited when. --AerobicFox (talk) 07:15, 15 January 2011 (UTC)

Handel's proposal sounds good. But in the meantime, it would be such an advantage in tending to one's watchlist to have a little button adjacent to each item to unwatch it, without having to go through the contortions of visiting the editable list, ticking boxes, scrolling and saving, or alternatively of going to the target, unclicking the blue star and returning. Tony (talk) 08:03, 15 January 2011 (UTC)

OK. See user:js/watchlist. ---— Gadget850 (Ed) ^talk 17:53, 15 January 2011 (UTC)

Yes, would be good. In the mean time, WP:POPUP has an Unwatch item that saves clicks. Rd232 ^talk 10:20, 15 January 2011 (UTC)

Another way of doing something similar would be to have a device to incude the pages of your last 50/100/whatever contributions included in your watchlist. Peter jackson (talk) 12:05, 15 January 2011 (UTC)

A slight tweak on this proposal that I would find useful, would be a facility to easily de-watchlist any items that have not been updated in x days. That is, you display the watchlist, you specify the number of days and click - articles where my edits were definitely uncontroversial i.e. no-one has changed or commented on the article for x days since my edits - are gone from the list. Colonies Chris (talk) 14:26, 15 January 2011 (UTC)

I would find it a big DISadvantage to have instant unwatching on the watchlist, myself. An optional timeout sounds like a very good idea, though. ♫ Melodia Chaconne ♫ (talk) 14:52, 15 January 2011 (UTC)

Strong support. I just recently took a weed whacker to my Watchlist, removing all the stuff I only reverted vandalism on or PRODded or whatever. This feature would be a godsend. -- RoninBK _{T C} 16:04, 15 January 2011 (UTC)

Ed, thanks heaps for that little x button function for the ongoing weeding of one's wl garden. At some stage, we should push for it to be a permanent feature (or at least optional via prefs; but I can't see what the objection would be to permanence—the little x adds almost no bulk to each item). Tony (talk) 00:57, 16 January 2011 (UTC)

Not a bad idea. Now I have to figure out why it doesn't work on my watchlist any more. Probably one of the multitude of scripts I have loading. ---— Gadget850 (Ed) ^talk 01:48, 16 January 2011 (UTC)

It seems that there is good support for the idea. What happens now?  GFHandel.   19:16, 21 January 2011 (UTC)

• I could write up a script on the toolserver that could be used to help prune my watchlist, right how I have a personal tool that I use, it has a list of about 100 pages that I want permanently on my watchlist, and then grabs a list of the last 500 pages Ive edited and combines the two into a list I just dump onto Special:Watchlist/raw after I clear it. ΔT _{^{The only constant}} 19:26, 21 January 2011 (UTC)

I like this idea a lot, and would strongly support implementation. I too will often make a minor effort where I'm only interested in "watching" it for nn days. Having said that, another way to do this might be to have an advanced feature for editors that classify the edit being made into one of several categories which would then have user-definable behavior for each category. E.g., for N2eCat4, I could customize it to remove all edits from my watchlist at nn days, or I might just use the Cat to look at all of my recent Cat4 edits on one rainy Wednesday afternoon and then bulk delete them after my review. In short, great idea for a feature. Implementation details could vary depending on how powerful someone wanted to make the tool. Cheers. N2e (talk) 19:52, 28 January 2011 (UTC)

• Support. Great idea! It should be in the preferences and also a clickable "remove" box on the watchlist itself beside each item. Right now I "have 5,281 pages on your watchlist (excluding talk pages)." It's a pain to weed it out, and I usually have about 4,000, but this idea would help a lot. -- Brangifer (talk) 01:14, 29 January 2011 (UTC)
• Support. I already have the clickable remove button on my watchlist via this handy lil script, but i'd love to also have the option of having my watched pages expire on their own. So how can we push for this to be implemented? A feature request at bugzilla? -- œ^™ 12:48, 29 January 2011 (UTC)

I was reading a nearby thread where someone stated that there are about 31 million rows in the watchlist table. A few design suggestions for this proposal:

1. Add a new column to the watchlist table (of type Byte, called ExpiryPeriod) with a default of 0, and populated with 0s for all existing records. (A default of zero means that there would be no change to the current watchlist mechanism, and the proposal would be opt-in.)
2. At a designated time each day, delete all records that have a 1 in the ExpiryPeriod field, and subtract 1 from all rows that have an ExpiryPeriod > 1. Zero would mean that items never expire, and the longest expiry time would be 255 days. Using two-byte storage would of course allow much longer ExpiryPeriod values (but I can't see that being significantly more useful).
3. (Technical DB issue...) Not sure if a transaction should be used for the above two operations? Probably would be best to index the ExpiryPeriod field though.
4. Change the Watchlist Preferences tab to provide a UI that either indicates no expiry (the default) or a number of days to use as a default. (This could be done with a drop-down list described below.)
5. When an editor makes a change to a page, if the page is on the watchlist with an ExpiryPeriod of >0, then reset the ExpiryPeriod field for the page to be the value indicated by the Watchlist preference.
6. Change the Special:Watchlist/edit page to allow the display of the current ExpiryPeriod value, and the entry of a value for each entry on the watchlist. If the maximum number were to be 255, the UI mechanism could be a drop-down list with the number 1 to 255, and the first entry (with key value 0) being "0 (no expiry)". The drop-down list could either be next to each item on the page, or there could be only one drop-down list at the bottom of the page that works with an "Update expiry days" button on any watchlist items that the user has checked (similar to the current "Remove titles" mechanism).
7. (To slow the growth of the watchlist table...) Automatically set the ExpiryPeriod value to be 255 for all watchlist items (where ExpiryPeriod is equal to 0) for any editor who hasn't logged-in to WP in (say) more than a year. This would mean that defunct editors' watchlist items would eventually be removed from the table (currently after 365 + 255 = 620 days). A note could be displayed to an editor who has had this event triggered and who subsequently logs in (to indicate that they should check the expiry settings of their watchlist items).
8. The above could be simplified by changing the implication of Days to be either Weeks or Months (and artifically lowering the maximum of 255 accordingly). Weeks or Months would also mean less database processing.

(If it were in C# asp.net and SQL Server, I could do the above in a few hours, but...?)  GFHandel.   23:27, 29 January 2011 (UTC)

• A watch-list table with 31 million items tells me that there are abandoned, orphaned, obsolete items no human is paying any attention to. What GFHandel is proposing is to address something that has obviously gotten out of hand. Greg L (talk) 23:56, 29 January 2011 (UTC)

• Doing something about the abandoned watchlist items would be a possible side-effect of the proposal. The main point of the proposal would be to help the active editors (by auto-removing watchlist items after a predetermined interval).  GFHandel.   00:05, 30 January 2011 (UTC)
• I don't think I formally supported this idea above. I do support it. Tony (talk) 02:48, 30 January 2011 (UTC)

Yeah, that would be great. --A. di M. (talk) 00:34, 7 February 2011 (UTC)

"Mark all edits as minor by default" should be disabled

Resolved

 – Yes it should, as previously agreed. Vote for bugzilla:24313 to possibly hasten the day it happens. Rd232 ^talk 04:31, 9 February 2011 (UTC)

The option in "My preferences" to "Mark all edits as minor by default" should be removed. I think this is being used more for abuse than what possible benefits there are. For instance, a vandalism-only account can set the option and then go on a vandalism-spree of minor edits; those who choose to ignore minor edits on watchlists won't notice it. IIRC, this is a good explanation as to why IP addresses cannot make minor edits. –MuZemike 20:45, 30 January 2011 (UTC)

Consensus to remove this option has existed for some time. The bugzilla seems to be stuck. –xeno^talk 20:48, 30 January 2011 (UTC)

Perhaps it would be a good idea to do something like what we do for rollback or auto-patrolled, where we only allow this option to trusted users who have demonstrated a pressing need for it (such as editors who almost exclusively focus on spell-checking, Wikilinking, punctuation, etc.). -- Mesoderm (talk) 20:54, 30 January 2011 (UTC)

There is a script trusted users can use if they still need to use this function. –xeno^talk 21:04, 30 January 2011 (UTC)

Then in that case, I see no reason for the feature to exist at all. Mesoderm (talk) 21:44, 30 January 2011 (UTC)

To expand on xeno's comment, see also Help talk:Minor edit#Should we remove the Preference setting to "Mark all edits minor by default" ? and bugzilla:24313. The process was initially bogged down when a developer removed the feature across the board and was reverted, and since then we have a complete lack of useful response by the people in charge (e.g. claiming they want all users using the preference notified, but then ignoring the request to provide the list of such users so we can do so). Anomie⚔ 21:52, 30 January 2011 (UTC)

• I support the removal. If this is going to be removed, it has to be done on all wikis (to maintain some "standard"). Rehman 01:14, 31 January 2011 (UTC)

• Support removal. I run into misuse quite often. One doesn't have to ever mark an edit as a "minor" edit, even when it is, and the opposite only causes problems and misunderstandings, such as the abuse mentioned above. -- Brangifer (talk) 05:18, 31 January 2011 (UTC)

• Support removal It's fine if someone does not mark a minor edit as minor, but it's not too good the other way around (marking a nonminor edit as minor). ManishEarth^{Talk • Stalk} 11:31, 31 January 2011 (UTC)

• Yepp, do that. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 11:34, 31 January 2011 (UTC)

• Support per all above Kayau Voting IS evil 11:53, 31 January 2011 (UTC)

We already have consensus to do this. There's no need to vote again. Mr.Z-man 02:41, 1 February 2011 (UTC)

• Support removal per above. Armbrust ^Talk _Contribs 16:38, 5 February 2011 (UTC)
• Support removal Allow for trusted users, should be easy to grant, easy to remove.--SPhilbrickT 02:17, 9 February 2011 (UTC)
  • I think that's an unnecessary complication. It has no real use model, so just take it out of the interface, and it's one less thing people have to learn. --Trovatore (talk) 02:25, 9 February 2011 (UTC)

Another Proposal

Sorry, I know I've already posted a proposal very recently. This proposal also relates to Book Creator.

Proposal:

Change Book Creator so that it can convert Wikipedia articles into .doc and/or .docx (Microsoft Office documents).

I guess I am posting this and now realize this may not be possible. I'll keep the proposal up just in case it is possible and will gain momentum...but while I'm at it, does anybody know Wikipedia policy on converting to a "non-free" file format such as a Word document? Oh, I'll throw one more in just for good measure in case it hasn't been mentioned:

How about e-books too? 24.10.181.254 (talk) 03:05, 2 February 2011 (UTC)

.doc and .docx are closed formats so they won't ever be supported. You can however, download things as .odt, although the PDF are much nicer. e-books are being investigated. Headbomb {talk / contribs / physics / books} 06:21, 2 February 2011 (UTC)

You can also download OpenOffice.org from http://www.openoffice.org/, and use it to convert the output file into .doc format. עוד מישהו Od Mishehu 09:03, 3 February 2011 (UTC)

Thanks for the info, Headbomb. I agree that PDF's look better. Od Mishehu--thanks as well. I appreciate the willingness you guys had to respond. 24.10.181.254 (talk) 03:38, 4 February 2011 (UTC)

E books is one of the BEST ideas I have EVER seen here. Being investigated? By who? Staff or volunteers? Is there a forum or page about it?Shabidoo | Talk 22:51, 8 February 2011 (UTC)

Propose WMF get involved with dead link issue

Anybody tired of dead links in citation templates? Several of us have been looking in to the problem of WP:LINKROT and have come to the conclusion there are no easy/free solutions. We think it's time for the Wikimedia Foundation to step in and help in some capacity. We would like to get input from the greater Wikipedian community on this issue. Those that are interested are encouraged to voice their opinions here. Thanks. - Hydroxonium (H₃O⁺) 20:42, 5 February 2011 (UTC)

Someone I think was liaising wit the Web Cite people. If you can find out who it might help. Rich Farmbrough, 22:39, 8 February 2011 (UTC).

OTRS flag

Just like Commons, I think we should have an OTRS flag. That way, we could easily identify and contact members of the OTRS team, via lists like Special:ListUsers. Comments? Rehman 05:29, 7 February 2011 (UTC)

And why on Earth would we need to identify OTRS members? They are people who respond to emails - if you need help from them, you email, not leave a message on their talk page. On commons there is actually a use for it, since OTRS-ticketed files are often dealt with publicly. Here, however, the only reason I can think of for having this is for vanity purposes (Look at me, I'm in another user group!) Ajraddatz (Talk) 23:57, 8 February 2011 (UTC)

Maybe you're right. I'm confusing Wikipedia with Commons as another file repository site. Also, Wikipedia deals with much less files than Commons, it doesn't seem that useful here. Thanks for the response. Rehman 01:50, 9 February 2011 (UTC)

More detailed "You have new messages..." banner for IPs/newbies?

The meaning of the basic "You have new messages (last change)" banner might not be clear to casual IP editors who might think it's about their own email or something non-WP related or something unimportant. IP editors should especially be encouraged to read the messages as these could be warnings which if ignored could lead to a blocking, or perhaps a welcome message which might encourage them to register or read up on policies. Could a more detailed banner text be displayed to IP (and perhaps new/non-confirmed) users? Maybe something like "You have new messages from Wikipedia - please take a few moments to read these as soon as possible. (last change)" Once registered, editors would see the current concise orange banner wording instead. Dl2000 (talk) 02:17, 24 January 2011 (UTC)

I'm not convinced that it's unclear; surely most people know what their own email looks like. My reaction to my first message was more "ooh, a message" rather than "I'll just ignore that". Although I guess it might be more confusing for people who haven't registered. Is there any reason to think its a problem at the moment?--Physics is all gnomes (talk) 12:48, 26 January 2011 (UTC)

The key point here is that unregistereds may not always be expecting that WP has a talk page system. There are often problem edit/revert cases where warning messages have gone unheeded, perhaps because these are unread. Or perhaps some IPs miss out on the welcome messages which might encourage registrations. Some admin tools would need to be run to determine how frequently messages are read by unreg/IP editors. If the stats show a low pickup rate, that suggests using a more obvious and explanatory banner for them. It's not the biggest problem in WP - at least in vandalism cases a block gets the message across the hard way. Dl2000 (talk) 04:19, 31 January 2011 (UTC)

Actually, now you've explained it more it seems like a good point, if the stats show there is a problem. Some users end up banned quite shortly after their warning, so helping make sure they read the warning is a good plan! --Physics is all gnomes (talk) 16:10, 5 February 2011 (UTC)

So it seems reasonable that before we alter the messaging behaviour, the first thing is to get some message pickup stats collected. Not sure where to move this forward, though, as it likely would involve some Wikimedia tech folks to indicate how feasible that is. Dl2000 (talk) 04:17, 11 February 2011 (UTC)

Gallery

So, there are a decent number of articles with gallery sections in them such as Basilica of Our Lady of Licheń and St. Laurence and All Saints Church, Eastwood. Some galleries can be quite extensive, ~20 photos, but to really appreciate them one really must click on them, but than to get to the next one must go back a page than go forward again. This can get annoying so I was wondering if if was possible to create a template that when mulitple photos are put into the template that there would be a 'next/previous image' buttons so that a viewer could go through the images much more efficiently. These buttons exist pretty much everywhere online but not on wikipedia, why not if they are all in the same gallery? Passionless -Talk 00:20, 2 February 2011 (UTC) Addition- I also propose that the description is included when a person clicks on a photo to enlarge it. This, while valuable by itself, would be very much needed if the next/previous image button is created. Passionless -Talk 22:53, 3 February 2011 (UTC)

• I have also brought up this idea at Wikimedia Commons here. Passionless -Talk 21:09, 9 February 2011 (UTC)

That idea has good potential. My curiosity leads me to wonder if the reason that it hasn't been implemented is because...maybe it's too hard for new editors to format? But if that is the reason, I think it's a poor 'justification'; I'm sure there are plenty of editors that would be able to figure it out. Seems to me like the beginners edit what they can and the advanced users take care of more difficult, but manageable tasks. I like your proposal a lot. I too get a little tired of the process of going back and then clicking the next image. For one or two images it isn't 'killer', but for a huge gallery, efficiency would be very nice. 24.10.181.254 (talk) 03:10, 2 February 2011 (UTC)

I understand the idea but if an article has enough images in a gallery to cause issues they should really be deleted and moved to commons. If an image is that important to understanding the subject it should really be placed near the related text and not in a gallery. MilborneOne (talk) 21:28, 3 February 2011 (UTC)

Please see WP:Galleries-specifically "gallery section may be appropriate in some Wikipedia articles if a collection of images can illustrate aspects of a subject that cannot be easily or adequately described by text or individual images."

I have only found the wikimedia commons for the first time today, after years of reading wikipedia. I see that the problem is much greater there. I suppose there is a seperate bureacracy for the commons than here that I would have to wade through to get change brought there. The problem is not only limited to galleries, the images in articles such as Fallingwater or Lion are all so closely related a next/previous button would help readers immensely. Passionless -Talk 22:53, 3 February 2011 (UTC)

I agree with Passionless. Even after using Wikipedia for years, it took a while before I even noticed Wikimedia Commons. I personally think that the Wikipedia Guideline on Galleries needs to be discussed. "Indiscriminate" collections of images, yes, certainly is a problem. But I think that the guideline has been formulated too far to the other extreme. I'm just as much opposed to indiscriminate collections of images as the next Wikipedia editor; however, why must all (or most) galleries be discouraged?--Why not omit the 'indiscriminate' pictures in a gallery? I am more likely to look at images that I actually see thumbnails of; much less so to click on a "Commons" image or media link. I highly doubt that Passionless and I are the only frustrated users when it comes to clicking through the images. But yeah, like Passionless has mentioned, maybe it's through the Commons discussion that we try and get our voices heard. 24.10.181.254 (talk) 03:57, 4 February 2011 (UTC)

This also raises the question why click-through rates from WP articles to Commons are so low. If you check stats.grok.se, it looks like typically only 1 or 2% of those whose read a WP article also visit the related Commons category or page. Therefore, if a gallery is removed from an article, more than 95% of readers will no longer see its content, even if it's still available from Commons. I can only think of two explanations here: Either they don't notice the link at the bottom at all because it's typically in the right margin and therefore easily overlooked. Or they disregard it because they are under the not unreasonable impression that all important and high-quality images for that subject are part of the Wikipedia article already, so Commons wouldn't have to offer anything significant beyond that. Whatever the reason may be, galleries in WP articles remain an important feature as long as this situation persists, so making them more convenient to use is an excellent idea IMO. --Morn (talk) 11:50, 9 February 2011 (UTC)

I agree this would be a good feature. There may be a way of implementing it using the "show/hide" functionality (or the same technique) of navboxes, otherwise I think it would need an extension, either a custom one or page variables, or javascript as they have at Wikia. Rich Farmbrough, 00:32, 9 February 2011 (UTC).

The feature sounds a good one especially for Commons and could also be implemented automatically for categories. However I would oppose the galleries in Wikipedia being just galleries with loads of pictures stuck in, I think the current guidelines are good. A way I think of getting more people to Commons would be to put the box linking there in the gallery section if there is one instead of in the see also section. Dmcq (talk) 12:08, 9 February 2011 (UTC)

Right now the link box is under external links, not "see also". But perhaps that's the problem--Commons is not actually an external web site but part of the same project. That might be confusing for readers. I have also already experimented a bit with putting an extra link to Commons below galleries, like here, but I don't know if that makes a difference. --Morn (talk) 14:09, 9 February 2011 (UTC)

You are absolutely right Dmcq that offering tools can result in people getting carried away. But that is what good governance is about, or ought to be. Preventing the problematic uses of facilities rather than denying facilities themselves. This is how WP came about, after all, allowing anyone to edit, then stopping the malicious, misguided or incompetent. Rich Farmbrough, 14:14, 10 February 2011 (UTC).

There is a slide-show gadget on Commons. That does show promise - firstly for registered users, but secondly that a suitable default interface could be provided. Rich Farmbrough, 14:14, 10 February 2011 (UTC).

Ya, I saw the slideshow yesterday, though only editors and not readers can use it, and although it does make the photos larger, it still does limit the size of many photos to be smaller than if they were to be clicked on once, and I don't think you can re-click a photo to make it its true full size in the slideshow. Though in general, it is going in the right direction. Passionless -Talk 21:50, 10 February 2011 (UTC)

HTTPS

Proposals

1. I suggest that all logins are made through a secure page by default like Gmail and Yahoo
2. I suggest that login page does NOT use mixed contents
3. I suggest that secure pages are easier to reach. Simply adding s to http should make the page secure. Currently the secure page is REALLY long https://secure.wikimedia.org/. Let's simplify it to https://www.wikimedia.org and https://en.wikipedia.org

--Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 05:53, 9 February 2011 (UTC)

Why? Dmcq (talk) 11:57, 9 February 2011 (UTC)

For more security and prevent session jacking. --Tyw7  (☎ Contact me! • Contributions)   Changing the world one edit at a time! 20:31, 9 February 2011 (UTC)

See Bug 225. This feature request is older than tumbleweeds. Titoxd^{(?!? - cool stuff)} 22:48, 9 February 2011 (UTC)

WP:TALK Title change

For discussion, please see Wikipedia talk:Talk page guidelines#Title change. Jujutacular ^talk 08:06, 10 February 2011 (UTC)

MOS:FLAG description of appropriate use needs expansion

I recently re-added a flag icon to a country topics template. The revision history is here: [1]. My edit was then reverted, citing the WP:ICONDECORATION guideline and the WP:Other stuff exists essay. Then, in reading MOS:FLAG, the guideline gives descriptions of "inappropriate" uses, but is not clear in mentioning what would be an "appropriate" use. Shouldn't both "sides" be presented and described in the policy, in order to avoid mis-interpretations? I would think that using a flag icon in a country's topic template would be an appropriate use, and am eager to hear if other editors would agree. I would also like to know how that MOS section could be updated, per consensus. Thanks, --Funandtrvl (talk) 06:15, 11 February 2011 (UTC)

It is tricky, there does seem to be a lot of "colourful bunting" around. Sometimes the flags are useful, often they are not - in which case they are an accessibility issue, as well as cruft, albeit pretty cruft. I raised the question about balance (and also the negative tone) on the talk page of Icondec some considerable time back, and thought I had made the page more positive. Which is what should be aiming at with all our guidance. Lists of prohibitions are beloved by bureaucrats however, and are much easier than saying what is good in many cases. Rich Farmbrough, 06:33, 11 February 2011 (UTC).

Yes, that is a good point. In looking at the edit history of that MOS page, it does seem to be recently edited by just a few people, which is not using a consensus-based model to set up a guideline-- to say the least. Could you explain how the flag icon causes an accessibilty problem? Is there an accessibilty problem with all templates, or just the flag/country icons? Thanks, --Funandtrvl (talk) 06:54, 11 February 2011 (UTC)

Tastes differ. There are some people that'd rather have no picture at all on wikipedia. There is also the potential political problems introduced by flags, such as the flag of northern ireland (template:Northern Ireland topics). Pictures in such template title bars should be highly relevant, indicative, and non-intrusive. I find this is the case for template:countryX topics, like for example template:Denmark topics, template:Japan topics, template:Peru topics. Cheers. ^walk victor falk ^talk 07:16, 11 February 2011 (UTC)

What is the relevance for the flags in the templates you listed, should we add a flag every time a country in mentioned Gnevin (talk) 12:33, 11 February 2011 (UTC)

I think flag icons are overused, and would favor a clearer and more restrictive policy on their use. I work on a number of articles with a historical context, and see a fair amount of the wrong flag icons being used in an article. Of course, the historically correct flags are not recognizable to most readers. In fact, many contemporary flags, especially at icon size, are not recognizable to most readers. That's why the guidelines also call for the name of the country or sub-national entity to be displayed with the flag icon. The flag icons are not really adding anything to the information being delivered by an article (with the exception of articles about the flags, where larger images should be used), and in many cases may convey misleading or incorrect information, or exacerbate controversies. -- Donald Albury 12:58, 11 February 2011 (UTC)

I too think flag icons are overused. My particular problem is that the use of such flag icons on Wikipedia articles can often introduce a subtle but important non-nuetral point-of-view. A bunch of flag icons in an article tends to imply a nationalistic point of view and gives the state a prominence that may be unwarranted by the particulars of the article. Examples may be found in many business-related articles that have businesses from around the globe involved; the businesses are presumably private associations of private individuals doing business. Yes, they are each domiciled in some nation or the other in terms of their business addresses, but bringing in national flags seems to me to introduce a WP:POV, and one that is generally not supported by the specifics of the article. Cheers. N2e (talk) 15:20, 11 February 2011 (UTC)

Well, it boils down to a matter of taste, really. Like mentioned above, some people like flags, and some don't. Somehow, I don't think we're going to arrive at a consensus here. I do agree, however, with N2e that flags on a business-related article is probably not a good idea, but I also agree with victorfalk that flag icons on the "countryX topics" templates are an appropriate use. I really find the flag icons helpful, based on the fact that I've learned about a number of country flags and can now identify more of them than before, due to the icons being present on the templates. I still would like to see the MOS:FLAG article updated to list not only the "inappropriate" uses of the flag icons, but also the "appropriate uses" too. It's only fair to describe both sides of the issue and let the editor make his/her decision, and not to just present the "negatives" of the issue in a biased manner. --Funandtrvl (talk) 18:32, 11 February 2011 (UTC)

MOSICON lists the appropriate uses Wikipedia:Manual_of_Style_(icons)#Appropriate_use. How do you find the flag helpful other than you've learnt by osmosis so extra flags which if you could of learnt a lot easier and better by visiting List_of_national_flags and where the icons aren't tiny Gnevin (talk) 18:57, 11 February 2011 (UTC)

(edit conflict) No, it doesn't. As stated in my comments above, I was referring to the lack of an "appropriate uses" section under the "Flags" section (where MOS:FLAG points to), not just the "General" section (where WP:ICONDECORATION points to.) In regards to your question, I do find the List of national flags article helpful, of course. However, that is just one article out of 3 million, and most of the country articles and templates do not even link to that page. Having the flag icon on the different country templates adds exposure, obviously, to what the national flag is, of those respective countries. --Funandtrvl (talk) 19:13, 11 February 2011 (UTC)

I've always thought that the most useful application of flag icons is to aid navigation of (relatively) long lists or tables, where each item has a strong (or "strong enough") national association, and ideally has more than one entry per nation. With this possibly narrow definition, I present some "good" examples:

• List of Olympic medalists in alpine skiing – clearly Olympic sports have a strong national association, and these icons make it easier to browse the list to find all skiiers from a certain nation
• 2010 FIFA World Cup – the flag icons, especially since they are aligned vertically, help the reader scan the list for match results of a single team, as it progressed through the tournament
• Napoleonic Wars – the infobox has long lists of combatants and commanders. Even though most every flag is historical and unknown to the average reader, they serve a purpose here by associating commanders with nations, without making the infobox unwieldy by imposing a different layout
• Moscow#International relations – the long list of twin cities is slightly improved by the flag icons, as it makes it easier to scan the list looking for cities in specific countries

and some "bad" examples:

• PepsiCo – there is absolutely no value in having a singular flag icon in the infobox. It draws undue weight to the "Headquarters" field, and adds nothing to the linked text of "United States"
• Template:U.S. presidential elections – almost every article on which this navbox is found has a title that starts with "United States" in large bold text. What added value is a little, singular icon at the bottom of those articles?
• USL Premier Development League#2011 Teams – subnational flags are even more obscure, and these teams don't "represent" their state or province

I do agree that WP:MOSFLAG is poorly written and due for a makeover, and I'd like to see it somehow capture these thoughts, without suffering from bureaucratic bloat. There must be an elegant way of stating where flag icons are useful, and where they are not. — Andrwsc (talk · contribs) 19:07, 11 February 2011 (UTC)

RfC to use archived citations at Wikiwix

Dead links in citations (i.e. WP:LINKROT) are a significant problem on Wikipedia. A task force found that the French Wikipedia dealt with this situation by using cached webpages at Wikiwix.com. Based on the conversation here, I have started an RfC to do the same thing. This requires modifying MediaWiki:Common.js, which is the javascript common to everybody that visits the English Wikipedia using a web broswer with javascript enabled. This modification will change how everybody sees Wikipedia, so I am encouraging everybody to comment on the RfC. Thanks. - Hydroxonium (H₃O⁺) 15:43, 11 February 2011 (UTC)

Virginia Elisabeth Farmer

Forgive me, please, for suggesting this but I did not grow up with computers and I can't figure out how to do this. I was hoping that someone could create an article about Virginia Elisabeth Farmer, an author. She wrote "Lizzie's Blue Ridge Memories," for children and is also known as an extra in at least two movies. (I read about this on her facebook fan page.) Her fanpage says she is working on more projects and she has about 90 fans. Her book for children is sweet, but at the same time, thought provoking, dealing with death and other social situations.

Facts: Resident of Grandhaven, Michigan Of mixed blood Cherokee heritage Brigham Young University alumnus

Articles and reviews can be found on Amazon and other pages. More articles and reviews can be found on her facebook fanpage. I wanted to find out more and did a search on here. That's when I found out there were no articles about this author or her book. Please, don't suggest that I do this because as I said, I didn't grow up with computers and if anyone out there is a computer snob, that really won't help. Second, I am sick and weak and can't do it as I tire easily. I hope I will get better. Thank you for your time.— Preceding unsigned comment added by JunkMailFyle (talk • contribs) 17:00, 11 February 2011

She doesn't seem to have significant coverage about her in reliable sources such as books, magazines, or newspapers. We don't use Facebook as a source. We need significant coverage about someone to write a biography. Fences&Windows 04:17, 12 February 2011 (UTC)

Accessibility for unregistered users

Having the references in smaller type is an accessibility issue for unregistered users. We should remove the css element that does this. Rich Farmbrough, 22:25, 8 February 2011 (UTC).

Could you elaborate a bit more? I know that references are smaller, but why does this only affect anonymous users? Yoenit (talk) 22:34, 8 February 2011 (UTC)

It doesn't. Simply every time I bring this up as a genreal issue people kindly tell me how to hack my css, or that a gadget is available. I don't have much of a problem, personally, but enough to know that it is a problem. Rich Farmbrough, 00:11, 9 February 2011 (UTC).

Are you proposing that we should 'forbid' anything under our default font size because some people don't know where the "Larger" option is in their webbrowser ? —TheDJ (talk • contribs) 22:45, 8 February 2011 (UTC)

No, I'm saying we should not have small fonts for references for several reasons. We already have guidance elsewhere on the general deprecation of non-standard font sizes. Using the embiggen control results in the normal text of the article being too large, those who can control, or have others control for them, the size of text will already have optimized the size. There are no compelling reasons to have small text. We do not need to look like paper. We are not paper. Rich Farmbrough, 00:11, 9 February 2011 (UTC).

Just to comment, a lot of people with visual impairments are already using OS settings, browser settings, and other software to enlarge text on their screen. Browsers let you set a minimum font size, or override all font and color styles on web pages, and this does not require editing CSS files. You can also disable CSS altogether for a particular site (in Firefox under the View menu), and the result is often quite nice. – Acdx (talk) 06:53, 9 February 2011 (UTC)

It's only 10% smaller, so this is hardly an accessibility issue (if X*0.9 is too small, then X probably is too, so it's the reader's responsibility to zoom as needed). It's just a design issue: and most people prefer it because it makes it easier to skim the page, because the refs look slightly different. Rd232 ^talk 00:29, 9 February 2011 (UTC)

I have seen a number of complaints about the legibility. "Just a design issue".... Rich Farmbrough, 00:38, 9 February 2011 (UTC).

If the reference list size needs to go, the so does every other instance of small fonts— infoboxes, navboxes, etc. ---— Gadget850 (Ed) ^talk 04:27, 9 February 2011 (UTC)

While I have no issue with other instances going too, it doesn't necessarily follow. Navboxes and inofboxes are a different style, less dense than normal text, while references may be more dense. And while they have internal footnotes as small as 6pt (I would judge) that could also be resolved in a number of ways (there does seem little point using a smaller font for collapsed navboxes since they take no space until they are uncollapsed). We should really consult usability/accessibility experts on this stuff. Rich Farmbrough, 11:43, 9 February 2011 (UTC).

Wellll... some websites have CSS font size change buttons baked in, don't they? Could we do that? Rd232 ^talk 04:28, 9 February 2011 (UTC)

I don't know, its certainly an idea. Whether it's worth increasing the complexity of the interface to maintain an existing piece of complexity or not might be determined by some study. Rich Farmbrough, 11:43, 9 February 2011 (UTC).

Well the buttons would apply to the entire page; I just don't see the 10% difference as an issue. My suggestion is merely aimed at making it easier for a reader to adjust Wikipedia's font size generally, even though many readers will already be well aware of how to do it via the browser. Rd232 ^talk 13:59, 9 February 2011 (UTC)

Personally, I like to have the footnotes smaller, but I can see how this may be an issue for some users. Same thing with size for images.

Couldn't there be a way for unregistered users to set some preferences and save them via cookies? I mean, I have some preferences set for Google (which national site for the main Google page, which country for Google News, and so on), and these are in force via cookies whether I am logged in or not. Couldn't Wikipedia do the same? (Anyone refusing to accept cookies is probably tech-savvy enough to fix this in some other way.) --Hegvald (talk) 18:27, 9 February 2011 (UTC)

Would someone please explain the problem with font size? Wikipedia:Manual of Style (accessibility) is mute on font size as an issue and even mentions the use of <small>. I have skimmed through the Section 508 and Web Content Accessibility Guidelines and don't see this. I have used some online accessibility tools and don't see a font problem.

Now, if we do have accessibility issues, wouldn't a better solution be to create variant skins with accessibility to address any and all issues? (It does appear that our use of stylesheets is a 508 issue.) ---— Gadget850 (Ed) ^talk 18:05, 12 February 2011 (UTC)

The issue is simply that the end user can be assumed to have set their browser to a default font size that's comfortable and legible for them. Increasing the font size over the default by too much is annoying to read, but unless it's set to be enormous (less than one word per page, say) there's no real usability issue. Decreasing the font size below the default by even a little bit can make it difficult to read, and the only stylistic defense of this that's ever been offered is "on my browser on my computer it looks fine for me". — Gavia immer (talk) 18:32, 12 February 2011 (UTC)

And that is why every page fails the 508 standard in our use of stylesheets, regardless of font size. ---— Gadget850 (Ed) ^talk 18:39, 12 February 2011 (UTC)

Keep deleted templates to support viewing old revisions

Suggestion: deleting templates ({{expand}} springs to mind) breaks old revisions. It should be possible for deleted templates to be wrapped in a {{deletedtemplate}} wrapper which detects whether the page URL contains "&oldid", which makes it likely that it's an old revision. What the wrapper would do is simply display the template as it was before deletion (if &oldid is found), and suppress the template output (or give an error message) if not (i.e. if the current revision contains the deleted template). Does this make sense? Is it worth doing? Rd232 ^talk 00:25, 9 February 2011 (UTC)

I don't believe templates can detect that they are on old versions of pages. A significant template like Expand could simply display as a null template - unbreaking the old revisions. The better solution is for the historical verisons of the pages to use historical versions of templates (proper history like ZUG), something I have advocated for some time. Rich Farmbrough, 00:37, 9 February 2011 (UTC).

historical versions of templates would be lovely, but infinitely more complicated and vaguely never-gonna-happen territory. What's wrong with my detection of &oldid in URL proposal? (The only kink is permalinks to the current version, but they shouldn't contain deleted templates anyway.) Rd232 ^talk 03:35, 9 February 2011 (UTC)

I seem to remember coming across this. If you go to the history of a page and click on a past version, you won't get the version of a template that was actually on the page at that time, you'll get the present version, or an error message if it's been deleted. Peter jackson (talk) 10:20, 9 February 2011 (UTC)

(True history is not that hard.) Well the current (permalink) version we can use in theory "revision = -" ({{REVISIONID}}) - but I'm not sure any of the magic words give is the actual URL being accessed in the first place which is the pre-requisite for your idea. If you can (something like {{fullurl:{{PAGENAME}}}} =//en.wikipedia.org/wiki/Village_pump_(proposals)/Archive_69, of course, doesn't work) then the implementation should be easy enough, given that our damaged string functions can cope, which they quite often can't. Rich Farmbrough, 11:25, 9 February 2011 (UTC).

Hm, looking around at the string functions available, I'm sure it's doable, but I'm not sure how the various limitations will interact in terms of working for all page titles. Perhaps someone else would like to play around and see how it goes... Is there a bugzilla entry for a proper history thing? Rd232 ^talk 14:11, 9 February 2011 (UTC)

Of course, a simpler, temporary alternative would be for the {{deletedtemplate}} wrapper to always display a small "deleted template, should only be visible on old revisions" warning over the final version of the template before deletion. Rd232 ^talk 17:26, 9 February 2011 (UTC)

Or, more crudely, simply "This template has been deleted". Rich Farmbrough, 14:43, 10 February 2011 (UTC).

I don't know, I am not terribly enamoured with the rate that Bugzillas get zapped, so I haven't looked (that I remember), I should.

But your basic idea might well be solvable, since you can compare the revision ID of a history page with the current one. Let me experiment with Expand and we can find out. Rich Farmbrough, 14:43, 10 February 2011 (UTC).

'Tis done. [2] displays an "Expand" template, but if I use it here I get:

The template {{Expand}} has been soft deleted.

Et voila! Soft deletion! Rich Farmbrough, 14:58, 10 February 2011 (UTC).

Now someone has to continually monitor Special:What Links Here on all the 'soft deleted' templates to see whether some n00b has created error messages on current revisions by placing a softly deleted template on it (bearing in mind that one of the keep arguments for {expand} was, it's so simple even idiots can remember it/use it - the exact kind of idiot who isn't likely to know what 'soft deletion' even is, or how to fix the resultant error message), just so we can view old revisions in perfect condition. MickMacNee (talk) 16:04, 10 February 2011 (UTC)

Infact, even non-n00bs are likely to not have a clue what it means if they see it mentioned. The analogy to soft-redirection is if anything, a complete red-herring. Given the fact that Wikipedia:Soft deletion is a failed proposal about something completely different, I suggest you avoid the whole phrase all together, and come up with a simple message which explains why someone might be seeing this message, and what to do about it. MickMacNee (talk) 16:14, 10 February 2011 (UTC)

I've done it myself infact [3] (I've hardcoded the message above too, to retain this discussion thread's logic.) MickMacNee (talk) 16:23, 10 February 2011 (UTC)

Well that seems pretty neat, if it really works consistently. The logic should be moved into {{deletedtemplate}} for general use, and some instructions written. Unless anybody thinks it a bad idea to implement this. PS One kink: the same "remove me" message is shown on old revisions which postdate the template's deprecation, even though you obviously can't remove the template from an old revision... I've tweaked the message accordingly to add an "if this page is a current revision". Rd232 ^talk 17:29, 10 February 2011 (UTC)

{{Deleted template}} created. Needs documentation. Also created tracking category. Rich Farmbrough, 06:28, 11 February 2011 (UTC).

Done. I wonder if it's possible to allow subst:ing in order to fix talk pages and archives using deleted templates in past discussions? Rd232 ^talk 14:49, 12 February 2011 (UTC)

Community input invited on a request for bot approval to automatically delink dates

A request for bot approval has been filed for a task that will, among other things, "delinks full dates (but not lone day-month strings or years), days, months, decades, centuries", "removes direct links to full dates, whether ISO8601, dd mmm yyyy or mmm dd, yyyy, including piped links of same to chronological articles in almost any imaginable form" (per WP:UNLINKDATES) and ensure articles uses a consistent date format throughout.

A member of the Bot Approvals Group has requested community input to determine if community consensus exists for an automated process of this nature.

Editors are invited to comment on the feasibility and desirability of the automated task here. –xeno^talk 16:22, 15 February 2011 (UTC)

Featured sounds main page proposal

Voting has begun at Talk:Main_Page#Featured_sounds_vote. Adam Cuerden ^(talk) 19:58, 15 February 2011 (UTC)

make wikilinks non-breaking

• Hey, is nowiki broken?? I had to delete the final semicolons

  I think it doesn't work inside headings? -- œ^™ 06:18, 12 February 2011 (UTC)

• Dunno how doable this is, but when wikilinks break across right margin of body text or (even worse) across the columns of a cite (imagine one breaking from the bottom of a long left column to the top of the right) it's odd to say the least. I suggest it would be beneficial to comprehensibility to replace all empty space in wikilinks with &nbsp; ...can this proposal be done?Locke'sGhost 05:41, 12 February 2011 (UTC)

You can replace the ampersand with the HTML entity &amp; ---— Gadget850 (Ed) ^talk 06:22, 12 February 2011 (UTC)

• Done, thanks. Now about the proposal...? Locke'sGhost 06:29, 12 February 2011 (UTC)

I think it would be better to use CSS. For example <span style="displaywhite-space: nowrap;">[[Wikipedia]], the [[Free content|free]] encyclopedia that anyone can [[Help:Editing|edit]].</span> should not wrap. – Allen4names 06:59, 12 February 2011 (UTC)

• Good suggestion. I leave it to techie folks to decide on implementation. Can and should we make wikilinks non-breaking? Locke'sGhost 07:11, 12 February 2011 (UTC)

I'm fairly sure that that implementation is wrong; you probably want <span style="white-space:nowrap;">Blah blah blah</span>. I don't think nowrapping links is a good idea, though; there are too many places where long links (eg section links) should wrap. Happy‑melon 19:55, 12 February 2011 (UTC)

Correction made per Happy-melon. Thank you for the correction. – Allen4names 23:16, 12 February 2011 (UTC)

Behold the magic of {{nobr}} Titoxd^{(?!? - cool stuff)} 06:53, 17 February 2011 (UTC)

• Why should section links wrap? Locke'sGhost 23:18, 12 February 2011 (UTC)

Forced Response tool for Admins

I often see that warnings and questions on talk page regarding disruptive users are often left unanswered or even acknowledged...especially by new or unregistered users. I sometimes wonder if they even know that a talk page exists, or that they should bother to look at it. Anyway, would it be possible to add an admin tool that blocks a user from editing until a response is made on their talk page? I would see it working, for example, in this way: A disruptive user gets a couple of warning on his/her talk page, but does not respond or change behavior ----> Admin uses the "response required" tool and requests communication with a message (or template) on the user's talk page ----> Next time the user tries to edit, he/she gets a notice that a response is required to an issue on their talk page before editing can resume ----> When a response is received, the admin can verify this and remove the editing restriction. I just think this might be a good way to "force" someone to put down the stick and communicate...even if the response is "go to hell", an admin can at least determine where the user is coming from. Thanks, David Able 18:58, 16 February 2011 (UTC)

Special:Block ? –xeno^talk 19:01, 16 February 2011 (UTC)

Just trying to think of ways to retain some users since the numbers have been in decline lately, and the subject of discussion. I guess it would be a last-resort attempt before block. Maybe some of these people just need a little guidance and don't know its available to them. David Able 19:03, 16 February 2011 (UTC)

I agree with xeno. If the user refuses to respond and is editing disruptively, a block is warranted. Once the user responds, the block can be lifted.

In the case of a user repeatedly recreating a page, I've also SALTed the page for a short time. That at least forces the user to choose a new page name, which reaffirms intent to disrupt (or ignorance of his talk page), or brings them into discussion on a talk page.

As for giving guidance and getting the user's attention, the latest revision to the underlying software isn't a help. The new message notice box is now a pale blue instead of the attention-grabbing orange. —C.Fred (talk) 19:06, 16 February 2011 (UTC)

@ Xeno, I am not an admin so I can't see the link you provided...but perhaps a tool like this already exists in some form. David Able 19:07, 16 February 2011 (UTC)

(It's a link to the blocking form) I think a bigger problem affecting retention is administrators blocking before the users have had a chance to respond/resumed editing. If they receive a talk page message and keep up their disruptive behaviour or otherwise do not attend to the message after the orange bar (pale blue?) should have drawn their attention to the message, an attention-getting block strikes me as an appropriate response, and serves the function you've suggested. –xeno^talk 19:08, 16 February 2011 (UTC)

I see a lot of the same problem with warnings, xeno. A user makes series of edits and gets warned. A subsequent warning comes in for an edit that preceded the one he got warned for. Suddenly, a user goes from an empty talk page to a level three warning, and they haven't made any intervening edits. I look at time stamps a lot, especially if a user is nearing a block. I won't block them over an edit that they made right after the level 4 warning, because they were probably in the process of hitting save page before or as the warning came in. —C.Fred (talk) 19:14, 16 February 2011 (UTC)

Blocks go in the block log, and require an admin to lift them. I can see the merit in this: the person would effectively be able to unblock themselves by responding on their user talk, and it wouldn't be logged. As a result, it would be a very minor measure which could be used much more liberally than blocking. Rd232 ^talk 19:09, 16 February 2011 (UTC)

Ok, fair enough. –xeno^talk 19:19, 16 February 2011 (UTC)

• Since we're talking about tools to get a user's attention, it'd be nice to be able to do a user-specific edit notice. So that, if there are warnings they haven't responded to, they get a "Warning! You have not responded to messages on your talk page about your conduct. If you do not respond, and if you continue to make the same inappropriate edits, you may be blocked. Please respond to the comments on your talk page" message inside a bright orange box at the top of the edit screen. —C.Fred (talk) 19:16, 16 February 2011 (UTC)

It should just be an attention getter...gentle prod...a temporary removal of editing privileges with a personable message of concern, and an easy link that directs them to a new section of their talk page to respond. And don't call it a block. Sometimes the language in the escalating warning templates can be downright intimidating. Something like "Hang on a second. I've noticed some problems with your editing that may be breaking the rules of Wikipedia. Why don't you click here, and tell me what you're wanting to do? Once you respond, I'll restore your editing privileges, no harm done." Again, I'm not trying to take the teeth out of a block. This would be a pre-block step to be used when circumstances warrant maybe less of a "bite." Definitely not to be used in all cases. David Able 19:46, 16 February 2011 (UTC)

That's in the same direction, but I think forcing a response is more commonly going to be helpful. They've probably already ignored requests to discuss things. Rd232 ^talk 01:41, 17 February 2011 (UTC)

Alternative. Change the message bar to red and have it double in size for each talk page message not responded to until it fills his full screen.. Seriously though, I can see how it might be easier for some people to edit articles then talk pages. Some newbies might not even realize that the warnings on their talk pages are something they can respond to. I use to participate in usenet and web forums before Wikipedia and it took me a while to get the hang of talk pages and noticeboards. I wonder if liquid threads might help in this regard. It certainly would make it more obvious that the messages on their talk pages are messages that they can respond to. As far as editors who do know what talk pages are and how to use them, if they still let the warnings pile up (or delete them), show them the door. --Ron Ritzman (talk) 05:24, 17 February 2011 (UTC)

Well that consideration just makes the concept more attractive, because the notification template could include crystal clear "click here" type instructions. Rd232 ^talk 06:38, 17 February 2011 (UTC)

Perhaps we could add a monobook.css/vector.css to the user to make an input-box appear on any page they use on Wikipedia that would also pose the critical message we want them to read and respond to. They would get this even if not editting. The hard part will be to make it save the answer they may give. As alternative we could even just simply change that light blue background to a blinking orange with the personalised style sheet upgrade!. Graeme Bartlett (talk) 07:53, 17 February 2011 (UTC)

How would you apply it for the target user alone? The saving bit could probably be done the way MediaWiki:Protectedpagetext does the "submit an edit request" thing. How would JS/CSS know to clear the response request though? Rd232 ^talk 09:07, 17 February 2011 (UTC)

Make it at User:offender/monobook.css or user:22.33.44.55/monobook.css which should only strike the affected user, perhaps there can be some if exists test that will suppress the alert once the response is saved in a talk sub page. Graeme Bartlett (talk) 10:00, 17 February 2011 (UTC)

An excellent idea - I could have used it today. Sometimes you need to block to stop a chain of disruption and discuss the issue with the user, but a traditional block can just make things worse. In this case I discussed the problem with the user, who settled down and was cooperative, and unblocked. It would have been less stinging if we could have a friendlier tool to say "time out while we talk this over," as opposed to a regular block that gets interpreted as "you're banned." In this case the user was in fact communicating, but not particularly constructively until they had to come to a full stop, but a required response might have done a gentler job of breaking the chain of escalation. Acroterion _(talk) 20:06, 17 February 2011 (UTC)

I can't see it working for IPs, with all the concerns if another person uses the IP.

Otherwise...the principle, to force a user to respond, might have merit. It's time-centric though; what exactly will happen if they don't respond for hours/days/weeks; and, who will respond to their answer - if the same admin requesting it was around, yes, great; but they might not be. Will their 'quick need for response' potentially languish for days?

I do think it worth discussion though. It could reduce the stigma currently attached to blocks for minor offences by new users.  Chzz  ►  20:26, 17 February 2011 (UTC)

From what I know of the MediaWiki software, it would be possible to design an interface similar to Special:Block that, similar to blocking a user, would prevent them from editing until they edited their talk page, and provide a notice to that effect when they try to edit pages. And yes, it might be worth it, especially in regards to new users as Chzz said. Ajraddatz (Talk) 22:08, 17 February 2011 (UTC)

Ultimately, this whole deal will mean that people will only have to pay attention to warnings issued by admins (or a special group of users), and other warnings can be safely ignored. Not a very convincing idea. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 23:19, 17 February 2011 (UTC)

• No, lets not do this. It will be abused or misused - at the very least admins will be accused of misuse and abuse. Far better to simply block users if they fail to respond and continue to engage in the unacceptable behaviour that is a concern. After all, if the concerning behaviour isn't worth a block its certainly not worth forcing someone to respond over. Spartaz ^Humbug! 04:55, 18 February 2011 (UTC)

Allow trusted users to create edit notices

Can we make it so that certain users can create and modify edit notices? They've recently been enabled on every page and namespace. I think there would be a lot of use for them on WikiProjects, where they can direct users to the correct venue, or on the talk pages of controversial articles to state that "Controversial edits to this topic can ignite heated debates, consider discussing your proposed change on the talk page before making an edit".

Either this or we need a new class of trusted users that have more permissions to do basic housekeeping tasks (page moves, editing protected templates, and other things that can be easily remedied if performed incorrectly). I don't want to be, nor do I believe I have the patience or temperament to be an administrator, but I'm requesting their assistance for simple edits several times per day. - ʄɭoʏɗiaɲ ^τ _¢ 17:20, 17 February 2011 (UTC)

Account creators and administrators can, and I think that it would be good to keep it that way. You are free to request a modification through any user with access to it. Ajraddatz (Talk) 19:39, 17 February 2011 (UTC)

A proliferation of excessive messages can really get annoying. A type of WP:CREEP. Also, edit notices are quick hack-ish.

Regarding the wider matter, there have been various calls for 'unbundling' of various user rights. I'm not necessarily saying it is a bad idea, but just that you should do a bit of a search through WT:RFA e.g. this, and search around a bit for prior discussions - clearly none of which succeeded, thus far.  Chzz  ►  20:33, 17 February 2011 (UTC)

P.S. Your comment of I don't want to be, nor do I believe I have the patience or temperament to be an administrator is understandable, and a good illustration of just what is wrong with the current adminship process. It should be no big deal, and if you, or anyone, has a valid need for those buttons, they should get 'em. If you don't like blocking or whatever else would try your patience, then don't do that stuff. Just 'coz you have buttons does not mean you have to press them.  Chzz  ►  20:37, 17 February 2011 (UTC)

Editnotices don't normally need to be changed often enough than an occasional {{editprotected}} is that big a deal, IMO. Looking through your contribs, Floydian, I don't see where you're asking for admin assistance several times per day. Anomie⚔ 21:50, 17 February 2011 (UTC)

I usually ping them through the IRC channel I frequent because its faster that way, and they're the admins that understand the kind of articles that I'm working on. Add to that various template modifications and the numerous moves I've requested. - ʄɭoʏɗiaɲ ^τ _¢ 22:05, 17 February 2011 (UTC)

Proposal of General Sanctions on Abortion articles

See WP:ANI#Alternative to Topic block of User:WikiManOne.... General Sanctions on Abortion articles. - Neutralhomer • Talk • 05:35, 18 February 2011 (UTC)

Olive Branch

I wonder if there is currently, or has been in the past, an organized effort to reach out to inactive users, inviting them to return to editing? Among these, retired users...or even users with a history of good editing that were at one time temp blocked for something minor (like edit warring), never to return. I'm thinking of something like a Wiki-pardon. Perhaps an incentive could be the blanking of a block log after a one month return to productive & unproblematic editing. I've seen a lot of good editors who leave WP basically due to a bruised ego, and maybe they just need an olive branch to return. David Able 18:41, 17 February 2011 (UTC)

Maybe we should instead fix the problems that caused them to leave, like the constant biting of newcomers? Ajraddatz (Talk) 05:34, 18 February 2011 (UTC)

I agree. Fixing the problem of biting newbies is much better. - Hydroxonium (H₃O⁺) 03:52, 19 February 2011 (UTC)

2010 census boilerplate

This should be the time to talk about the boilerplate info that will used to plug into geographical articles from the 2010 U.S. Census. Unfortunately, I find that the material from the 2000 census was really very weak in construction and was, I fear, not too helpful to the reader. I don't say this to denigrate anybody's hard work, but to ask for very good preparation for a similar project this year. If you look at Inglewood, California#Population, you will see three ways of treating the census figures: The top example are population figures that have been run through a human brain. The second example is a chart that compares nearby areas, with some explanation (all sourced). The third example is a modified use of the 2000 boilerplate. (It was modified because the boilerplate could simply not be used the way it was.) An unmodified version is, I believe, at Lennox, California#Demographics. I propose that, instead of a one-size-fits-all narrative (as was used for the 2000 figures), we use a chart of some sort that could be easily modified to fit each community. At any rate, we really don't want to end with a one-size-fits-all wording that really does not give the information the reader would be seeking. Sincerely, GeorgeLouis (talk) 00:16, 19 February 2011 (UTC)

Proposal to discourage "parent–child links" at WT:LINK

See Wikipedia talk:Manual of Style (linking)#Parent–child links.

- dating so this will be archived. Fences&Windows 22:47, 20 February 2011 (UTC)

Article Blame -- a simpler WikiBlame tool

There is a simpler version of the WikiBlame tool, linked as "Revision history search" from a history page; this is called Article Blame, from toolserver.org: http://toolserver.org/~soxred93/blame/ It should be considered whether the simpler tool should also be included in the External Tools section of a history page.

- dating so this will be archived. Fences&Windows 22:48, 20 February 2011 (UTC)

MS Word 2010 compatibility

I'll have to admit, I'm not overly familiar with this side of things, i.e. whether the initiative in such collaborations is taken by Wikimedia or by the other party, but if it is by Wikimedia (in the case of e.g. Wikipedia (en) searches straight from your Google toolbar, or whatever), then it might be an idea to integrate WP into what seems to be the new MS Word's replacement for the 'Synonyms' feature (roughly explained here). It Is Me Here ^{t / c} 23:51, 19 February 2011 (UTC)

Broadcast content transcription and verification program

A situation has come up in regards to a TV broadcast and WP:V. The discussion can be found here, but the crux of the problem is how WP:V applies to broadcast content once it is no longer available. In this particular instance, while the BBC archive all their broadcasts, the vast amount of the archives are only available to people involved in the production of the programme (outside of those programmes that are commercially available). The interpretation of the WP:V which we have is that just existing in an archive isn't completely consistent with WP:V, and such archives need some form of public access so that editors can verify content. This is causing a problem for a particular editor who wants to include quotes from a current affairs show that can no longer be accessed by the public.

Since TV/radio broadcasts seem to be the main medium especially for current affairs interviews, it would be a shame if we couldn't use this material, and a policy which is supposed to enhance Wikipedia starts to become a hindrance. I was wondering if initiating a "transcription verification" service might be a way to incorporate the material without compromising WP:V to an unacceptable level. Maybe some form of this already exists? The basic idea would be in a typical interview/debate, a quote (along with the context i.e. such as a question) is fully transcribed for use on a particular article, and two independent editors who haven't edited the article could verify that the transcript is an accurate rendition of the quoted material. In the example of the BBC and this particular problem, the shows are available on iplayer for a week after broadcast, which would allow enough time for the transcription and the verification.

If this idea is a complete no-go I understand, but we have an editor at the discussion who is willing to trial the system if we can try it. Betty Logan (talk) 03:52, 21 February 2011 (UTC)

I took a look at that link, but it's just the one comment. What I'm wondering is who is interpreting WP:V to mean that we can't use TV shows as sources, even when those shows aren't archived? WP:V says, "The principle of verifiability implies nothing about ease of access to sources." Now, I would be comfortable excluding such sources for information about living people under the more stringent sourcing requirements laid out by WP:V. Similarly, if someone is trying to include an incredulous claim based upon "I saw it on BBC News yesterday", WP:REDFLAG ("Exceptional claims require exceptional sources") could also be invoked. And, of course, it would be better to have a print source if one were available. But, all of that being said, I don't believe WP:V can be read to generally state that un-archived television programs cannot be used as sources. Is this being discussed somewhere else? Qwyrxian (talk) 00:40, 23 February 2011 (UTC)

Proposal to Acquire a Professional Musopen Account for Wikipedia

Discussion at Portal talk:Featured sounds/Musopen. Sven Manguard Wha? 08:02, 22 February 2011 (UTC)

Archive Protection

I got an idea of having an new type of protection on archived pages that is not supposed to be edited like RfA. The protection makes no one can edit it. Maybe that when bureaucrats approve or rejects the request, it automatically protects the page.

~~Awsome EBE123~~(talk | Contribs) 12:58, 22 February 2011 (UTC)

Is there currently a problem with vandalism on the RfA archive pages? If not, then what is the point of protecting them. Yoenit (talk) 13:21, 22 February 2011 (UTC)

Although probably unnecessary, and technically not worth the trouble of implementing, It's still not a bad idea: There's no reason anyone should be editing those pages anyway, and in the off-chance that they do get vandalized, and I can see that happening as someone wanting 'revenge' on an admin for some past block, it's possible that the vandalism can go uncaught for a long time, especially if the admin is inactive, as presumably noone other than the admin would have that page on their watchlist. -- œ^™ 18:42, 22 February 2011 (UTC)

As there is always the possibility of unforeseen future reasons to edit closed RfAs, I don't think it's necessary to preemptively protect them. –xeno^talk 18:49, 22 February 2011 (UTC)

Allow users to suppress the external links icons in their preferences

Basically wrapping everything (articles, watchlists, special pages, etc... in <div class="plainlinks">. This icons can be annoying to those of us who are fine with the difference in tone as the only way to tell internal apart external links. Headbomb {talk / contribs / physics / books} 00:18, 23 February 2011 (UTC)

Try adding this to your skin.css:

a.external {
    background:none !important;
    padding:0 !important;
}

That could probably be turned into a gadget, if there were sufficient demand. Anomie⚔ 01:59, 23 February 2011 (UTC)

I'm not sure what the proposer means. Are there external links icons? Where? GeorgeLouis (talk) 03:44, 23 February 2011 (UTC)

the arrow in the box to the right of this text is what he's talking about. Sven Manguard Wha? 04:22, 23 February 2011 (UTC)

A-class

How about a top icon for A-class articles? I made a template already. It's at Template:Class A article.

~~Awsome EBE123~~(talk | Contribs) 12:51, 22 February 2011 (UTC)

GA and FA are wikipedia-wide standards while A-class is wikiproject specific. Not all wikiprojects use A-class and if one wikiproject makes an article A-class that does not mean it is an A-class for another wikiproject. For example Thinis is assesed as A-class for Wikipedia:WikiProject Ancient Egypt, while Wikipedia:WikiProject Former countries considers it only B-class. Yoenit (talk) 13:17, 22 February 2011 (UTC)

I'm not a big fan of the idea. Actually, I'm not a big fan of the GA top icon either. For the casual Wikipedia reader, I think the multiple icons are confusing because their meaning is not that obvious. In particular, the fact that a good article is "not as good" as an A-class article but "better" than a B-class article is somewhat counter-intuitive. Furthermore, the process that identifies A-class articles is not transparent. For the avid Wikipedia reader/editor, there's always the possibility to set the preferences to include the user interface gadget that automatically displays the assessment. I highly recommend it if you're not already using it. Pichpich (talk) 13:21, 22 February 2011 (UTC)

This whole classification reeks of subjectivity. I suggest the "EmmanuelM index" for article greatness, which is the ratio of total visits / number of edits, both over the last 30 days. In other words, a great article is an article that many people read but few find something that needs to be corrected. Emmanuelm (talk) 20:02, 22 February 2011 (UTC)

Speaking from WP:PRIMATES, some of the articles in our top 25 for hits get very few edits, but are in really crappy condition. Monkey and Slow loris quickly come to mind (although we have a collaboration slowly working on the latter at the moment). – VisionHolder « talk » 21:25, 22 February 2011 (UTC)

I was going to propose this and I think it's personally an awesome idea, but we need to standardize this site-wide first before we can really make progress with this proposal. Kevin Rutherford (talk) 06:19, 24 February 2011 (UTC)

Main page redesign

A proposal to add Featured sounds to the mainpage was put forward on February 15. An additional proposal to add Featured lists was added on February 23. Together, these two proposals involve a redesign of the main page, under discussion. SandyGeorgia (Talk) 03:57, 24 February 2011 (UTC)

Wikipedia's Most Wanted (Pages)

I think Wikipedia has progressed far enough that it's faults are becoming more apparent. It seems that recently (the last two years or so), community work has been focused on the nuances of existing policy, rather than the less functional aspects of the wiki model. Basically, given enough time, wikipedia will eventually have generated articles on all subjects. However, this model suffers from the fact that people find some stuff more interesting than other stuff, and the extremely popular subjects are basically exhausted in terms of new articles. This leads me to think that for the wiki to become more well rounded, the areas of missing content should be addressed.

It seems that about a year ago, the process that generated pages on Special:WantedPages was sabotoged by a new mode of editing, where redlinks get added to templates. Because of this, links to missing pages got disproportionately measured, since any article added to a popular template would make it seem highly requested, while articles only redlinked in mainspace text would be easily missed. There is also Wikipedia:Most wanted articles, which was created using a database dump in 2007. This page only includes links from mainspace articles, not templates. This circumvents the problem generated by Special:WantedPages, but there is no automated updates or removals to this process.

There are two other processes worth mentioning: Wikipedia:WikiProject Missing encyclopedic articles, which is a project geared to create articles that have been identified as missing through a variety of other sources. There is also Wikipedia:Requested articles where users can add red links to the subject-based lists.

Basically I am looking for ideas. I guess there's two issues, methods of discovering missing articles and methods of creating missing articles. I think this is the sort of problem that would be served well by applying the original goals and ideals the wiki, since when it started out there was a great deal of interest and momentum in article creation. As things are right now, there are huge gaps in certain areas, and this is a community issue. What are your thoughts? --NickPenguin_(contribs) 00:54, 22 February 2011 (UTC)

Not really an answer to your questions but: aren't red links still strongly discouraged in templates? That's what Wikipedia:Red link says. Pichpich (talk) 01:16, 22 February 2011 (UTC)

Not always - "The exception is redlinks in navboxes where the articles are part of a series or a whole set ..." - which fits most of the large templates which have been the issue here. Shimgray | talk | 03:07, 25 February 2011 (UTC)

Number of hits per article

It's too late to start over, but I always wonder when I read an article how many others have read before me. It would be interesting to me to see how many hits each article has had. Wouldn't Wikipedia administrators as well as users like to have some idea of this?

Just a suggestion.

Thanks for reading.

An external counter for page view statistics is linked under the page history tab - it's on a daily basis rather than "for all time", but it should be more or less what you're looking for. Shimgray | talk | 20:02, 23 February 2011 (UTC)

You click on "History" and then you click on "Page View Statistics." Sincerely, GeorgeLouis (talk) 20:03, 23 February 2011 (UTC)

A fresh install of MediaWiki still has counters for total page hits at the bottom of every page (mw:Manual:$wgDisableCounters). However, this feature was disabled on Wikipedia many years ago, so it looks like admins didn't like it. --Morn (talk) 00:47, 24 February 2011 (UTC)

I believe it's disabled because it doesn't count pageviews that are served by the caches, just the ones that make it through to the apache servers. And since we want as many hits as possible to be served by the caches, it's basically useless here. Anomie⚔ 01:52, 24 February 2011 (UTC)

There's also the fact that, as I understand it, MediaWiki itself doing the hit counts is quite inefficient. Whilst it's theoretically capable of it, enabling the function on a system with this much traffic could have rather messy effects, since it has to update a record every time a page is hit. Even without the caches, it would still be more efficient to use the "secondary" counting via logs. Shimgray | talk | 02:07, 24 February 2011 (UTC)

True, cache hits aren't counted, so enabling the stock MedaWiki feature wouln't help. Then again, a nightly job could be set up to analyze the logs like stats.grok.se does and add total daily hits per article to the database. I don't think it's a technical or performance issue. It's more due to lack of interest on the admin side that this feature never came back to Wikipedia. --Morn (talk) 11:49, 24 February 2011 (UTC)

Click on the "History" bar at the top of each article, and then find the icon that says "Page view statistics". Click on that - I think that that will give you the information which you have been seeking. ACEOREVIVED (talk) 19:56, 24 February 2011 (UTC)

He's looking for total hits, not hits per day. --Morn (talk) 22:53, 25 February 2011 (UTC)

You can get a good idea by adding all the years' data together. http://stats.grok.se/en/2011/User:Killiondude/stats + http://stats.grok.se/en/2010/User:Killiondude/stats etc. etc. stats.groke.se appears to list things from 2008 and onward, but see User:Killiondude/stats about locating its source data and for links to the internet archive's copy of even older data. Killiondude (talk) 23:06, 25 February 2011 (UTC)

[technical] Wikipedia after 10 years: sharing informations - step two

Hi all, my name is Paolo.

First of all: sorry for my bad english language :)

Next, right to the subject: I really appreciate what Wikipedia gives to me everyday and I would like to return to it a little bit.

I think this idea could lead to:

a) significantly lower the storage costs of the immense wikipedia mass of data while exponentially increasing available space;

b) boost the wikipedia speed;

c) involve all us, as users, in a new higher grade of collaboration;

My idea simply consists into developing and issuing a software through which we all can share a little percentage of Hard disk space on our internet-connected home computers, just like p2p philosophy, and following the example of SETI @ HOME project, in order to host some encrypted datas of wikipedia which will be managed only by the original website

I will not annoy you with all the technical details I have thought of, because I would like before to know your opinion about this proposal...and for sure there are many other people who are better than me for this :)

Wishing to help you improving wikipedia...

Regards,

--94.163.7.8 (talk) 08:28, 24 February 2011 (UTC) Paolo Bianchi e-mail: bianpaol @ gmail . com

Well, SETI@HOME doens;t share disk space: It only uses your computer's processor to process data. SETI's data is run through many different algorithms, and this requires a lot of RAM. It wouldn't be a good idea to implement this on Wikipedia, as we don't need that much processing. It would require as much RAM to send the data requiring processing and the algorithm to a computer as it would to do the job itself. Wikipedia requires fast results, which would be slowed down if the data was sent to another computer for processing every time you used the search suggestions or something similar. All of Wikipedia's processing is related to messing around with the database, so a user's computer can't help anyways. ManishEarth^{Talk • Stalk} 12:45, 24 February 2011 (UTC)

I'm sorry, but this does not seem like a good idea for a number of reasons. First of all, Wikipedia has a massive and very complicated network architecture, and this type of change would require it to be completely redone. Second it poses major security risks, as anyone with direct access to the servers and enough technical knowledge can get into places they shouldn't by simply circumventing any web interface based security features. Third, it would only be possible if the volunteer computers were always on and always connected to the internet, something Wikipedia can't ensure. Fourth, if something does go wrong, having the servers all in a limited number of places allows for more efficient repairs and less downtime. Finally, for legal reasons, Wikipedia keeps servers in some places and explicitly out of others. If a single person from New York donated part of her computer as a server, it would open Wikipedia up to New York's very restrictive laws on musical recordings, and Commons would have delete about a third of its repository of sound files. Likewise if a single person from another country opted in, it would have legal and tax ramifications.

Simply put, if you want to help Wikipedia with it's storage needs, ask them for a wishlist and buy them hardware off the wishlist (or send them money earmarked for said hardware so that you save on shipping.) Sure a server is expensive, but there are likely other things they could use too, and everyone likes donating tangible items. Sven Manguard Wha? 16:47, 24 February 2011 (UTC)

Storage is cheap, it's constantly getting cheaper, and text does not take much space to store. The cost to develop and implement a system like this would probably offset any savings in storage costs for years. Mr.Z-man 21:48, 25 February 2011 (UTC)

Extension:ArticleEmblems and Top Icons

Extension:ArticleEmblems was designed and developed to handle top icons properly (Bug 23796) without some of the css hacks we need, I propose we actually use it. Peachey88 ^{(T · C)} 06:58, 25 February 2011 (UTC)

Has it been reviewed yet ? Unreviewed code cannot be deployed (I know it's on Roan's list for the coming weeks, just like the new Narayam and a few other extensions, but as far as I know, it has not yet been done at this exact time) —TheDJ (talk • contribs) 08:39, 25 February 2011 (UTC)

Extentions don't really get reviewed unless somewhere (a community) requests that it be activated to avoid pointless requests, which is why I'm trying to gain consensus first. 09:08, 25 February 2011 (UTC) — Preceding unsigned comment added by Peachey88 (talk • contribs)

(More specifically, extensions don't get reviewed unless a sufficiently large community requests it, otherwise it just sits around for years while all the code reviewing gets done for the big projects. Grumble grumble...) Does this extension actually solve any real problem, or is it just a more elegant solution to something already been dealt with by CSS? --Yair rand (talk) 11:24, 25 February 2011 (UTC)

Permanent Preservation

This will sound like a bit of a silly/stupid idea, but as an archaeologist, I know that pretty much the only histories we have ancient cultures other than oral histories and papyri are those written on (accidently baked) clay tablets and stone (and a few other anecdotal instances of other materials.) Paper degrades and so do disks and all manner of digital storage. So I was thinking wouldn't it be fun if at some point the articles (after review of course) in Wikipedia were copied down onto either hard durable plastic or some manner of stainless steel tablet? Something that would never degrade and even if somehow civilisation was wiped out completely, the archaeologists of the future would have an abundance of information from this era and our knowledge and cultures would be preserved. After all, the cultures for whom we have no histories are pretty much lost to history.

I can just imagine the caches being found in the distant future and whoever finds them saying "Ah Ha!" and finding out all the old stories and whacky theories about this time and earlier are true! Full records of our global civilisation with its many peoples, languages, musics, foods, dances, etc.

Silly I know, not to mention expensive and time-consuming. However it would be nice if this could be done. I would love to see projects like this in maybe a decade when the other languages have caught up to the English wiki. It would be a marvelous thing if people in many different nations raised money for this sort of thing and everyone contributed to the preservation of their collected knowledge in their own tongues (no sense just preserve the English Wikipedia.

Just a thought.... =) TheArchaeologist 06:36, 24 February 2011 (UTC)

The idea had been kicked about a bit. Metal has too high a scrap value and plastic degrades on exposure to sunlight. Best suggestion I've run across is probably to stamp extracts of wikipedia articles into bricks (and then use them for normal construction.©Geni 01:45, 25 February 2011 (UTC)

We could put it on a solid gold CD and shoot it into space. (Please someone get the reference.) Sven Manguard Wha? 03:56, 25 February 2011 (UTC)

Yes, yes, haha, very funny. =p You two laugh, but a lot of people, when they really really think about it, are at the very least a little uneasy with the idea that if our civilisation just ceased to be tomorrow, then there would be nearly nothing left of us (our modern civilisation) in a thousand years (if you believe the History Channel, which is typically not good practice I will admit) except from some plastic cases, of course garbage dumps (archaeological gold mines) and apparently the Hoover Dam. (yes I do overuse commas)

Looking at what you said as jokes seriously though (time to kill the jokes >:3), the scrap value thing assumes that stainless steel would still be valued at that time and they wouldn't have something better that they use for their main metal (like some manner of cheaply produced titanium or some other metal) and the idea of a cache is that usually it is in a vault of some sort or buried (in a vault in this case), and I don't think many plastics degrade on immediate contact with sunlight, it also depends on the type of plastic you use (in this case, not one of the eco-friendly ones that degrades quickly). Even then, it's not like if the vault is exposed for study that its contents would degrade anytime soon. They might be stolen and sold, yes, but not degraded for a long time.

Yep, Voyager 1 and Voyager 2. I think Futurama helped a few more of the younger generation get that reference (though I read many Astro books when I was a kid (21 atm)). There was a recent little Finnish film (which I cannot find or remember the name of) actually where one of the Voyagers (I think it was 2) crashes and this odd man and his alien dog (don't ask, I didn't get that bit) play it and then build a rocket to go to Earth. They find nothing there but an old man and a bar with a computer that has a short video history, nothing else.

It would be nice if someone financed a project similar to this at some point. If not with wiki then maybe Britanica or Encarta (though they are very limited) TheArchaeologist Say Herro 04:29, 25 February 2011 (UTC)

Well the closest I'm aware of is the Long Now Foundation's Rosetta Project.©Geni 18:55, 25 February 2011 (UTC)

If it's good enough for Scientology, it's good enough for us: "The archiving project, which the church has acknowledged, includes engraving Hubbard's writings on stainless steel tablets and encasing them in titanium capsules."[4] Fences&Windows 19:21, 26 February 2011 (UTC)

Well the disk is a start, but I don't like the fact that it will eventually degrade. =/ Ugh, I for one hope THOSE tablets stay buried or are destroyed. Godforbid whoever the later archaeologists are find those and think that it was a major religion or part of our culture. See they have the right idea though, even if they are basically preserving what is in my opinion (don't want the CoS to sue) garbage. TheArchaeologist Say Herro 03:35, 27 February 2011 (UTC)

My Brilliant Idea

I have no clue if this has been discussed before, or if there's a reason why it hasn't been done but I think that in order to edit Wikipedia, you must create in account or login. No more anonymous IP edits. Wouldn't this greatly cut down on vandalism? If you have something constructive to add, you can easily sign up. Others will be discouraged from adding nonconstructive things. It seems like it would work to me. ~ Richmond96 t • c 23:50, 27 February 2011 (UTC)

See Wikipedia:Perennial proposals#Prohibit anonymous users from editing MBelgrano (talk) 00:00, 28 February 2011 (UTC)

Ok, thanks. I see the reasons for the current method, now. ~ Richmond96 t • c 03:26, 28 February 2011 (UTC)

Template

One thing I think would help improve the ol' Wikipedia is to have a little template appearing at the top of the page saying you have new messages on your talk page whenever you do have new messages. Of course, it would have to be done so that it doesn't appear on every single page to everyone, just to those who have new messages on their talk pages. Maybe have it say something like this:

You have new messages

Just have it be as simple as possible, and have "new messages" link to whichever user's talk page. Besides, just about every other Wiki I've been to has this feature, why not Wikipedia? --Codyrox (talk) 01:24, 25 February 2011 (UTC)

• Isn't that what the orange "You have new messages" band is for? – Peacock.Lane 01:51, 25 February 2011 (UTC)

• This is, in fact, the way it works already! The reason you're not seeing it is that you're editing as Thebigfan2 (talk · contribs), with your user talk page redirected to User talk:Thebigfan. As a result, anyone looking to leave you a message will end up doing so on the talkpage associated with Thebigfan (talk · contribs), and triggering the message alert for that (now dormant) account; the message alert would only get triggered for you were a message to be left on User talk:Thebigfan2. Shimgray | talk | 03:04, 25 February 2011 (UTC)

Well, I would edit as "Thebigfan" but I seem to have forgotten what my password was to get on it. --Codyrox (talk) 18:35, 25 February 2011 (UTC)

Can't you just request the password be sent to your email address? Otherwise, redirect User:Thebigfan to User:Thebigfan2, and get on with editing, problem solved. You already use the totally unrelated "Codyrox" in your sig so there's no reason to be wedded to the Thebigfan account. Fences&Windows 23:58, 28 February 2011 (UTC)

WP:Notability (video games)

Posting here as there it seems we have a final draft before this gets promoted. This is based on the GNG, WP:VG/GL and common practices, If anyone has any comments please feel free to discuss them there.陣内_Jinnai 22:40, 28 February 2011 (UTC)