ebooksgratis.com

See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Wikipedia:Village pump (proposals)/Archive 10 - Wikipedia, the free encyclopedia

Wikipedia:Village pump (proposals)/Archive 10

From Wikipedia, the free encyclopedia

Village pumps: PolicyTechnicalProposals (persistent)AssistanceMiscellaneous

Contents

[edit] lists of academic (and other) sources

i think it be useful to have a list (or more likely several lists) of people who own or have access to a particular book or books, the list could be organized by author and then title with the usernames of anyone who has said book added afterwards (voluntarily) like a signature. this would help authors help each other with fact checking and stuff. SJMNY (talk) 22:54, 18 December 2007 (UTC)

I cannot imagine how that would work, unfortunately. It would be nearly unmaintainable. - Rjd0060 (talk) 23:00, 18 December 2007 (UTC)
Welcome to the unimaginable - [[Wikipedia:WikiProject Resource Exchange. Johnbod (talk) 02:15, 19 December 2007 (UTC)
wow thanks. i couldn't find that by searching, are most people aware of this?SJMNY (talk) 02:16, 19 December 2007 (UTC)
It's hard to find things here because most people don't know about the index. For example, that also lists the Wikipedia group at LibraryThing.com. -- John Broughton (♫♫) 13:38, 19 December 2007 (UTC)

[edit] random article for various subject areas

I think their should be a random article generator for various subjects. e.g if you wanted a random article about maths you would go to the math's portal and click on the random article link their. Ziphon (talk) 04:50, 13 December 2007 (UTC)

I support. I also feel there should be a way to pick a random featured article and a random FA/GA article. Perhaps we can have a random article generation page. Subject wise randomization can be done by wikiprojects. Arman (Talk) 08:17, 13 December 2007 (UTC)
Given the limited number of FAs (I won't speak to GA's), it doesn't seem that difficult to set up a random article page - see this, for example: Portal:Middle-earth/Random-article.
As far as getting readers to it, perhaps a link in the "Today's featured article" section of the Main Page, so the links at the bottom of the page would then read Archive – By email – More featured articles - Random featured article -- John Broughton (♫♫) 19:53, 13 December 2007 (UTC)

See bugzilla:2170. It is possible to get a random article from a category (e.g. Category:FA-Class articles), but for performance reasons this is disabled on Wikimedia wikis. GracenotesT § 20:31, 13 December 2007 (UTC)

Categories are not consistently organized here. It would be a better idea to get random articles under the banner of a given WikiProject.--Pharos (talk) 05:20, 21 December 2007 (UTC)

[edit] Important article statistics on mainspace

One of the main criticisms of Wikipedia is that its articles are often not reliable. Whenever Wikipedia or Wikipedia fans try to defend this complaint, they generally stress that the reliability of a Wikipedia article can be checked with a few simple tests. Like:

  • If the article has verifiability / factual accuracy / neutrality tag - it is likely to be unreliable. In such cases it is advisable to consult the discussion page along with the article page.
  • The older the article, the higher the chances for the article to be stable and reliable.
  • An article on which several unique editors have contributed is likely to be more reliable than an article edited by only one or a few editors.
  • Article subject to a very recent change or high frequency of changes in recent time may have lower reliability as other editors have not yet got the chance to validate these changes.

All these sound very simple to experienced Wikipedians, but most new comers are not familiar with the way to check all these.

That’s why I propose the following:

There should be a small but prominent box (with small font) showing the vital information of the article at a visible location of article mainspace. It may be in article header, footer or even right below the Wikipedia logo on left hand side. The box should contain the following information:

  1. Whether the article is an FA or a GA. Omit this line if it is not.
  2. Whether the verifiability / factual accuracy / neutrality / notability of the article is disputed. The "disputed" word may be linked to the talk page. If there are no disputes, this line should be omitted. Also if this is implemented, the "ugly" tags that now appear at the beginning of articles should all be removed.
  3. How old is the article and when it was last edited.
  4. How many unique editors have contributed to the article; and
  5. How many edits it received in last 24 hours. May omit this line if there were no edits in last 24 hours.

Although I have proposed 5 sentences, with the proposed omissions, for most articles the number of sentences will come down to 2-3.

These are the vital information that a reader should know to decide how to use an article or to what extent the article can be relied on. So I think these information belong to the article page. Arman (Talk) 06:28, 13 December 2007 (UTC)

This is not a bad idea. Actually, it is a good idea. Anecdotally, I know from my experience with casual non-editors who use Wikipedia that they have no idea about checking the 'discussion' or 'history' tabs. They simply read the article. These people would notice an info box of the type proposed - and I suspect that they are by far the most common users of Wikipedia. Cheers! Wassupwestcoast (talk) 13:55, 13 December 2007 (UTC)
It's definitely better than the huge ugly banners that are there now.
However, I have a suggestion. The current banners added to protected articles are ugly (that's why some administrators replace them with padlocks). Perhaps this could also be mention in the box (and omitted if the page isn't protected).
Furthermore, if consensus is gained, maybe we could get a bot to transform the current banners to this compact box.
What I'm, unsure about is the placement of this box. I don't think a footer is enough of a prominent place, as you pointed out, this is an important thing for users to know. My ideas are the toolbox (along with interwiki links), but I'd prefer it in the header. Puchiko (Talk-email) 14:48, 13 December 2007 (UTC)
Good idea in concept but I suspect that most readers wouldn't have any idea what to make of those statistics. Do you think it would be feasible to boil down the statistics to a single number: a reliability rating? Sbowers3 (talk) 17:01, 13 December 2007 (UTC)

Wikipedia does not make disclaimers about the reliability of its articles, and a heuristically based disclaimer may cause more harm/speculation than good. As Sbowers3 said, most readers might not understand (and even make incorrect guesses) about what the statistics mean. The 24 hours line may be a problem, since that cannot be cached – I'd imagine it must be calculated every time a user visits a page. The reason why Wikipedia's servers are efficient is because they cache (hold copies of) pages for the next time someone requests it. he last-modified date can be seen at the bottom of the article, in the white box with the orange border. The rest of the statistics can be cached, it looks like, but the database load of it all might be too much. GracenotesT § 17:55, 13 December 2007 (UTC)

It sounds like a great idea in concept, but technologically, as Gracenotes points out, it is costly. I think we might be better off abandoning this in favour of using the effort towards implementing FlaggedRevs, which would probably be more effective anyway. :) Nihiltres{t.l} 18:24, 13 December 2007 (UTC)

At the least it might be an informative thing for our casual readers if we started putting {{ArticleHistory}} on the front side of our articles.--Pharos (talk) 06:38, 14 December 2007 (UTC)

[edit] Simplifying proposal for technical feasibility

Thanks everyone for the feedback. In general there seems to be a consensus that this is a good idea - at least better than the "ugly" tags we have now. As far the article rating suggestion is concerned, we should rather allow the readers to interpret the "facts" given in the box, than giving a conclusive remark on the reliability of the article, which would be too subjective and debatable. So far the strongest objection to this has been on technical limitations. I strongly feel technical limitations tend to be short lived. What seems impractical today may become very simple in few year's time. But still, let's think whether the following suggestion makes it more practical given today's technology: Let's have the box with the first 3 points: the GA-FA status, The quality tags and the first & last edit dates. Then we have a (show more) link which, if clicked, will retrieve the two more processing-capacity intensive points - number of unique editors and number of edits in last 24 hours. May be we could think of a few more points. Does it sound more practical now? Arman (Talk) 08:58, 14 December 2007 (UTC)

It is worth mentioning that there are academic research projects on-going looking at client / browser side solutions to the article credibility problem. You may wish to check out these external sites: U of California Santa Cruz Wiki Lab' Wiki Trust Coloring, PARC's Wikidashboard and an article in The Chronicle of Higher Education. Cheers! Wassupwestcoast (talk) 17:34, 14 December 2007 (UTC)
Yes, in principle, I think that a substantial part of the information that is currently "hidden" on the talk page should also appear in the mainspace, where it would be accessible to the wiki-unsavvy (the great majority of our readership).--Pharos (talk) 05:24, 21 December 2007 (UTC)

[edit] Proposal regarding sunset and sunrise times

If one visits http://en.wikipedia.org/wiki/December_19, for example, one will see more news about the anniversaries and deaths on that day, but nothing about sunrise and sunset times for that day. Do you think that these dates could at least include dates for Greenwich Mean Time?This would, I am sure, interest some people. The article on sunsets has a useful external link, so the times should not be too hard to fnd. ACEOREVIVED (talk) 20:52, 18 December 2007 (UTC)

Which year should we provide the times for? It changes. --Carnildo (talk) 21:12, 18 December 2007 (UTC)
Sunrise and sunset times for the same day vary based on the observer's position (east–west) in the time zone, distance from the equator, and local terrain. I don't think that would be particularly useful if we single out a single location as the de facto world sunrise and sunset time.—Twigboy (talk) 22:43, 18 December 2007 (UTC)
There's no computer code to automatically detect what time zone you are in?Jerse (talk) 00:34, 19 December 2007 (UTC)
It's not the time zone that's the issue - it'll be the same at 75°W in Eastern time as at 90°W in central time, if you're at the same latitude. The problem is when you're at 67°W; and latitude also matters. —Random832 15:03, 20 December 2007 (UTC)
In some places, like Singapore and Ecuador, sunset and sunrise times are about the same year round. It is about 6:30 am and 6:30 pm. Archtransit (talk) 19:32, 20 December 2007 (UTC)

[edit] Removing user names from search engines

I brought this up at VP (technical) (but this particular thread was started by someone else, moot point), and was referred to this page. I was wondering what is the point of having user namespace pages show up in search engines and can they be removed from such searches?

I reason that: A) if someone types in "Old Hoss", the last thing they want is me (#4 on Google [1] and #2 on Yahoo! [2] with my test page showing #5); and B) if they did want me (as a user), they could go to Special:Listusers. The average lay person typing in "Old Hoss" in a search engine most certainly does not want me (they probably want Old Hoss Radbourn, whom I was not thinking of when I chose this name, although I am a 19th century baseball fan).

I would propose that user pages and user talk pages (and all accompanying subpages) be exempt from search engines. I was told it could be added to "robots.txt", even though I have no idea whatsoever what that means. Thoughts?--Old Hoss (talk) 02:44, 19 December 2007 (UTC)

I have asked for this also several times. the part of WP that should be indexed by outside search engines is the mainspace and only the main space. What we are building is the 'encyclopedia, the apparatus is secondary. DGG (talk) 02:49, 19 December 2007 (UTC)
Except we like to use google to search wikipedia for internal things, because Mediawiki search is quite useless. Blocking searcg engine caching would make that impossible. Prodego talk 02:55, 19 December 2007 (UTC)
A better solution would be for Google and Yahoo! to automatically exclude User namespace pages when searching wikis. But we can't fix that on our end. —Remember the dot (talk) 02:57, 19 December 2007 (UTC)
To Prodego: but isn't Special:Listusers separate from Mediawiki search?--Old Hoss (talk) 03:00, 19 December 2007 (UTC)
Yes, but that is just a list. I mean, if I wanted to search user pages for, say, Miami, I could use Google Search. Obviously that is so simple Mediawiki search could probably do it, but you get the idea. Prodego talk 03:05, 19 December 2007 (UTC)
Gotcha. So, just to be clear, one flaw in this proposal is the current weakness of Mediawiki search. Therefore, it would follow, that the question would be which one is more important presently. I imagine eventually Mediawiki search will be improved (I think I read something about that somewhere), so maybe this proposal should be packaged with that. So now I must ask, if this was proposed previoulsy, why did it fail then, and is this worth pursuing again now?--Old Hoss (talk) 03:14, 19 December 2007 (UTC)
Remember the dot: we can automatically exclude the user namespace, using certain HTTP headers or equivalent HTML meta tags. I would strongly support using the noindex meta tag on all user and user talk pages. — Carl (CBM · talk) 03:16, 19 December 2007 (UTC)
I would strongly oppose that until a decent internal search is available. Once that's done, certainly, outside searches can reasonably be limited to article space. —Random832 14:37, 19 December 2007 (UTC)
How often is it actually necessary to search for text content in user space? We do have a search engine that works well enough for the rare occasions this is needed. — Carl (CBM · talk) 14:51, 19 December 2007 (UTC)
Well enough? I'd disagree there. GracenotesT § 18:02, 19 December 2007 (UTC)
I dunno. I searched for "Removing user names from search engines" on MediaWiki and on Google. Google hasn't indexed it yet, but MediaWiki returns the hit. (Neither matches "Well enough? I'd disagree there." as of press time.) – Quadell (talk) (random) 18:21, 19 December 2007 (UTC)
For text search, MediaWiki is great – that's Lucene's strongest suit. For a more semantic search, however (backlinks &c), Google is better. MediaWiki has backlinks built into it, which it doesn't utilize for searching, as far as I know. GracenotesT § 19:56, 19 December 2007 (UTC)

Blocking search engines from indexing User: and User_talk pages is certainly possible from a technical perspective. However, doing so would be a large change for this project (i.e., the English Wikipedia). For this proposal to get serious consideration and discussion, I suggest starting either an RfC or a separate Wikipedia: page discussing the benefits / detriments of the proposal and then getting community discussion and consensus. Cheers. --MZMcBride (talk) 20:20, 19 December 2007 (UTC)

I've often used external searches to find discussions, templates, and other things in user and project namespaces. An idea, would it be possible to place noindex as some kind of opt-in option for the short term? Users concerned about their pages being indexed could put a tag on their specific pages. -- Ned Scott 20:26, 19 December 2007 (UTC)

I've thought of that before – having a flag for noindex and nofollow – and such a feature would be useful to replace courtesy blanking. However, it might cause more drama than it's worth, simply because of the fact that it's useful for courtesy blankings. We have enough edit wars about that, let alone page-tagging wheel wars on controversial pages :) GracenotesT § 20:33, 19 December 2007 (UTC)

The WMF is in such a position that I don't think it would be unreasonable for them to just ask Google to drop the pagerank for the userspace pages. They certainly have the ability to do so. User pages showing up as the top result is not helpful for anybody (except spammers who dump crap on their userpages and don't get noticed by RC patrollers). We could then just tell everyone but Googlebot to not index userpages at all and exclusively use Goog.... hmmmm, this is the beginning of a bad idea, isn't it? --- RockMFR 06:02, 21 December 2007 (UTC)

Maybe a suggestion to Google would be have their search algorithm only search the Mainspace for general web search. However, if the "site:" command is used to only search within a website (say Wikipedia as a prime example), then return all results regardless of namespace. --Breno talk 11:40, 11 January 2008 (UTC)

[edit] Forums

You guys should definatly have a forums... It would also keep vandalism down. because the main reason people vandalize is because they are bored. If you would like i would make a forums for you. All you have to do is do the financing unless you want to make a free forums first to see how it works out>>>>>> i recomend www.setbb.com

Please take this into consideration>>>>>>> Mr_KC (talk) 17:32, 19 December 2007 (UTC)

I have my doubts that making a chat forum would reduce vandalism. Indeed, I see the possibility of an opposite effect. Given the huge availability of all manner of chat sites and forums online, I don't think we would be redirecting their boredom; if their desire is to chat, rather than vandalize, they certainly know where to go. What we would be doing is making Wikipedia attract users to the site for activities unrelated to building the encyclopedia and, thereby, tacitly approve such off topic activities, which could carry over to all areas. Keeping the encyclopedia entirely separated from blog/myspace/social networking is important to our health and reputation. Wikipedia is not a chat forum or a play ground. I think this would be the equivalent of putting up an arcade in the front lobby of a sober institution in the hope that doing so would somehow distract and deter children that sometimes spray paint the walls at night—not likely and it would function as an attractive nuisance.--Fuhghettaboutit (talk) 20:23, 19 December 2007 (UTC)
As fugheetta says, the internet is HARDLY for want in terms of places to get together and chat. What the internet DOES have a limited supply of is reliable, free-to-edit encyclopedias. Lets keep Wikipedia that, and let the chat sites be chat sites. --Jayron32|talk|contribs 02:21, 21 December 2007 (UTC)

[edit] Per page IP range blocking

I'm listing this here to see if other people think it might be a good idea because implementing would require both a technical and a policy change. Generally speaking, I've noticed that the most persistent IP vandals tend to have a narrow focus for their vandalism and use an ISP that gives them a different IP each time they log on to the internet. Because such ISP's also tend to have non-vandal anonymous users, simply blocking the whole range of IP's isn't practical nor desirable, but if such ranges could be blocked on specific pages it would at a minimum allow for a more specific block than simple semi-protection, and because it is more specific, perhaps it would be possible to leave it in place for longer periods of time. Caerwine Caer’s whines 21:59, 20 December 2007 (UTC)

This is an interesting idea. I have no idea what it would take to implement it, but I think it is a neat idea. --Jayron32|talk|contribs 02:17, 21 December 2007 (UTC)

[edit] Simple English Wikipedia

This is something that definitely needs to be addressed. The English Wikipedia needs to more recognize the Simple English Wikipedia, not just list it in the in other languages bar on the side, hidden with the other languages alphabetically where only the most dedicated Wikipedians know of its existence. Imagine a little elementary kid needing to do a report on the American Revolution. He goes to Google or Yahoo! and types 'American Revolution'. Of course, the first result is Wikipedia. He clicks on it but, he cannot read its complex english. Wouldn't it be nice if he can actually read it (since we already have a simple english wikipedia). I think that adding a simple template on all English Wikipedia articles that have a Simple English equivalent similar to this one

at the end of the article under See also or External links, should solve the problem for the most part.

Why else is this good?

  • helps the growth of the simple english wikipedia
  • helps young people trying to learn
  • no point in having simple english wikipedia if a young kid cannot even find the link

Hopefully this gets implemented somehow.-- Penubag  05:49, 25 November 2007(UTC)

SEWikipedia (and all other language wikipedias) are separate projects. "We" (as in Eng Wikipedia users) are responsible for neither their content nor their advertising. I don't see why that one particular project should get extra attention. - Koweja (talk) 06:38, 25 November 2007 (UTC)
Read the explanations above why having a SE wikipedia link on English articles would be very useful. Simple English is a part of English even though a seperate project. I just recently learnt about the SE Wikipedia (about a year and a half ago), and had I known of it sooner, I may have been able to use it to its full extent. Also Google French won't turn up Wikipedia english articles so we don't need an extra notification on a french wikipedia page for english articles. And sure, maybe we aren't responsible for them, but just think how much that could help people, everywhere, both kids and English learners. I think just because they are a separate project, it doesn't mean we shouldn't help what can help everyone.-- Penubag  07:03, 25 November 2007 (UTC)
Agree with Penubag. Koweja, You shouldn't put a limitation of help from us users to just the English Wikipedia. Actually, you should promote other users to join other Wikipedia's if they understand the language. We are all under the Wikimedia Foundation, and even if we are all different websites, we still serve the common goal of a Free reliable informative encyclopedia. Lex T/C Guest Book 07:20, 25 November 2007 (UTC)
That's his point. We're all under the Foundation, so why should the English wikipedia give special treatment to a specific other project? -Amarkov moo! 07:32, 25 November 2007 (UTC)
Well, we link to wiktionary even though that is a separate project.-- Penubag  09:16, 25 November 2007 (UTC)
Because Simple english is derived from English. So, we are like a parent Wiki to them. Thus, it should get special treatment. Lex T/C Guest Book 07:34, 25 November 2007 (UTC)
Yes, and besides, it can greatly help learners. SE should get special treatment because it helps people looking for an article in the same language. Is that not what wikipedia's main goal is based off of? We need to expand our focus not only who are extremely well fluent and knowledgeable in English, but also on the younger generation, since those are the people that are going through school and those are who most need information in which they can understand. "Knowledge is the result of the cumulation of youth, which is where the doors must be first opened"-- Penubag  07:38, 25 November 2007 (UTC)
I'm kinda unsure. To begin with, I really don't think the English Wikipedia is that hard to comprehend for 9-year-olds. The articles are usually written quite clearly. This is question almost impossible to answer, but I'll ask it anyway-How many of those who come to the English article find it too hard to read? Sure, little elementary kids use Wikipedia. So do college students. So do adults. Another unanswerable question-How many of our readers will benefit from the link, as opposed to how many will find it annoying/distracting/useless/cluttering?
Finally, the link to the simple English version might not be that useful, it's quite short, POV and has stunning pieces of prose such as ...the colonies totally refused to cooperate with this law. Puchiko (Talk-email) 12:00, 25 November 2007 (UTC)
Believe me, if you are 9 years old and trying to read an article on the String theory, it is very hard to understand. And whose to say that the SE wikipedia won't grow once we add the templates to English pages. I believe it can come out as good as any wikipedia once it gets more attention. The reason why SE is "quite short, POV and has stunning pieces of prose" is because there are barely any people knowing of its existence, let alone know how to edit an article.-- Penubag  21:13, 25 November 2007 (UTC)
Are you sure, that a 9 year old kid will understand string theory in SE wikipedia. :) Well perhaps, you are right, reading string theory here, the kid has two difficulties - to understand the difficult english (per kid's standards) and then to decipher the concepts of string theory itself. Atleast the first task would be diluted in the SE wikipedia. But I was wondering how you would convert the intimidating terminology of the theory itself in SE for kids to grasp it better. - DSachan (talk) 21:34, 25 November 2007 (UTC)
  • Support for Penubag's proposal. English is more than a mother tongue, it is an international communication tool, as well, so it needs a different treatment compared to the other languages. I use English as a foreign language and I think Simple English Wikipedia is a useful project which can become an important information source for the non mother tongue English speakers. At the present, it's articles are stubs, missing or not well written, but it can change in the future. I think that it should become the same rich and high quality than any other Wikipedia. On the one hand, the articles of the English Wiki should be transported to it in a simplified form (simplified linguistically but not for their content!), on the other hand non mother tongue English speakers who use English as an international tool, should write articles in it. (You can maybe understand the difference between my simple international English and the real English of Luna Santin a mother tongue person here: [3]) Back to our topic: I think if there is an article in Simple English Wikipedia which is high quality fot its content, it could be linked from the correspondent English Wikipedia article as Penubag suggests. --Hunadam (talk) 20:45, 25 November 2007 (UTC)
  • Support yes, we could make a team that copy-pastes English Wikipedia articles into Simple English Wikipedia, and just change the hard words to words that everyone can understand.-- Penubag  21:07, 25 November 2007 (UTC)
  • Sorry, but no. Just because there's a tight relationship between English and Simple English doesn't mean we should be pushing their articles. There are several other language pairs that are closely related (there are 9 variants of Chinese you can choose from in the preferences, for example). At most, I'd support pushing [[simple:]] interwikis to the top of the list (similar to how the Hebrew Wikipedia puts en: interwikis at the top), but outside of that, I think it'd be detrimental to the project. EVula // talk // // 21:38, 25 November 2007 (UTC)
No, not just because there is a tight relationship between English/SE, but for the benefit of young readers. I don't see a the purpose of having a SE wikipedia if no one knows about it. I don't see what's so wrong with letting a bot add a SE template to our english articles. Everyone can benefit from that, no one can seriously be so hurt from it that they don't want to help younger and english learners.-- Penubag  22:45, 25 November 2007 (UTC)
  • Support The number of non-native English speakers is two or three times the number of native English speakers. If you add a link to the Simple English Wikipedia, it will help the non-native speakers and young children. Also, more people will write articles in the Simple English Wikipedia. Just like if there is a Simple Chinese Wikipedia, I think the Chinese Wikipedia should link to it (but there is no Simple Chinese Wikipedia). --Kaypoh (talk) 09:45, 26 November 2007 (UTC)
  • Support. Unfortunately, there is not Simple Chinese Wikipedia. Maybe we could request it. bibliomaniac15 00:25, 27 November 2007 (UTC)

So is this enough support for the creation of a bot that will place SE templates to English articles??-- Penubag  03:41, 29 November 2007 (UTC)

I hope not; not only am I personally against this, but I have grave concerns about how it will look in a real article. Placing the "SE" link above the infobox and other information will make the page look like crap. We don't need to clutter up of our own articles. EVula // talk // // 15:50, 29 November 2007 (UTC)
You don't understand. The template will be placed way below at the bottom at the page, near external links/See also, right above that Wiktionary Link. Only the people who need the link shall see it.-- Penubag  16:41, 29 November 2007 (UTC)
I'm somewhat opposed to this too. Currently we use templates like the Wiktionary and Commons link templates to direct people to where they can get more information, not similar information in a different format. And I would think that you need a wider consensus than this to put a template on 21,000 articles. Mr.Z-man 18:16, 29 November 2007 (UTC)
How much wider can my consensus get? In case you want a sum of all the advantages/dis you can just read this: >It will help everyone from highschool (where new concepts are introduced) down (and maybe up too, kids and English learners included >It will help improve the quality and quantity of the Simple English wikipedia >It will get SE out of the in other languages bar and to somewhere where kids can find the link instead of searching through an alphabetical list >and most importantly for fluent english speakers, it is a quick summary for lazy people (like me) who just can't read an entire article on WWII just to find out which battle turned the tables for the Allies (although stated in English, this important battle is introduced much earlier in SE so it helps at times when readers are feeling lazy) Cons> Nothing at all except maybe a little cluster issue which can be resolved (see my next edit below).-- Penubag  03:31, 30 November 2007 (UTC)
Ah, I was misunderstanding it; however, I still think it'll be cluttered. We currently use that space to direct users to other WMF projects that are of relevance to the article; why would someone scroll all the way down to the bottom of the page, when there's a link on the left within the first two thresholds? It gets cluttered enough with {{commons}}, {{wikispecies}}, and other such templates; drawing a distinction between Wikipedia and Wikispecies is good, as they're separate projects, but it gets considerably less clear once we start adding additional language editions. EVula // talk // // 18:45, 29 November 2007 (UTC)
The reason why we should put the template at the bottom of the page rather than the side is because no one knows that SE is over there on the side (let alone, it's not even another language). Only experienced wikipedia users would know of it's existence (by then SE is not needed for them), which is why it is only two thresholds for you. Simple English can be very informative especially for highschoolers who are learning new concepts and for other young persons or foreigners. Addressing the concern that the See also and External Links may become too cluttered..: Usually it's not that cluttered where adding an additional template makes it so unorganized that we can't even help young readers with an SE link. But, I do see your concern. Maybe adding a smaller template will help this issue, similar to this one:
See ARTICLE in the Simple English Wikipedia
. With this template, young readers alike can go to almost any wikipedia article, type in what they want, and scroll down to the bottom of the page to click the link. It sounds stupid at first, but if you really think hard about it, I think that's what a lot of kids will be doing.-- Penubag  02:56, 30 November 2007 (UTC)
I'm still opposed to this; I've yet to see any evidence that this is helpful other than vague "think of the children"-type hypotheticals. I agree with the overall purpose of the Simple English projects, but only in regards to the greater good of making information more accessible. Creating garish templates to redirect people who may very well not care to be redirect doesn't strike me as a very good idea; the more I think about it, the more I think this would be best served by moving the simple interwiki to the top of lists.
Suggestion: make some temporary versions of a handful of existing Wikipedia articles in your userspace that would illustrate how the template would/could function. Seeing a working example might change minds moreso than imagining it (for example, it could work better than I'm thinking, or it could work worse than you're thinking). EVula // talk // // 04:09, 6 December 2007 (UTC)

Ahh Sorry, I missed this post...as response to your post, every effort made to make simple more well-known is better (such as moving it to the top of interwikis and bolding it. ) However a great substitute for the template, I still believe a template would be better, as it is still more prominent. I will be working some examples on my page and present them when they are done.-- penubag  05:59, 22 December 2007 (UTC)
I think I could support moving it to the top of the interwikis - can we get consensus for this change in particular, since the devs won't do it without a clear consensus?—Random832 14:32, 30 November 2007 (UTC)

For this change in particular? You mean that little template above? Well, as stated many times above, that little template will get the Simple English Wikipedia out of the In other languages bar from the side, where it clearly doesn't belong, let alone, it won't be found be anyone needing it; and it can promote and help the growth of the SE. Hopefully that convinces the devs ;)-- Penubag  08:58, 2 December 2007 (UTC)
To move a [[simple:]] link to the top of the list, you simply move it to the top of the list; interwikis are displayed in the order they are given in the article. No dev involvement needed, but you would (most likely) need a bot to make all the changes. EVula // talk // // 04:09, 6 December 2007 (UTC)
Okay, moving it to the top of the interwikis and possibly bolding it, but I still don't think it would stand out enough, can I have your (since you're an admin in every project) confirmation for the little template thing above? -- Penubag  04:21, 6 December 2007 (UTC)

Support for the proposal, but only if there's a visible link for a guideline to simplification on the SE pages. It is more difficult than many realize to simplify things, so without a guide we might get excessive length from over-explaining, dumbed-down to a point of confusion which hurts the goal of being understandable. I'd like to see the SE pages get special treatment, where a list of un-friendly words are cross-referenced with an internal database that editors contribute to. So if anyone writes an article in SE, the unfriendly words become highlighted in a low-distraction color (vey light gray?) and users can double-check that internal database for whatever alternatives might be listed in pararenthesis next to the un-friendly word. -boozerker 01:12, 01 December 2007 (UTC)

That's a whole new proposal altogether; but, I do agree with you, it would be nice to have-- Penubag  08:58, 2 December 2007 (UTC)

So? Do I have proper support for a bot now? What's my next step? -- Penubag  07:55, 4 December 2007 (UTC)

Support moving simple english wikipedia link to the top of the interwikis and even make it more prominent than other links. Arman (Talk) 03:26, 6 December 2007 (UTC)

Support We need to make Simple Wikipedia easier to find and help it develop. Encyclopedia Britannica has 6 levels of articles, with different levels of difficulty and sophistication. With Simple Wikipedia we can have 2 levels for many articles. With the introductory articles like Introduction to evolution together with Simple Wikipedia we can have some articles with 3. If EB can have 6 levels, can't we have 2 or 3?--Filll (talk) 05:31, 6 December 2007 (UTC)

Oppose Ugh. This is a lousy idea, and an even worse one if someone tires to implement it with a bot. I can't watchlist both the English and Simple English versions of every article that I keep up with, and if you try to prominently link the simple article to the en article, it just blurs the line for readers. Can't we think of the readers? The vast majority of them who wind up at a POV fork on Simple will think they "read it on Wikipeida". There's no need to encourage this. Simple can get the same treatment as the other language wikipedias, and stand on it's own merits, or lack thereof. ➪HiDrNick! 07:23, 6 December 2007 (UTC)

Just because we provide readers with a link doesn't mean you have to watchlist both of them. With the link, it would populate Simple and they would accumulate their own watchlisters. And, you say, "think of the readers", that's exactly what this is about. We are thinking about people who aren't fortunate enough to understand English as fluently as you are. Besides, how much is a little note at the bottom of a page going to hurt anyways?-- penubag  05:30, 19 December 2007 (UTC)

I think not. We already have enough clutter in terms of links to other projects.Geni 03:51, 9 December 2007 (UTC)

Hmmm Some good points Geni, and it could become messy where article splitting, page redirection, and such on regular Wikipedia isn't mirrored on its Simple counterpart. That is a big problem if the two versions are tightly cross-linked. At the same time, the increased readership of Simple means they have healthy population of their own watchlisters, so you don't need much worry there. --Boozerker (talk) 07:47, 9 December 2007 (UTC)

A little tiny template like the one above? that shouldn't hurt at all, and I agree with you as respect to the watchlisters.-- penubag  05:30, 19 December 2007 (UTC)

Oppose Don't get me wrong, I like the Simple English Wikipedia and I've used it on occasion to explain Mechanics of Materials to a 9 year-old... lol. However, Simple English is just another form of English. The Chinese Wikipedia has six types of Chinese, ranging from Simplified Chinese, Traditional Chinese, Taiwan Traditional Chinese, People's Republic of China Simplified Chinese, Hong Kong/Macau Chinese, and Malaysian Chinese. They all appear to be as separate languages when linked properly (however, they have a pull down menu on top next to the "History" tab where they could select again which six versions of Chinese to use. Nevertheless, they are listing all six Chinese forms (max) as different languages, even while in the same article under a different form of Chinese, so I don't see how Simple English and regular Wikipedia needs any more distinction than it already has. - Jameson L. Tai talkcontribs 07:37, 12 December 2007 (UTC)

Yeah, you use the Simple English because you know of its existence, whereas many other people don't. I'm just saying we should make the link more prominent, possibly adding a little template to the bottom of the page. No kid is ever going to find the Simple English link on the in other languages bar on the side.-- penubag  05:30, 19 December 2007 (UTC)

[edit] Expand to more generalized solution

Support, but think it is high time we stop the highly parochial (and more than a little childish) attitude that "they aren't us, so why should we advertise for them". Admittedly, other projects in their early days had some real rough spots... but then so do our article stubs. It's time to revisit those "consensus decisions", if indeed they weren't the normal case... a swarm of the really involved subborning those who have less time to keep up. (Personally, until and unless we have a"quorum floor", I don't believe we've got a mechanism that reflects the claim of consensus. As a project now maturing and stable, that is perhaps a good next step too, but I digress! Sorry.)

Interwiki's are known to many foreigners, and probably nearly totally unknown to newer editors here. Worse, they don't link to our sister sites, many of which are equally unheralded, but would be of interest to our readership. Hell, I didn't know about Simple English wikipedia, until seeing the above, and I've accounts on most sisters! What harm would there to be having a page wide (noprint class) 'banner' above our article proper. It'd be far less controversial to me than those confidence distroying self-inflicted wounds we base on {{ambox}}, that is about every cleanup template out there. Better yet it'd be more consistent to the current state where one sister (wiktionary's {{wiktionary}}) template is tolerable on a page top, at least defacto, and others are in effect insulted by being relegated to "External Links", with other links. I'm personally convinced that this issue is a big factor behind some sister's almost hostile attitude to any idea which originates here... people don't like their hard work to be dismissed, and if the foundation is funding them, I say they deserve a little prominence and acknowledgement here!.

Have such a banner template link to whichever sisterpage handles the same topic, wikibooks, wiktionary, wikiversity, the commons (may need two entries sometimes, given atlases), wikiquote and other content sites (admittedly, meta and mediawiki will hardly ever be linked, but they are administrative or source repositories, not content sites per se.) whatever... and cease denigrating our sisters as if they were just another external link. THEY AREN'T.

Like any other nav box, it can be thin and inconspicuous, and programmed in this case with named parameters to generate boilerplate if the community desires. Unlike most other nav boxes, I think this one should be a header placement. I'm suggesting something fairly inconspicuous, but standardized along the understated size and height of {{commons-gallery}} which can be seen on a page here. Considering all the waste space we create with "Ugly White Space" (how professional does a screen filled with long Table of Contents and nothing else look!??, giving a small banner border to cross-sister linkages is a minor page formatting issue. Actually, implementation would be pretty trivial, a few parserfunction tests in the applied template, calling some sub-templates modeled on {{commons-gallery}}, which is a table format, gives an array of tables across. The order would be standardized alphabetically, and the link could be the display icon, sans text... that would prevent space overcrowding, and enable links to slightly differently worded titles covering the same materials. Some template savvy editor could knock together something like that in a few hours. The template could take a command arguemnt that tells it how to format itself. Three or four links as icons would fit in the 250 pixels width easily of the current sister links templates, as "commons-gallery" will fit in less as shown. A few more links could wrap to a double row of icons format. Hence on linkname trigger for each sister, one number command, saying how many links are involved to control the formatting. That would appear above any infoboxes etc., but if a page has a lot of links, could left float and appear as one stretched out banner of icons above page intros. // FrankB 17:37, 14 December 2007 (UTC)

We have enough tagcruft already. Based on your changes to Middle Ages just now, I don't like this idea at all. Johnbod (talk) 18:10, 14 December 2007 (UTC)
I did not agree at all with what I saw on Middle Ages. Seemed particularly cumbersome and somewhat unnecessarily complicated. Modernist (talk) 20:31, 14 December 2007 (UTC)
On my monitor at least, your edit displays very badly. A single word ("The") is isolated at upper left, then there's the contents box, the two nav boxes and the image; some scrolling is required to find the rest of the sentence: "Middle Ages form the middle period..." etc. Perhaps an inconspicuous page-wide noprint banner would be fine, but if it's inconspicuous it will be easily overlooked, no? Is there any evidence that users have had trouble finding nav boxes located in External links? Ewulp (talk) 22:41, 14 December 2007 (UTC)
Very interesting idea, but I think that the template/banner you proposed will never pass because it is ugly/distracting. I think the idea that a small template box like this one:
See ARTICLE in the Simple English Wikipedia
at the bottom of the page under See also or External Links would be very informative and not distracting. No one seems to want to let this pass because they think it will become too cluttered, even though we could fix the template to change the size.-- penubag  05:44, 19 December 2007 (UTC)

[edit] TOC wrap

Any way to make text wrap to the right of the default left-TOC the same way it wraps to the left of right-TOCs? For example see Wikipedia:WikiProject Trivia and Popular Culture. Would be a more efficient use of space, especially for long TOCs.

Equazcion /C 12:48, 12/21/2007
{{TOCleft}}? –Pomte 12:55, 21 December 2007 (UTC)
That works. But I was thinking can/should that be made the default behavior? Lots of large auto-TOCs out there creating a lot of unnecessary whitespace.
Equazcion /C 12:57, 12/21/2007
If you view an article like Helsinki at low resolution or in a small window, the first section looks really crammed between the TOC and the infobox. In many cases, the whitespace allows for good breathing room. –Pomte 13:04, 21 December 2007 (UTC)
I think that's a special case that could be dealt with using "clear"s. I think the majority of articles would benefit from a default wrap, and clears could be inserted where needed -- instead of the other way around, as it is now (wrap when needed, clear by default).
Equazcion /C 13:10, 12/21/2007
Lengthy TOCs can be hidden with a single click; you can jump to the first section of the body of the article with a single click. I'm not a big fan of the aesthetics of white spaces, but I think this is something to set aside for a few years until there are fewer low-resolution monitors out there. -- John Broughton (♫♫) 14:52, 21 December 2007 (UTC)
The problem with "default behaviour" is two-fold: 1) It is first and primarily one of page integration... that is the elements each individual page are somewhat unique, and unpredicable... that's the job as it were of the page's editors... to mix things in predictably (MOS/wikiprojects guidelines, etc.) and also allow such customization as a page needs or offers (interesting informative images which tell part of the story, or illustrate some facet of the the topic. 2nd) two million extant pages would all need re-proofed to verify the change in the current default behaviour is desired... and desirable, and hence, becomes a lesser of two evils...

In short, who has the time... the community would be well advised to stay on the current horse without trying to switch in the middle of that river rapid! There is a third problem... the MOS specifically discourages pinching text in between rectangular graphical elements, which by default we usually float to the right side... all the Infoboxes and whatnots...

Satisfying both (1) and (3) can rarely be accomplished using TOCleft, more often using TOCright, and both need a page with no top section graphics such as a chemical substance infobox, or history box... That leaves one option for pages with gobs of ugly white space, which if you think about it only occurs on pages with a lot of TOC entry lines... {{TOCnestright}}. That will butt up against the tall infoboxes, while letting the text stay in the left margin, without pinching per the MOS. Because different browsers render pages in different orders, it is best used in conjunction with the antibunching fix template {{FixBunching}} which prevents the corner to corner alignment issues which can occur... mainly evincing on that most damnably common of browser families, Internet Explorer. Unfortunately, it is and will be the most common browser for a long long while, and any page construction must assume it will be used by at least 80% of readers... Sigh!. Two other good features on TOCnest right... one can limit the width of the wider TOC's, and force wrapping using the maxwidth option... use with care, where only a few section lines are long and a problem; secondly, one can essentially add small thumb images as a suffix within the element... This can be useful in biographies in particular to keep "youngster photos" up high in the article without resorting to left placements and that same MOS pinching problem.// FrankB 15:34, 21 December 2007 (UTC)
Ok, I see the issues. I've never heard of TOCnestright but I'll have to test that out. I appreciate the comprehensive answer.
In the interest of getting rid of all the whitespace though, how bout this: multi-column TOCs? They could extend horizontally, when the browser width allows for it, so they wouldn't need to be as vertically long.
Equazcion /C 15:59, 12/21/2007

I had the same need... Requires a change to Common.css or some such... You can find "technical discussion thread" on that on User talk:CBDunkerson about two weeks ago. I've got to get to the dentist. Cheers! // FrankB 16:32, 21 December 2007 (UTC)

Languages


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -