Jump to content

Wikipedia:Village pump (proposals)/Archive

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Village pump (proposals)

This is an old revision of this page, as edited by Werdnabot (talk | contribs) at 15:22, 25 February 2007 (Automated archival of 4 sections from Wikipedia:Village pump (proposals)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Village Pump - Archive

DO NOT EDIT OR POST REPLIES TO THIS PAGE. THIS PAGE IS AN ARCHIVE.

Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

Post replies at Wikipedia:Village pump (proposals), copying or summarizing the section you are replying to if necessary.

Note: Please add new material at the bottom of the page and remove any duplicate sections.

This talk page is automatically archived by Werdnabot. Any sections older than 14 days are automatically archived to Wikipedia:Village pump/Archival dump. Sections without timestamps are not archived.

Salted pages

[moved from Wikipedia:Administrators' noticeboard]

It's been proposed that we replace all of our "salted" articles (currently tagged with Template:Deletedpage) with redirects to a page in the project namespace containing similar text (thereby removing salted article pages from the random article pool and total article count). I believe that this would be an improvement, but the main disadvantage would be that users would no longer be able to view useful links unique to the individual pages.

Now that cascading protection has been enabled, it's finally possible to protect a nonexistent page (simply by transcluding it onto a page with cascading protection directly applied, thereby causing it to appear as a red link). I propose that we switch to a system in which a series of project pages (perhaps one for each month) is created and used for this purpose.

I've created a demonstration template and added a couple of transclusions to a demonstration page. The syntax is as follows: {{protected title|page title|optional reason}}
For non-articles, the namespace should be omitted from the page title and appended as the conditional "ns" parameter (ns=[namespace]). To omit the talk page link (handy if it's a likely vandalism target and there's no realistic legitimate use for the page name), append the following parameter: talk=no

I've tweaked some MediaWiki code to display a {{deletedpage}}-style notice (along with advice to check for additional information on the page to which cascading protection has been directly applied) when a non-sysop attempts to edit (or follows a red link to) a nonexistent page with cascading protection applied. If a non-sysop merely attempts to view such a page, he/she sees the standard "Wikipedia does not have an article with this exact name..." message (which could be modified to reference instances in which "view source" is displayed instead of "edit this page"). Clicking on "view source" displays the aforementioned {{deletedpage}}-style notice and accompanying link/advice.

A bot could be used to convert all of the salted pages to this format (automatically sorting the titles chronologically—likely based on the pre-existing list—and inserting the most recent edit summary as the reason).

Opinions? —David Levy 06:38, 27 January 2007 (UTC)[reply]

This is a very intelligent solution--and certainly we've all agreed for some time that the holy grail would be some way to protect articles in a genuinely deleted state. The only problem I can see is that it will have the same effect if a non-existent page is (for whatever reason) transcluded on to some other page with cascading protection, but perhaps that doesn't matter (it seems like it would be rare). It would also require admins to change their behavior in a more drastic way, which is also always a challenge. :) Chick Bowen 06:56, 27 January 2007 (UTC)[reply]
I've given this some thought, and I've been unable to come up with another situation in which we'd want to transclude a nonexistent page on a page with cascading protection enabled. —David Levy 17:30, 27 January 2007 (UTC)[reply]
Typo on mainpage links? Night Gyr (talk/Oy) 17:58, 27 January 2007 (UTC)[reply]
Well, yeah--it would be from a screwup of some sort. If a template were deleted and the admin forgot to check whatlinkshere, it might appear to another editor that it had been protected against creation. As I say, though, not a big deal. Chick Bowen 18:03, 27 January 2007 (UTC)[reply]
Ah, okay. I misunderstood your comment to mean that we might actually want to do this for some reason. —David Levy 18:10, 27 January 2007 (UTC)[reply]
Is there a way to make the "This page has been deleted and protected to prevent re-creation" message not show if the cascading protection is only semi-protection? That would make eliminate the likeliest circumstances. Chick Bowen 18:15, 27 January 2007 (UTC)[reply]
I'm surprised to learn that cascading semi-protection is possible, as this enables anyone with a non-new account to semi-protect pages. That's a far worse problem than the display of that message (which would require developer intervention to change) and I don't believe that cascading semi-protection should ever be applied for any reason. In my opinion, it should be formally prohibited via the protection policy. —David Levy 18:34, 27 January 2007 (UTC)[reply]
Thank you very much for noting this. In fact, when semi-protection cascades it becomes full, so the problem is even worse. I've filed bugzilla:8796 about it. Superm401 - Talk 20:19, 27 January 2007 (UTC)[reply]
Yikes, I didn't realize that! I'm going to go ahead and add an explicit prohibition to the protection policy. —David Levy 22:04, 27 January 2007 (UTC)[reply]
That's a really good idea. —Centrx→talk • 17:45, 27 January 2007 (UTC)[reply]
I am not really against it. So, instead of adding the {{deletedpage}} or {{spambot}} templates to the pages, we would include the page in a list. Gives us better control than just a category for sure. -- ReyBrujo 17:57, 27 January 2007 (UTC)[reply]
This is a great idea, but when someone attempts to edit a non-existing, cascading-protected page, I think as well as the message you added, there should also be an empty, disabled text box on there, to make it clear that they are on the edit tab, there is no text on the page and to keep with convention, e.g. with non-existent MediaWiki: pages. Also, the 'edit this page' tab should be replaced with 'view source'. Other than that, yes, this is a great idea. Tra (Talk) 19:00, 27 January 2007 (UTC)[reply]
There is a "view source" tab instead of an "edit this page" tab. I don't believe that a disabled text box would be of any benefit, and I also see no means of adding one. (We're working within the confines of MediaWiki:Cascadeprotected.) —David Levy 19:56, 27 January 2007 (UTC)[reply]
If you go to this page (from one of your examples), the title of the page says 'View source' but the tab at the top says 'edit this page'. However, yes, I can see now, you didn't edit any code, you just customised MediaWiki:Cascadeprotected so unless it allows raw HTML, I agree a text box wouldn't be possible. Tra (Talk) 22:29, 27 January 2007 (UTC)[reply]
Ah, I see. I'd only viewed the page while logged out (which results in a "view source" tab). —David Levy 22:36, 27 January 2007 (UTC)[reply]
Oh, wow. This is brilliant. -- Steel 19:06, 27 January 2007 (UTC)[reply]
I really like this idea. ···日本穣? · Talk to Nihonjoe 20:17, 27 January 2007 (UTC)[reply]
If this is what I think it is, Wikinews has been doing it for ages with noxiously recreated pages, see n:Wikinews:Protected deletions. 68.39.174.238 22:54, 27 January 2007 (UTC)[reply]
They're using protected redirects to a project page. (The pages aren't actually in a deleted state.) As noted above, this is something that we've considered doing. —David Levy 01:49, 28 January 2007 (UTC)[reply]
I dislike that idea. It decouples the protection from the page, which means that, for instance, the protection will not be recorded in the page's history or logs. It would be a better solution to change the code to allow nonexistent pages to be protected (if it displays a special message in that case, we could simply change it to be identical to the current {{deletedpage}} template). --cesarb 21:57, 28 January 2007 (UTC)[reply]
The page must be re-deleted before it can be protected. If the sysop includes a comment along the lines of "salting page," why would this (combined with a clear recording in the history of a specific project page) be insufficient?
Yes, a function created specifically for this purpose would be preferable, but that isn't available (and it isn't as though we haven't asked the developers to add it). Until it is, we have to choose one of the available methods. —David Levy 22:07, 28 January 2007 (UTC)[reply]
That would, assuming the admins specifically say so when deleting (which I doubt; the delete reason is to write the reason for deleting, not what you are going to do next), only record when the page is protected, but not when it's unprotected.
I know it might not be easy to create a function like I described (in particular, it's quite probable that either the database layout would have to be changed or a "phantom" row would have to be used... which would be quite similar to what's currently done with {{deletedpage}}). But it's the right way to fix the real problem, which is that we have a page at the article namespace which should not be counted as an article (the same happens with things like the Main Page and redirects; in fact, something similar to what is done with redirects could be a reasonably elegant solution). --cesarb 23:16, 28 January 2007 (UTC)[reply]
1. The designated project page would contain a record of both the protection and the unprotection.
2. Again, the fact that it it may be possible to implement a better solution in the future doesn't change the fact that we need to implement something now. We currently have no perfect option, but I believe that the use of unorthodox bookkeeping is an exceedingly minor issue compared to the problems inherent in the available alternatives. —David Levy 23:50, 28 January 2007 (UTC)[reply]
Pending the implementation of a feature to protect nonexistent pages, using cascading protection to create protected redlinks seems like a good idea to me. As for the 'this page has been deleted, and protected to prevent recreation' message, it would be possible to prevent confusion in any other cascaded-redlink case by changing it to something like 'this page has been protected against creation' (which is much the same thing, but slightly more general). --ais523 15:35, 29 January 2007 (UTC)
The one time I landed on a delete-protected page via Special:Random is enough to make me love this proposal, barring future improvements to directly protect non-existent pages. Flyingtoaster1337 02:23, 31 January 2007 (UTC)[reply]
Excellent excellent idea. Take a look at Reality. (while logged out if you are an admin) to see this in action. Prodego talk 02:39, 31 January 2007 (UTC)[reply]
And the final step would be a bot run with admin rights that deletes {{deletedarticle}} and adds the article name transcluded to Wikipedia:Protected titles. Guy (Help!) 14:20, 31 January 2007 (UTC)[reply]
Yeah. I counted about 1200 transclusions. So next step is to start another bot RfA, say "no, it's not open source" and wait if Werdna comes up with a MediaWiki solution :-) (I'm just kidding, please forgive me). Other options would be to employ a horde of admins with AWB or just ignore the current transclusions and use the new system for new salted pages only. --Ligulem 16:43, 31 January 2007 (UTC)[reply]
We should simply run the bot under the owner's sysop account. —David Levy 16:55, 31 January 2007 (UTC)[reply]
In that case one such bot comes to mind. Flyingtoaster1337 17:43, 31 January 2007 (UTC)[reply]
Minor quibble... the deleted title message currently says, "Specific information may be found by... contacting the administrator who protected the page." Since the logs for the page itself may not list any protections, I suggest that "who protected the page" be changed to "who deleted the page". Flyingtoaster1337 16:30, 31 January 2007 (UTC)[reply]
Good catch! Fixed.  :-) —David Levy 16:39, 31 January 2007 (UTC)[reply]
I thought the above would be the last "minor quibble" I had but there's another... I notice you removed the link to Special:Undelete. However, if the page has ever been deleted even once there'll be no easy access to deleted versions. For that reason I think the link is worth retaining. (Perhaps change "view the page history and content" to "view any deleted page history and content" so the sentence is ambiguous on whether the page has been deleted before.) Flyingtoaster1337 17:08, 31 January 2007 (UTC)[reply]
I removed that line because the message isn't visible to sysops (who are presented with such a link in the text that they see). —David Levy 17:18, 31 January 2007 (UTC)[reply]
Activity log link is borked for pages with spaces in the titles but thta is a minor quibble :-) Guy (Help!) 17:50, 31 January 2007 (UTC)[reply]
Minor indeed. The parameter that gets put into the link just needs to be {{urlencode}}d. Flyingtoaster1337 18:10, 31 January 2007 (UTC)[reply]
I wasn't aware of this when I created the template (which is why I included a conditional parameter for the page title with underscores in lieu of spaces). I'm working on a better version now. —David Levy 18:23, 31 January 2007 (UTC)[reply]
I've reworked the template accordingly. The underscored title parameter has been eliminated and the optional reason parameter has been shifted to the second position (which is more intuitive). Thank you, Flyingtoaster1337! —David Levy 19:04, 31 January 2007 (UTC)[reply]
Go vote for Bugzilla:2919. I left a pointer there to this discussion here and noted David's cascade protection trick. --Ligulem 17:43, 31 January 2007 (UTC)[reply]

I'm in the planning stages a real delete-protect feature, possibly being smarter, and allowing a "title blacklist" that prevents non-admins from creating a page with titles matching a regex, or moving to illegal titles. I'll probably do this after per-page blocking. — Werdna talk 05:09, 1 February 2007 (UTC)[reply]

Werdna, you are a god among men. Thanks. Philwelch 05:23, 2 February 2007 (UTC)[reply]
Which should stop those spambots creating Talk:Foo/w/w/wiki/index.php/Asdf/index.php style pages once and for all. Yay! Flyingtoaster1337 09:04, 5 February 2007 (UTC)[reply]

Are we ready to make the cascading protection-based deletedpages system official? It probably will make it easier to migrate to Werdna's system once that gets rolled out. Neither system needs any boilerplate text in place at the deleted title. IMO, if we delete the {{deletedpage}}s now there won't be any left when we switch to the blacklist system. Flyingtoaster1337 09:04, 5 February 2007 (UTC)[reply]

WP:DRV is the process to use if you want to have an article at any of the blacklisted titles. Tra (Talk) 15:21, 11 February 2007 (UTC)[reply]

English translation of Italian tv show Don Matteo

I'd like to suggest an English language translation of the Italian television show 'Don Matteo': http://it.wikipedia.org/wiki/Don_Matteo

As it's just started a run on Australian tv (SBS) this might be of interest to readers. --Robert Fraser 06:39, 10 February 2007 (UTC)[reply]

Hi Robert. This request would probably be better placed at Wikipedia:Translation/*/Lang/it, specifically set up for translation requests of Italian Wikipedia articles into English.--Fuhghettaboutit 12:07, 10 February 2007 (UTC)[reply]

ddafd


thank you

Jeremyp1988 17:47, 12 February 2007 (UTC)jeremyp1988[reply]

two proposals: use of wikipedia materials as course material for universities or schools, listing of most visited(say 10) pages on the front page of wikipedia

it would be a good idea to advertise the use of material from wikipedia for schools or universities. I know that such an activity is active for school children, however i dont know of anything similar of higher education. a lot of colleges/university professors, write there own notes, which are then given out to university people, much like mit ocw. so you might have a project where you have various courses which are provided for in the universities. these course materials would be edited only by professors or people of good knowledge of their subject, so that it can be used for course work. it would be very useful for people from backward nations, where there are not enough educated professors, or good professors. also since most universities teaching the same level course have a similar syllabus, it would standardize the courses over the world, so that people in backward nations are at par with the information available to that available to better off countries.

a second proposal would be to have a list of the most accessed topics(say 10) on the front page of wikipedia. this would be mainly for information purposes to the casual visitor. i saw that a proposal for a similar thing might lead to vandalism. however since you are listing the most visited pages not the least visited pages, it shouldnt cause any problem

Most schools do not accept Wikipedia as a reliable source, and rightfully so, since anyone can edit and throw in misinformation. There are statistics listed at Special:Statistics, especially under "Other statistics" that you might find useful. I don't like the term "backward nations" either. − Twas Now ( talk • contribs • e-mail ) 13:15, 10 February 2007 (UTC)[reply]

I cant understand why most wouldn't accept a possibly wrong information source, but what I proposed was a expert written text, not something which will be readily edited by every body. so you can have a list of ips of reknowned educational institutes, whose people would be allowed to edit topics. undoubtedly you can never prevent vandalism,(even if you some way to ensure that it is a professor who edits a particular article, his id can also be stolen) but it is definitly a good way to increase the accurate ness of articles which are most necessary for learning. as a student i have seen, almost all of my batchmates using wikipedia for information, it would really be helpful for a lot of people to have a better information source.

also if you look at the number of science or humanities topics that are being accessed by people you will realise that most of them would be from college going students

Yes, it is certainly a good place to start—to get an idea of a topic. However, textbooks and academic journals are more appropriate resources in an academic setting such as a university. − Twas Now ( talk • contribs • e-mail ) 13:35, 10 February 2007 (UTC)[reply]

what i am saying is to have a mit, ocw version of wikipedia, only that it would contain a much wider variety, of content but related to academics. OCW is a quite a good concept, and the purpose of that is very similar. But the problem is that various universities, (like a stanford ocw, a beijing university ocw etc) have there own versions of ocw, why cant there be a single repository of information. I am not talking of academic journals, anyway if you are doing research academic journals are the best way to go, they are peer reviewed, and you will definitely have a better source of information.

We already have Wikibooks to write textbooks and Wikiversity to do academic stuff like research and writing teaching materials. Night Gyr (talk/Oy) 20:20, 10 February 2007 (UTC)[reply]

New paragraphs to the infoboxes.

I want to add these paragraphs:

to:

to inform related medias.--JSH-alivetalk to mesee my worksmail to me 15:06, 10 February 2007 (UTC)[reply]

These could be added to the infoboxes by putting in the following lines of wikicode into the correct positions:
{{#if:{{{based on|}}}|<tr style="vertical-align: top;"><td>'''Based on'''</td><td>{{{current}}}</td></tr>}}  
{{#if:{{{related book|}}}|<tr style="vertical-align: top;"><td>'''Related book(s)'''</td><td>{{{current}}}</td></tr>}}  
{{#if:{{{related comic|}}}|<tr style="vertical-align: top;"><td>'''Related comic(s)'''</td><td>{{{current}}}</td></tr>}}  
{{#if:{{{related film|}}}|<tr style="vertical-align: top;"><td>'''Related film(s)'''</td><td>{{{current}}}</td></tr>}}  
{{#if:{{{related TV series|}}}|<tr style="vertical-align: top;"><td>'''Related TV series'''</td><td>{{{current}}}</td></tr>}}  
{{#if:{{{related video game|}}}|<tr style="vertical-align: top;"><td>'''Related video game(s)'''</td><td>{{{current}}}</td></tr>}}
They are all optional parameters so they won't break any existing articles with the infobox that have not added the parameters. To specify the values of each of these parameters, you could then add the following to where the infobox is referenced:
| based on =
| related book =
| related comic =
| related film =
| related TV series =
| related video game =
Tra (Talk) 16:08, 10 February 2007 (UTC)[reply]

This seems unnecessary; doesn't related content generally go at the bottom of the article, with the see also links, rather than at the top? The infoboxes are pretty big as it is. Night Gyr (talk/Oy) 20:19, 10 February 2007 (UTC)[reply]

The "Based on" line sounds good, but otherwise, what Night Gyr said. Infoboxes are meant to be concise summaries, and their size is a point of contention already. "Related" items do belong at the end of a subject's article. --Quiddity 01:10, 11 February 2007 (UTC)[reply]
Well, frankly, I want to disable {{Infobox animanga}}. In my opinion, TV anime should use {{Infobox Television}}, manga should use comics infoboxes, OVA and film should use {{Infobox Film}} and video games should use {{Infobox CVG}}.--JSH-alivetalk to mesee my worksmail to me 02:28, 12 February 2007 (UTC)[reply]

GFDL image tag depopulation

While stumbling around a few pages, I came upon this, which says that all instances of the (current) {{GFDL}} tag should be migrated to {{GFDL-with-disclaimers}}. Then after the tag is depopulated, the code from {{GFDL-no-disclaimers}} would be copied into the GFDL tag, and then the GFDL tag would be repopulated through transferring the instances of the no disclaimer tag to the new GFDL tag (or simply keep the transclusions in place, either works). I am planning to do this by adding another task to my bot, VixDaemon, but I want to make sure there are no concerns with this before I submit the task for approval. I have compared the current GFDL tag and GFDL-with-disclaimers, and the text matches down to the letter, so there would be no change of license with the migration.

Since Dragons flight who originally proposed this plan to standardize the usage of the GFDL tag between the projects has "basically abandoned" the plan, I am planning to pick up where he left off. Does anyone have any concerns with, or support for this? Kyra~(talk) 23:23, 11 February 2007 (UTC)[reply]

Additionally, I'd like to expand this to include the {{GFDL-self}} tag, as it has disclaimers too; those instances would be migrated to {{GFDL-self-with-disclaimers}}, and then it would subsequently be replaced with {{GFDL-self-no-disclaimers}}. A change to MediaWiki:Licenses would be advisable as it would prevent new instances from arising during the time when the templates would be migrated, as well as currently. Kyra~(talk) 08:07, 12 February 2007 (UTC)[reply]

a better portable wikipedia device

my name is nick church and I am aware of the tomb raider version of wikipedia, however I believe I have a better idea. I have seen many electronic dictionaries which are very popular over in japan. What about a device very similar to the electronic dictionary, yet with wikipedia on it. I realize that wikipedia as a site must take up quite a bit of space, but if you cut out all the user pages, and the talk pages, it could be made to fit on a 30g drive which would definitely fit in something the size of an electronic dictionary. along with this you could include a docking station which will update all the pages automatically, as well as charging it. You could also include basic functions such as a calendar, clock, etc. Also if possible you could consider hooking up with google maps/news to include area maps and news. perhaps an sd card reader would be a good idea so that one may use it to watch videos or play mp3s as well.

you could probably get a good deal on the manufacturing, sell it for about $300 a piece and use the profit for wikipedia expansion...or whatever you want.

Anyone can take a data dump and stick it on such a device. Quality control is an issue, not size. All the text for the current version is only a couple of gigabytes. Night Gyr (talk/Oy) 01:47, 12 February 2007 (UTC)[reply]
Some of the more expensive dictionaries I saw at the E-Mart also doubled as a book reader but I think they were around $350 US. My dictionary was on sale for about $89 but I can't change the contents. I would think one could make a cheap book reader for around $50 that could have just about anything you wanted on it. --Gbleem 03:16, 12 February 2007 (UTC)[reply]
You could just browse it from a cell phone with an appropriate skin. If you want a local copy, you run into the trouble of downloading all that data every time you want to update. Unless the servers make up a custom set of diffs for you, you'll need a couple of gigs of data, and that's not going to be done in the time it takes to charge the battery. Night Gyr (talk/Oy) 04:32, 12 February 2007 (UTC)[reply]

Unique display format for Wikipedia

E-Book Systems Inc., would like to share with the Wikipedia community - a unique display format for Wikipedia purposes.

Founded in 1998, E-Book Systems’ patented Digital Flip® Technology provides a unique way to organize and view digital information. Our solutions bring life to digital content with its ability to integrate multimedia, and display it in a realistic 3D page flipping interface.

With Digital Flip® Technology, Wikipedia can provide its users a true encyclopedic experience. Users can browse through Wikipedia like they would a hard copy encyclopedia. They can flip individual pages, grab a few pages to flip, lift a page to compare with contents on the proceeding or preceding pages, flip through pages rapidly, zoom in or zoom out on a page, jump to a desired page, click on links to navigate to desired page, search content for a desired search term (where feature is available).

We would like to work with Wikipedia to create Wikipedia FlipBook. This Wikipedia FlipBook should adopt the same concept as the existing Wikipedia site. Please click on the following link to browse through the sample Wikipedia FlipBook created for the editors' evaluations : Sample Wikipedia FlipBook

Please note that the Wikipedia FlipBook is only for demonstration purposes. It contains only an extract of the contents in Wikipedia site. The links (in black underline) included in the demo Wikipedia FlipBook have not been enabled. However, please note that we do have the ability to enable the links and ensure that all links navigate to the relevant pages.

About E-Book Systems E-Book Systems is a private organization, with offices in the U.S, China, Japan, Korea, Europe, and Singapore. Investors in E-Book Systems include Creative Technology Ltd, and SOFTBANK Media & Marketing Corporation, a subsidiary of SOFTBANK Corp.

I'm not speaking officially here, but you're just as welcome as any other of the Mirrors and forks to copy the content under the GFDL and use your interface on it. I doubt it'd catch on here, because it requires downloading addition software, and doesn't sound like it adds enough to be worth it. We try to keep the technical requirements low here. Night Gyr (talk/Oy) 09:53, 12 February 2007 (UTC)[reply]
We would like to work with Wikipedia to create Wikipedia FlipBook. The Wikimedia Foundation, which controls Wikipedia and a variety of other free-access projects, has a policy of not using commercial (aka "pay-for") software unless absolutely necessary. So if you are proposing some sort of business proposition whereby you would pay the Foundation for a specialized feed, for example, feel free to contact them; otherwise, you're probably wasting your time. -- John Broughton (♫♫) 00:05, 13 February 2007 (UTC)[reply]
I doubt it'd catch on here, because it requires downloading addition software, and doesn't sound like it adds enough to be worth it. We try to keep the technical requirements low here. E-Book Systems also offers the FlipViewer® BV version which does not require any software download. Please click on the following link to browse through the FlipViewer® BV version of the sample Wikipedia FlipBook: Sample Wikipedia FlipBook - FlipViewer® BV version

"Invert selection" option for watchlist

In Special:Recentchanges, there is an option to "invert" the selected namespace. I think this means it will show edits in all namespaces except the namespace selected, whereas it would normally show only the selected namespace.

If this is correct, I think it would be useful (thought not imperative) to have this option available in our watchlists. Is there a more appropriate place to bring this up? − Twas Now ( talk • contribs • e-mail ) 11:01, 11 February 2007 (UTC)[reply]

Any thoughts? − Twas Now ( talk • contribs • e-mail ) 06:42, 14 February 2007 (UTC)[reply]

Return To Ido Should Also Have, Return To Talk:Ido, Return To Articlehistory:Ido, And Return to Talkhistory:Ido

For example.100110100 08:37, 14 February 2007 (UTC)[reply]

Instead of Articlehistory:Ido, shouldn't it just be History:Ido? —Doug Bell talk 10:28, 14 February 2007 (UTC)[reply]

Template:Taxobox - Authorisation

As far as I can see, there is no complete consensus here regarding the format of the taxonomist's name ("authorisation") in the template:taxobox. There are articles with Linnaeus's name abbreviated, whereas others state his full family name.

I think the taxonomist's name should appear in the abbreviated form, common in the scientific literature, and without parentheses, which should only include the year of description. The abbreviated format should link to the article regarding the specific taxonomist. Reasoning:

  1. Such a format, together with the binomial name, gives the complete and exact scientific format, to designate a species. The template is the best place to expose the readers to this standard way of writing, common among all scientists and scientific literature. This way there is also a match between the format in the article and in scientific articles.
  2. Readers who will be confused by the abbreviations, can clarify the matter immediately by clicking on the abbreviation and reaching the article regarding the taxonomist.

Parallel message posted on the template's discussion page.

Gidip 13:11, 14 February 2007 (UTC) [reply]

google-like spell check

I have always loved Google's "spell-check" when searching for a term I do not know how to spell. I use this often before I search for the term on Wikipedia. It would be great if I could simply skip the copy-paste step and have the spell check on Wikipedia. Not being computer-saavy, I couldn't begin to suggest how to do this. Thanks!

This has come up quite a few times. Basically, spell checking has had to be disabled on Wikipedia search for performance reasons. I would suggest that you continue to use Google for spell checking. Tra (Talk) 04:18, 14 February 2007 (UTC)[reply]
If you're using Firefox, I find that the built-in spell check works very well, and it doesn't require any cut-and-paste operations. You can install a wide variety of different languages and switch between them quickly and easily. As an example, I default to Canadian English, but I can "right-click-select" to switch to British English or American English if the article requires it. (Apologies if this sounds like a promo for FF, but the feature does work quite well.) --Ckatzchatspy 09:23, 14 February 2007 (UTC)[reply]
I'll back that up. I use the same feature for the same reasons. -- KirinX 16:20, 15 February 2007 (UTC)[reply]
How do I find firefox built-in spellcheck?
For those not in the firefox cult, the Google Toolbar, which works in IE and many other browsers I believe, offers similar text-box spell checking. -Indolences 17:38, 16 February 2007 (UTC)[reply]

How about a built in spell checker when actually editing articles? RyanPostlethwaiteSee the mess I've created or let's have banter 21:43, 15 February 2007 (UTC)[reply]

Firefox 2.0 does this out of the box. MER-C 11:29, 16 February 2007 (UTC)[reply]
And you can also do this with the Google Toolbar. Tra (Talk) 14:57, 16 February 2007 (UTC)[reply]
The Google check is helpful (I used it before Firefox added spell checking) - but it unfortunately has a size limit wherein it will only do the first "x" errors in a large group of text. The Firefox one doesn't seem to have that issue. --Ckatzchatspy 20:08, 16 February 2007 (UTC)[reply]
What I've done with the Google spell checking for long pages is I either edited the article in sections or I copied and pasted part of the article into another text box and spell checked that. Tra (Talk) 20:30, 16 February 2007 (UTC)[reply]

Performance reasons? Is there no way around this? I think it would greatly improve the performance to have a "did you mean..." or spellcheck option, like Google. Aceholiday 17:29, 16 February 2007 (UTC)[reply]

Deleted Revisions

Currently deleted edits are retrievable up to June 2004, it is time that we actually start cleaning out the deleted old mainspace page revisions for up to, say 2 years? I was reading up this, I do not believe that anyone would really want to look up for something on mainspace that was previously deleted for more than two years, and I'm sure there are costs for maintaining this database. Over half of what is created today is deleted everyday, and we know that several of them are spam/vanity/copyright violations. Do we really need to keep and retrieve them in five years' time, for example?

At the moment images are not undelete-able for up to June 2006, but in future it's going to take up a lot of space if we don't have a cut-off time. Let's be practical, do we really need to retain imagevios, CSD#I4s, CSD#I5s for more than a year that takes up gigs of space and maintenance costs? - Mailer Diablo 16:40, 14 February 2007 (UTC)[reply]

The deleted revisions are not a problem. If they were, the developers would already have pruned them. They have already warned they can purge all deleted revisions without any warning, and that we shouldn't depend on them being kept forever[1]. --cesarb 17:58, 14 February 2007 (UTC)[reply]

We need a Template:Let the developers worry about it for people worried about server load. Night Gyr (talk/Oy) 21:31, 14 February 2007 (UTC)[reply]

We already have a Wikipedia:Don't worry about performance. --cesarb 01:05, 15 February 2007 (UTC)[reply]

This is a proposal that has been discussed a little on individual talk pages for certain templates found in Category:Religion navigational boxes. Currently, there are a number of pages dealing with criticisms of specific religions, such as Criticism of Christianity, Criticism of Mormonism, Criticism of Islam, Criticism of Judaism, Criticism of Hinduism and Scientology controversy. Over the past few months, some of these religion's navigational templates have included a link to the corresponding criticism page, and some have removed the link. There were proposals to include the link in religion A's template because it was found on other religions X, Y, and Z, and there were proposals to remove the link in religion B's template because it was not found in other religions W, V, and U. I think it is strange when one group of templates are using another set of templates for precedent, and vice versa. So I am proposing that we include a link to the top tier Criticism page in a religion's navigational box, if applicable. I believe that including a link such as this gives a more holistic view, falls within the NPOV policy (and because it is only one link, isn't giving undue weight). If someone is researching a religion, it can be helpful to read about common criticisms, and therefore I believe it is helpful to be included in the template. I am coming here because a respondent at Template talk:Hinduism small encouraged me. What do other people think about including a critical link in religion navigational infoboxes? Thanks for your consideration.-Andrew c 03:03, 15 February 2007 (UTC)[reply]

Definitely. We're here to provide knowledge on all aspects of a subject, not just to promote a particular viewpoint desired by the subject itself. Tyrenius 03:08, 15 February 2007 (UTC)[reply]

I'm the one who encouraged Andrew c to ask about this here - but what I was suggesting was that he enquire about putting criticism links on all WikiProject templates, not just Religions. I don't think it's a necessary or helpful idea. But if it's going to be a new policy, it should apply to all Projects, not just Religions—for example, Projects templates for Countries and Ethnic Groups (to point out a couple of examples that might be as controversial as Religions) should be included in this policy if it's going to be a new policy. ॐ Priyanath talk 03:24, 15 February 2007 (UTC)[reply]

Well, there are some things that aren't going to have any sort of criticism article, but for the ones that do, we certainly should require a link to them. -Amarkov moo! 03:29, 15 February 2007 (UTC)[reply]
Hello, law of unintended consequences. I suppose it's not overly important, as there will never be a policy regarding what one should or shouldn't put in one's infoboxes and nav templates. Opabinia regalis 05:41, 15 February 2007 (UTC)[reply]
It's an arguably valid interpretation of WP:NPOV that you should be, and I don't see any unintended consequences. -Amarkov moo! 05:45, 15 February 2007 (UTC)[reply]
That I should be what?
I suspect the criticism links do belong in the religion navboxes. But the way to implement that is to figure it out with the religions projects and editors, not to try making a general policy on the specifics of navbox contents. Opabinia regalis 06:12, 15 February 2007 (UTC)[reply]

It definitely sounds like they should go in. To not include them for some silly reason would be a whitewash. NPOV and all that ... Cyde Weys 06:07, 15 February 2007 (UTC)[reply]

Thanks everyone so far for the comments. I apologize to Priyanath for not fully understanding the comment to me, and not making the proposal more broad. I do not believe that there is any policy that specifically restricts the use of critical links in infoboxes. Template:Abortion has links to pro-life and controversy/debate pages. I also do not see an abundence of criticism pages dealing with the vast majority of infoboxes (take template:Pokémon species, is there a "criticism of Pokénon species" article?) I think we should stick to discussing the religion navigational boxes (unless we have specific examples of other neglected criticism articles).--Andrew c 06:37, 15 February 2007 (UTC)[reply]
Valid criticism articles should be included in any navigation structure about the topic, and sometimes in "See also" sections for articles that don't have nav templates. If the criticism page is bogus/unfair,. edit or have it deleted, don't sweep it under the rug. That's almost textbook POV editing. -- nae'blis 16:31, 15 February 2007 (UTC)[reply]

I think including criticism articles is probably required according to policy. Criticism article are already on questionable ground when it comes to content forking. If we kept criticism off the template, we would be permanently severing part of the complete article on each religion. Indeed, any topic with a "criticism" article must include it to maintain unity and avoid the worst problems associated with POV forks.

This is not an endorsement of criticism articles, but if we must have them, they should be well-linked to their subjects. Cool Hand Luke 22:55, 15 February 2007 (UTC)[reply]

Wikipedia:Places of local interest

There is discussion on its talk page as to whether or not this is a consensually-supported guideline. Comments are welcome. >Radiant< 17:07, 15 February 2007 (UTC)[reply]

Wikipedia:Attribution: Merger of Wikipedia:Verifiability and Wikipedia:No original research

Wikipedia:Attribution, a proposal to subsume and replace Wikipedia:Verifiability and Wikipedia:No original research, is ready to be implemented. Please review the document and discuss any problems on the talk page. —Centrx→talk • 23:08, 16 February 2007 (UTC)[reply]

Proposal / RfC: Donation appeal ideas

I'd like us to come up with a better text for the permanent donation appeal to unregistered users than the current one. You can contribute ideas at Wikipedia:Donation appeal ideas.--Eloquence* 04:48, 17 February 2007 (UTC) [reply]

"Older"/"Newer" navigation for watchlist

Would it be possible to add navigation to the watchlist, similar to the "History" and "Contributions" pages? With large watchlists that feature very active pages, the "last x changes" setting in "Preferences" can often fall short of when you last logged in. That means going into the preferences, changing the size of the watchlist, and then either having to go back and reset it OR forgetting (and then facing the increased load time every time one calls the watchlist). Thoughts? --Ckatzchatspy 03:18, 9 February 2007 (UTC)[reply]

Do you have the option to collapse multiple changes to the same page turned on? Night Gyr (talk/Oy) 18:51, 9 February 2007 (UTC)[reply]
Thanks for the suggestion. I did use that feature for a while, but found that I was able to do more with the non-collapsed version. (It often saves a lot of time in checking frequently updated pages, as you can see the context for edits rather than just the last one.) I would think that adding navigation shouldn't be all that difficult, given that the code already exists for the other pages. However, if there is some reason that it isn't doable, another option might be to add an "override" feature on the Watchlist page (much like the "Last 50"/"Last 100"/etc. choices on History pages. That way, you could choose a temporary increase in the number of edits, without having to adjust your default setting. --Ckatzchatspy 19:49, 9 February 2007 (UTC)[reply]
Umm, there is a manual override at the top of the watchlist page. It says "Show last 1 | 2 | 6 | 12 hours 1 | 3 | 7 days all". ;-) --Quiddity 01:15, 11 February 2007 (UTC)[reply]
Tried that. It limits your watchlist, if the setting goes too far back for your liking. However, it doesn't extend it, which is what I would like. If, say, you're set for 500 changes, and that times out 18 hours back, adjusting the settings you mentioned still only goes back the same amount of time.
Ah, well that's probably more a WPtechnical question. Or try searching bugzilla. --Quiddity 19:28, 12 February 2007 (UTC)[reply]

A while ago [2], I suggested making the watchlist a regular page, made up entirely of links, so that checking it would be a "Related changes" thing for the watchlist page, and so that editing it would be like editing any other wiki page. Naturally, this would include the page having a history. Clicking "Watch" would add a link to the desired page at the bottom; clicking "Unwatch" would replace any link by an empty string. Users could freely edit their watchlist, e.g. to organize it by grouping the links under various headings.--Niels Ø (noe) 10:22, 18 February 2007 (UTC)[reply]

TfD structure to match AfD

I would like to propose that the TfD process be restructured to match the AfD process. For example, discussion about an article's deletion is relegated to its own subpage of AfD. The discussion about a template is currently done within the TfD page itself. Therefore, monitoring a template discussion is more difficult than monitoring an article discussion, since Watching the page causes you to see a change made to any template deletion discussion. Making the two processes uniform and consistent will also aid editors who make submissions to both projects. There is some discussion from Jan 2006 and a little bit more recently. - grubber 17:30, 14 February 2007 (UTC)[reply]

  • The reason it's set up like this is because the mailflow on AFD is an order of magnitude larger than on TFD. >Radiant< 17:32, 14 February 2007 (UTC)[reply]
    Agreed that the volume on AfD is larger. But, what do we lose by changing the process? I can think of plenty of advantages to the change, however. - grubber 17:35, 14 February 2007 (UTC)[reply]
    • What we lose is that both nominating and closing become more complex and less efficient. Note that TFD is already "in line" with CFD, SFD, RFD and DRV, so bringing it "in line" with AFD for standardization is not such a useful argument. >Radiant< 17:43, 14 February 2007 (UTC)[reply]
      Opening an AfD isn't that hard, or there wouldn't be a hundred of them every day. I don't know how difficult it is to close an AfD as opposed to a TfD, since I haven't ever done it. But in any case, assuming you're right: We would make two edits harder, but make the actual process of voting, watching, debating, and stating easier on all the other editors who participate. It seems like a useful tradeoff. Further, I would argue that making the whole XfD more uniform would be a good thing. Clearly, because of volume, we can't change AfD. Let's change the others to match it instead. We lose so little and gain so much. - grubber 18:45, 14 February 2007 (UTC)[reply]
Given the volume of AfD over TfD, I think it makes sense that it behaves differently. That said, I have no real strong feelings about this one way or another... EVula // talk // ☯ // 18:53, 14 February 2007 (UTC)[reply]
I've done a couple of AfDs nominations over the past year, including one in the past week. I've always been struck by how many steps there are to the process, and how kludgy it feels, but it's definitely gotten better. Still, while I favor, in concept, changing the whole XfD to be consistent with AfD, I can see the reason to oppose the change until it's agreed that the AfD nomination process is as smooth and painless as possible. (XfD closing, on the other hand, tend to be done by those who do it a lot, I'd guess; an extra step or two for such closings wouldn't seem to me to be a big daal.) -- John Broughton (♫♫) 19:25, 14 February 2007 (UTC)[reply]
(indent reset) My main issues are: (1) Using subpages (like on AfD) is useful to voters. (2) Making the XfD pages more uniform is a good thing (admins and users would need to know only one procedure to use for any XfD page). I don't have an opinion either way if AfD is the "best way we can think of". If not, let's design the "best way we can think of". Once we have a good method, then let's adopt the procedure to XfD as best as possible. - grubber 20:34, 14 February 2007 (UTC)[reply]
I see no reason to change other XfD processes to match AfD at this time. Radiant has my opinions already outlined above. -- nae'blis 21:01, 14 February 2007 (UTC)[reply]
If uniformity of process is what you're after this matches most XfD types and AfD is the odd one. Separate pages for every nom make sense when there is a high volume and therefore a high likelihood of edit conflicts, or watchlisting the page is impractical because of so many changes. But separate pages impose a workload/complexity cost. They definitely make sense for AfD, but I don't think TfD needs them right now. —Dgiest c 21:12, 14 February 2007 (UTC)[reply]
Do you really believe the workload is that much higher? - grubber 15:59, 15 February 2007 (UTC)[reply]
The attendance is so limited that any good means of attracting more users would help. Having a similar structure would increase useful cross-references to topics that might be of more general interest. And, how does the use of subpages add to the workload or complexity. It's just section editing.DGG 19:33, 15 February 2007 (UTC)[reply]
When I say "workload", I mean the effort required per entry. Higher volume is higher work, but my question is: Does using subpages increase the amount of effort significantly compared to the status quo? - grubber 20:02, 16 February 2007 (UTC)[reply]
I think it does, yes. It requires at least three edits/nine pageloads to make an AFD (due to the three steps), and most other processes (TFD, RM, DRV, etc) can be done in two edits if you're careful. Also, keeping them on one page makes multiple nominations concomitantly easier to perform. -- nae'blis 20:12, 16 February 2007 (UTC)[reply]

Main Page - "On This Day" Improvement Suggestion

Hi,

I use the Wikipedia main page (http://en.wikipedia.org/wiki/Main_Page) as my home page. But because I live in New Zealand our timezone means that for more than half of any day (midnight until early afternoon) the "on this day" section is always a day behind NZ time and showing facts for yesterday. At the bottom of the section there are quick links for the last three days (ie "recent days"). What would be great is if you also had a quick link here for "tomorrow", being today for us in New Zealand. ie. currently I have to click "more anniversaries" and find the date from the full year calendar.

Thanks for considering my suggestion.

Regards, Matthew Blair Wellington New Zealand.

You can use Main Page/Tomorrow to see what tomorrow's main page will look like. However, if you are interested in adding a link to this page from the main page, you might want to ask at Talk:Main Page. Tra (Talk) 21:37, 15 February 2007 (UTC)[reply]
I wonder if it would be possible to refine the software to implement this through preferences, though I doubt it'd be a high priority for the developers. See Wikipedia:Bugzilla for how to file a request for a software improvement.--Pharos 02:13, 18 February 2007 (UTC)[reply]

IP Userpages

I think IP userpages should get information known about the IP posted on them, this could prove useful for an admin when determaining how much a block may effect legit editors, ect. For example it could contain whois info, perhaps if it belongs to a lan, or specific computer if know, ect.--RyanB88 18:15, 16 February 2007 (UTC)[reply]

That information's added to the talk page at the moment, when known. There are a lot of IP userpages around at the moment as well (see Special:Prefixindex/User:68. (to take a common IP first number), for instance). --ais523 18:18, 16 February 2007 (UTC)
One can tag a given IP address talk page with info found by clicking the [IP Info] link and copy and pasting the info into the template Template:Ispinfo like so {{subst:Ispinfo|whois results}}. (→Netscott) 18:28, 16 February 2007 (UTC)[reply]
Perhaps IP pages can automatically be generated and tagged? Koweja 18:24, 17 February 2007 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive&oldid=110837447"