Wikipedia

Wikipedia:Village pump (idea lab)/Archive 9

< Wikipedia:Village pump (idea lab)
Village pump (idea lab) archive  

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

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56

Listing changes to What-Links-Here ..?

Is a tool that would list changes to "what links here" something that would be useful enough to implement? Electron9 (talk) 01:36, 3 August 2012 (UTC)

Isn't that what Special:RecentChangesLinked does? WhatamIdoing (talk) 23:09, 3 August 2012 (UTC)
It only shows changes within articles that link to the requested article. Not if links has been made or removed. Electron9 (talk) 01:42, 4 August 2012 (UTC)
The pagelinks table is huge at 4.5 GB compressed. At WP:DPL where we are monitoring it for the leader board, only a small subset of our subset is used. — Dispenser 03:22, 4 August 2012 (UTC)
Something to implement on the toolserver as a search query? (SQL) Electron9 (talk) 06:47, 5 August 2012 (UTC)

Approaching StretchText

I have noted that some wiki articles written by subject matter experts contain much jargon and assumptions about knowledge that the average reader does not understand. I realize that Wiki standards are to minimize jargon and to use hyperlinks and references to explain underlying concepts. That is great. But having to click on a dozen or more articles to explain an article (see for example Bayliss Effect), creates a real impediment to expanding ones horizons to new areas of interest.

So, my thought is that if all the articles could have a one-liner summary (or even an easily understandable phrase) giving the essence of the article and if that one-liner were tagged, then it would be possible to click a button and have all of the hypertext ideas in the article expanded with the one-liner so that the article becomes more accessible to non-experts in the field. One could alternatively just hover over a word and get the one-liner if one does not want to "expand all". This is a simple version of what Ted Nelson called StretchText.

I would really LOVE this feature since I read articles out of my field all of the time--mostly because I am insanely curious about EVERYTHING. It seems that it would not be that difficult to implement both from a Wikipedia programming perspective and for authors (and subsequent editors who could go back and provide the one-liners for existing articles).

What do you all think?

If this idea is well-received. To whom does one suggest this? Does it go over to the proposal forum?

-Sami — Preceding unsigned comment added by Ssaydjari (talk • contribs) 10:58, 31 July 2012 (UTC)

You might like to try turning on navigation popups - they're in "my preferences", under the "gadgets" tab. This gives a popup box for any link when you mouse over it, including the first image and the first paragraph or so of the text. It's not perfect, but it works 95% of the time - the first sentence and first paragraph are usually a good essential summary of the content of the article. Andrew Gray (talk) 14:16, 1 August 2012 (UTC)
Per Wikipedia:Lead summary, ideally an article should start with such a summary sentence, which leads into a summary first paragraph, which leads into a summary first section. Reality falls somewhat short of this, but it's long been an ideal of how to write a Wikipedia article - David Gerard (talk) 15:02, 7 August 2012 (UTC)

Screen Colours

Am over eighty and have poor sight. Computer expert used NoSquintSiteSettings to set my screen to White text/Blue background. Effect excellent, I strongly recommend it.

However: Red Google Subheadings come out Black - virtually invisible against the Blue.

Can you experts solve the problem? - All white text would be fine. — Preceding unsigned comment added by 86.184.211.48 (talk) 20:38, 5 August 2012 (UTC)

I'm not sure what you mean by Google subheadings. Could you clarify? Perhaps you mean the color of the Wikilinks? Possibly you could try changing the link colors for the site using the Site Settings. Regards, RJH (talk) 20:25, 6 August 2012 (UTC)

Ref RJH 20:25 August 2012 (UTC) Thank you VV much.

An example from BBC News front page 7/Aug/2012:

Features & Analysis//Drawing Themes//Comic Book Styles from around the world 

  Columns headed:  Country    Artwork    Characteristics

  'Country' names (black) invisible
  'Characteristics' inserts: "Beano" etc (black) invisible

I suspect NoSquintSiteSettings needs extra programming to cope with this.

J Jeffery

(Example of my sight problem: I can barely see this entry as typed (black on white)- but the white on blue (and Ctrl+/-) make superbly clear. — Preceding unsigned comment added by 81.157.196.115 (talk) 09:06, 7 August 2012 (UTC)

This page is for discussing improvements to the English Wikipedia. It is not the place to discuss improvements to other software such as "NoSquintSiteSettings", even when that other software breaks when used on Wikipedia.
You should go to the website for NoSquintSiteSettings and discuss it there. Anomie⚔ 13:49, 7 August 2012 (UTC)

Jeffrey, do this: 1) Click through Edit->Preferences->Content->Colors. 2) Turn off the option labeled "Allow pages to choose their own colors, instead of my selections above". 3) change the "Text:" and "Background:" colors to match what you desire. 4) Smile as the text at BBC turns white. (I installed the firefox plugin NoSquint, to test and check. That will work.) (For future reference: 1. the folks at WP:Reference desk/Computing might be more relevant and interested in helping with technical problems, though that's really not what Wikipedia is for.) -- Quiddity (talk) 04:44, 8 August 2012 (UTC)

Baiting blocks

I've noticed we don't have a serious policy for baiting and I've been tossing this idea around in my head. I was thinking about stating that a) baiting cannot be used as justification for your actions, and that b) baiters can be subject to blocks. My idea here would be that the baiting must be malicious. The obvious problem is how do you define baiting? Any slightly confrontational edit could be construed as baiting, but it isn't baiting unless it was done with the intent to get someone blocked. Is this something that would be too subjective to enforce? Ryan Vesey 14:54, 7 August 2012 (UTC)

I am afraid that if you are going to use this definition, then you will end up calling any post asking to block an obvious vandal "baiting". I guess they can be considered "confrontational" and their intent is "to get someone blocked"... Perhaps a better definition would be "actions meant to provoke a violation of Wikipedia's order". Unfortunately, in that case detection of "baiting" would require refusal to assume good faith - and I doubt that "rewarding" such refusal can be good... After all, in many cases "baiting" would be made completely harmless by extreme (naive) assumption of good faith... --Martynas Patasius (talk) 18:36, 8 August 2012 (UTC)
Yeah, that is a tough one. Baiting can be subtle. We already deal with your first part via the oft quoted phrase "It might explain your actions, but it doesn't excuse them", so that is already ingrained in how we treat personal attacks and the like. Also, English is a very twisty language, and it is very easy to turn a phrase that might appear innocent, or might appear to be baiting, and that would be in the eye of the beholder. I don't want a jury vote every time I pop off a slightly sarcastic remark to determine if it was insightful yet amusing, or baiting. Other times, baiting depends on the individual. I might know what your "buttons" are, so a simple phrase that would seem like nothing to anyone else, might be baiting to you. I don't think you can have a baiting policy, you just have to use common sense when applying existing policies. If I see someone call another an "asshat", but it was baited by another person telling them they were ignorant, foolish, must be a school kid, go play on cartoon articles, etc (ie: classic baiting but not a personal attack) then I would treat that differently than if it were unprovoked. Again, it is doesn't excuse it, but it might explain it. In short, common sense is enough when determining how to weigh baiting into existing policies. Dennis Brown - 2¢ © Join WER 20:24, 8 August 2012 (UTC)
Hmm, it might be a bit of instruction creep; however, I feel that there are times where one editor clearly baits the other and we consider the baiting in the block, but don't punish it. Right now WP:BAIT says "Most discouraging of all, this tactic is nearly risk-free. There rarely are negative consequences for those who use it" and that is true. Even if we didn't codify it, I'd love to see baiting applied more often in boomerang blocks and the like. Not because I want to see more blocks, but because I want to see less (you are less likely to bait someone if it can get you blocked). Ryan Vesey 20:33, 8 August 2012 (UTC)
It might say that, but most admins (I think) try to keep baiting in mind when they know about it. Often, what would be blockable ends up not getting blocked for due to it. It is very hard to put a metric on it, since all blocks are up to the individual admin and while you will always know why they did block, you aren't always sure why they didn't. Dennis Brown - 2¢ © Join WER 21:05, 8 August 2012 (UTC)

Prononciation of names

Can we please have some requirements for inclusion of pronunciation of names in English Wikipedia? I don't mean names like Jones, I mean names like Yntema, Pólya and similar. RlyechDweller (talk) 07:11, 8 August 2012 (UTC)

The requirement is that you WP:BOLDly do your best to add that information wherever you think it would be helpful. WP:Nobody reads the directions, and we're all WP:VOLUNTEERs here, so simply writing down a "rule" somewhere that says the information should be included doesn't actually add any information. WhatamIdoing (talk) 21:02, 8 August 2012 (UTC)
You're probably looking for WP:PRON. But also note WP:DICTIONARY. Regards, RJH (talk) 22:09, 8 August 2012 (UTC)

Wikimedia visual identity guidelines

It seems to me that the Visual Identity Guidelines would be compatible with a Creative Commons Attribution-NonCommercial-No Derivs license, since both allow verbatim copies of the work to be used for limited purposes, and trademark law would further limit usage to fair use. 68.173.113.106 (talk) 16:45, 25 July 2012 (UTC)

Generally speaking, copyleft trademarks are not restricted to fair use only. It's simply our policy to apply our stringent internal fair use policy to trademarks. I'm not quite clear on what your suggestion is; are you saying that the WMF should release its trademarks under a CC license? commons:File:Wikipedia-logo-v2.svg is GFDL'd already, which is more permissive than the CC BY-NC-ND. BigNate37(T) 21:59, 2 August 2012 (UTC)
@BigNate37: I think you have "trademark" and "copyright" confused. Our stringent internal fair use policy considers only copyright, completely ignoring trademarks and other non-copyright restrictions on reuse.
As for the original question here, I guess it's somehow aimed at wmf:Trademark policy and the fact that many of the various Wikimedia logos are "all rights reserved" rather than copyleft (WMF's legal people are somehow unsure about the effectiveness of copylefting the logos and relying on trademark law alone to protect the "brand identity", but I can't find any details; see m:Logo#Logo guidelines). Anomie⚔ 19:11, 3 August 2012 (UTC)
No, I do not have them confused. I am rather well educated on the differences between copyrights, trademarks, patents, and licenses. However I was misinformed. I was going off of the discussion linked at Wikipedia:Logos#Logos as icons which I have recently had reason to reference. More to the point, you are correct about fair use as it pertains to trademarks; Wikipedia:Restricted materials makes it rather clear that I was wrong, and we do not apply our fair use policy to freely licensed trademarks. BigNate37(T) 23:25, 3 August 2012 (UTC)
BY-NC-ND plus trademark could easily supplant allowing highly limited uses under the trademark policy and might be a little more clear to re-users such as journalists and Wikimedia fans. 68.173.113.106 (talk) 02:41, 13 August 2012 (UTC)

Making inline cleanup tags more visible

Snow close. -- Toshio Yamaguchi (tlk−ctb) 21:42, 10 August 2012 (UTC)

I propose to make inline cleanup tags, such as [citation needed] more visually annoying. These inline tags are often barely recognizable in a long article, yet their purpose is to highlight important problems. What about something like  [citation needed]? -- Toshio Yamaguchi (tlk−ctb) 11:27, 9 August 2012 (UTC)

That's why the tags are in their current form, why would we want an article dominated by annoying diamond flags? If anything they should be an optional mod for editors who willingly seek out an correct such tags, though I've always used Ctrl-f. ChrisGualtieri (talk) 12:46, 9 August 2012 (UTC)
If an article were dominated by them, then surely there would be something elementary wrong with the article, in which case it would be appropriate for readers to see what it is. -- Toshio Yamaguchi (tlk−ctb) 12:59, 9 August 2012 (UTC)
Excessive placement of the tags are common warfare for editors who want to annoy a primary editor or address legitimate concerns with an article out of care to the readers. CN tags often appear in groups. ChrisGualtieri (talk) 04:23, 10 August 2012 (UTC)
I don't want these to be visually annoying, we have enough of a problem with article level tags being visually annoying. I'm willing to tolerate these as long as they are minimally sized, but if people want to make them deliberately annoying then my !vote would be to get rid of them altogether. I'm sure if we got rid of all such tags then some of our taggers would spend some of the effort saved in actually improving articles. ϢereSpielChequers 14:30, 10 August 2012 (UTC)
If we got rid of them, I feel that more information would be removed. Ryan Vesey 18:58, 10 August 2012 (UTC)
  • Oppose – I'm against anything that will make maintenance flags more prominent than the article content. There's already way too much interface bleed into the content. (Hatnotes, warning tags, stub tags, categories, inline warning tags, redirect messages, polls, bloated tables of content, incomplete list tags, excessive section titles for one paragraph sections, navboxes, &c. &c.) Regards, RJH (talk) 18:54, 10 August 2012 (UTC)
  • Oppose In this case, an reader will see the citation needed template no matter how it is shown. (There's no way to miss it) The proposed version actually draws a readers eye to the uncited material. It seems to go against its purpose. Ryan Vesey 18:57, 10 August 2012 (UTC)
  • Oppose [citation needed] is exactly the thing that we want. no need to make it more annoying. The reader is annoyed enough to see this [citation needed] as it brings a doubt in the readers mind.--DBigXray 19:30, 10 August 2012 (UTC)
Err, snow close of a Village Pump discussion? Have we come to this now? LOL. Regards, RJH (talk) 15:44, 11 August 2012 (UTC)
There is no support for this proposal and I read from the comments that the current tags are more fitting for their purpose than what this proposal is aiming at. I do not expect this to change, so I closed the discussion. -- Toshio Yamaguchi (tlk−ctb) 15:56, 11 August 2012 (UTC)
Also, the Oppose votes are pretty indicative in my opinion and I take having them here at VPI as an indicator that this is something the community does not want to be implemented. -- Toshio Yamaguchi (tlk−ctb) 16:14, 11 August 2012 (UTC)
I made a mistake when I put in an oppose; I should have read the forum header more carefully. My apologies for turning this into a poll when it shouldn't have been.   Regards, RJH (talk) 14:37, 12 August 2012 (UTC)
If you personally want to make these bigger, I would suggest manipulating the css class Inline-Template, which is output by Template:Fix, which is the standard metatemplate for such inline fixme templates. --Izno (talk) 23:33, 12 August 2012 (UTC)

SUL automatically recreating renamed accounts

See this request and my comments on it for background. Basically, a user requested a name change, but their account was recreated automatically by SUL upon their return, so the user made a new request. All in all, this is a rather messy state of affairs. Is there any obvious way we can prevent this from happening in the future? The simplest idea I can think of is to put a notice on the old account's talk page instead of just redirecting it, at least for a little while (maybe have a bot eventually turn it into a redirect). But I'm not sure if that would trigger the "You have new messages" banner upon recreation... Perhaps the 'crat should email the requesting user after it's done, to warn them. --NYKevin 04:11, 2 August 2012 (UTC)

Well, one way to prevent the recreation is to temporarily add a line like User:Example <newaccountonly|casesensitive|errmsg=some-useful-message> to MediaWiki:Titleblacklist. Not sure exactly how scalable that is, though. Anomie⚔ 13:06, 2 August 2012 (UTC)
How would SUL respond to that sort of situation? Would the error be propagated to the user? --NYKevin 05:13, 4 August 2012 (UTC)
Not sure exactly, except that I know it will prevent the creation. They had to disable the global title blacklist rules that were to prevent people from creating "(WMF)" accounts because it also prevented SUL creation of the accounts for legitimate staffers. Anomie⚔ 14:06, 4 August 2012 (UTC)
If the 'crats get an aditional button to force resetting the password (by sending a new one) then the problem would be solved... mabdul 22:41, 14 August 2012 (UTC)

Organization of the Lacking references section of WP:BACK

I am not sure how many people browse WP:BACK for possible tasks to improve Wikipedia. Most of the information displayed leads to a natural way to solve most problems. Persondata ones simply display a list of pages that need to be fixed and others sort by tag date, 'Category:Articles that need to be wikified' and 'Category:Articles that may contain original research' are common examples. However the main concern of 'Category:Articles lacking sources' shows 233,446 articles without a single source. Its close cousin, 'Category:Articles needing additional references' contains 195,603 articles.

Over 400,000 articles are arranged in an indiscriminate mess by date tagged. WHY? Surely date of tagging is useful to smaller categories or priority driven focuses with time-sensitive matters would be useful, but it does not address efficiency. Category:Articles lacking sources from October 2006 still has 1,599 pages in it almost 6 years later. Most other sections have somewhere around 2,000 pages each, regardless of creation time. Who can blame any editor when the articles have nothing in common, are largely obscure and don't give many clues as to WHERE a source could be found.

I propose that 'Category:Articles lacking sources' have a different sort mechanism, by category of the stubs listed. We have category trees, right? Why not use existing categories tagged on these unreferenced pages to focus editors to a section that they could assist. WWII articles can be split by faction or event, medical could be split by specialty. Categories are great for sorting information, its time that our unreferenced articles be sorted by category as well. Trying to source vast unrelated articles is troublesome, even in alphabetical order or by 'tag-date', I've already used categories to source groups of articles, why not create a system of unreferenced or need more references section that holds to a category tree to maximize the efforts of editors to source these unsourced articles? Surely a bot could be programmed to do such a task, take the existing pile and sort and see where it gets us. ChrisGualtieri (talk) 03:42, 9 August 2012 (UTC)

There are already such alternatives. See http://toolserver.org/~svick/CleanupListing/CleanupListingByCat.php?project=Medicine for a list of all medicine-related articles sorted by type of work needed (warning: large page). WhatamIdoing (talk) 16:06, 12 August 2012 (UTC)
That one works for medicine, but I'm still referring to something else, but I'll be reducing the backlogs soon enough anyways. I've devised a system for doing so. ChrisGualtieri (talk) 13:01, 13 August 2012 (UTC)
It can work for any WikiProject's pages. I've given WPMED's as an example, because it's the one I use most. WhatamIdoing (talk) 01:08, 15 August 2012 (UTC)

PC for sockpuppet

Do we happen to have an established non-derogatory word one can use when describing a sockpuppet? Should we have one, that describes a human being as someone that may mean well but fails to understand how Wikipedia works in that regard? I am a new editor, and just a couple of minutes ago I found myself calling a sock a sock, and I do feel quite uncomfortable with that and wish there was a gentler word around that would say what I meant and not carry so much shame. →Yaniv256 talk contribs 21:30, 14 August 2012 (UTC)

An illegitimate alternate account? I don't know, just guessing. I always use "sockpuppet". David1217 What I've done 21:40, 14 August 2012 (UTC)
Yes, thank you David. Certainly, if I had thought of that I would feel much better. But it does have quite a few shortcomings. Primarily it is too long and too hard to spell. On the margin that counts quite a bit and may explain why nobody seems to use it. Even civility crusaders use sockpuppet, which in my mind tells you a lot more about how language works than it does about human nature. I suggest that ideally the word we need needs to be shorter than sockpuppet, carry as good a metaphor, and be easier to spell. →Yaniv256 talk contribs 22:37, 14 August 2012 (UTC)

I'll give an example of what I have in mind but please try to brainstorm with me here, and come up with your own ideas. How about "a-multiple", "b-multiple", "c-multiple", ... "z-multiple", where the prefix letter expresses how much good faith or bad faith one would like to assign to the sockpuppet? →Yaniv256 talk contribs 23:09, 14 August 2012 (UTC)

That kind of thing is only useful to people who already know the insider's jargon. "Abusing multiple accounts" is something that anyone can understand. WhatamIdoing (talk) 01:10, 15 August 2012 (UTC)
That can easily be solved by providing a link with an explanation. I could set this up for myself in a minute if I wanted to start using that word unilaterally.. you know the quote ... my words mean exactly what I want them to mean, not more or less... language is bottom-up and so this is not a policy debate. We can each go home and use whatever words we fancy. →Yaniv256 talk contribs 04:05, 15 August 2012 (UTC)
What I meant to say by that is that I think that unless it is catchy it is not going to catch. →Yaniv256 talk contribs 04:09, 15 August 2012 (UTC)

You could just call it an alternate account, especially if evidence of abuse has not yet been established, but you are pretty sure it's the same person. Gigs (talk) 13:34, 20 August 2012 (UTC)

Suggest add a crowdin-like translate tool

I moved this post from VPP
I'm a translator of Chinese Wikipedia. I suggest add an Crowdin-like translation tool that with


  • Multi-lang. support


etc.
Thanks!
by guy from the Far WestL19980623 (talk) 05:03, 18 August 2012 (UTC)

External SSL Support

Wikipedia needs to develop a policy regarding external URL links with SSL support.

For example, can Google search engine URL on the Google Wikipedia page use https://www.google.com instead of http://www.google.com? On some of the pages, such as Google, the links have already been converted to SSL. Some Wikipedia pages, such as Cisco support SSL but have not been converted to SSL.

There should be a consistent policy regarding adding external SSL support. Please chime in with comments or concerns.

Reposted: https://en.wikipedia.org/wiki/Wikipedia_talk:Secure_server#External_SSL_Links

64.128.27.82 (talk) 17:36, 20 August 2012 (UTC)

Proposing a Major New Feature

If I wanted to propose the addition of a major new feature to Wikipedia and have a demonstration website to preview it, were could I place this to get the most attention of the powers that be?

jroehl2 (at) yahoo (dot) com

Jroehl (talk) 00:22, 15 August 2012 (UTC)

This page is great for that. What's your "major new feature"? David1217 What I've done 00:37, 15 August 2012 (UTC)
The "perfect" page depends on the nature of the feature. Also, you will want to read Wikipedia:Unsolicited redesigns. WhatamIdoing (talk) 01:11, 15 August 2012 (UTC)

I am going to wait for tomorrow as I need to backup my demonstration server. Carbonite is straining to backup the 300,000 demo files involved in this. When it is done tomorrow I will post the link here, as I want to provide you and everybody else a clear shot with unencumbered bandwidth.

I just wanted to confirm that this was the best place to introduce this.

Is there any other place to post something of this nature? Simultaneously?

Thanks

Jeff

Jroehl (talk) 01:20, 15 August 2012 (UTC)

If you need it built, or want "official" support, okeyes wikimedia.org is the place to go :). Ironholds (talk) 17:50, 17 August 2012 (UTC)

Wikitimelines.net

Wikitimelines.net is now in beta.

Wikitimelines.net is a website with a unique set of tools that creates interactive timelines out of Wikipedia articles, without human intervention. It then allows users to modify the initial results in order to make the information contained in the timelines more informative, approachable and attractive.

The timelines are created by parsing dates from text. Even whole books can be displayed on a timeline.

Any suggestions, ideas, criticisms are welcome. We intend to incrementally improve the site and continue to add functionality over time. We are privately funded, free and non-commercial.

It would be interesting to see this in a "Show timeline" box in Wikipedia articles, at some point.

Thanks Jeff and the whole team here at Wikitimelines.net

Jroehl (talk) 16:26, 23 August 2012 (UTC)

It's unlikely to be used on Wikipedia unless it is implemented as a MediaWiki extension, IMO.--Jasper Deng (talk) 00:31, 18 August 2012 (UTC)

Wikinac?

From time to time I see in this place comments that "Wikipedia is not an almanac", although some state that it does serve that purpose. Wikipedia guidelines also promote limiting tabular data in articles. ... Well, Wikipedia also discourages articles that are mere definitions; that is what Wiktionary is for. Other Wikimedia projects have similar purposes. ... So how about this: Wikinac, a sister-project almanac. It could be filled with detailed tables, charts, graphs and other data too elaborate for Wikipedia. It could incorporate complete election data, sport statistics, meteorological information, and so on. Cross-wiki links from Wikipedia could be used. Maybe it is too much to consider, but this is the Idea Lab, and I got an idea.    → Michael J Ⓣ Ⓒ Ⓜ 00:36, 21 August 2012 (UTC)

New Wikimedia projects can be proposed at meta:Proposals for new projects. meta:Proposals for new projects#Closed proposals shows an old proposal at meta:Wikinac. PrimeHunter (talk) 01:09, 21 August 2012 (UTC)
OK, thanks. So what I thought was an original idea isn't so original after all.    → Michael J Ⓣ Ⓒ Ⓜ 01:50, 21 August 2012 (UTC)
See also WikiData. It was announced earlier this year [after many years of background]. 5 years from now, a lot of our current and proposed projects should be using that as a backend. See old Signposts for more info. -- Quiddity (talk) 23:16, 21 August 2012 (UTC)

Disambiguated pages as seen from ArticleFeedback commenters

I was looking through some comments posted on ArticleFeedback and noticed that on many articles "Foo (X)" there are comments along the lines of "I was looking for Foo in the context of Y, but can't find it" (e.g. Special:ArticleFeedbackv5/Stack_(abstract_data_type)/148713, the commenter was looking for Stack-based memory allocation). It seems many people are arriving at "Foo (X)" instead of "Foo (disambiguation)" or "Foo", probably through a search engine, and then don't know how to search for "Foo (Y)" instead.

Any experienced Wikipedia would know you need to change the URL from https://en.wikipedia.org/wiki/Foo_(X) to https://en.wikipedia.org/wiki/Foo or https://en.wikipedia.org/wiki/Foo_(disambiguation) or make an appropriate guess for Y and go directly to https://en.wikipedia.org/wiki/Foo_(Y). But if you think about it, this is actually a very hard to discover process for readers.

Does anyone have any ideas on how to improve this situation? —Ruud 18:15, 21 August 2012 (UTC)

Do the pages in question have hatnotes linking back to their disambiguation pages? BigNate37(T) 19:51, 21 August 2012 (UTC)
No, because the MoS states that those shouldn't appear on articles with a name of the form "Foo (X)", only on articles named "Foo" is there also exists a "Foo (X)" or "Foo (disambiguation)". —Ruud 22:01, 21 August 2012 (UTC)
Ah, the relevant bit here is WP:NAMB. Truthfully, that took me a while to find. Perhaps it's time to test consensus on rethinking that bit of the hatnote guideline? A simple hatnote would solve the problem you describe with a satisfying amount of consistency and simplicity. BigNate37(T) 22:32, 21 August 2012 (UTC)
I suspect you're right, and I even prefer that simple disambiguation form of the hatnote for its elegant lack of clutter.   Regards, RJH (talk) 16:32, 25 August 2012 (UTC)

Consistent User Links for Revision history

This is a request to make the links for the user, user's talk page, and user's contribution page consistent in the Revision history, regardless of whether the editor is a registered user or a generic IP address.

When clicking the "View history" hyperlink for an article, you're taken to the "Revision history" timeline. That timeline lists revisions in the following format:

(cur | prev) [radio buttons for the "Compare selected revisions" button] Date and time stamp User Name (talk | contribs) . . (article size) (size change) . . (Edit summary) . . (undo)

The part I'm interested in discussing is this for registered users. The hyperlinks are intuitive. The User Name links to the user's page, "talk" links to the user's talk page, and "contribs" links to the user's contribution page.

User Name (talk | contribs)

For unregistered users, the following displays. The hyperlinks are less intuitive. "talk" still links to the use's talk page, but the IP Address links to the contribution page.

IP Address (talk)

I suggest that for unregistered users, the "Revision history" display the following. If the distinction between an IP Address and User Name is deemed necessary, then a small icon can be placed to the left or right of the IP Address. Additionally, if we want to discourage have a user page for an IP Address, then that could be plain text rather than a hyperlink.

IP Address (talk | contribs)

Thanks. Let me know whether this sounds good and whether there are any other suggestions. Wikky Horse (talk) 21:44, 26 August 2012 (UTC)

WP:COMMONNAME Tiebreaker?

I've been involved in several RMs, and noticed a great deal many others, relating to the interpretation of the WP:COMMONNAME policy. In general, I think this policy is a great thing for the encyclopedia to follow, and I wholeheartedly endorse it's continued use.

The policy does have its problems, though, in particular relating to country names. In most cases, the question of "Official vs. Common name" isn't an issue; no one is arguing that the article on "Guyana" be renamed to the "Co-operative Republic of Guyana". However, an issue arises in some circumstances when it is the Common name itself that is in dispute. In a few, high-profile cases, the official name is used in almost equal measure with another unofficial name; in essence, they are BOTH common names. As a result, we see RMs with page-after-page of circular, contentious debate over which name is in fact "more common." Unfortunately, in some instances names are defended based on political preferences or regional biases, furthering the contentious nature of an already controversial debate, and causing a great deal of headache for Wikipedians. Oftentimes, these RMs are re-proposed again a few months later, regardless of the outcome, and the result is articles switching between/debating two rather common, and equally valid names for years on end. In summary, these RMs cause a great deal of conflict on Wikipedia, and take up much effort that could be better used elsewhere.

A small sample of these contentious RMs are below. In some prior cases, the official name prevailed as the "common name." In others, it did not. (Note: my personal opinion has no bearing on the examples selected below. These RMs are by no means all-inclusive, but merely represent a small sampling of more recent discussions.)

  • Talk:United_States See the FAQ section; many, MANY more comments exist in the article archive.
  • Talk:Ivory_Coast See the box at the top of the page for a textbook example of the Move-Re-move Cycle I mentioned above.

And many, many more.

My proposal, therefore, is to alter the policy to end most of these debates prematurely. In the event of a "No Consensus" (I.e. both names are shown to be approximately equally as common), The "more official" name is favored as the article title. The official name has the benefit of being more encyclopedic, as well as is used more frequently in international organizations. As such, I believe that, when against an equally-common unofficial name, it should take precedence as the article's title. If, however, it can be shown in the future that the unofficial name is indeed the "common name", then there would be no prejudice in moving the article in a future RM.

Obviously, this is still a rough proposal, and I would appreciate thoughts and feedback to refine this into something that could be brought before the community as a whole. Thoughts? I recognize that this is a contentious issue, and I think it would be best if we could solve it here rather than in countless RMs and RFCs. Cheers, Zaldax (talk) 13:45, 21 August 2012 (UTC)

To my understanding that was already part of either this or WP:AT. Anyway I would support such a clarification. Only problem that needs addressing is if the official name is in dispute ie country x does not recognize regime y and therefore uses old name a instead of new name b. Our core policy of neutrality comes into play here. Agathoclea (talk) 14:17, 21 August 2012 (UTC)
This seems like a good idea. I suggest bringing it up at WT:AT. Jojalozzo 14:37, 21 August 2012 (UTC)
Yes, it is a good idea... but... it focuses on only one of our titling principles: Recognizability. We also need to account for the other principles (Naturalness, precision, conciseness, and consistency). To elaborate... Let's say that after searching for a WP:COMMONNAME, we found two equally common names (one more "official", the other less so). This means neither is more Recognizable than the other. However, at this point we also have to ask: Is one more natural than the other? (we examine what other articles use when linking to the topic under discussion)... is one more precise than the other? (we examine whether using one or the other could cause confusion with another topic)... is one more concise than the other? (or to put it another way, is one overly long?)... Is one more consistent (what do related articles use)? The answers to these questions may well indicate that the best title isn't the more official name. That said, I could see using the concept of "more official name" as a tie-breaker if, after considering all the titling principles, we still could not choose which title to use. My point is that there are a lot of things that have to be considered before we consider "officialness". "Officialness" comes in at a much later point in the decision making process, if it comes in at all. Blueboar (talk) 14:46, 22 August 2012 (UTC)
I'm not entirely sure how to account for those in the wording, especially as they're somewhat more subjective criteria than common-use. (At least the latter can be supported by various web program generated statistics.) Since I haven't addressed those other principles, I guess I can break it down?
  • Naturalness: Agreed that this is an important consideration, but not sure how to address it. The issue here is that, in some cases, articles use the long form of a name (i.e. "The People's Republic of China is a single-party state governed by the Communist Party of China." or "From its founding in 1949 until late 1978, the People's Republic of China was a Soviet-style centrally planned economy, without private businesses or capitalism.") and in others, the article uses the short form. (i.e. "Compared to its closed-door policies until the mid-1970s, the liberalization of China has resulted in the administrative climate being less restrictive than before." or "China has diplomatic relations with 171 countries and maintains embassies in 162.") Oftentimes, it depends on the context and grammar, and usage can be varied. Generally, the short form is used more often, but that also includes abbreviations (USA, PRC) which no one is seriously suggesting we title an article with.
  • Precision: In general, the official name is more precise. (the only possible counterexamples I can think of are PRC vs. ROC, DPRK vs. ROK, and GDR vs. FGR, but only the first has ever been a serious RM issue.) Consider the issue of "United States" (several nations have "United States" or a variant thereof as a part of their official name, i.e. "United Mexican States". "United States of America" would be more precise in that instance)
  • Conciseness: Same issue as naturalness, in that it also can be subjective. Generally, the official name is longer than the short-form name, but not by such a margin as to be unwieldy. If it was, it's likely that the long form wouldn't be as commonly used as the short form.
  • Consistency: This is also a consideration which needs to be addressed; however usage tends to vary based on context and grammar. Inertia shouldn't be an argument against changing a name (except in special circumstances), but if the two forms are used in about equal proportion than the "tiebreaker" concept still applies.
With that in mind, I guess there are two options with how to progress. Either we can alter the wording to reflect the above 4 categories somehow, or we can change to something like the following (in keeping with the "tiebreaker" concept):
  • In the event that two names are found to be roughly equal in common usage, and no consensus can be reached based on the criteria of naturalness, precision, conciseness, and consistency, favor the more official of the two as the article title.
The wording of that would still need to be refined, though. Thoughts? Cheers, Zaldax (talk) 15:34, 22 August 2012 (UTC)
1) I'm not sure we should include consistency in the list since this discussion presumes there is no standard, consistent way to name these articles.
2) See why titling disputes can be so difficult: since the official country name will often be viewed as less natural, less concise, and more precise than an unofficial, but equally recognizable, name, we'll be bogged down in weighing these other criteria before we ever get to the tie breaker. Jojalozzo 19:02, 22 August 2012 (UTC)
Agreed. I still think the first proposal (something like "in case of no consensus, favor the official name") is better. Otherwise, people will stonewall to prevent the tiebreaker from ever being reached. It's also more nuanced, so it gives the admin and editors more leeway in implementing it. Personally, I'm opposed to including the subjective criteria, as during RMs they are very difficult to objectively support with policy. Cheers, Zaldax (talk) 19:08, 22 August 2012 (UTC)

8The revision I'm currently proposing is: "In the event that a consensus between two equally common names cannot be reached, favor the more official of the names." I think leaving it somewhat vague is the best proposal; the tiebreaker still exists (neutralizing many a contentious RM), but allows for interpretation based on other criteria. Strictly speaking, this is only an alteration to the WP:COMMONNAME part of the WP:AT policy. Cheers, Zaldax (talk) 19:13, 22 August 2012 (UTC)

It seems that this will just move the problem to a new set of articles. Rather than the heated debates being at the 50-50 titles, the heated debates will be at the 66-33 titles (or whatever the rough threshold for consensus is considered). Kaldari (talk) 05:35, 24 August 2012 (UTC)
This proposal on the surface sounds good, but the more I think about it the more it starts to concern me. How do we determine when there are "two equally common names"? And in reality, can 2 names ever be "equally common"? If one name is used 50.1% of the time and one is used 49.9% of the time, that's technically not "equally common". In all of the examples at the top of this section, which countries would be at a different location as a result of this tie breaker rule? In trying to apply this rule to each of those cases, I honestly can't decide if none of the outcomes would be different or if all of them would be different. Rreagan007 (talk) 14:49, 28 August 2012 (UTC)

Notification for AFD/PRODs

Currently, only the creator of the article is typically notified when an article goes to AFD, but why not all editors that edited such a page? An opt-in to notify editors that their edited pages have come up at AFD/PROD/SPEEDY will help put eyes that previously worked on the article will be able to easily tell that a page to which they contributed to is going to be potentially deleted.

Why does this matter, if you are a major content contributor, improving a range of pages comes naturally, yet if something goes to AFD you will not be notified unless you created the page. Since bots can do a great deal of things, I think it would be ideal to have a Bot automatically scan the AFD list, check the contributors and send out AFD notices to those editors (or opting-in editors). With a generic message like: 'Article title' - 'Article title' is up for 'deletion type' and you contributed to this article.

Unless I am mistaken, such a function isn't yet in Wikipedia and it would relatively easy to implement and provide better notification to those editors of that particular page. Does anyone else think this is a good idea? ChrisGualtieri (talk) 15:13, 28 August 2012 (UTC)

  • This makes perfect sense. Unfortunately, by that virtue, it is likely to be rejected. Having my support doesn't help much either; but it does strike me as a good idea. 76Strat String da Broke da (talk) 16:05, 28 August 2012 (UTC)
I believe (but I'm not sure; I don't hang out around AfD) that some editors don't notify the creator or major contributors because they feel it is effectively canvassing anti-deletion users to the discussion. I also believe that they think anyone who cares about an article will have it on their watchlist, so they'll see the AfD nomination, eliminating the need for notification. But don't quote me on this. David1217 What I've done 17:08, 28 August 2012 (UTC)
I have more than 500 pages on my watchlist and I cannot tell what is what because half of the articles move so fast between watchlist checks. The matter of notification is left to the taggers who use tools like Twinkle, if I was to pull anyones work for a peer review, let alone retraction (the equivalent of deletion on Wikipedia), one would assume that the writers be given notification before their work could disappear. Sometimes the major contributor or writer is not the creator of the article, so current methods won't let that person know it is up for deletion. Currently the burden is on the editor to watch the page, when we have the capability to notify them instead. ChrisGualtieri (talk) 11:14, 29 August 2012 (UTC)
The main problem is working out which contributors to notify. Anyone who makes any edit ever? Include or exclude someone who tags it? Someone who writes a paragraph? Someone whose contribution is subsequently deleted or replaced? Someone who vandalises it? Someone who fixed a comma two years ago? Someone who fixed a comma yesterday? I can imagine different users having different opinions about when they want to be notified. But if you have any ideas about resolving this. --Colapeninsula (talk) 12:07, 29 August 2012 (UTC)
While not perfect, someone who made more than one non-consecutive edit might make sense. ♫ Melodia Chaconne ♫ (talk) 13:33, 29 August 2012 (UTC)
  • I think an opt in bot notification would be the way to go. As pointed out just above, it is necessarily a judgement call to determine who should be notified about a deletion nomination, which is not the sort of thing a bot is good at, but with an opt in the bot could be set to expansively notify without worrying about editors who don't want notifications getting them. It is also consistant with canvassing policy to neutrally notify everyone who has edited an article, while it may bring in an keep bias, in my experiance most editors act in good faith and wont reflexively !vote keep just because they have edited the article. An opt in would also allow opting in editors to specify a threshold for notification (1 edit, 2 edits, 2 non-consecutive edits, +1000 bytes of edits, etc...). However I would say we should leave alone the manual notification procedure. Monty845 13:48, 29 August 2012 (UTC)
I am leaning to the opt-in side, at least for a test run to see how it would work. More than 2-3 edits usually constitutes some interest in the article aside from AWB fixing, vandalism removal or whatever maintaining the article needs. It also goes to note that the more editors that work on an article, the less likely it is to be deleted, so it is not as if we are going to tag Obama or Putin as deletion candidates. As for the !voting, if the editors and creators of the article cannot make a case against deletion, than why should it stay? I see this issue more of transparency rather than actively trying to canvass or sneakily delete an article; current methods do not notify the primary contributors of many articles. Those contributors would be valuable at AFD, and often have no other reason to check their watchpages or AFD to see if their work came up there. So their work may be deleted without their input, whilst they are still active. ChrisGualtieri (talk) 12:02, 30 August 2012 (UTC)
  • I would notify a creator only in case when both a) an article exists less than 1 year b) there is less than 500 revisions in it. In other cases probability that you have inactive creator or article text he would not know what to do is high. So is my opinion. ♪ anonim.one ♪ 10:42, 31 August 2012 (UTC)
  • I agree that an opt-in bot would be useful. Making it policy to automatically notify every contributor of an article when it's nominated for deletion is a bad idea, even if a bot was used, because there are many editors who've made minor edits to thousands of articles and don't need or want to be notified every time one of them gets taken to AFD. But if it was available as an opt-in notification, allowing editors to specify their own notification threshold, I for one would certainly use it. Personally, when I nominate an article for deletion, I try to notify every single editor who made a significant contribution to it (more than a minor edit or vandalism reversion) and who appears from their history to be still active. Not everyone else does the same, so it would be nice to be able to select guaranteed notifications when your contributions are up for deletion, rather than having to rely on your watchlist to find out. Robofish (talk) 16:26, 1 September 2012 (UTC)

Treat identical English and "foreign" names as different?

There was another short "Polish-Lithuanian" edit war recently ([1], [2]). Such edit wars concerning article names and "alternative names" are rather common (for example, [3], [4] or [5], [6], or [7], [8], [...], [9], [10], [...] - just for one article "Burbiškis"; in each pair of edits the Polish name "Burbiszki" is added and removed)... Of course, the main reason for the fight is the impression that such names make: if there is a Polish name right in the "definition" of the Lithuanian town, it creates an impression that Wikipedia considers that there is a "rightful" Polsh claim to the territory, the absence of the Polish name creates a contrary impression. It seems hard (if at all possible) to avoid such impressions completely, but I have thought of a modification that is meant to make them slightly "softer"...

As we know, two different types of "introductions" can be seen Wikipedia's articles about "foreign" (non-English speaking) locations. One of them is used when the English name is different from the local one (for example, "Warsaw (Polish: Warszawa) - [...]"). Another one is used when the English and local names coincide (for example, "Berlin - [...]"). But if an "alternative" name is added in the second case, the "introduction" starts to look like the one of the first case (let's say, "Berlin (Lithuanian: Berlynas) - [...]")... It is not very confusing, but maybe the confusion is sufficient to make some edit wars a little more vicious..? And in that case, maybe adding the local name even if it coincides with the English one (like "Berlin (German: Berlin) - [...]") would help (if only a little)..? I guess it might also make the guideline Wikipedia:Use English a little more obvious...

So, are there any problems with such proposal (or alternatives) that would have to be considered? Or would it simply fail to do anything useful..? Or maybe something like that has already been proposed and rejected (I couln't think of a particularly useful set of keywords to search for such proposal)..? --Martynas Patasius (talk) 21:43, 27 August 2012 (UTC)

  • I could support such a proposal upon well crafted prose. I suggest showing the standard English pronunciation for the second rendition. For years I held the Mexican proper name, Jesus, to the same pronunciation used in Christian context. Berlin is also quite different although spelled the same. I do believe adopting this suggestion would provide the means for quick resolution to the naming controversies that all too often do erupt. 76Strat String da Broke da (talk) 15:00, 28 August 2012 (UTC)
  • I think the most important improvement to UE would be a section that says what name to use when (nearly) all the English sources agree (answer: use whatever name they use), but it has been opposed by one regular editor there because everyone already knows that you should follow the sources without worrying whether the name Venice implies a UK right to an Italian city. WhatamIdoing (talk) 17:03, 28 August 2012 (UTC)

I would like to thank the editors who have given their advice. I will try to take in into account while formulating the "real" proposal. --Martynas Patasius (talk) 22:10, 6 September 2012 (UTC)

Dollars for donuts

I realize this is wide-eyed and overly ambitious, but bear with me for a minute and feel free to shoot it down if it's been discussed before (I'm relatively new).

Premise 1: One of Wikipedia's aims is to improve the quality of its vital articles and/or most popular articles.

Premise 2: Wikipedia's foundation has money that it would be willing to spend to accomplish this goal.

On the assumption that both of these premises are correct (I'm not sure either one is), here is a proposal:

Step 1: A group of trusted people (administrators, established editors, whatever) is formed who are capable of making decisions about Wikipedia's priorities for article improvement.

Step 2: This group is instructed to formulate a list of articles that Wikipedia most wants to see improved.

Step 3: The foundation allocates a small annual budget to this effort as a trial (perhaps $10,000), and the group agrees on a strategy of how best to spend it.

Step 4: The group puts out public Requests for Proposals (RfPs) for improvement of articles it deems important, offering small amounts of money for accomplishing this task, for example by bringing the article through the normal processes up to Featured Article status.

Step 5: Interested editors submit their proposals and their qualifications for improving articles outlined in the RfPs. An editor, for example, may say s/he has nominated eight articles successfully promoted to FA in the philosophy field, and hence would be a good candidate to bring Philosophy up to FA. Editors asserting qualifications beyond accomplishments on Wikipedia may have to identify themselves to the foundation to prove their veracity.

Step 6: The group decides after an open dialogue which of the proposals is most suitable. Members of the oversight group who have conflicts of interest (have worked in some capacity with the RfP editor before, for example) must abstain from judgment on that proposal. A timeframe in which the task must be accomplished is specified in the RfP, but is usually rather generous – four months, for example.

Step 7: The selected editor works to improve the article over the specified period; during this time, only the chosen editor is allowed to create GA reviews, peer reviews and FA reviews connected to the article. Otherwise everything is the same. If the period of improvement runs longer than expected, the editor may request additional time from the oversight group. Whether to grant it is at the discretion of the group.

Step 8: All GA and FA reviewers must be free from conflicts of interest with the nominator/editor, and this must be checked as part of the review process on top of the usual requirements.

Step 9: If the nominator succeeds in promoting the article to FA, s/he is given the monetary reward ($100 for example). If in the judgment of the oversight body the editor has not completed the work within the established timeframe or things like editing wars and other impediments have cropped up that made further improvement impossible, the award is not given.

Step 10: The nominator may do whatever s/he pleases with the award, including declining it and donating it back to the article improvement budget.

The End. --Batard0 (talk) 15:26, 4 September 2012 (UTC)

I think that Premise #2 might be invalid. WhatamIdoing (talk) 02:40, 7 September 2012 (UTC)

'hit counts' or 'hit timelines" to show approx popularity of an article.

'hit counts' or 'hit timelines" to show approx popularity of an article. Should be easy. — Preceding unsigned comment added by 70.29.40.85 (talk) 17:32, 5 September 2012 (UTC)

Hit counters are available through the "view history" tab for an article. Andrew Gray (talk) 17:56, 5 September 2012 (UTC)

Using stylometry and statistical methods to identify sock-puppets

This is an idea I've been thinking about for some time now. I see sock-puppets as a growing problem on Wikipedia, and I believe our current methods aren't completely dealing with the problem. For example: from time to time I see a new user who dives into editing controversial topics with much more experience than new users generally have. They know the "Wikispeak," know the policies, and know how to game the system. When I see users like this, I often leave a polite note on their talk page asking if they have edited under previous/IP accounts or if this is a clean start account. If they say it's a clean start, I accept that and leave them alone, but often they say this is their first/only account.

And here's the problem: I'm pretty sure they're a sock account, and I may have suspicions of who they're a sock of, but I can't prove anything. Even if I have them narrowed down to 2-3 users, opening 3 SPI investigations would be extremely disruptive; I'd annoy a lot of people, waste a lot of time, and make a lot of enemies. Even with SPI's filed, there's no guarantee that it's going to get a Check User endorsement. Even in the best-case scenario that a Check User confirms a sock, I've still dragged two innocent users off to SPI.

So, what I'm proposing here is a non-invasive tool that would check a variety of publicly available information. This idea was sparked when I saw a tool (I don't remember which) that compared articles that were edited by both users. What I'm proposing is a tool more extensive than this that would check a variety of different things. To operate the tool you would simply feed it the usernames of two or more users.

Time of day statistics

The tool would automatically search the edit history and would download and compile the time stamps for every edit (during the time when both accounts were active). It would then create a 24-hour histogram for each account which could be compared. (The histograms would look different for different users, depending on their time zones, employment, school schedule, sleep schedule, etc.) The tool could do a statistical analysis of the two plots, and spit out a chi squared or P value or something like that.

A similar analysis could be done for the day of week, looking at the days when editors edit the most. (For example, I rarely edit on Saturdays.)

Stylometry

Stylometry is a statistical analysis of words, and has been used to determine the authorship of documents based on samples of the author's work. There are several free programs out there that you can basically feed two chunks of text, and they will tell you how similar they are based on things like word length, sentence length, punctuation, etc. (see [11] for one of these programs) The way I would see this tool working is that it would download all the users' contributions to talk pages and compile them into a single document, paragraph by paragraph. (We'd have to drop stuff like signatures and indenting colons.) It would end up with two very long documents containing the complete unabridged works of each author. (For stylometric analysis, longer is better.) It would then compare the two works and spit out another number related to the probability of the two authors being the same person.

The nice thing about some of these programs is that you can build up a database of known authors, and when you feed it an unknown it will spit out the name of the most likely author in your database. In other words, one could potentially build a database of known sockpuppets to compare suspected sockpuppets against. (This might be taking things too far though.)

Other

We could also integrate other tools such as article overlaps, time between edits, etc. I'm sure code has already been written for these.

Testing

Before making the tool available for public use, we could test it against a large number of known sockpuppets. We would use this data to see which tests are the best predictors of sock-puppetry. We might find, for example, that article overlap means little, time of day is an ok predictor but can give false positives, day of week is a moderate predictor, and stylometry is generally ok. We then combine the various numbers that were spit out by the various tests (50% article overlap, Chi-squares for time of day, stylometry, etc.) and combine them in a way so that each is weighted in proportion to it's usefulness in predicting known sockpuppets. On the user side of things, this number would be the program's output. (We probably wouldn't want to give people much detail on what the program is looking at, because that would give prospective socks ammunition to game it.)

Anyway, that's my idea. If I had any experience with computer programming I would do this myself, but unfortunately I don't. I would love to see an experienced programmer pick up this idea and make something with it, and I'd be willing to help where I could. I realize it's a big project, but it could be taken a step at a time. For instance, I imagine it would be very simple to gather the time data and make a histogram. So...sorry for the length...and let me know what you think. ~Adjwilley (talk) 17:15, 7 September 2012 (UTC)

Discussion

Wow... This would be awesome for trying to identify socks. It would be a lot of programming (sorry—I can't help either), and I wonder if there would be privacy issues. I guess not though, since this data is public. David1217 What I've done 03:37, 9 September 2012 (UTC)
All these data are public because it has already published at Toolserver in some scripts (definetely for time between edits in certain articles, intersection of contributions). ♪ anonim.one ♪ 08:26, 9 September 2012 (UTC)
The problem, of course, is that sockpuppeteers will adapt to the algorithms of the program, rendering it useless. :-) Ed [talk] [majestic titan] 05:53, 9 September 2012 (UTC)
Old classics -- criminals invent new ways to rob money from safes, safe manufacturers have to invent new ways to protect safes and this continues indefinitely. But this program should be intended (as for me) for detection of obvious socks who are stupid enough for editing the same articles as their owners have edited early, making statements similar to their owners' ones, maybe harassing of particular users their owners have been in conflict early etc. Serious socks are unlikely to make such mistakes. ♪ anonim.one ♪ 08:26, 9 September 2012 (UTC)
The community needs to get more comfortable with statistics and tools to improve the efficiency of all the things we're doing by hand. Do it! - Dank (push to talk) 11:15, 9 September 2012 (UTC)
He can't do it, that's the problem :-( ♪ anonim.one ♪ 12:19, 9 September 2012 (UTC)
@Ed, sure there may be some die hard socks who will pick through the program or scour the documentation and then set up a different schedule for each sock and try to utilize different writing styles, but it will be pretty darn inconvenient for them.


@Dank, If I thought I had any chance of being able to write this myself I'd already be doing it. Unfortunately I don't know any programming languages at all, unless you count stuff like Matlab. ~Adjwilley (talk) 14:21, 9 September 2012 (UTC)

Here are some links to help:

These tools may be used as a part of your plan. Anyway, you should search for an owner of Toolserver account because it's better to work with data you need on Toolserver as I suppose. ♪ anonim.one ♪ 15:38, 9 September 2012 (UTC)

Wow, thank you. Those links are great, and the last one is golden. Just looking at the one chart that has day of week on one axis and time of day on the other makes me wonder if I can do 2-dimensional correlations. It looks like User:Scottywong wrote one of those tools, and it's on toolserver with with a bunch of other stuff he wrote. I'll try contacting him (though by the looks of his talkpage he's currently taking a break). ~Adjwilley (talk) 21:27, 9 September 2012 (UTC)

doubling the rate of human innovation

Dear Mr. Wales,

Today I feel the need to applaud your vision. You have given the world it's most significant invention of all time. Worldwide access to knowledge. The reason why your vision is greater than the sum of all man's other accomplishments?

Knowledge. Knowledge begets knowledge. Without learning from those before us we are unable to progress. Knowledge of the world spread through the world will ultimately lead to peace.

They say that the human mind uses a small percentage of its capability. Imagine if that number was increased by even just a fraction.

Statistically there is .047% of researchers in the world compared to the population. One could argue using the Rule of 72 that knowledge will double in 1500 years. What if 1% of the population contributed to the process? In 72 years the sum of man's knowledge will have doubled.

Imagine a world if the collective of minds descended on a single scientific matter. Theoretically there would be billions of solutions. Perhaps almost all useless. But that open dialogue may spark an idea in somebody somewhere.

Is it possible to cure all of man's ailments with this model? I believe so. Today all research is done by a few people. It is done essentially in secret for the sole gain of fame and profit. That is rather sick in a sense. To deny millions of people a satisfying life so that one could live in his own bubble of greatness.

You have a worldwide infrastructure for allowing the world to come together. I believe in a matter of days you could create this virtual collective body. A simple link to a page where people could list off matters of importance. People would begin to populate it with ideas. Other people might build on those ideas.

Who knows what may become of this. A few hours of your time may lead to some of the greatest advancements in humanity.

Imagine if you wrote one page and said to the world "Solve this problem."

Sincerely,

C.S. Sobo — Preceding unsigned comment added by Csgcraig (talk • contribs) 13:47, 9 September 2012 (UTC)

  • Absolutely fascinating, but I'm not sure this is the place for it. You might be better off approaching the Wikimedia Foundation, or by requesting to start a new wiki within the foundation, to join the likes of Wikipedia, Wikisource, and Wikiquote. Wikipedia, if you are successful, could be used to spread the word and to encourage non-user researchers or random, potentially interested people to take part in the discussion which you propose. Again, your ideas are quite interesting and the best of luck with your project! dci | TALK 19:56, 9 September 2012 (UTC)

REQUEST TO EASE UI

it would ll be heplfull if the mouse when pointed on LINK(wiki words)gives a mini explanation under it(mouse) — Preceding unsigned comment added by Manu2mech (talk • contribs) 13:30, 10 September 2012 (UTC)

Registered users like you can enable "Navigation popups" at Special:Preferences#mw-prefsection-gadgets. PrimeHunter (talk) 21:00, 10 September 2012 (UTC)

Tool to find requested_photographs pages that actually have a photograph

I have found that about 30% of the articles marked as missing a photograph actually have a photograph, but the person who added the picture did not know about the "requested_photographs" mark. Is there a script somewhere to find all such pages? I would then check manually whether each mark is valid or obsolete. The problem with obsolete marks is that it wastes photographers' time, they might check their nearest map and go to shoot pictures in places that actually are already covered. Nicolas1981 (talk) 15:33, 30 August 2012 (UTC)

I could give this a crack when a new database dump goes up, I'm sure it would be fairly easy to process as we are searching a list of articles for an image file. I could perhaps do it by hand, but the weeding process is probably easier through a dump scan with actual hand checking to make sure that those images are relevant. Granted I'm still learning how to do this. ChrisGualtieri (talk) 05:12, 1 September 2012 (UTC)
There is a tool http://toolserver.org/~jarry/imagechecker/index.php?lang=en&category=Wikipedia+requested+photographs from Jarry1250. Rich Farmbrough, 13:12, 12 September 2012 (UTC).

Bot to notify article talk pages of DYK and other stuff

Hi. Someone nominated an article I created for DYK. Unfortunately I only found out after the request was rejected. I was wondering if there was some way to have a bot leave a message on the talk page so that interested editors could find out that the article has been nominated for a DYK or to appear on the front page or FA and so on. Hope that's clear enough, Hiding T 17:37, 13 September 2012 (UTC)

BLP-Like Policy for Companies

Should we create a policy comparable to the BLP policy, but for companies?

Rationale: Not because companies are comparable to people, or that they are made up of people, but because it will improve our content merely by better-enforcing pre-existing content policies on a set of articles subject to extensive bias issues.

Additionally, I find it silly to invite paid advocates to lobby for neutrality, rather than empower the community to be more careful using impartial volunteer editors.

Ideas for things that could be included in the policy:

  1. Controversial or contentious material that is poorly cited should be removed quickly
  2. When presenting all viewpoints on an issue where a company is involved, the company's viewpoint should be included, when documented in secondary sources.
  3. In most cases, Criticisms should be put into a balanced "Reception" section.In most cases, contentious material should be balanced with positive information as appropriate based on reliable sources.
  4. We should be cautioned to be factual in controversies and avoid bias activist sources
  5. Controversial issues should be covered in substantial depth by multiple independent sources to be included in most cases. (depending on the general notability of the subject)Multiple independent sources that cover the issue in substantial depth should exist to establish notability for inclusion of controversial issues.

User:Corporate Minion 17:18, 2 September 2012 (UTC)

I changed from bullets to numbering in order to help reply more easily. (1) I completely agree with, and think it's already in the WP:V, WP:NOR and e.g. the WP:REDFLAG policies. (2) Seems problematic, because most of the time, the company's viewpoint is going to be published by the company. We could recommend that editors try to find independent sources representing the company's viewpoint. (3) "Reception" seems to be for things like movies, albums, and events. I can understand why you might want to avoid "Criticisms" and/or "Controversy" but those are the words used in the vast majority of existing practice for that kind of thing in articles on organizations. I can't think of how you might overturn that practice going forward. (4) We should also encourage editors to try to find independent reporting of detractors, which is usually pretty easy for major controversies, when reporters will write stories on both the criticisms and the company's reaction. There is an inherently subjective issue here where one person might think a group is biased activists, and another might think they are objective muckrakers and it's the company which is biased. I don't think you're likely to be able to resolve that, and certainly not with a policy which always comes down on the side of a company being criticized. There's no other way to uphold WP:NPOV. (5) I completely agree with, but how are you going to recommend enforcing it without ending up in the situation where people can't make incremental edits on a company controversy? —Cupco 20:47, 2 September 2012 (UTC)
I made some changes above. I would imagine much of this could be worked out in the details of the policy or by the judgement of editors on a case-by-case basis. User:Corporate Minion 02:40, 3 September 2012 (UTC)
I would very strongly oppose any extension of blp-like policies to other than living individuals. The basic policies of NPOV (etc) cover it. There is reason for being extra careful with BLP, mainly as a matter of empathy with other individuals and possible harm to known people, and a civilized decision to give them the benefit of the doubt--but I do not feel that way about inanimate entities. Indeed, I think that the present use of BLP policy sometimes goes too far in terms of Sympathetic Point of View, the negation of NPOV, This proposal is way too restrictive. We are already pretty good at removing unsourced material of this nature, though there is some left over from earlier. What is needed isn ot new policies, but more work aty checking articles and edits. All the policies in the world do no good without that. DGG ( talk ) 04:40, 3 September 2012 (UTC)
Concurring with DGG on BLP, I feel the normal PROD is quite adequate for companies. More important is to encourage page patrollers to do a thorough job, understand that speed of patrolling is not of the essence, and then tag appropriately. Wise patrollers will have configured their PROD and CSD logs and will check back regularly to see if their PRODS are still blue-linked and have been removed with the addition of more spurious 'notability' links. Kudpung กุดผึ้ง (talk) 05:58, 3 September 2012 (UTC)
From my point of view we do a very poor job with NPOV, balance, etc. on company articles, but I have a very bias perspective as I typically see the worst of it. User:Corporate Minion 07:51, 3 September 2012 (UTC)
  • In most cases, contentious material should be balanced with positive information as appropriate based on reliable sources.; please, please no! How many times do I see people saying this. Neutrality is not about balancing good and bad in an article; it is reflecting the material in sources with due weight. Which means if the vast majority of sources deride the subject of an article then we cover this. Neutrality means we a) do this fairly and b) do it without vitriol. --Errant (chat!) 08:41, 3 September 2012 (UTC)
I'm not sure that is going far enough. A company is almost always going to produce professional looking public relations material defending themselves in a scandal, even when the evidence that they are in the wrong is entirely overwhelming. In such cases, even giving what most people would consider due weight to the corporate point of view is probably contrary to WP:REDFLAG where extraordinary claims require extraordinary evidence. A good example of this was when Progressive Insurance recently paid to defend one of their customers' killers in a court trial to determine liability. The public relations issuances from the company included blatant falsehoods, one after the other, for several days until the parties settled, involving a very much more substantial payment by the company than was their nominal obligation before the controversy. Giving due weight to both sides of the story in "he-said, she-said" format would be far worse than noting that the company's claims about not having joined the trial as a defendant were contradicted by public court records. —Cupco 22:03, 3 September 2012 (UTC)
I don't think that we should implicitly distrust "professional looking public relations material defending themselves in a scandal". Their view IS a valid and significant view, after all. Mythpage88 (talk) 22:57, 3 September 2012 (UTC)
Not if, as I wrote following that excerpt, the evidence that they are in the wrong is entirely overwhelming. —Cupco 23:17, 3 September 2012 (UTC)
So suddenly the viewpoint becomes less than significant? We include significant views, not just iron-clad, indisputable views. Mythpage88 (talk) 23:21, 3 September 2012 (UTC)
Please see WP:UNDUE, WP:REDFLAG, WP:VALID, WP:FRINGE, etc. —Cupco 00:06, 4 September 2012 (UTC)
  • To be clear, are we just talking about adding/adjusting some aspirational goals, or are we also talking about creating new mechanisms for enforcement? Monty845 22:24, 3 September 2012 (UTC)
  • Some copy edits:
    4 We should be cautioned to be factual in controversies and avoid biased, activist sources.
    5 Multiple independent sources that cover the issue in substantial depth shouldmust exist to establish notability for inclusion of controversial issues.
    And a suggestion:
    3 In most cases, cContentious material should be duly balanced with positive information as appropriate based on reliable sources.
    Jojalozzo 22:44, 3 September 2012 (UTC)
Joja, that is peerrrfect.
Lets take this through some examples. Under this policy, we might:
  • Discuss removing the coverage of the same-sex marriage controversy on the Starbucks article, if it is not covered in multiple sources.
  • Looking at the old article on Credit Suisse we would not write as if we are presuming Credit Suisse is guilty, or use words like "scheme" and "naked greed" for the 2009 lawsuit.
  • We would not presume Progressive is lying, but document the statements they made, the accusations that they are lying, and the evidence that they lied.
  • It would be a best practice to balance controversies with corporate citizenship when doing is an accurate representation of reliable sources.
I'm thinking that it wouldn't be much of a new policy, but more of an understanding on how NPOV applies to corporate situations. Maybe even just an essay. I feel we should not presume companies are guilty or lying, nor should we favor controversies over charity. Corporate Minion 00:12, 6 September 2012 (UTC)

Draft

Thoughts? WP:NPOVCORP Corporate Minion 13:54, 6 September 2012 (UTC)

It's certainly interesting and well put-together. I'm struggling, however, to understand precisely where these guidelines are more strict than the normal NPOV guidelines. Are not these guidelines equally applicable for all articles? I think the reason we have BLP guidelines is very clear: potential legal jeopardy. Applying a similar set of standards to an area where no such threat exists does not make sense; there's no reason to unduly restrict the project where such a restriction may go more in the direction of limiting discussion about contentious material than encouraging an informed consensus on such issues. But it appears that the proposal now is to enact a set of guidelines that don't rise to the level of a BLP warning, and as I said, it's not apparent to me how these guidelines are more stringent than the ones that apply generally across all articles. Could it be characterized as an amalgamation of existing guidelines that reflect policy on corporate articles? Or is that essentially already what it is? Sorry for the confusion. --Batard0 (talk) 14:11, 6 September 2012 (UTC)
Two different ideas. One is a BLP-like (but more modest) policy; the other is simply a reminder of how NPOV applies to corporations and perhaps an effort of some kind to follow it. Current content policies seem acceptable, when followed, but I wonder if a special reminder of some kind would be helpful. Corporate Minion 23:33, 6 September 2012 (UTC)
BLP is not about being sued. It is about behaving like a decent human being. Rich Farmbrough, 20:04, 11 September 2012 (UTC).
"Being a good corporate citizen, charitable works and business successes should be treated with equal weight, notability and verification requirements as other areas." No. These types of claims are not extraordinary and should not require extraordinary proof. Conversely they are also often unremarkable. The sentence as constructed could be construed as requiring their inclusion if they meet the same level of proof, as for example, the Bohpal disaster. For this sort of thing in general a much lesser level of proof is needed (if a company says 1,200 of its 20,000 workforce help children read during their lunchtimes, we should take it on face value).
As far as corporates and even small companies go, we are subject to the same laws concerning libel, the same rules concerning NPOV, UNDUE and WP:RS. I can see no reason for yet another guideline (although more essays... in theory should not be a bad thing). Rich Farmbrough, 20:04, 11 September 2012 (UTC).
Hmm... I will take another look at some more word-smithing. The idea is that we should not have a double standard, whereby we have very low requirements for including controversies, but very high standards for being a good employer, charitable works, etc. One of the most prolific forms of bias in volunteer-written corporate articles is that companies are defined almost exclusively by their controversies. Corporate Minion 17:43, 14 September 2012 (UTC)

As a Chinese User, I Have Something to Say

Is the US govermental documents, or by other reasons, that English Wikipedia using Senkaku Islands on all related articles over Diaoyu Islands? - Mr a (talk) (contrib) 14:13, 14 September 2012 (UTC)

The naming has been discussed a lot. One of the boxes at top of Talk:Senkaku Islands says: "Any discussions regarding the naming of this article or moving this article to a different title are forbidden until January 1, 2013". The main argument against Diaoyu Islands is that the English language Wikipedia has a long established policy to use names widely accepted in English language sources. See Wikipedia:Article titles#English-language titles and Wikipedia:Naming conventions (geographic names). This does not imply that Wikipedia takes a stand on who the islands belong to. We merely use the name readers of English texts are used to. Wikipedia's in other languages can choose another name. PrimeHunter (talk) 14:35, 14 September 2012 (UTC)

Dwayne Johnson fact incorrect

Dwayne Johnson (The Rock) stat for his physical height is not 6' 5" tall. There's a picture of him walking next to Mark Walberg who is only 5' 7" and Mr. Johnson looks the same height as Mark. Please correct this fact. — Preceding unsigned comment added by 173.61.182.135 (talk) 18:28, 4 September 2012 (UTC)

The article says it's his billed height and it is. Jason Quinn (talk) 15:01, 18 September 2012 (UTC)

External SSL Websites

Wikipedia needs to develop a policy regarding external URL links with SSL support.

For example, can Google search engine URL on the Google Wikipedia page use https://www.google.com instead of http://www.google.com? On some of the pages, such as Google, the links have already been converted to SSL. Some Wikipedia pages, such as Cisco support SSL but have not been converted to SSL.

There should be a consistent policy regarding adding external SSL support. Please chime in with comments or concerns. 64.128.27.82 (talk) 21:31, 5 September 2012 (UTC)

Why should there be a consistent policy? Https requests consume more resource, but might be considered appropriate in certain circumstances. Should this not be a matter for editorial discretion? Users who want a consistently secure web interface should be addressing this problem client side, (maybe even blocking port 80 in favour of port 443). Rich Farmbrough, 19:39, 11 September 2012 (UTC).
HTTPS Everywhere will save your soul, Brother Rich. —Tom Morris (talk) 01:13, 19 September 2012 (UTC)

A way to track how long it's been since the stats were updated

I don't have the know-how to create something to do this, but it would be beneficial if there was a page for WikiProject Baseball members to consult that could list which baseball player articles had gone the longest since having the stats updated. Basically, the way to accomplish this would be to take the date listed in the "stat_year" field in the baseball player infobox and have a page where you could see which "stat_year" fields had a date that showed it had not been updated recently. Of course, this would require a way to differentiate between active and inactive players, which perhaps could be to exclude pages that have an empty "team" field in the infobox or a blank "stat_year" field. I'm not sure how this kind of chart could be created, but it would enable me to know which pages are most in need of updating stats-wise. AutomaticStrikeout 01:52, 4 September 2012 (UTC)

Does anyone know if this idea is feasible? It would be helpful to me in updating the stats to know which pages are most in need of updating. AutomaticStrikeout 19:51, 5 September 2012 (UTC)
Yes, it is eminently feasible. Three methods might be used:
  1. a regularly generated report
  2. a category which is sorted by age
  3. a category with sub-categories for each month/year
All these systems are in use for one purpose or another. Rich Farmbrough, 12:27, 12 September 2012 (UTC).
Ok, good. However, like I said, I don't have the know-how to make this work myself. I'm asking because if someone else could set it up, the editors who update stats could find it helpful. AutomaticStrikeout 20:07, 12 September 2012 (UTC)
Perhaps asking at Wikipedia:Bot requests — Frankie (talk) 20:22, 12 September 2012 (UTC)
But what could a bot do? The stats have to be updated manually, I need a page that can rank the active baseball players by what time the stats were updated, which ideally is reflected in the stat_year infobox field. In what way would a bot be helpful? AutomaticStrikeout 20:32, 12 September 2012 (UTC)
I was thinking that the bot could check whether there are players that meet the requirements, and include/remove them from a page for editors to know they need updating, not that the bot would update the biographies themselves (similar to what is done by a bot at Wikipedia:Community portal/Opentask). I understand that's what Rich meant above by "a regularly generated report" — Frankie (talk) 20:42, 12 September 2012 (UTC)

Take a look at User:Legobot/Baseball. I generated it based on the first 5000 transclusions of {{Infobox MLB player}}, then filtered out players which were "retired" players. I didn't sort by namespace so userspace drafts will show up, however I can easily change that. Obviously this doesn't cover all baseball players, but as a quick example it works. I can easily expand it based on other templates/categories. LegoKontribsTalkM 23:26, 12 September 2012 (UTC)

Thanks. That looks like it will be helpful. Sorry for the delay in responding. AutomaticStrikeout 23:46, 15 September 2012 (UTC)
No problem. Let me know when you want it re-run and if you want a larger sample size. LegoKontribsTalkM 02:02, 19 September 2012 (UTC)
Yes please. A larger sample size would be nice. AutomaticStrikeout 18:00, 19 September 2012 (UTC)

RfC for differentiating text in the editing window

Based on the previous discussion here on whether syntax like references should be colored differently than other text in the editing window, I have opened up an RfC on the proposal. My intention is to ensure this proposal is as visible as possible, because it would be a change that affects all Wikipedia editors. The intention behind it is to increase accessibility in general editing to new users and to make navigating through articles easier for both new and experienced editors, particularly on articles with hundreds of references. If you are interested, I encourage you to participate in the RfC. Thank you. I, Jethrobot drop me a line (note: not a bot!) 23:54, 20 September 2012 (UTC)

Flag for later reading

If only a tool were available that, like the watch-list could list pages to be read at a later time and as convenient. Sure, a subpage could be created to list said pages, or the links be stored on file, but contributing from multiple place limits the feasibility of Op. #2 and that of Op.#1 will lead to multiple edits, additions, deletions, possible repetitions and increased page size. Tools anyone? --HarshAJ (Talk)(Contribs) 18:56, 21 September 2012 (UTC)

See Bookmark (World Wide Web) ;)
More seriously, see Wikipedia:Village pump (proposals)/Persistent proposals/Archive 3#Multiple watchlists, and the most recent iteration of that perennial suggestion, Wikipedia:Village pump (proposals)/Archive 92#Multiple watchlists. Yah, there is 100% support for this idea, which many people have wanted for many years - it just needs all the actual work of coding... Let us know if you find anything fresh :) —Quiddity (talk) 21:09, 21 September 2012 (UTC)
Bookmarks. 1000s of them! No can do! --HarshAJ (Talk)(Contribs) 01:44, 22 September 2012 (UTC)

Astrobiology Portal

Should there be an astrobiology portal? I tried making one myself in my sandbox, but, being a new user, I can't get it right, so maybe I'll leave the project to other wikipedians (of course if this portal is created, I'll contribute). Can we reach a consensus on the yea or nea of creating an astrobiology portal?--Jacob.husted (talk) 17:18, 25 September 2012 (UTC)

Temporary warnings for article abuse (especially by spammers)

I feel like I'm supposed to apologize for being an extremely casual contributor to Wikipedia and for not wanting to get more deeply involved. Though I have a fairly concrete proposal, and will include some details here, I don't particularly want to get involved that deeply, so I feel like I'm posting it here both for refinement and in hopes of finding an advocate who likes it and wants to run with it. Good luck and more power to you. Though my writing may mislead some folks, I don't actually like advocacy... (And yes, I checked in both the persistent and perennial proposals and couldn't find it with a number of searches.)

The problem: Spammers use Wikipedia to gain credibility for their scams. A spammer may do this by tailoring the scam to match the information in an article, and then cite the article in the spam. However, I also suspect that they sometimes vandalize the cited articles to create details that they can exploit in their fraudulent pitches. The spamming scammers are exploiting and damaging Wikipedia's reputation in hopes of getting money.

Suggested solution: A new temporary warning tag something like the "recent death" tag. The tag would be added near the beginning of an article that is cited by the spammer. There could be an option to tailor the warning to the spam, but I don't think that is really needed. It would be sufficient if it is a generic warning such as "This article is being cited as support for a 419 scam" with the obvious link to the page on 419 scams. Or maybe it should just say "possible" instead of "419" and the link would be to a higher level topic on Web-based fraud?

Suggested implementation: As unobtrusive as possible. There should be some way to manually activate the button for this feature, but it would be especially nice if it could be triggered automatically, perhaps by detecting that the link has been followed from an email website. Maybe if the same link is followed from several email websites within a relatively short period, then it would more prominently display the button with a label such as "Do you think this article is being cited for questionable advertising?" The click would add the warning for some period, perhaps a day or two for normal spam. Shanen (talk) 07:17, 20 September 2012 (UTC)

We have Template:Coi Template:POV and Template:Advert which come close to what you are describing. Are you familiar with those tags? Or do you want a tag that is more specific than those? ThemFromSpace 20:33, 20 September 2012 (UTC)
I'm afraid not, though obviously spam is a kind of 'advert'. Should I clarify that they are NOT (as far as I know) actually putting the advertisement in the article. I am certain that they are attempting to milk the legitimate information as part of their scam, drawing on the skeleton in Wikipedia. From there the spammers can easily embellish their scam, but they also have the temptation to vandalize Wikipedia more actively, for example by embedding useful hints in the article as teasers.
Though I have been participating in Wikipedia for some years, I've never gotten that proficient with the templates. However, if the advert template is what I think it is, basically a warning that the article sounds like advertising, then I don't think it really sounds suitable. I am suggesting something more similar to the warning that 'This person has recently died, and details involving the death are liable to change.' This warning would be more like 'This article is currently being cited to support a scam', possibly with such juicy details as 'The Russian prince in your spam was NOT assassinated in Nigeria while carrying any money for you.'
The focus of my suggestion is more an interface issue, actually. Some way to detect the abuse and make it easy to warn potential victims. As soon as the spammers know Wikipedia has such a mechanism, they will realize it is pointless to abuse Wikipedia in that way. (However, being sociopaths, they will simply look for other rocks to crawl under. I'm not suggesting the spammers will ever become decent human beings.) Shanen (talk) 06:10, 21 September 2012 (UTC)
So are you thinking of something more like a cosmetic surgeon sending out a note saying "Read all about this new technique for face lifts at the 100% independent Wikipedia" (secretly re-written by yours truly to decrease mention of side effects and increase the odds that you'll cough up the bucks), or are you more thinking of something that's actually a scam? WhatamIdoing (talk) 22:09, 24 September 2012 (UTC)

<-I think what the OP is saying is that regular email spammers/scammers are using links to Wikipedia articles in their messages in an effort to make them appear more legitimate. -Versageek 03:30, 27 September 2012 (UTC)

Yes, that's a good summary. It isn't such a common technique, though I've seen it before and this particular spam campaign did go on for several days. The spam claimed to be written by the subject of the Wikipedia article, and then he fleshed it out with some sob story about how he needed help with money or whatever. I'm sure it was a typical 419 scam, though they seem to be relatively less common these days (which presumably reflects on their low profitability for the spammers). Actually, judging by the amount of spam abusing the source, the spammer's evidently think that Wikipedia has a much lower credibility than the BBC (or maybe my adding warning on previous occasions has annoyed them?). I just think there should be a standard and relatively convenient way to add such a warning... I'm sure it's a form of abuse of Wikipedia, but a different kind. Shanen (talk) 06:52, 28 September 2012 (UTC)
I'm not convinced that free advertising of our normal articles (not articles that have been damaged by the spammer) is really "abuse of Wikipedia". WhatamIdoing (talk) 16:35, 1 October 2012 (UTC)

Contributions private?

There should be a way to make your contributions private on Wikipedia in case you don't want everyone to view them. — Preceding unsigned comment added by 76.111.252.99 (talk) 19:21, 26 September 2012 (UTC)

That would sort of go completely against our basic ethos and principles. Ironholds (talk) 19:46, 26 September 2012 (UTC)

Why? — Preceding unsigned comment added by 76.111.252.99 (talk) 19:55, 26 September 2012 (UTC)

Because Wikipedia is an open project. Our mission is to make the world's knowledge available to everyone and anyone, for free, in perpetuity. We can't do that if we basically introduce firewalls around some pages or some edits.
If instead of segmenting things you mean "make it so that articles are public, but who wrote what is private" - that would violate the copyleft license our content is released under, which requires us to attribute content to authors. Ironholds (talk) 20:00, 26 September 2012 (UTC)

No, if you click view history the author will show up. but if you go to their user page and click view contributions theyll say private. — Preceding unsigned comment added by 76.111.252.99 (talk) 20:02, 26 September 2012 (UTC) Its jus t the list thats private — Preceding unsigned comment added by 76.111.252.99 (talk) 20:04, 26 September 2012 (UTC)

That removes a huge part of how Wikipedia works - the checks and balances.--Jorm (WMF) (talk) 20:14, 26 September 2012 (UTC)

I wish there was a way to perform an experiment to see whether the benefits of eliminating stalking outweigh the drawbacks of this aspect of transparency. Don't dhcp-hopping IP users effectively have this anyway? —Cupco 20:45, 26 September 2012 (UTC)

You can make your edits private by registering an account. There will then be no IP address displayed with your edits, and no way for people to know who you are. Some of us are happy to use our own names for our accounts, but there is no requirement to do so. Phil Bridger (talk) 20:49, 26 September 2012 (UTC)

I think the OP means private from wikistalkers, which are a huge problem. There's no prohibition against scrutinizing all a user's edits and reverting everything even vaguely marginal at the slightest hint of a grudge, and it happens far too often. Since there are plenty of IP-hopping DHCP users immune to that tactic, why shouldn't registered users be, too? How about if only admins could examine user contribution histories directly? —Cupco 22:53, 26 September 2012 (UTC)
That would be an incredibly bad idea. Most reversion of vandalism or other unacceptable edits is done by non-admins, and, if an editor has made one bad edit, it is perfectly reasonable that we should be able to check whether other edits need to be reverted. What is this "huge problem" with wikistalkers, particularly if you choose not to edit using your real name? We have perfectly good procedures for dealing with° abusive behaviour. Phil Bridger (talk) 23:30, 26 September 2012 (UTC)
I gather you've never had to use them. —Cupco 03:11, 27 September 2012 (UTC)

Or maybe you could make your userpage private? — Preceding unsigned comment added by 76.111.252.99 (talk) 23:41, 27 September 2012 (UTC)

You are not required to have a userpage at all. You, for example, don't have a user page. It would be at User:76.111.252.99 if it existed. You are only required to have a user talk page, so that other people can post messages for you (and others) to read. WhatamIdoing (talk) 16:40, 1 October 2012 (UTC)

Expansion on Naming articles with contraversial names

I recently noticed that certainn articles such as Fun (band) and Awkward (TV series) would state or use to state "stylized as (enter actual name here)" in the header. I personally find it very controversial because it implies that the names are merely stylized and not actual name.

So even though "fun." is the most common and official name, the article uses "Fun"suggesting that Fun is the most common spelling of it . There needs to be a way for situations like this to be made clear that the only reason we cant use names like this is for sentence structure issues only. For one, avoiding saying "stylized as" unless other versions differs from its actual name. And if the most common name isnt the official name, it should still be made clear what the actual name is. Or allow these articles to have some exception to be named "fun." or "Awkward." but directly staye that we remove the period due to sentemce structure issues in some sort of tag.

That said i think we should make it clear by expanding the MOS on trademark names on how do handle these situations. There seems to be a misunderstanding that of a name isnt within traditional english ortography, then it is a stylized name. But names have nothing to do with that. Also please excuse any typos. I am doing this all on smart phone.Lucia Black (talk) 04:58, 27 September 2012 (UTC)

Hi Lucia,
This all reminds me of the urban legend that if you get convicted of a crime, but the court paperwork types your name in ALL CAPS, that the conviction is for some other person and you're free to go. Or that if the tax authorities send you a bill, but they type your name in all caps, then you personally don't owe any money, because your true name is in mixed case.
All of which is a long-winded way to say that "Fun" and "fun" are the same names, as are "Toys R Us" and "Toys Я Us". We don't follow the marketing department's choice of style because it's not necessary under English rules of orthography. WhatamIdoing (talk) 16:48, 1 October 2012 (UTC)

Major event outcome updates

Sometimes I see sections about corporate fines (example: Libor scandal#Barclays Bank fined for manipulation) or criminal convictions that end with "...was fined $100 million dollars..." or "...was convicted and sentenced..." etc.

Oftentimes, the fine is appealed and no money is ever paid, or the person doesn't end up going to prison.

Do we have a system of keeping track of such high-importance events so we can check back and add the ultimate outcome to the article? Anna Frodesiak (talk) 10:42, 28 September 2012 (UTC)

I know about Template:Out of date, but does that really help? If this is all a jugheaded idea, please say. Anna Frodesiak (talk) 11:02, 28 September 2012 (UTC)

You can use {{As of}} to mark sentences that might need to be updated later. Whether anyone will actually update it is an open question. WhatamIdoing (talk) 16:57, 1 October 2012 (UTC)
Hmmm, okay. Thanks for the input. I guess that's a reasonable system. I will check to see how much followup gets done. Many thanks, Anna Frodesiak (talk) 00:07, 2 October 2012 (UTC)

Timeline with links to main text

I am not sure whether this proposal violates any style guidelines, otherwise I think it could be a good idea... For articles that describe chronological events (e.g. historic events, people vitae,...) I propose to have a timeline in addition to the (potentially long) text with links to the relevant text section. This way busy readers could quickly find the part that interests them. I could create this timeline manually using footnotes, but perhaps even better would be a graphical layout. It would be good if this timeline creation required very little work or programming skills of the editor. bamse (talk) 19:28, 28 September 2012 (UTC)

For large time scales, we have Template:Ma which can create handy links such as: 3,600 million years ago and 400 to 30 million years ago.
I don't think we have anything as simple, for human-civilization time scales.
We do have Wikipedia:EasyTimeline, which is very powerful, but that's quite laborious and convoluted to use.
(We've always wanted more options though. See dozens of old requests, eg 1, 2, etc, and a current proposal at VPR).
HTH. —Quiddity (talk) 21:26, 28 September 2012 (UTC)

Sorry for not being very clear with my proposal. The links should not point to other wikipedia article, but should point to sections or anchors within the same article where the respective date is discussed. For instance I have a text: In 1900 happened event one ... In 1923 happened event 2 And a timeline in the same article with links to the text like:

What I propose is to i) have a prettier timelin; ii) Have some easy and consistent (template!?) way of creating such timelines+links. As far as I can see this is different to other proposals. bamse (talk) 21:38, 28 September 2012 (UTC)

Complex ideas are hard to describe! :) Are you suggesting that the list-format section would be auto-generated, based on the prose-format sections being wrapped in appropriate tags? I'm not sure what content or links you specifically want. Perhaps if you made a larger example, in your sandbox, using a lot of lorem ipsum to stand in for paragraphs and list item content...? —Quiddity (talk) 06:07, 1 October 2012 (UTC)
Yes, the timeline should be auto-generated based on some markup in the prose text. The timeline can be a simple list, or preferably something fancier. The timeline could appear at the end of the article or (only if found useful) in other locations such as article's talk page, infoboxes,... I want links from the timeline dates/events to the main text where these events are described in more detail. I created an example article in User:Bamse/timeline-proposal; bold facing is purely for visibility and not part of this proposal. bamse (talk) 18:42, 1 October 2012 (UTC)
It's a grand idea, but the gritty details of implementation are correspondingly complicated. There's really no easy way to automagically have Mary Wollstonecraft create something even half as impressive as Timeline of Mary Wollstonecraft. Too many contextual decisions, which would each be argued over if automated (Eg. "x is the best way to write the sentence for this paragraph, but y makes more sense when that sentence is transcluded into the timeline...").
I think you're/we're stuck with manual labour, until the AI overlords rescue us.
If you do still want to pursue it further, then the microformat project, and something akin to {{start date}}, might be a way forward. The main objection will be the added complexity it brings to the editing interface (Moar templates! oh noes!). HTH. —Quiddity (talk) 21:47, 1 October 2012 (UTC)

Print/export "epub" support‏

Hello there, EPUB is a free and open e-book standard and it is supported by all the e-book readers avaiable in the market (while pdf format is not). It would be better if we can export the wikipedia articles/books in epub format as well. Thank you.Uttam Pal 16:09, 19 September 2012 (UTC) — Preceding unsigned comment added by Uttam Pal (talk • contribs)

We enabled EPUB support 3 days ago; when you create a book, it should be available under the download options.--Eloquence* 07:05, 20 September 2012 (UTC)
"supporter by all the e-book readers avaiable in the market". Actually, I think you'll find the Amazon Kindle doesn't support ePub. Mobipocket files would be useful too. —Tom Morris (talk) 09:22, 24 September 2012 (UTC)
Unlike the Mobipocket format, ePUB is an and open format. Furthermore, there exists free software, like the application calibre, that can convert ePUB books to Mobipocket format books suitable for reading on the Amazon Kindle. -- Lunasspecto (talk) 20:20, 2 October 2012 (UTC)

Citation collapse option

What do people think about an option (a button at the top of the page, perhaps) that would collapse or hide citations for easier reading? This, it seems, might be useful for reading featured articles that will likely be fully sourced or just in general as an option for people who are reading but aren't interested in checking out the verifiability of the information, at least at that moment. There are plenty of articles that have unwieldy lists of citations for the same facts/sentence, which may be essential to support the information but are a burden for casual readers. Hence I think it'd be nice to have this option, not as a default but as something you could choose. Any thoughts? --Batard0 (talk) 13:14, 2 October 2012 (UTC)

Help:Reference display customization#Reference list for a scroll option. ---— Gadget850 (Ed) talk 14:56, 2 October 2012 (UTC)
Remember that nearly all of our readers are unregistered, so can't customise CSS. A button could (I think, although my involvement with software stopped before such things as CSS were invented) allow inline citations to be suppressed on a per-article basis, giving a much more user-friendly presentation for those who simply want to read the scintillating prose in this encyclopedia. While we're at it such a button could also hide maintenance templates, again on request on a per article basis, so people would still see that they have the option of improving the article. Phil Bridger (talk) 18:00, 2 October 2012 (UTC)
Good idea to also hide maintenance tags and templates -- it could, as you say, be something done on request on a per-article basis, in the manner of page protection. I think it could reasonably be made automatically available for FAs given the obvious lack of likely concern about citations. I also don't have any idea how this would be coded or whether it would be difficult to do so. --Batard0 (talk) 13:30, 3 October 2012 (UTC)
The main question to consider would be the likelihood of use. Page "real estate" is very valuable, and we'd have to be sure that the option would be so widely used that it would be worth cramming in another button/tab/link on every page. How would you go about finding that out? Qwyrxian (talk) 22:55, 4 October 2012 (UTC)
That's a good point. I don't think it would be proposed for all pages, just where it's considered appropriate by consensus. Would people use it? It's hard to say without actually having it as an option. I know I'd use it on articles where I'm interested simply in reading FAs, for example, because I know they're going to be pretty well sourced and citations stringed together are a bit of a distraction. --Batard0 (talk) 10:25, 5 October 2012 (UTC)

Opinions needed: Mass-semi-protection or mass-merging?

I'm looking for some second opinions on this problem. A while ago I stumbled upon a series of many hundreds of templates that each hold the election results of one electoral district of one election in Canada, such as Template:Canadian federal election, 2006/Electoral District/Edmonton—Strathcona and Template:Canadian federal election, 2008/Electoral District/Ottawa Centre. The purpose of these is to ensure that articles about each candidate and the article about the district are in agreement. My concern is that few if any editors will add every single one of these to their watchlist as new ones are spuratically created, so many of them likely only have one watcher, and subtle vandalism could go undetected for years until someone bothers double-checking the numbers. I see two options for better protecting these templates: (1) propose an amendment to Wikipedia's protection policy to allow preemptive mass-semi-protection for any small template that rarely have to be edited, or (2) merge all of these pages together into a few giant templates that allow articles to access any one results table using a switch command. Which of those ideas is better, or is there another option I haven't thought of? —Arctic Gnome (talk • contribs) 03:18, 6 October 2012 (UTC)

  • Draft a list of them, which would be required to protect or merge them, and ask a group of like-minded editors to import the list into their watchlists. Alternatively, create a userspace page with the list in it, and periodically do a related changes check on the page, if they are that inactive, you should not have many diffs to check. Absent evidence that someone is targeting the set of templates for subtle vandalism I don't think preemptive protection is justified. Monty845 04:21, 6 October 2012 (UTC)
    • I've never made much use of the related changes feature, but that idea makes a lot of sense, thanks. Do you know if there is a way to check for related changes of articles in a subcategory of a category? There are dozens of categories, so if I could check all categories at once for changes and new pages, that would save me some time. (Alternatively, I can modify the template that makes the tables to put them all in one giant category.) Also, do you know if there is a way to look for related changes more than 30 days back? I tried changing the number of days in the URL for related changes of Category:2008 Canadian federal election ridings, but no matter what number I put, it still only shows me the changes made within 30 days. —Arctic Gnome (talk • contribs) 04:46, 6 October 2012 (UTC)
  • A single template that uses switches to show a specific riding would be massive, and therefore a detriment to every article it is placed in. Resolute 04:27, 6 October 2012 (UTC)

Deletion logs are overly intimidating

I've never liked the enormous deletion logs at the top of the edit windows such as at Viddy or the ones at on protected pages like here (why are those red anyway?). I think their presence has impeded the creation of many notable articles. For example, Pinterest was among the 500 most visited pages on the Internet (for comparison, wikihow is currently ranked 471) by the time I re-wrote the article in August 2011 (see the page view chart for that month). I propose that the red background be changed to white with the dark-ish red border being left unchanged. There really isn't a reason for it to command any more attention than is necessary for the average reader to notice. Marcus Qwertyus (talk) 10:49, 3 October 2012 (UTC)

I'm pretty sure most deletions are for notability, i.e., the subject should not have its own Wikipedia article. I think it's appropriate to give a very strong warning to make sure that things have changed and that creating the article is now justified. Ntsimp (talk) 15:50, 4 October 2012 (UTC)
I agree with Nitsamp; the whole point of the message is to discourage recreation of articles, which will probably be the right position 99% of the time. Any experienced editor (such as yourself, Marcus Qwertyus) will simply ignore the box/color...the hope is that a newer editor will think a minute or two before trying to recreate something that was previously deleted. In other words, the color is a feature, not a bug. Qwyrxian (talk) 22:53, 4 October 2012 (UTC)
Nothing more to say than: agreed. —Tom Morris (talk) 12:10, 12 October 2012 (UTC)

Expand Wikipedia:Tutorial to an assessed tutorial?

I made a suggestion on Wikipedia talk:Tutorial#Expand to an assessed tutorial? and would be happy about feedback. --Pgallert (talk) 16:22, 9 October 2012 (UTC)

CSD tags

On the CSD tags, at the very bottom they say who last edited the article. Would it not make more sense to replace this, or expand this with who created the article especially as below that is the copy/paste code to place on the original author's talk page? Osarius - Want a chat? 07:45, 14 October 2012 (UTC)

It's impossible technically because MediaWiki doesn't have a magic word for this. However, everything is possible with some global Javascript code. ♪ anonim.one ♪ 13:48, 14 October 2012 (UTC)

Thematic orgs and User group recognition

Hi, I was following the approval process for Wikimedia Medicine as a Thematic organization, and started wondering if more Wikiprojects or groups on Wikipedia should consider some similar form of recognition. There is a category to be recognized as a user group, I wanted opinions if the Arbcom or some user groups here should start considering something like that or stay away from it all together. Theo10011 (talk) 11:38, 18 October 2012 (UTC)

  • I do not think this is the Arbcom issue, but what in any case would be good to have, formal or not, is more coordination between different language projects, in terms of translations, sources and other issues of common interest.--Ymblanter (talk) 13:47, 18 October 2012 (UTC)

Content Bar Modification

Dear Sirs

I need you to go through following steps ,I think this feature is easy to develop and much usefull to all wikipedia pages

First Step 1) GO To following page http://en.wikipedia.org/wiki/India

2) Contents section is usefull part of page but when you scroll down to culture(for above page) again you need to go back to top for getting index of page i.e content section

3) Solution On left pane every page are empty so to design a floating Content section Box in left of every page.

I can if you implement waiting for reply — Preceding unsigned comment added by 117.223.228.39 (talk) 07:12, 5 October 2012 (UTC)

You could just click the back button on your browser to get taken back to the content section.©Geni 02:39, 6 October 2012 (UTC)
This is actually a decent idea, although it might be hard to implement and clutter up the interface with floaty things. You can just click back, but then you need to examine the contents (at which point you may or may not find something you want to see) and then click that thing (if you find what you want). If it were a floating thing, you would 1) only have to click once instead of twice to shuttle between sections of longer articles and 2) would always have the contents of the article (its basic structure) on your screen, thus obviating the need to click back or scroll up to see if the article contains a section you want to read. --Batard0 (talk) 04:56, 6 October 2012 (UTC)
Actually - that's not a bad idea! Perhaps it could be made into a 'gadget' that logged-in users can turn on/off as they wish. The only restriction I can think of is space - on the left of the screen we have the internal links sections, but I suppose on an article that warrants a TOC there's enough room and text to scroll anyway. I shall link a member of the WMF to this suggestion. Osarius - Want a chat? 08:23, 14 October 2012 (UTC)
Are we talking a full floating TOC, then? I think a gadget would be the best place for that, yep. If you just mean a "back to top" button, that's actually on our to-do list, although at the moment I can't make any promises on timing :(. Okeyes (WMF) (talk) 03:28, 15 October 2012 (UTC)
Oh god. Floating sidebars are my second least favorite thing that people throw onto websites, right behind advertisements that flash or play music. Please do not do that. Sven Manguard Wha? 04:54, 15 October 2012 (UTC)
What else floats? Witches, and very small stones. Floating anything on a computer screen is infuriating. Burn it. Anna Frodesiak (talk) 05:15, 15 October 2012 (UTC)
Also rotting corpses. Rotting corpses float. Sven Manguard Wha? 05:39, 15 October 2012 (UTC)
And wood! And ducks! So if it weighs more than a duck, it can't float and this whole discussion is moot. RedSoxFan2434 (talk) 00:43, 17 October 2012 (UTC)
As per our Skype discussion last night, I have agreed with Okeyes to look into making a userscript for this, rather than embedding it into a gadget or into MediaWiki. If people wish to use it, then they can add it into their skin.js page. Watch this space. Osarius - Want a chat? 10:09, 16 October 2012 (UTC)
Good news! This has now been created. See User:Osarius/FloatingTOC. Osarius - Want a chat? 14:07, 16 October 2012 (UTC)
I like this and thanks for doing it. I'd like to put it on the right side of the screen instead of the left (somehow it feels like it'd be more natural there). Is there a way to make this an option or change the code? --Batard0 (talk) 05:41, 22 October 2012 (UTC)

Wikipedia Breakroom

Since my hasty and malformed proposal here is quickly approaching WP:SNOWBALL, I now realise that I should have first incubated the idea here (this is my first ever Wikipedia proposal). I think there is much merit in the proposal and that if presented in a proper way could gain some support, maybe not. ~ GabeMc (talk|contribs) 00:22, 25 October 2012 (UTC)

The current draft:

Proposal. - Wikipedia needs one talk page where any editor can speak freely (within reason) and vent complaints without opening themselves up to admin sanctions. Since admins seem to spend a good deal of their precious time going around to various discussions/disagreements telling editors to "shut-up and get back to work improving the encyclopedia", perhaps Wikipedia should have one talk page where admins cannot tell anyone what to do, what to say, or when to let an issue go (with a few caveats). Interactions that occur at the "Breakroom" would be virtually immune from Wikipedia policies, and sanctions at other venues in a way similar to mediation privilege. Editors would be free to speak their mind there and vent their frustrations without fear of admin sanctions. A safe place to blow-off steam may well positively affect editor retention/satisfaction long-term, and it may well improve/expedite dissolution of grudges and bad-blood. It can be easliy be shut-down if it does not work.

Rules. - 1) No threats or personal attacks of any kind (legal, physical or emotional). 2) No bigotry of any kind (sexism, racism, religious or national intolerance). 3) No comments about editors not actively participating in the specific "Breakroom" discussion thread. 4) No threats of admin sanctions based on comments made in the "Breakroom" unless in direct defense of "Breakroom" rules 1, 2 and/or 3.

Virtually everything else would be fair-game there (amongst willing parties), e.g. swearing (as long as it does not violate rule #1), heated debate, comments about about editor behaviour. A "Breakroom" would allow frustrated editors a controlled environment for release of that frustration that does not involve the ominously daunting and excruciatingly tedious AN/I, DRN, RfCU, mediation or arbitration, nor would interactions there directly disrupt the project. This may well reduce the workload at DRN based pages, and hopefully some wise and knowledgeable Wikipedians would volunteer to act as de facto mediators (oracles?) at the "Breakroom", helping to guide conflicts that do not seem to be resolving. Participation is of course voluntary, so any editors who dislike the way a thread is going can simply ignore it and leave the "Breakroom", with the expectation that editors who remain, refrain from commenting on an editor who bailed on the thread. Perhaps said editor would need to explicitly indicate they are "officially" disengaging from a specific BR thread, to clarify they aren't just taking a few days away: a point for further discussion.

Rationale. - Many times disputes/conflicts on Wikipedia are shut-down prematurely by admins who at times rightly fear the disruption will bleed into article space, or into an article's talk page, disrupting the improvement of the project. Also, admins will often suggest that a given disagreement is taking place at "the wrong venue", but what is the "right" venue? Sometimes editors need to verbally "duke it out" in order to reach some satisfaction, if not an outright resolution. The trouble is, anytime an editor or two "go at it", an admin will invariably come storming into the thread telling everyone to "shut-up, stop acting childish and go back to work". Well, we are all unpaid volunteers here, so this can at times be an extremely off-putting sentiment. So while I fully agree that excessive argumentation at talk pages can indeed disrupt the project, I also think that at times editors need to work-out their disagreements without "Big Brother" deciding who, when, where, and how much discussion is appropriate, and who was "right" and who was "wrong". In short, it would be the one place where editors can go to air grievances and speak freely without fear of admin sanctions. Any thoughts? ~ GabeMc (talk|contribs) 00:22, 25 October 2012 (UTC)

Suggestions

Perhaps those ideas should be evaluated in terms of psychological impact among the various users. I can think of several related issues:

  • I think some stress-related issues are best diffused by physical activities, such as hitting a pillow, or jogging a long distance, rather than venting hostilities which other editors might think directed at them, rather than just general "venting" of repressed rage. I would beware various issues of "anger management".
  • Another worry, as to a potential "descent into darkness" could be the notion of "rageholic" personalities, perhaps addicted to their rage, where the more other people can reflect, or escalate, the anger, then the angrier they might become in response, in a vicious circle, ending with extreme violence at their location.
  • Then there is the old warning, "Words said in anger can never be unsaid". Consider those rare, but real, cases where people, years later, have recalled, "You said about me 9 years ago...." (yes, a specific remark remembered over 9 years). It can be very risky to allow free-ranging conversations in a stress-filled environment, and Wikipedia is very stressful, with 4.2 million articles needing hundreds of updates, plus millions of templates with the most convoluted, "esoteric" and its-so-spastic warped features. We want to avoid unbridled rants, about anything.
  • When dealing with a wide range of unknown personalities, I think the best approach is often to say less, not more.
  • Perhaps people might mention several other websites, where various conversations, or forums, are discussing related subjects, to provide some other venues for free-ranging discussions.

Those are some initial suggestions about the issues. -Wikid77 (talk) 02:58, 25 October 2012 (UTC)

Great suggestions, thanks for taking the time to comment. I guess, everyone seems to think that if everyone could swear that everyone would just start swearing uncontrollably at each other, I've seen otherwise. Trolls would be dealt with internally by the community. Its not that all hell is always breaking loose, that's actually discouraged internally, without any admin assistance. Perhaps the wording of the proposal is too harsh. All hell can break loose, but its not all hell breaking loose all the time, we just wouldn't need an admin to come in and assert their authority to end a disagreement. ~ GabeMc (talk|contribs) 03:15, 25 October 2012 (UTC)
  • This is a very intriguing and promising idea. I would suggest taking a look at the field of restorative-justice, particularly at methods of "executing" it, as many of them involve effective ways of facilitating conversations involving angry, bitter, or otherwise unhappy fellows. My only concern is that an open-swearing environment could allow the disparaging of certain editors, that's why a more conversation-based method could enable editors to cooperatively work out problems without the risk of unneeded insult. dci | TALK 03:19, 25 October 2012 (UTC)
    • Well thanks much for acknowledging that there may well be a decent idea in here, and actually, I have some experience with restorative-justice, and it is a large part of the inspiration for this. Perhaps the swearing should be allowed as long as its not a personal attack? E.g. you could use the f-word but you couldn't call someone a f---. Thanks again for weighing-in, any more thoughts? ~ GabeMc (talk|contribs) 03:52, 25 October 2012 (UTC)
      • Venting without personal insults sounds fine; allowing editors needing to blow off steam to do so doesn't hurt anyone as long as they aren't spewing out personal attacks. dci | TALK 04:05, 25 October 2012 (UTC)
        • Yeah, that's looking better already. Thanks for your comments. Can you think of any more needed rules? ~ GabeMc (talk|contribs) 04:30, 25 October 2012 (UTC)

Discussion

I do believe for certain people frustration can be efficiently vented via a breakroom of some sort. But I do not believe that anonymous, unmoderated room with no professionals at hand and no individual attention would bring any results. This can work because you have human-on-human interaction where both parties are prepared often with help of a professional. This won't work in an anonymous text-only environment. That's my "technical" opinion on the issue. My more important argument is that this is an encyclopedia, not a social club and some editors lose sight of the goal. This proposal caters to such editors. I would think we ought to cater to the editors that actually do the work, instead of those that start to act so disruptively, admins have to resort to blocking; in other words WP:DENY. —  HELLKNOWZ  ▎TALK 08:49, 25 October 2012 (UTC)

I personaly like the idea but it might not do much good. Venting really wont help if someone isnt going to be heard. This wont cool things down. Though i would like to vent, the issue isnt that im not heard but ignored.Lucia Black (talk) 04:42, 26 October 2012 (UTC)

Possibility of developing French simple Wikipedia using français fondamental

After a reference desk discussion on EN (Wikipedia:Reference_desk/Language#Equivalents_to_Basic_English.2FSpecial_English_in_Spanish.2C_French.2C_and_German.3F) I learned that there is an artificially restricted, simplified form of French. The Simple English Wikipedia uses two artificial forms of English as its basis. I figure the same could be done with French. But I haven't made a formal meta proposal yet. Instead I have started a talk page discussion at meta:Meta:Babel#Simple French Wikipedia proposal based on français fondamental to get some more info. Any input would be greatly appreciated WhisperToMe (talk) 06:49, 17 October 2012 (UTC)

This mailing list discussion (2011) may be of some interest; it specifically names Français fondamental. Andrew Gray (talk) 09:39, 17 October 2012 (UTC)
Thanks, Andrew! I'll mention it! WhisperToMe (talk) 11:14, 17 October 2012 (UTC)

I opened a discussion at meta:Requests for new languages/Wikipedia French Simple (2) WhisperToMe (talk) 02:13, 29 October 2012 (UTC)

Ability to remove a page from watchlist directly on the watchlist page

Currently, to remove a page from the watchlist you have to either 1) click the "View and edit watchlist" link and manually uncheck pages or 2) Go to the page and click the "star" button next to View history. If each page on the watchlist had a little remove button to the left (where the bullet currently is), it would be a lot easier to remove items from the watchlist. Any suggestions/comments? –– Anonymouse321 (talk • contribs) 04:38, 26 October 2012 (UTC)

WP:Popups lets you watch/unwatch a page when hovering over any bluelink to the page of (non)interest. DMacks (talk) 04:42, 26 October 2012 (UTC)
I guess that is a good alternative, but it still doesn't seem as easy as it could be. –– Anonymouse321 (talk • contribs) 04:47, 26 October 2012 (UTC)
See User:Js/watchlist (it has also a lot of other features for managing a watchlist). ♪ anonim.one ♪ 06:32, 26 October 2012 (UTC)
That is what I use, it's excellent, when you have it turned down it allows you to go down the list and unwatch many different articles. Ryan Vesey 20:56, 26 October 2012 (UTC)
OK, I guess using tools/scripts is probably a better way to go. –– Anonymouse321 (talk • contribs) 21:05, 26 October 2012 (UTC)

biographical articles, conditional linking, and bibliographic tracking

So, I've had an idea. Or rather a set of ideas. Basically, I think we the way that we model biographical and bibliographic information is intermingled in an unhelpful way, and I wonder if we can untangle this.

Not all people we mention in prose on Wikipedia have a biography. Not every writer, actor, filmmaker, sportsman, random member of the public, etc, that we name in text, is going to have enough to warrant one. We have decision-making processes, and having made the decision we delete the article (or just don't create the article), and then go to the pages that have redlinks to this person's article, and remove them. Because there's no point having redlinks to an article that can never be created. (This doesn't always happen consistently, but nobody seriously objects to removing redlinks to stuff that's been deleted as unwritable-about, yeah?) Except, that it can't never be created. They might become notable enough later on for an article to be created, in which case, they need to be wikilinked from those articles they had been delinked again.

If they're not delinked then it just becomes an invitation to recreate them (and it's difficult for a non-admin to see whether or not they're recreated the old content if we've deleted it!). If they are delinked, it involves a lot of work (and yes, it can be scripted away with bots, but it still leaves a lot of noise in the edit history). Especially then when the person becomes notable and we decide to have an article after all. We might never get them all! So, I'm wondering, can we make borderline biographical links better? One way to do this would be to have a new page type, which would be a kind of non-biography. It would assert that a person of that name exists, and you could perhaps use Special:WhatLinksHere to find that. Pages would then be able to link to them always, without having to make the decision about whether there should be a biography about that person in so many different places.

It might have the very basics of PersonData, a link to IMDB, and one of those funky Template:Authority control templates I see popping up. But it would simply be a database entry, not a biography, and it would not try to be a biography, and trying to turn it into a biography would require the same level of signedin-ness as creating a new article does today.

Then, links to bibliographical entries could be distinguished visually from links to actual biographical articles visually - maybe a third colour (although I've been wanting a third colour for years for links to DAB pages). Perhaps there could be a preference.

Thoughts, anyone? Obviously this would require some technical work; but is this an idea worth developing further? Morwen - Talk 14:47, 5 November 2012 (UTC)

  • Full names are discouraged, else redirect to article sections: I think the general concept could span a murky area where a person is likely to become notable, but the sources would not yet verify the notability. However, in many cases, the appropriate handling of a lesser-known person is to chop the name, depending on the rare mentions, such as the remarks of witness "Fred S." were considered the major testimony which swayed the decision of the jury. Where lesser-known full names are still in articles, then they should be chopped to have initials, or if considered a key part of an "ensemble group" then a name could be redirected into another article, at a section which provided background about the ensemble. For example, suppose a group of lesser-known scientists had invented, or discovered, some notable process in technology or biology, then the names of those people could become redirects into a section of an article about the notable process. However, perhaps another person was named in sources as having arranged financing for those scientists to continue their work, but that person might be noted in an article as "Helena J." who had secured major funding for the group. If multiple sources emphasized the impact of the funding, such as reporting extensive praise for her, then the name "Helena J." could be expanded to the full name, and perhaps also gain a redirect as being a critical aide to the ensemble. There could be better guidelines for when to chop a person's name, versus when to show the full name, or to have a redirect for that name into an ensemble section of an article. Anyway, there is so much capability to have redirects for semi-notable names or else to chop names, that I think not much else would be needed. Have I missed some aspect of the linking? -Wikid77 (talk) 02:44, 6 November 2012 (UTC)
    • Is "chopping" an accepted practice? Where do we do that? I have never come across it, even on crime stuff? My idea is to be able to remove the tempting redlinks and discourage people from making bios about people who cannot be adequately sourced. People are making those redlinks and they are a temptation. And there's no way of stopping people making articles under those titles other than salting, which is fundamentally un-wiki. Going around removing redlinks won't stick. If we could have something at the end of those links, then the temptation to spam up Category:Living people with thousands of marginal articles, many of which aren't on watchlists being checked often enough, could be removed. Morwen (Talk) 10:00, 6 November 2012 (UTC)

The need for "WP:TRADEMARK"?

I find this guideline rather unnecessary or rather more intrusive than helpful. For example, when the correct name is "fun." with a lowercase "f" but the article uses "Fun" and claims that the period at the end is also part of stylization but another article doesnt allow punctuation to stop it from using the common name such as "Strawberry Panic!, most likely due to the exclamation point being less intrusive than the period. However articles such as "C (anime)" that its correct name cannot be used and says so under the title

I believe we should expand WP:TRADEMARK for allowing naming conventions to allow the official/most common name to take place so that WP:TRADEMARK doesnt get in the way. I think also the main issue is trying to be close to english as posible. But why should that be the priority for naming conventions? Names nowadays deviate from english, so why try to push it closer to what "english" is if a title may not even be known as such in the English community.

Though i cant imagine any damage to wikipedia if WP:TRADEMARK was removed from wiki's general guidelines.Lucia Black (talk) 02:50, 10 November 2012 (UTC)

It would be great if we got some opinions.Lucia Black (talk) 01:23, 14 November 2012 (UTC)

Watchdog templates when Lua searches text rapidly

This topic concerns creating "watchdog templates" embedded in article text, to scan part of the article's text and warn the next editors to avoid particular words, or require some phrases be left inside a block of text, as stating the minimal facts about a topic. I have run several timing-tests, to rate the speed of string searches for improper words/phrases, using Lua script modules to check template parameters. The speed is amazing, estimated as "183,000x" times faster than the current string-searches allowed by Template:Str_find_max. I posted initial thoughts at wp:PUMPTECH, as the thread:

The Lua script tests, run on test2.wiki, scanned for 50 phrases in a string of 22,300 characters (about 35 paragraphs of text), passed as template parameter 1, looking for particular words in those 35 paragraphs. Now, I have created a prototype of a "watchdog template", to show some ideas of what phrases could be watched, in article text, all scanned within 1/10 second if using Lua-based searches.

The prototype below, Template:Watchdog, currently uses the slow markup-based searches (limited to 6 searches of a paragraph of text, to avoid the template-size limits), but the prototype at least provides an example of issues to consider for grammar, rumors and omission of required words:

  • {{watchdog | required1 = experiment
    | John Doe (1900-1990) was an American [[nuclear physicist]] who developed anti-[[quantum]] theories. Born in Berlindorf, Texas, the town suspected he was a thief stealing from his employer. He was also an idiot. One expeeriment tested light speed between 2 mountain tops {{convert|7|km|mi|0}} apart. When he were awarded the Physics Prize of 1934, he didn't accept the award. }}

Result:
John Doe (1900-1990) was an American nuclear physicist who developed anti-quantum theories. Born in Berlindorf, Texas, the town suspected he was a thief stealing from his employer. He was also an idiot. One expeeriment tested light speed between 2 mountain tops 7 kilometres (4 mi) apart. When he were awarded the Physics Prize of 1934, he didn't accept the award.

      Warnings:

      (no other warnings).

The above watchdog results were copied from the live template, as just the generated warnings, to avoid crashing this talk-page due to the searches nearing the template-size limits, as 2,048,000 bytes. With the quick, smaller Lua-based searches, then various articles could use multiple watchdog templates, in muliple sections (or skip some), depending on the text phrases which should, or should not, appear in each section of an article. For talk-pages, different watchdog templates could be used to pre-scan an edited post to look for typos. Those templates could also check a per-user watchdog-preferences file, for topics (or words) to please not mention on the talk-page. Even before saving a posted message, the user could be warned to avoid the subject.

Before Lua string-searches were limited to 99 characters: Currently, by using new Template:Str_find_max, the markup-based string-search templates have been increased to search 500-character base strings, but they cannot match a word beginning in column 501, even though a string in template parameter 1 can contain over 160,000 characters (about 300 paragraphs of text). The underlying parser function, {padleft} was stopping at 500 characters. So, even the ability to match a word at 501 length is "infinitely" faster in the Lua-based string-search template.

Alerts for grammar/content must be done in wikitext: There have been numerous other discussions, about methods to pre-screen "all" content outside of the wikitext format, but unfortunately, the use of direct quotations in articles requires that the rules must be selectively turned on, or off, multiple times per article, to allow exact quotations, even with misspelled words or grammar errors, to appear in text without pre-screening by edit-filters. We even have Template:sic (" [sic]") to defend misspelled words. Each article, section-by-section, should decide what words or phrases must, or must not, be used in each part of the article. For direct quotations, almost anything is allowed, and so a watchdog template must not be used to reject quoted text from the original quotation. Another crucial point we learned from the slow cite templates: people will still edit articles even when checked for 200 non-used cite parameters in 250 citations, where the time to check for those 50,000 rare parameters was tolerated, even to wait over 20 seconds for an edit-preview of a page. Although 99% of citations can be coded using only 30 title, author, journal, volume, page, date and url parameters, the cite templates always check to allow another 200 alias parameter names. So, by comparison, the idea of waiting to search for just 50-100 specific phrases will seem "instantaneous" compared to the cite templates always checking for those 50,000 unused cite parameters in a major pop culture article.

Any other thoughts about those ideas? -Wikid77 (talk) 19:29, 23 October 2012 (UTC)

Firstly, I like the idea and this comment is just about one aspect: I'm not sure of the utility of warning about context-sensitive words like "thief", "idiot", etc. If a user is there to throw libel and generally edit nonconstructively, no warning is going to stop them. Established editors know better and would be more annoyed by this when using words in genuine context. And there is no easy way to determine when a word is used right or wrong. —  HELLKNOWZ  ▎TALK 08:55, 25 October 2012 (UTC)
Following comment below, I should also probably make it clear I like the idea of such a process, not necessarily the specific implementation via a template; but this is idea lab, so I didn't really mention that. —  HELLKNOWZ  ▎TALK 12:57, 25 October 2012 (UTC)
Bad idea. Leaving aside discussion of the merits of trying to abuse templates to somehow "police" the words people use (with all the difficulties that entails), this is dead simple for any vandal or POV-pusher to get around: just remove the template or change the parameters. Anomie⚔ 12:15, 25 October 2012 (UTC)
  • Intended to warn all, not just vandals: Although the use of watchdog templates would add another obstacle to vandalizing a page, where most vandals would be delayed by the surprising warning, it could be made a "hidden template" with the trigger phrases stored in a talk-page subpage, where most vandals would be puzzled to disable the warnings. However, I agree that some vandals could overcome almost any barrier, even pretending to be regular editors waiting to be auto-confirmed. Anyway, the warning about rumor text would be an alert to any editor, who might hear a news story and run to insert "accused of rape" where the word "rape" would be caught and require changing the template parameters to save without warning. Otherwise, the next user to view the page would see the word "rape" was noted as a potential rumor, and Wikipedia would be seen as more careful in posting comments without any review. Meanwhile, rejecting words such as "very famous" or other wp:Peacock terms would notify a novice user to be more careful about adding extravagant terms, or removing crucial facts in the section. Then, catching slang words, such as "can't" or "gonna" might also help keep new users thinking more carefully about adding such text. Currently, I feel confident that 100 phrases could be scanned, but I need to run a timing test to see if 500 words could be scanned within a split second. -Wikid77 (talk) 20:06, 26 October 2012 (UTC)
  • Hiding phrases from vandals: This is a follow-up to the concept of hiding the phrases so that a vandal would be surprised at the watchdog alert messages, displayed if an edit is saved, to readers of the article. I am thinking that a generalized watchdog template could have an option to quietly read restricted words from a default talk-subpage, such as "Talk:{PAGENAME}/watch". So, with a vandal not knowing the default page-name, then the article text could not be searched to show the optional parameters for retricted words, and it would be a matter of "guessing" which words might escape detection. Otherwise, a quick insertion of name slurs might be caught and highlighted as either invalid "rumor" text or "inappropriate" for the topic, and then other editors would be alerted to revert or edit the text to remove the restricted words (or phrases). Of course, seasoned editors would read the {watchdog} documentation and know the "hidden" list of restricted words was in page Talk:{PAGENAME}/watch (or such), where most vandals would not understand the connection. In some articles which actually use the offensive words, then the restricted words would be fewer, or different, and there would be no global "edit-filter" style rejection of all words; instead each article (or article set) would have its own list of restricted phrases. -Wikid77 (talk) 01:49, 5 November 2012 (UTC)
  • I'm a fan of the idea, at least. (I'm not entirely convinced that a template is the way to go.) Would this essentially replace the function of edit filters (albeit with finer granularity)? --Nouniquenames 18:35, 15 November 2012 (UTC)

Allowing non-free images of people in their prime

What would people think about creating a note at Wikipedia:Non-free content criteria that would allow non-free images of persons who are elderly or deceased that depict the person in "their prime". If free equivalents existed of the person in their prime, the non-free images would still be violations of NFCC#1. This would essentially be clarifying NFCC#8. The reason I have for this clarification is that depicting a person in their crime is essential for someone's understanding of that person. An image of Shammi Kapoor at 90 does not assist in my understanding of him as an actor. Thoughts? Ryan Vesey 20:56, 26 October 2012 (UTC)

Yes, I think you can argue a case for retired/really old actors that free images of them at 90 do not provide information of them in their prime. I've argued for one or two images but we are extremely tight on fair use images, most end up getting deleted at one point.♦ Dr. ☠ Blofeld 21:04, 26 October 2012 (UTC)

Yeah, that is a good idea, although there aren't very many free equivalents of the actors in their prime. (If I could get a time machine I'd buy out all the film stores in Bombay, but oh well...) I realize that me trying to take down the free pictures of the actors and put up non-free pictures was kind of stupid, actually. I just really would like other editors to share their thoughts about this. Red Hat On Head (talk) 21:24, 26 October 2012 (UTC)

I would not support this in any cases where the performer is still alive. In those cases, we should reach out to the performer and ask them to release an image from their prime. If the performer is dead, than we can use any non-free image we think works best, so I guess what I'm saying is that I don't support a change, I support more aggressive outreach. Sven Manguard Wha? 21:30, 26 October 2012 (UTC)

Okay, I understand about the performer being dead, but how are we going to reach out to the performer who is still alive? Red Hat On Head (talk) 21:39, 26 October 2012 (UTC)
You'd generally contact someone and say that you are a Wikipedia editor and ask if they'd be willing to donate an image under a CC-BY-SA license. Ryan Vesey 21:54, 26 October 2012 (UTC)
Yeah, but it's pretty hard for these Indian movie stars, although if I could contact Shashi Kapoor, I'd have melted into a puddle on the floor. Red Hat On Head (talk) 22:45, 26 October 2012 (UTC)
I'm sure that someone of the eminence of Shashi Kapoor has a secretary who takes care of such requests, and a well worded email (or letter, if you're old enough to know what that is), that includes a bit of flattery and subtly points out that the donation of a photograph would be good for his image, would have a good chance of getting a positive response. I've noticed before that many people seem to be willing to write copious amounts of comments on talk pages about whether this or that non-free image can be used, but seem inexplicably diffident about writing a short message requesting a free image. The worst that will happen is that you will get a polite "no" in response, or no response at all. Phil Bridger (talk) 12:48, 28 October 2012 (UTC)
I dunno his e-mail, although a letter... well. I'm no good at letters. I'll just be gushing and gushing and I won't even be able to hold the pen properly. One of my friends got to meet him. SO jealous of her. But that's off-topic. I guess I could try. (Hope that it's a cute picture of him though. Just kidding. Well, maybe not kidding. :P Sorry, is it obvious that I had coffee?) Red Hat On Head (talk) 20:51, 2 November 2012 (UTC)
On the topic of performers who are dead, are you stating that it is okay to use a non-free image of a dead performer in their prime if a free image of them exists as an older man or woman? Ryan Vesey 21:54, 26 October 2012 (UTC)
I don't know how often that situation takes place. I have to think about how I feel about that. I'd probably agree if the person was famous as a child star, but if someone was in their prime in their 40s and we have a photo of them in their late 50s, there isn't going to be too dramatic of a difference. I suppose the difficulty lies in how to codify policy that properly sets the guidelines. Sven Manguard Wha? 01:39, 27 October 2012 (UTC)
  • I'd like to go further and change Wikipedia:Non-free content criteria so that, to quote User:DGG: The only restrictions should be encyclopedic purpose and fair use in US law. We should interpret the "minimal use" requirement of the foundation as meaning the minimum that would allow us to give as much good encyclopedic content as possible in the widest sense that the words will bear. And at another level, I'd support a campaign for the WMF to change or remove the NFCC policy and agree to host anything that's educational & legal. The purpose of Wikipedia is to provide freely accessible content. The purpose of Commons is to provide free images for reuse. They are different projects. Hiding T 16:57, 28 October 2012 (UTC)
    I full agree with the above. Unfortunately there are many loud dissenters that will probably wax on about the 'mission' and this will never happen. ♫ Melodia Chaconne ♫ (talk) 17:41, 28 October 2012 (UTC)
    • Start a discussion and gather the reasons that the dissenters use. Check the archives to see if the argument has already been brought up. If so, address the old discussion in your new discussion. If not, start a new one. WhisperToMe (talk) 22:15, 29 October 2012 (UTC)
  • I think Ryan's idea has some merit, at least for people whose appearance is relevant to their notability (e.g., actors, but not writers). Our articles could benefit from having both "free image of Child Star, now age 90, snapped at the grocery store" and "non-free publicity image of Child Star at age 9". We could still encourage donations of images. If we wanted to be strict about it, we could even require an editor to assert that he has made such a request, or that he attempted to and couldn't find a way to contact the person. WhatamIdoing (talk) 01:09, 3 November 2012 (UTC)
    • I'm not sure why a cut-off point would be their death. We could reach out to their estate afterwards, in principle. Morwen - Talk 14:49, 5 November 2012 (UTC)
      The person's death ends our ability to get a picture that is copyrighted by an editor. The estate might have pictures, but we'd likely have to get OTRS to clear the copyright. WhatamIdoing (talk) 23:58, 6 November 2012 (UTC)
So let's say we editors agree, so how do we take it to the bigger community to decide on consensus? I really do hope that we stand a chance against those dissenters. It'll be so awesome if we could do this! Red Hat On Head (talk) 17:19, 11 November 2012 (UTC)
You'd make a proposal, probably at WP:Village pump (proposals). But why hasn't anyone so far in this discussion pointed out that there already is an exception for using non-free pictures of old-but-living people whose notability depends on their appearance in their youth (see the first item under WP:NFC#UUI)? Anomie⚔ 18:14, 11 November 2012 (UTC)
So actors count and are included under that? That's interesting, never knew that. Red Hat On Head (talk) 22:59, 12 November 2012 (UTC)
Depends on the actor, of course. Anomie⚔ 05:33, 13 November 2012 (UTC)
So it's a case-by-case basis, then? Red Hat On Head (talk) 20:51, 16 November 2012 (UTC)
  • I'm not sure if this issue is still alive, but I just posed a similar question which hasn't been resolved. Personally, I think the question is very important and deserves some conclusion. --Wikiwatcher1 (talk) 03:14, 2 March 2013 (UTC)

Guidelines for addressing external potential copyvios

Hi,

I have seen a number of examples of external plagiarism of WP articles, by which I of course mean "not in compliance with the attribution part of our CC-BY-SA license." The current way of dealing with this is either to do nothing, or is ad-hoc. One need only look at the talk page for WP:REUSE to see that others have similar concerns, and that there is no clear guidance on how to address this.

My concerns about this lack-of-guidance are several:

  1. Since the process is ad-hoc, natural variation in language and user affectation may undermine what may otherwise be considered attempts at outreach
  2. Widely-available, non-cited sourcing can confound the search for useful scholarship (for contributing to WP) that is not derived from WP, especially in subjects that are less dependent on academic journals and literature. Indeed, WP-sourced material, if not cited, may even make its way into academic literature.
  3. There does not appear to be any good information on how frequent or infrequent are dual-licensing schemes by editors who have contributed substantially to an article, e.g. when an editor writes a big chunk of copy, posts it to wikipedia, and then also allows others to use that copy under a different license.
  4. Having guidance in place may also enhance our community's ability to identify copyvios within WP; by working with external content providers to determine the chronology of such a similarity, it may become clear that the external provider's content was published earlier, and paraphrased, or the like.

As I implied above, I believe that having some guidance or template language for these situations would enhance our outreach activities.

UseTheCommandLine (talk) 20:04, 5 November 2012 (UTC)

I do believe Wikipedia:Mirrors_and_forks#Non-compliance_process addresses some of your concerns. Legoktm (talk) 20:20, 5 November 2012 (UTC)
I have seen that, and I think that those guidelines should be a part of the guidance I am talking about, but they are also quite confrontational, and I think as such should be reserved for more intransigent violators, e.g. the mirrors and sites that reproduce WP content wholesale for SEO juice or ad revenue. I think most importantly, the process described there does not "assume good faith" -- when dealing with a potential external copyvio, it may not even be something that the site manager is aware of, or they may simply need encouragement to provide a cite or linkback. There is a spectrum of this sort of behavior, and I think that there should be guidance on how to deal with the various points on that spectrum in a way that is in keeping with the foundations of wikipedia. UseTheCommandLine (talk) 20:41, 5 November 2012 (UTC)
More specifically, the assumption "you are in violation of this policy" is something that is not always in evidence. The following is text I used recently to inquire about a potential violation:

Hi,

I apologize in advance if this email is misdirected, as it almost undoubtedly is. feel free to forward it to whoever might take care of this, I have made my best guesses based on your website, but they are only guesses.

the content at: <website>

appears to be nearly identical to the content on the english-language Wikipedia. The current language: <WP article link>

stems from an edit first made in <date>: <WP article history link>

I am attempting to figure out whether the WP paragraph is plagiarized, or whether your website is not in compliance with the terms of the Creative Commons CC-BY-SA license (in particular the "Attribution" portion): <License link>

I did make an attempt to use the Wayback Machine to see if there was an archived version of your site, but there was not.

And although your site is clearly not operating as a mirror, I think some of the text at the following page is also pertinent: https://en.wikipedia.org/wiki/Wikipedia:MIRROR

I would very much value your assistance in tracking down whatever the underlying issue is here. There are obviously multiple possible explanations, so I in no way intend this email to be accusatory. Even if the language is in fact taken from wikipedia, it would almost certainly qualify as "fair use", in which case a simple set of quotation marks and a reference or linkback is the remedy.

Acknowledgement that this may simply be an oversight, and importantly, that there are multiple possible explanations for the WP content being the same as external content, I think is important, as i said, in terms of outreach and PR. And obviously, I'm mainly speaking about websites that have small portions taken from WP, rather than mirror sites, for which I think there is probably adequate guidance on the WP:MIRROR page UseTheCommandLine (talk) 20:55, 5 November 2012 (UTC)
Seems a little too soft, almost apologetic. I'd stick to the facts:
(You seem to be the right person to write to about content licensing on your website. If you're not the right person, let me know.) (the issue) (possible causes), (suggestions), (invitation to discuss) (We're not lawyers, we're just working to support proper use of Wikipedia content).
No apologies, and no accusations. My 2 cents. --Lexein (talk) 23:38, 5 November 2012 (UTC)
I think that the tone you want to take depends on the circumstances. One might reasonably be gentle when you expect to discover a simple oversight by a cooperative person. But I agree that WP:MIRROR#Non-compliance process is the general list of what to do, and probably all the advice that we ought to be providing. Enforcing individual contributor's private intellectual property rights is not part of Wikipedia's purpose. WhatamIdoing (talk) 23:56, 6 November 2012 (UTC)
If enforcing individual contributor's private intellectual property rights advances the creation of an encyclopedia then it is part of Wikipedia's purpose. One might say that when users' contributions are inappropriately reused then it is demoralizing to volunteers and empowering to efforts to squash Wikipedia with competing projects at the expense of the community. This is not a light issue and it deserves a discussion, if not action. Blue Rasberry (talk) 22:14, 7 November 2012 (UTC)
I am unclear on how asking about this is equivalent to "enforcing an individual contributor's intellectual property rights." In the absence of obvious evidence that a site is a full-fledged mirror of WP (i.e. the outside site has a limited amount of content that appears similar or identical to WP content) I don't think we can assume that the outside site is plagiarizing WP. And given the seriousness with which the problem of policing copyvios on WP is approached, I think it's imperative that WP editors not make assumptions when encountering these situations, and make serious efforts to determine whether the copyvio lies with WP or with the outside site.
The perhaps overly-conciliatory tone I struck in the above language has a lot to do with that -- I am explicitly not making assumptions, and am open to the idea that an editor may have, whether inadvertently or deliberately, committed a copyvio. Being open to that possibility, (though IANAL) also seems like the sort of attitude that would hold us in good stead if in fact it is a copyvio on the part of WP and we are subsequently exposed to legal action.
The way I think of it is, it's not attempting to enforce a contributor's copyright, nor is it so much about asserting that outside sites comply with WP's license. It is about aggressively policing WP itself for potential copyvios. If an increased outside compliance with CC-BY-SA, or with an individual contributor's copyright is a follow-on effect, so be it.
But perhaps someone from the foundation needs to weigh in on this possibility: If we inadvertently notify an outside party to a WP copyvio in the course of attempting to self-police, does this increase or reduce our legal risk? I am not clear on "safe harbor" provisions et al of copyright law (or if that is even the correct term). UseTheCommandLine (talk) 11:17, 10 November 2012 (UTC)
If the mirror has copied your contributions, it's not "Wikipedia's license". The license for your contributions goes directly from you to the rest of the world (including the Wikimedia Foundation). The mirror does not need to "comply with WP's license"; it needs to comply with UserTheCommandLine's license.
I'm not sure what you mean about notifying someone of a WP copyvio. Is this about notifying them that some Wikipedia editor has violated a source's copyright, or about notifying them that they've violated the editor's copyright by failing to comply with the editor's license? WhatamIdoing (talk) 04:39, 11 November 2012 (UTC)
This feels like a distinction without a difference. Whether the copyvio lies with the external site or it is in WP's content, one still has to ask the external site about the source and the license, and the easiest way to do that is to say "this looks similar to WP content from this date." This could be construed as notification of that site that they were violating some WP editor's individual copyright, sure, but it can also be seen as WP self-policing to ensure it does not contain improperly- or un-licensed content. One can never be sure in which direction the arrow points, until that question is asked. I happen to feel that enforcing the terms of CC-BY-SA, terms under which we are making content available, is, if not a legal duty, then a moral one. But it also happens that it helps us ensure copyrighted material does not appear on WP inadvertently. UseTheCommandLine (talk) 01:59, 13 November 2012 (UTC)
Two scenarios:
  • I violate someone else's copyright by copying, verbatim, three paragraphs from a (cited) book into a Wikipedia article.
  • Some website violates your copyright by mirroring a Wikipedia article that you wrote.
You don't see a material difference in these two actions? WhatamIdoing (talk) 22:57, 16 November 2012 (UTC)
This isnt at all the scenario I am suggesting. The situation I am talking about is more like:
An editor violates someone else's copyright by copying, verbatim, three paragraphs from a book into a Wikipedia article, without citing it.
Someone mirrors a section of a Wikipedia article without referencing or linking back to the article.
-- UseTheCommandLine (talk) 00:48, 17 November 2012 (UTC)

Simple HTML and/or Rich Text Format for the "E-mail this user"?

Hi all. At present the "E-mail this user" function sends bare plain text. Surely there could be an enhancement to that functionality in "XML" or whatever youse very clever people come up with next? --Shirt58 (talk) 14:24, 17 November 2012 (UTC)

Make file uploading a separate permission

Here is my translation of the russian uploaders policy. I posted a copy of it here for the convenience of users who will discuss this.

Translation of the Russian policy

Uploader is an account permission in Russian Wikipedia, whch is automatically granted no less than 14 days after the registration if the user has made 20 or more edits [1].

The status allows to upload images, video, and audiofiles. The process of file uploading is described in the illustrating policy.

It is recommended to upload files with free licences to Wikimedia Commons. An uploader flag is not needed for doing this.

Administrators can also grant the uploader flag manually — for exapmle, if the new user is experienced in another Wikimedia Foundation project. In case of systematic or rough violations of file uploading rules the uploader permission may be removed[2].

Reasons of removing uploader flag

The uploader flag may be removed from a user if he or she:

  1. systematically, despite warnings, uploads non-free files under free licences;
  2. systematically uploads other people's works as his/her own despite warnings and explanations of policies in non-obvious cases (screenshots, reproductions and other images of 2-dimensional objects);
  3. systematically, despite warnings, uploads non-free files, which are not subject to fair use;
  4. has uploaded a grea number of files with roughly wrong descriptions, ignoring warnings and explanations;
  5. systematically violates other Wikipedia policies (WP:No original research, WP:Biographies of living persons, Wikipedia is not a hosting и т. д.) in the file namespace. If such violations also occured in other namespaces, they should be stopped by blocks.

Before flag removal the administrator should make sure that the user knows that his actions violate policies; after the removal he should notify the user on their talk page.

The flag may not be removed if the user:
  1. systematically uploads free files to Wikipedia instead of Commons — it shpuld be explained to the user that it is better to upload free files to Commons. At the same time free files are not forbidden in Wikipedia.
  2. systematically uploads files with senseless names, if these names do not violate other policies — the files should be nominated for renaming.

Rules of granting and removing the uploader flag

As a rule, the uploader flag is removed or granted (early or again)by an administrator according to the close of a discussion on pages Wikipedia:Requests for uploader flag (WP:RFUF) and Wikipedia:Requests for flag removal (WP:RFFR) wthin 3 days. In extreme or obvious cases the requests may be filled on the requests for administrator attention noticeboard, and the flag may be granted or removed by a decision of 1 administrator, without a discussion.

References

  1. ^ The uploader flag was introduced in June 2009 according to the close of a requset for comment, which was started in January 2009; before this all autoconfirmed users could upload files.
  2. ^ The uploader flag was made removable according to results of a poll, which was conducted in January 2012.

See also

Discussion

In my humble opinion:

  • It is better to stop users uploading files rather than block them — a block also stops article, template etc. edits.
  • Raising the experience bar for uploading files can result in fewer newbies uploading files in violation of the rules. --Николай95 (talk) 16:11, 18 November 2012 (UTC)

Comments

I've posted this proposal here because I'm unsure if it's ready to be posted to WP:VPP. — Preceding unsigned comment added by Николай95 (talk • contribs) 16:09, 18 November 2012 (UTC)

Roll over text boxes

It would be incredibably useful to have scroll over text boxes on wikipedia pages. Kind of like Yahoo does on parts of their news sites, when you hover over a link, the first paragraph of the story pops up. > > This way when I am reading an article about Newfoundland dogs, I don't have to click on a link and go to another page just to find out what a Molasser. It would be nice if a text box could pop up and tell me that it is a large dog. > > Maybe a simplified definition for the pop up boxes, a brief sentence or two, but anything would be nice! — Preceding unsigned comment added by 178.76.146.20 (talk) 13:59, 29 October 2012 (UTC)

Thanks for that comment. If you create an account, you can enablepopups which should be exactly what you are describing. I've made comments before that someone should find a way to allow readers to use it too. I'll contact some people and see if we can move on that. Ryan Vesey 14:03, 29 October 2012 (UTC)
(ec)Already exists, although you need to have an account. Then, go to preferences, and enable Popups. They are incredibly useful, providing brief summaries of articles, plus links to user contributions and many other things.--SPhilbrick(Talk) 14:05, 29 October 2012 (UTC)

Thanks, I really appreciate it. This will surely save me time and probably increase my usage of the site. It looks like less 1 in 10 Wikipedia viewers have an account? And that number seems like it might still be high. And out of people that have a Wikipedia account, I wonder how many of them know about or have the popups enabled. Also, when the box first pops up, my eyes REALLY want to see the definition text at the top of the box, it would be nice if the actions and popups were below the important text. I am just putting it out there, no response neccesary, I really appreciate your help! — Preceding unsigned comment added by Stringbender101A (talk • contribs) 14:50, 29 October 2012 (UTC)

I came here to suggest this very idea, and it seems a shame it's hidden away. As an extension, perhaps we could have elements that expand to show the pop-up contents in-line with the text, albeit formatted to show it's clearly not part of the article. Something like a [+] button that only loads the required data upon expansion.Rosyatrandom (talk) 15:33, 19 November 2012 (UTC)

New userright to create talk pages of non-existent pages?

From what I have seen, my feeling is that pages created by new users in the Talk: namespace which do not have a corresponding article are rarely of value (e.g. see this – admins-only). Therefore perhaps we could add a right to Special:ListGroupRights for creating a talk page which does not have a corresponding article, and assign it to, say, Autoconfirmed?

I'm asking for opinions here because there may well be legitimate uses for this that I have overlooked. I am also not entirely certain just which namespaces should be affected – I'm largely thinking of the article talk namespace, since starting a User Talk for someone without a user page seems perfectly legitimate, as does File Talk for files on Commons, and I suppose Wikipedia talk:Articles for creation/Foo rules out WT. Not sure about Template Talk, Portal Talk, and the like, though, so I was wondering what people thought. It Is Me Here t / c 15:41, 14 November 2012 (UTC)

I'm not sure if this is enough of a problem to merit a solution of that grade; but unfortunately it's not presently possible to filter the logs by namespace (T16711) so it's hard to know how we could assess the number of mistaken article talk page creations. — Hex (❝?!❞) 16:38, 14 November 2012 (UTC)
This capability is deliberately used for WP:AFC so removing it would break IPs abilities to submit proposed articles for consideration. Graeme Bartlett (talk) 10:02, 19 November 2012 (UTC)

new gadget proposal: Template Parameters Wizard

this wizard is already used in hewiki and arwiki. a prototype for enwiki can be tried by adding to Special:Mypage/common.js the following line: 

if ($.inArray(wgAction, ['edit', 'submit']) + 1) importScript('User:קיפודנחש/TemplateParamWizard.js');

this was initially suggested in WP:VPT, and was since archived here: Wikipedia:Village pump (technical)/Archive 103#Template Parameter Wizard.

in a nutshell: this tool helps editors fill up the parameters for templates. it has 2 modes of operation: every template can be made "wizard compatible" by having a subpage named "parameters" that teaches the wizard how to present the dialog. in the absence of such a subpage, the wizard reads the template page itself and present all the parameters this specific template uses.

after this unproductive introduction in WP:VPT i was undecided whether to just let it drop, make a proposal in WP:VPR, or present it here to see what people have to say about it. eventually i decided to try to push it a little further by proposing it here. please let me know what you think. peace - קיפודנחש (talk) 16:50, 25 November 2012 (UTC)

I think it's an awesome idea, in general, even if it may need some technical tweaking. However your introduction in VPT doesn't seem unproductive at all, quite the opposite, it generated interest and useful comments. Perhaps showing a prototype that works with many of our common templates would generate more interest? --Cyclopiatalk 17:05, 25 November 2012 (UTC)
this prototype works with *all* the templates in enwiki. as mentioned above, there are those "2 modes", and since none of the actual templates now has a "Parameters" subpage, it's only in the 2nd mode, but i do not see it worthwhile to create this subpage for many other templates just for demonstration purposes as productive. once this is a real gadget, we can start a wikiproject to add "Parameters" subpage to other templates (this is what we did in hewiki).
as to productiveness: yes, it created positive feedback, but then it got buried in the archive. this will only make sense if it's a gadget (not only is it a gadget in hewiki and arwiki, but it's a *default* gadget there, so everyone that did not explicitly turn it off has it, including anons).
now for the interesting part: can you please list some of the "technical tweaking" that would improve this ?
thans, peace - קיפודנחש (talk) 18:41, 25 November 2012 (UTC)
  • "this prototype works with *all* the templates in enwiki" - Hmm, from the discussion it seems it has troubles with aliases and had also problems with case sensitivity (albeit you declare they've been then solved)
  • "it's only in the 2nd mode, but i do not see it worthwhile to create this subpage for many other templates just for demonstration purposes as productive" - You can try to get consensus to include it on some example template for demo purposes. I think it is worthwile if you want it to be adopted.
  • "then it got buried in the archive" - Heh, it happens. This doesn't mean it was unsuccessful, simply there was nothing more to say until you had some further improvement and/or demonstration.
My own advice is: Just be bold (reasonably). That is: Create a page in "Wikipedia:" space documenting the gadget well, upload the relevant Javascript to a corresponding subpage, and talk about it at the templates wikiproject. If people start to use it, like it, and it enjoys momentum, then maybe one day it'll be default here too   --Cyclopiatalk 19:11, 25 November 2012 (UTC)
(Also: I tried to put the line in my Special:Mypage/common.js but I see nothing new when I edit -can you help me figuring out how it works?) --Cyclopiatalk 19:18, 25 November 2012 (UTC) found it, nevermind --Cyclopiatalk 19:20, 25 November 2012 (UTC)
there is no thing as "aliases", strictly speaking. someone in enwiki, long time ago, had the incredibly asinine idea that having multiple parameters to the same template which do exactly the same thing is a good idea. this is easy to implement in mediawiki template syntax - wherever you want to use the parameter, you just do something like: {{{name1|{{{name2|{{{name3|}}}}}}}}}. this helps nobody and is awfully confusing (the old saying goes: a person with two wristwatches never knows what time it is). the wizard can not guess that 2 of these 3 parameters are completely junk and should never have existed in the first place: this is the job of the people making these templates. of course, if such a template has the "Parameters" subpage, there is no reason for it to contain those superfluous parameters ("name2" and "name3" in the example above), but when the wizard extracts the parameters from the template itself, there is no way for it to know that those 2 are junk parameters, and it displays them with the rest. i hardly think that this shortcoming is reason enough not to use the wizard.
note that the "Cite" gadget adds similar support for 4 specific templates. this support comes at a significantly higher cost (i.e., the script that does the "Cite" templates has much more code, maybe 4 or 5 times as much, as the wizard, and it covers only 4 templates). true, the "Cite" support shows the fields in 2 columns. it would not be that difficult to teach the wizard to use 2 columns, but so far, nobody suggested that doing so would be an improvement.
i would be open to do one or two "Parameters" subpages for some specific templates for demonstration purposes. which templates would you say will be good candidates for such a demo?
thanks, peace - קיפודנחש (talk) 20:52, 25 November 2012 (UTC)
"someone in enwiki, long time ago, had the incredibly asinine idea that having multiple parameters to the same template which do exactly the same thing is a good idea." - Well, fellow, you have to play with the cards you've been dealt with. I don't see aliases as a bad idea; they only look bad from your point of view, and it confounds nobody, AFAIK.
In any case, the "Parameters" thing is the way to go, sure. What templates would be good candidates, I have no idea -again, you should first put your script in WP space, with documentation, and then go on the templates wikiproject talk page to discuss that with people involved in templates. I advise you not to insult the template aliases too much (you can criticize them, but accept them as a matter of fact). --Cyclopiatalk 21:06, 25 November 2012 (UTC)
first, you are correct that criticizing this enwiki habit (i.e., "aliases") here is not really productive... i was just venting. as a software engineer, it is my experience and opinion that giving the same thing multiple names seldom has any positive value, and very often has many negative consequences.
second: of course, the wizard "plays with the cards it is dealt". this means, in case of templates with "aliases", that it will show them all (unless, of course, there is a "Parameters" subpage).
regarding placing the script in WP space: it is my understanding that in enwiki, the custom is to leave scripts in user space: this gives them some protection, as non-admin users can't edit pages whose name ends with ".js" or ".css" in another user space. see, for instance, the gadget MediaWiki:Gadget-CommentsInLocalTime.js: all it does is load a script from user space: User:Gary King/comments in local time.js. this is the same for many (most?) of the gadgets, so it is my understanding that for scripts, it is preferable to leave them in user space, i.e., leave it where it is: User:קיפודנחש/TemplateParamWizard.js. (moving a script to WP space would allow anyone to edit it - not a very good security for).
as to creating a documentation page in WP space: you might be right here. i will try to collet the different bits and pieces of documentation and create a wikipedia:Template PArams Wizard page.
thanks again, peace - קיפודנחש (talk) 22:19, 25 November 2012 (UTC)

Do you have any information on the format of the /parameters subpage for this tool? I'm also wondering if the format of the /parameters subpage could be tweaked so that a simple template call, say {{parameters}}, would display a good Usage section for the documentation subpage. VanIsaacWS Vexcontribs 21:30, 25 November 2012 (UTC)

it is not "documentation" per se, but you can see it here: Template:Param wizard demo/Parameters. if you install the script and then click in the {{}} symbol in the "Advance" toolbar, and feed in "Param wizard demo" as the template name, you can see the effect of the different options in the parameters subpage. peace - קיפודנחש (talk) 22:19, 25 November 2012 (UTC)
 
Ok, some first thoughts: Does the "depends on" parameter accept multiple dependencies? Are the table headings optional, variable, or static - ie, if you have a typo or don't put them in, will the tool still work? How set is the tool's input syntax - can we get rid of the table format in favor of something more universal, so that the information can be utilized by other processes? Does the tool completely ignore any parsing of the template if there is a /parameters subpage; what happens if there's a parameter defined that's not actually used by the template? That's my first glance thoughts, but I'll delve more deeply a bit later. VanIsaacWS Vexcontribs 22:50, 25 November 2012 (UTC)
i'll try to answer the questions one by one.
  1. Q: "Does the "depends on" parameter accept multiple dependencies?"
    A: no.
  2. Q: "Are the table headings optional, variable, or static"
    A: Optional. however, in hewiki we always use them - it helps others who might want to edit the "Parameters" subpage, and it also makes the subpage more useful as documehntation.
  3. Q: "can we get rid of the table format in favor of something more universal?"
    A:right now, the tool code presumes table format. this, of course can be changed - can you propose something "more universal"? the tool need to get triplets - the parameter name, the parameter description, and (optionally) a set of options.
  4. Q: "Does the tool completely ignore any parsing of the template if there is a /parameters subpage"?
    A: yes. if there is parameters subpage, the tool does not read the template page itself. whatever parameters are defined in the subpage will be displayed by the tool, regardless of what *actual* parameters this template takes (it works both ways: if the subpage define a param not used by the template it will be displayed, and if the template has a param not in the subpage it won't be displayed). note, that the "autofill" trumps both: if you select a partially filled template, and it has a parameter not in the subpage (if there is a subpage) or not in the template (if there isn't subpage), this field will be displayed in the tool, and the parameter name will show in red.
i hope the above is not too obscure to actually be understood...
peace - קיפודנחש (talk) 23:41, 25 November 2012 (UTC)
No, that's exactly the information I was looking for; I'm all about the arcana.
  1. is unfortunate, as I maintain some fairly complex, multi-dimensional templates, such as {{charmap}}.
  2. is good - I'd hate to have this get screwed up because of a typo. If it stays as a table format, you'd want to explicitly document the behavior being independent of headings.
  3. , I have some ideas, but I'd hope that others would chime in on data formats to make this a multi-use tool for standardizing documentation. I'll try to put something together tonight and make a new subsection to discuss it.
  4. is expected, but it would be nice if the tool remarked on any discrepancies - maybe a "debug" button, so that the person making the /parameters subpage can figure out what (s)he missed.
שָׁלוֹם - VanIsaacWS Vexcontribs 00:34, 26 November 2012 (UTC)
WRT #1: this being the "idea lab", i'd like to clarify: the fact that the tool does not currently support multiple dependency does not mean it can't be persuaded to do so. how do you see this "multiple dependency" thing? as an "OR" relation or as an "AND" relation? (i.e., if you give a field two other fields it depends upon, do you want them both to be non-empty in order to display this field, or should it be displayed when either one of them becomes non-empty?)
WRT #4: actually (wish i had thought it long time ago - would save me a lot of work in hewiki), it is pretty easy to check to see if we are in templatespace and the pagename ends with "/Parameters", and then do something completely different: methinks, if the editbox is empty, fill it with a skeleton table (i.e., all the params and empty columns for desc and options), and if the page is not empty, display a list of "missing and superfluous parameters". i will try to get to it...
peace - קיפודנחש (talk) 01:13, 26 November 2012 (UTC)
  1. 1 - Damn, I hadn't even thought about that. I wonder if we could actually do a simple boolean evaluation of some sort. It probably should at least recognize keywords AND, OR, and NOT.
  2. 4 - glad I could be of help, and glad that you are so eager to incorporate suggestions. I just wish I knew .js programming to help. שָׁלוֹם VanIsaacWS Vexcontribs 04:04, 26 November 2012 (UTC)
One more thought: how about an option for placeholder text - the grey background text, like in the mediawiki "search" box. VanIsaacWS Vexcontribs 09:37, 26 November 2012 (UTC)
as to multiple dependency: i am not at all sure the extra complication (for the editors: don't worry about the JS code - this can be accomplished easily enough on the JS side) is worth it. are you sure the simple existing dependency rule is not enough?
as to "placeholder grey text": i have mixed experience with them. i encountered numerous cases where users interpreted the grey-out of the placeholder to mean "this field is disabled", and they skipped it. however, it should not be a big deal to add an option to allow you to define the text for the "Selector" field (which defaults to "Select one:")
please note also that i updated the script to the latest version from hewiki: this one contains an idea i picked from the "Cite" toolbar templates: you can now mark a parameter as "Extended". when the dialog first shows, these fields are hidden. if there is at least one param with the "Extended" option, a new checkbox will appear at the top of the dialog, "Show all parameters". marking this box will expose the fields with the "Extended" option.
peace - קיפודנחש (talk) 17:29, 26 November 2012 (UTC)

Parameters file syntax

I'm wondering if a simple unnamed parameters list would work, but have a table template (eg, {{parameter table}}) inside <noinclude> tags to display the page identically to how it currently looks, with <includeonly> tags around a usage template (eg {{parameter usage}}). You can even do the usage template as a parameter of the transcluding call - WP:SELTRANS. <edit> I just realized that the Choices= syntax won't work very well with unnamed parameters, so I thought that all caps KEYWORDS could be a solution. We could also use a colon ":" instead of equals "=" to bypass the wiki software. </edit>

Looking at the example, it might be good to switch the positions of "options" and "description". I think having the options right after the parameter name would significantly help with readability, as the description can be quite lengthy, moving the options to an arbitrary place, while the options tend to be fairly short, meaning the description will usually fall in a predictable place when scanning the text. The only time that will probably be untrue, when there is a choice list, the choices will generally be quite helpful. So, the code for your example would be something like: 

<noinclude>{{parameter table</noinclude>
<includeonly>{{parameter usage</includeonly>

 | param1 | REQUIRED | This parameter is mandatory. for as long as any "mandatory" field is empty, the "OK" button will remain disabled. 
 | param2 | | Just a regular parameter. description can include [[Link]]s and [[File:Question book-new.svg |60px]] images
 | param3 | MULTILINE | multiline entry. 
 | param4 | CHOICES Red,Green,Blue,Sweet,Heavy | Multiple choice parameter: choices delimited with commas 
 | param5 | DEFAULT if you dig it - frig it | Parameter with default value 
 | param6 | REQUIRED;DATE | Date type field. also demonstrates that you can have more than one option (in this case, "Date" and "Required"). 
this is done by separating the different options with semicolons on the "Parameters" subpage. 
 | param7 | | Param8 depends on this one. once you enter a value, the next parameter will magically appear. 
 | param8 | DEPEND param7 |

}}

and {{parameter table}} would look something like: 

{| class="wikitable"
|-
! Param name !! Options !! Description 
{{#if: {{{1|}}}{{{2|}}}{{{3|}}} | {{!-}} 
{{!}} {{{1|}}} {{!!}} {{{2|}}} {{!!}} {{{3|}}} }}
{{#if: {{{4|}}}{{{5|}}}{{{6|}}} | {{!-}} 
{{!}} {{{4|}}} {{!!}} {{{5|}}} {{!!}} {{{6|}}} }}
{{#if: {{{7|}}}{{{8|}}}{{{9|}}} | {{!-}} 
{{!}} {{{7|}}} {{!!}} {{{8|}}} {{!!}} {{{9|}}} }}
{{#if: {{{10|}}}{{{11|}}}{{{12|}}} | {{!-}} 
{{!}} {{{10|}}} {{!!}} {{{11|}}} {{!!}} {{{12|}}} }}
{{#if: {{{13|}}}{{{14|}}}{{{15|}}} | {{!-}} 
{{!}} {{{13|}}} {{!!}} {{{14|}}} {{!!}} {{{15|}}} }}
{{#if: {{{16|}}}{{{17|}}}{{{18|}}} | {{!-}} 
{{!}} {{{16|}}} {{!!}} {{{17|}}} {{!!}} {{{18|}}} }}
{{#if: {{{19|}}}{{{20|}}}{{{21|}}} | {{!-}} 
{{!}} {{{19|}}} {{!!}} {{{20|}}} {{!!}} {{{21|}}} }}
{{#if: {{{22|}}}{{{23|}}}{{{24|}}} | {{!-}} 
{{!}} {{{22|}}} {{!!}} {{{23|}}} {{!!}} {{{24|}}} }}
{{#if: {{{25|}}}{{{26|}}}{{{27|}}} | {{!-}} 
{{!}} {{{25|}}} {{!!}} {{{26|}}} {{!!}} {{{27|}}} }}
...

I don't know exactly what the .js script even reads - the bare text file, or the actual HTML table created; this could literally require only one change to the code, but provide a lot of possible functionality. Thoughts? VanIsaacWS Vexcontribs 09:11, 26 November 2012 (UTC)

as to the change in format: to answer your question, the wiki API provide ways for the script to read both the rendered (aka "parsed" and "html") version of the page, as well as the "raw" version (i.e., what you see in the edit box). the script uses the "raw" mode to read the params page (and when this is absent, the template itself), but it also uses the parsing services of the wiki site to convert the "description" part to nice html (if you installed the script, open the wizard and choose the "param wizard demo" template, and float the mouse over param2).
to be honest, i do not see why this:
<noinclude>{{parameter table</noinclude>
<includeonly>{{parameter usage</includeonly>

 | param1 | REQUIRED | This parameter is mandatory. for as long as any "mandatory" field is empty, the "OK" button will remain disabled. 
 | param2 | | Just a regular parameter. description can include [[Link]]s and [[File:Question book-new.svg |60px]] images
 | param3 | MULTILINE | multiline entry. 
 | param4 | CHOICES Red,Green,Blue,Sweet,Heavy | Multiple choice parameter: choices delimited with commas 
...
}}
is more "generic" or easier for other tools to parse than this:
{| class="wikitable"
|-
! Param name !! Description !! Options
|-
| param1 || This parameter is mandatory. for as long as any "mandatory" field is empty, the "OK" button will remain disabled. || Required
|-
| param2 || Just a regular parameter. description can include [[Link]]s  and [[File:Question book-new.svg|60px]] images ||
|-
| param3 || multiline entry. || Multiline
....
|}
granted, the 2nd form is not very "generic", but i am not sure the 1st one is any better. if we decide to go this way, the change to the code is minimal, and it would not be all that difficult to persuade it to be "tolerant" and to work with either format. one question, though: why did you switch the order of "Description" and "Options"? i don't think i want to do that - we already have dozens of "/Parameters" subpages in hewiki, and switching the order *will* require editing all of them.
peace - קיפודנחש (talk) 17:08, 26 November 2012 (UTC)
The advantage of the former is that it can be used by templates; the latter cannot be parsed or evaluated in a template call, only displayed. VanIsaacWS Vexcontribs 20:57, 26 November 2012 (UTC)
i modified the script to support both, except for the swap between "desc" and "options".
the "template compatible" form relies on one-param per line, such that the line *must* begin with a vertical bar, and the order is the same as the table format: param name, description, options.
also please note the addition mention in previous section of new "Extended" option.
there is one small caveat, though: i use the equal sign "=" for options with values, such as "Default" and "Choices". in order to support the "templateable" mode, i taught the script to accept {{=}} also.
peace - קיפודנחש (talk) 21:08, 26 November 2012 (UTC)

Possible hatnote linkage to Simple English versions of some general reference WP articles

I've been keeping an eye on the Article Feedback for my Watchlisted articles and I've noticed that some/many readers come, for instance, to a historical biography and are frustrated by the article, maybe they are students, maybe English is not their first language, maybe the sheer length of the article is too overwhelming, but for whatever reason they are having trouble completely understanding some of our articles. So I was thinking that hatnotes pointing the way to Simple English versions of some of our high-view articles, especially the general reference type articles (on US Presidents, historical biographies, history, etc), might be especially useful. Any thoughts on if this is a good idea, if it's appropriate or not, would be appreciated. And before anybody mentions it, yes, I do know that the languages (along with various other internal Wikipedia links) are listed over on the left side of article pages, but how many readers (not editors, but readers) miss that information, especially the Simple English link which is ensconced between Sinhalese and Slovenian? There are many page-features that editors are aware of that the general readership probably never notices. If the whole point of this encyclopedia is to put the information into people's hands and to make the information as accessible as possible, then clearly pointing the way to a more basic version of the Wikipedia article might be a very good thing. I did cobble together a 'Simple English' hatnote for Thomas Jefferson, but maybe it's not a good idea... (And if this is in the wrong place on the Village Pump, feel free to move it to wherever it should belong, just leave me a note on my talkpage.) Cheers, Shearonink (talk) 07:38, 1 December 2012 (UTC)

I support the general idea. I suggest you team up with the people actively discussing this proposal, it deals with the same subject: RfC: Complicated articles — Preceding unsigned comment added by Jesus Presley (talk • contribs) 09:50, 1 December 2012 (UTC)
Thanks for the link. Shearonink (talk) 15:51, 1 December 2012 (UTC)

Average size of article by Wikipedia?

I had posted this on "Proposals" but one user pointed out that the right place for it is "Idea Lab". Here for the record are the exchanges that had already taken place on "Proposals".Basemetal (talk) 18:12, 10 November 2012 (UTC)

Usually the size of a Wikipedia is considered to be its number of articles. But if you compare Wikipedias you'll see that they differ not only in how many articles they have but also how detailed their articles are. Typically articles in the big languages are several times longer than those in smaller languages. So the relevant, the real size of a Wikipedia is not so much its number of articles as much as (number of articles) X (average size of articles). Can the average size of the articles of a Wikipedia be easily computed? I would then propose to add a column to the table in http://meta.wikimedia.org/wiki/List_of_Wikipedias to also display the parameter (number of articles) X (average size of articles) for the list of Wikipedias Basemetal (talk) 19:27, 6 November 2012 (UTC)

The specifc proposal here has several implicit assumptions, including how "size" is to be measured, and that "size" in some form is "good" in some form. Consider: if two wikis had the same number of articles and words of text, and the same average size of articles, but one wiki had the text distributed fairly evenly across all articles, and the other had a preponderance of the text in a small number of articles, would they be equally good? I think not, the numerical equality of the metrics not withstanding. In such a case one might also consider the different kinds of "averages" (mean, median, modal), but all this still misses a key point: the overall quality and trustworthiness of an encyclopedia.
To the extent that the distribution of article sizes is important, there are some ways this might be measured. But this would be a rather deep discussion perhaps better done in a different venue. ~ J. Johnson (JJ) (talk) 22:53, 7 November 2012 (UTC)
Come on people. Life is short and there's stuff to do. This is a pragmatic proposal. The question is: would a table with a column indicating the average size of articles in wikipedias be more or less informative than a table that did not have that column? Sophisticated argumentation about "implicit assumptions" and deep philosophical points do not really answer that question. If two wikis had the same number of articles but one was full of garbage whereas the other was crammed with high quality content, would they be equally good? I think not. Well, but we still have a column with the number of articles in wikipedias. Such parameters might not answer all the questions but they are better and more informative than nothing. We might miss "a key point: the overall quality and trustworthiness of an encyclopedia" but until we can encapsulate quality and trustworthiness in a simple numerical parameter that we can display in a table then we're stuck with this kind of crude ones: number of articles, average size of articles, etc. Do you have a constructive proposal to make? Would you like to add yet another column with the sigma of the distribution of the size of articles? Then by all means say it. Otherwise... Let's get down to real work.Basemetal (talk) 12:50, 10 November 2012 (UTC)
Can the average size of the articles of a Wikipedia be easily computed?". No. Besides the obvious issues with markup, text and non-text in templates, non-prose material, etc. Each language has different alphabets, semantics and word lengths. For example, a sentence in Japanese vs a sentence in English may differ in length drastically when the context is the same. You dismiss the editor above (who hasn't outright opposed any of this, mind you) for trying to answer your own question, yet offer no in-depth guidance on how we would calculate size, not to mention technical details. This being "proposals" and not "idea lab", one would expect you to have done some research on this. —  HELLKNOWZ  ▎TALK 15:35, 10 November 2012 (UTC)
Sorry. You are right on all counts. I didn't understand the difference between "proposals" and "idea lab". I'm going to transfer this thread to "idea lab". Anyone who wants to react here please don't and go to "idea lab" instead. Thank you.Basemetal (talk) 17:57, 10 November 2012 (UTC)

This started on the Discussion page of http://meta.wikimedia.org/wiki/List_of_Wikipedias. There was one intervention by A. Mahoney which I am copying here

I agree that the average length of an article is a useful measure. But I don't agree about the total number of characters (or bytes, whichever way you're measuring length); that seems less useful. The parameter (number of articles) times (average size of articles) will be the same as (total number of bytes/characters in all articles), since after all (average size) = (total characters)/(number of articles). Of course that means it would be really easy to add to the table, since it's a step in calculating the average size! A. Mahoney (talk) 13:18, 7 November 2012 (UTC)

The discussion on "Idea lab" could start here.Basemetal (talk) 18:12, 10 November 2012 (UTC)

If were going to start here then maybe you could kick things off by explaining how this idea would help us in our task of building an encyclopedia? In your own words, "Otherwise... Let's get down to real work". Phil Bridger (talk) 21:56, 10 November 2012 (UTC)
I could answer something like: "It could help build a better encyclopedia just the same way that any other data (e.g. the number of articles) in the List of Wikis table does, just the same way that any parameter that helps to describe reality, albeit often in crude and imprecise ways, helps you evaluate what you've achieved and map out what needs to be achieved, just the same as mapping cities, for instance, helps you build better cars if those are to be used in cities, etc. etc." but I wont. Because Idea Lab "is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, [Idea Lab exists to] discuss ideas and suggest variations on them" and because I do not want to spend any energy defending the point that this metric can be useful to both users and editors (or worse, risk the discussion being sidetracked into an endless for or against series of arguments). Obviously we two do not have the same idea as to what real work is. But that need not be a problem. If you are not convinced that having such a metric available would be useful then please concentrate your efforts in some other area for there is still plenty that still awaits doing. In my opinion the discussion should kick off by addressing the points raised by HELLKNOWZ regarding the difficulty of comparing article size across languages and writing systems.Basemetal (talk) 00:29, 11 November 2012 (UTC)
If you wanna do it, come up with a reasonable proposal for how and find a technical person to implement it. There's really not much here that needs discussing. —Tom Morris (talk) 23:50, 10 November 2012 (UTC)
Right. Well, we'll have to agree to disagree on this one. I think there is plenty that needs discussing (see above)Basemetal (talk) 00:29, 11 November 2012 (UTC)
I am including the statement you find at the top of the editing page. Maybe that will help steer the discussion in a more useful direction:Basemetal (talk) 00:29, 11 November 2012 (UTC)
 This Village Pump is for developing ideas, not for consensus polling. Rather than merely stating support or opposition to an idea,
 try to be creative and positive. If possible, suggest a better variation of the idea, or a better solution to the problem identified.

What do you guys think of the following two methods aiming at bypassing the difficulties raised by HELLKNOWZ regarding the variety of languages and writing systems. (He raised also other points, but I'll get to them later):

1. The stub method:

Define the size of an article in any language Wiki (for the purpose of computing the average size) as (size in bytes) / (average size of a stub in that Wiki); language specific differences which prevent comparing things across languages would cancel out since languages with relatively longer (or shorter) articles simply as a result of a property of the language would also have relatively longer (or shorter) stubs

2. The section method:

Define the size of an article in any language Wiki (for the purpose of computing the average size) as simply the number of sections in the article. Long in-depth detailed articles have typically many sections. And the more detailed an article the more sections. The number of sections should not depend on the language (or at least I don't see why it should) but only on the subject matter and at what level of depth and detail it's being treated.

Tell me what you think. I'll try and address the other issues raised by HELLKNOWZ (markup, formatting, non-text, e.g. video, etc.) some other day but this is enough for today and I'll stop and wait for comments. See ya.Basemetal (talk) 01:43, 11 November 2012 (UTC)

I believe you can get stats on disk space used, which would account for images as well. WhatamIdoing (talk) 04:43, 11 November 2012 (UTC)
Are the disk space stats mentioned by WhatamIdoing from the same source as that mentioned by MarsRover? Basemetal (talk) 18:29, 14 November 2012 (UTC)
I believe this report shows you the variables easily retrieveble. And it appears database size is not updated that often. The database size is not really a good number to compare various wikis. There are two problems: language itself (e.g. less characters for Chinese vs. English for same meaning) and character encoding (e.g. more bytes to store Russian characters than to store English characters).
My suggestion of a simple way to solve this would be to use the "size of compressed export of all articles" as a rough number for the total content size. This would give true content more weight than for example adding a big repeative table to an article. This number can be divided by the article count to give a content per page number. I think the "compressed articles number" can be scraped from the subpages of the following webpage [12].
For example "enwiki-20121101-pages-articles.xml.bz2 8.8 GB" and there are 4,096,170 articles, so you get a number of 2306 compressed bytes per article in English wikipedia. And "ruwiki-20121107-pages-articles.xml.bz2 1.7 GB" with 926,583 articles, so you get a number of 1969 compressed bytes per article. --MarsRover (talk) 23:41, 12 November 2012 (UTC)
Pretty neat MarsRover. And Jimbo's head appearing out of nowhere like Jack Nicholson's at the window in the last scenes of The Witches of Eastwick or like either of Mars's twin moons Phobos ("fear") and Deimos ("terror") (ooooh!) over a Martian landscape that's a pretty ingenious trick too (the first time I saw him enter outta the left side I got so scared I dived under my desk). I've got to learn to do that (I don't mean diving under my desk). Now regarding your suggestion I'd like to ask you a few more questions but they are so embarrassingly simple that I'll do it on your talk page. Whatever valuable comes out of that exchange I'll post here in order to further the technical discussion. Basemetal (talk) 18:29, 14 November 2012 (UTC)

Perhaps I missed something, but what is the supposed benefit of knowing the "average" size of an article (for some concept of "average")? ~ J. Johnson (JJ) (talk) 23:38, 13 November 2012 (UTC)

basemetal described the benefit fairly well in the third comment.
But my take on it is that is just a missing metric about the size of an encyclopedia. Like having the height without the width. IMHO, the depth column was a weak attempt to give you that other dimension. Basemetal's idea seem simpler and better version of "depth". As for the value, seems odd to have to explain that benefit of knowledge to an wikipedia editor but... if you want specific examples, the ability to compare wikipedias is a more holistic way (e.g. Is "Volapük" really a bigger encyclopedia than "Croatian"?) and because of human competitiveness and just a natural desire to fix things, having more measurements of an encyclopedia will actually improve it. --MarsRover (talk) 01:30, 14 November 2012 (UTC)
What is the supposed benefit of knowing the "average" size of an article (for some concept of "average")? Ok, I'll try to deal with this as best I can, but not now, a little later, when I have a little more time and not here. Not so much for the benefit of J. Johnson (JJ) since his mind seems to be pretty much made up (his question sounds more like a statement than a question) but in the direction of the "undecided". Since this is not the right venue for this kind of discussion I'll do it on my talk page unless someone can suggest some other Wikipedia public venue established precisely in order to host such discussions. Basemetal (talk) 18:29, 14 November 2012 (UTC)
  • We already have this information, though the latest available EN wiki stats are from 2010. If you look at Erich Zachte's stats he has figures measuring Wikipedias by both number of gigbytes and number of words. Dividing either by the number of articles gives you a measure of average article size. Does that give you what you want? ϢereSpielChequers 19:06, 14 November 2012 (UTC)
This is an average all right but it is not an average that you can easily compare across scripts and languages. This is what I'm trying to figure out how to do. For the moment we've got MarsRover's proposal (see above, and also mine but mine are a bit low-tech). But (as I wrote above in response to MarsRover's proposal) I'll first ask him a few questions on his talk page. For example I may be missing something but I don't understand how compression would make things comparable across scripts and languages. But like I said, I'll talk to him a bit first and report back here. I'll get back to you guys in a little while. Signed: Basemetal (write to me here) 17:46, 17 November 2012 (UTC)
Well yes, my suggestion ignores the issue of some languages generally being more verbose than others. But there is a fairly neat solution to that, either find an agreed verbosity factor or define one yourself, and weight the bytes per article by that. Of course the risk is that the common words in Wikipedia are different to those in the material used in your verbosity weighting process. Obviously it would work better if you didn't weight square brackets, Latin names for species and commons filenames. I suspect that the New Testament has been translated into all the languages that you would be interested in, if you can get a gigabyte count or word count for each version of the New Testament then that would give you your language verbosity factor, though there would still be a risk that the typical words used in Wikipedia articles are sufficiently different to those in the Bible or whatever document you choose for verbosity factor that the results may not be perfect. ϢereSpielChequers 08:43, 18 November 2012 (UTC)
Indeed predefined static "verbosity" factors as you call them are also a possibility. I'll keep this in mind, and of course the robustness of the factor you get this way can be tested for most languages against translations of other widely translated texts from other languages (Shakespeare, Old Testament, Don Quixote, etc. etc.) One problem I can see at the outset is that in Wikipedia we are not checking (most of the time) translations against each other but idiomatic ways of expressing the same amount of information specific to each language. Wikipedia editors do not (most of time) translate. They express information directly in their respective languages. Whereas the translators of the New Testament were not free to so to speak extract the informational content of the document and then express it idiomatically in their own words. Might this not artificially inflate that factor (except for Biblical Greek but there's no Biblical Greek Wikipedia and there are no doubt translations available in Modern Greek)? Now this problem may not be as serious if we could be confident that those factors would be inflated in the same amount for all languages. After all it is the ratio of those factors we are interested in, not their absolute value. Thanks a lot ϢereSpielChequers. One more idea in the bag. (As you can see I had to tweak a bit your nickname because the way you write it, it also gives access to your talk page which readers don't need at this point. Sorry about that.) Signed: Basemetal (write to me here) 22:55, 18 November 2012 (UTC)
Yes you can't calculate a "verbosity factor" by looking at the Wikipedia articles on say Barack Obama in nearly 300 languages - some of these may be translations but many if not most will be different articles. That's why I'd suggest going outside Wikipedia and using a document that people are trying to translate exactly to calculate verbosity - the Universal declaration of Human rights might also be a good one. ϢereSpielChequers 10:08, 19 November 2012 (UTC)
The idea of using the Bible to figure out a verbosity factor has been examined --> here. We even have a table of numbers you can use. I think is works somewhat ok but it has some flaws. Not just the common characters like "[", "]", "{" and "}" being included as a higher weight. But you can have issue like a Korean article about the ko:Beatles. The article will basically list the musical catalog in English but be weighted as Korean.
Sorry, I didn't reply about the "compressed bytes" idea. But I believe it will solve the problem of comparing "byte sizes" between two different character sets. For example, Russian character is usually two bytes even though there alphabet is the same size as English because it encoded as UTF8. So, I think the compression will allow you to compare those two sizes because the first byte in Cyrillic characters is repeated. As for making the actual content comparable, If you repeat the English word "language" several times and repeat the Chinese character "语" the same number of time, they probably compresses to the same number of bytes. If so, it would be a lot easier than first trying to convert bytes to characters for every single article than applying a weighting scheme. --MarsRover (talk) 21:10, 20 November 2012 (UTC)
You probably mean "[and] then applying a weighting scheme" not "than applying a weighting scheme"? That is, the compression idea is easier than "first trying to convert bytes to characters for every single article [and] then applying a weighting scheme". Did I read you correctly? Signed: Basemetal (write to me here) 19:03, 28 November 2012 (UTC)
Regarding your compression idea: yes, this is what I thought the idea was, but I wasn't sure. Thanks for clarifying. Signed: Basemetal (write to me here) 16:04, 2 December 2012 (UTC)
often times, when looking at stats, "Median" is more interesting value than "Average" (strictly speaking, "Average" is not well defined, but most people take it to mean "mean", i.e. total size divided by number of items).
the neat thing about it is that unlike the "Mean", the median value of any wiki based on the "mediawiki" platform is readily available: all you have to do is go to Special:ShortPages, and add to the address line "?offset=<half of the number of articles>". for instance, when i write this, there are 4,107,333 articles in enwiki. half of it is 2,053,666.
this makes Nevius Street Bridge the median, with a size of 2,826 bytes (same as many articles before and after it - there is serious conglomeration around the median).
quick check shows that in arwiki, the size of the median article is 2,264 bytes. since in Arabic, every characters weighs 2 bytes (wikipedia uses unicode), and taking into consideration that punctuation, spaces, and wikicode ([, {, < and so on) is the same as latin (i.e., each characters weighs one byte), a conversion factor of 70% can be used (i.e., the # of characters is roughly 70% the number of bytes). specifically, the median article in arwiki is 1568 characters long. the median in nlwiki is 1395 characters, in frwiki the median is 2251 bytes/2138 characters, and in hewiki the median is 4487/2853 (bytes/chars). what can one learn from this? i do not know. peace - קיפודנחש (talk) 20:42, 28 November 2012 (UTC)

A HUMBLE SUGGESTION : ADDITION OF COMMENTS SECTION

Hello Sirs,

I can see that you don’t have the comments section below the articles and the literature your are providing. I am absolutely sure that your pages will get 100 times more hits than the regular ones. Youtube is one of the example, because more people enjoy reading the comments about the videos posted.

With best regards

Khan Salim, A reader 00965 97200313 — Preceding unsigned comment added by Salimuniversal (talk • contribs) 08:47, 25 November 2012 (UTC)

Yes, but increasing readership is not our objective. Improving the encyclopedia is. In a sense, everything else is a "side effect". And you haven't demonstrated that the comment section is going to help to improve the encyclopedia. Thus I see significant costs and no clear benefit. --Martynas Patasius (talk) 15:56, 25 November 2012 (UTC)
Also, we already have the feedback feature, which are comments to help us improve the encyclopedia. --Cyclopiatalk 16:10, 25 November 2012 (UTC)
I disagree with both Martynas Patasius and Cyclopia and am in agreement with Khan Salim (Salimuniversal).
To say increasing readership isn't an objective, overlooks it is among readers Wikipedia finds its editors: the more readers, the more editors, the better the quality. The feedback feature isn't a substitute. There is no page specific feedback page for all pages and it can't be accessed easily by readers unfamiliar with Wikipedia. A comment page would be more free-form than a feedback page which is geared towards improvement, or the talk page which is meant for discussion around editing, and thus an added benefit of a comment page would be that it would give readers a venue where they can form a small community around an article and its topic, vent frustration, display wit and humor, spend their energy and go a little bit crazy if they want to, which would reduce the amount of vandalism to articles. I don't see what "significant costs" Martynas Patasius is talking about.
I think Khan Salim's suggestion is brilliant and its time will come, but it will have to fight its way through the usual "Who needs that? We're already fine!" type of reactions.
Finally, arguing for or against, is not what this Idea Lab page is for. Khan Salim used this page as it is intended to be used but we three (me and the other two) who are arguing about whether his idea is good or not, are not. This is the place to discuss suggestions how Khan Salim's suggestion can be implemented and improved upon.
Khan Salim, I think your suggestion is great. Keep the discussion going. You can sign your posts with the four tildes.
Signed: Basemetal (write to me here) 17:37, 3 December 2012 (UTC)
"I don't see what "significant costs" Martynas Patasius is talking about." Software maintaineance, and comment moderation, for a start. --Cyclopiatalk 17:41, 3 December 2012 (UTC)
Comment moderation? What other page of Wikipedia is moderated? In any case you can't assume it would have to be moderated. That would have to be another discussion. What specific additional software maintenance costs than those involved in running Wikipedia? And you say "for a start". You mean you envision still other costs. Such as? The interface of course should not be a complicated one with markup like the normal Wiki editor but a simple one like that of the feedback thing. The whatchamacallit opens and you leave your comment. That should prevent the kids from fucking with each other's comments. Contrary to YouTube (say) there ought to be no requirement that you register but the kids should be pointed out the advantages of registering, such as having each their own nifty signature in colors and everything. Now I could wax epical about all the advantages I already can envision, but I'll first wait for some traffic. It's so simple and brilliant I'm surprised I didn't have it myself. (We need some smileys around here, you know I'm kidding.) Is it possible that in 12 years no one in Wikipedia has come up with this idea and there's been no discussion around it? Or is it hidden in archives somewhere? If you know please let me know. Signed: Basemetal (write to me here) 19:13, 3 December 2012 (UTC)
No, I'm pretty sure the idea of a comments section has been made before. However, the concept provides almost no benefit to the encyclopedia, while yes, the cost of maintaining software and moderation would not be trivial. For instance, we would have to enforce the BLP and NPA policies just as we would any other forum. And anyone who actually does read YouTube comments knows that this would not be an insignificant time cost. But the truth is, both talk pages and article feedback provide this service in a fashion that we do need - discussions of the article itself. Wikipedia is neither a forum, nor a social media site by design, and it does not need to become one. Resolute 20:02, 3 December 2012 (UTC)
Or to put it succinctly, it flies in the face of multiple points of WP:NOT. ♫ Melodia Chaconne ♫ (talk) 20:26, 3 December 2012 (UTC)
Oh well. I guess it will take another generation of Wikipedians to understand the concept and see its benefits. Note guys (Martynas Patasius, Cyclopia and Resolute who argued on the basis of predicted costs) that I defer to you guys on the question of costs which I may not have been sufficiently aware of. But I feel you do not understand the benefits. And the fear that it would turn Wikipedia into something it isn't and doesn't want to be is unfounded and arises precisely from that misunderstanding. It is a bit like if someone had proposed: "I think Wikipedia should open a chain of restaurants where people could come do what people do in restaurants but in the same time congregate to work on editing, etc." Now that might or might not be a good idea. (I doubt it would be.) But the point is that, one may criticize such an idea on many grounds, but criticism it would somehow turn Wikipedia into a restaurant chain is the least valid of them and can only come from a lack of understanding of its goals, when they are precisely to further the very purpose of Wikipedia. In any case, one can argue a priori about the precise costs and benefits one could expect from comments pages. Or, using the experimental method, one could establish comments pages for a few well chosen articles and see what happens. If indeed it's a mess and nothing good happens, it's never too late to shut them down. Like I said, I'm convinced that whereas 2012 Wikipedia might not yet see the benefits of Khan Salim's idea, this is an idea whose time will come at last. Khan Salim, I guess we'll have to wait, but we won't lose hope. (Where's that damn smiley?). Cheers, and thank you all for sharing your thoughts. Signed: Basemetal (write to me here) 23:28, 3 December 2012 (UTC)
Disagreeing with you is not the same as not understanding the concept. Resolute 02:35, 4 December 2012 (UTC)
Ok. I'll let you have the last word. Cheers, and thanks again. Signed: Basemetal (write to me here) 20:17, 4 December 2012 (UTC)

Personal Private Notes

I have a recommendation for a feature for Wikipedia that would vastly improve its value for some people.

Many research websites now have space for registered users to insert their own, private (or small community) notes which are not visible to the general public. Such notes might be anything from comments, links, and other data that can help them in their research and study. This would greatly personalize Wikipedia. Such tools have an extra column for the notes, tools which allow the user to "permanently" highlight the text of the Wikipedia article with different colors (and links the highlight to any note created about it), and an index page that lists the pages where the individual has added comments.

Perhaps the tool I am looking for is already there. If so, where is it? If not, is there any plan to implement this idea? — Preceding unsigned comment added by Chad A. Woodburn (talk • contribs) 13:24, 24 November 2012 (UTC)

Something like Scrible maybe? See also web annotation.--ukexpat (talk) 21:24, 3 December 2012 (UTC)
If you use Firefox, check into wired marker. I just added it and have only used it a couple times, but it seem to do what you want. You can add highlighting to a page, and a comment.--SPhilbrick(Talk) 18:33, 5 December 2012 (UTC)

List of pages on no watchlist?

Is there a way currently to display in Wikipedia a list of all unwatched pages, that is all those pages that are on no one's watchlist?

If there's no way currently, then how technically difficult would it be to accomplish?

Signed: Basemetal (write to me here) 09:03, 5 December 2012 (UTC)

This is already available at Special:UnwatchedPages. But since a list of unwatched pages would be useful to vandals, the software will only show the page to administrators. -- John of Reading (talk) 09:11, 5 December 2012 (UTC)
Such a list would also be useful to counter vandals. In the past two days I've reversed one vandal acting from two different IP addresses who was bent on introducing Ice Cube into the Fall of the House of Usher article. No bot detected anything. Only human attention can detect those things the way that guy was doing it. But I could notice that only because that page was on my watchlist. What happens to unwatched pages, where no one is watching? So the fewer unwatched pages the better if you want to counter vandals effectively. A list of unwatched pages would indicate to users those pages that still need to be watched. They could "adopt" one or two unwatched pages simply for the purpose of watching over them to counter vandals. They would put those in their watchlist besides those they already watch for their own personal interests. As they adopt one of those pages, that page would no longer be unwatched and so it would disappear from the unwatched list, but only as long as the adopting user was a registered user, or a user from some more restricted category such as autoconfirmed users (otherwise vandals themselves could, by "adopting" a page, make it disappear from the unwatched list). Note that vandals do not have access to the unwatched pages list but they can already determine, with a tool available to anyone, for any page, if it is watched or not, and if it is watched by how many. Signed: Basemetal (write to me here) 11:25, 5 December 2012 (UTC)
Wikipedia talk:Special:UnwatchedPages#Toolserver watch lists an "Unwatched changes" tool. — Dispenser 16:38, 5 December 2012 (UTC)

IPs - Edit summary abuse - External link spam

I seek ways to discourage one particular type of vandal.

At least one prolific (yet blocked) IP sockpuppet is motivated mainly by getting visibility for external links supporting their POV on various subjects. They do driveby external linking, and to ensure visibility they repeat the full link in the edit summary field. Some of us have been trying to reform this behavior by reverting the external link spam but our friend can still tell himself that he is getting visibility for these links because they remain in the edit summaries.

I would like to find a way to reduce this fellows motivation by cutting off his ability to use edit summaries as a podium for his POV.

TENTATIVE IDEA The simplest method I have come up with is to simply prevent IPs from adding backforward-slashes to edit summaries. Would there be any significant collateral damage?

All other questions or comments welcome NewsAndEventsGuy (talk) 14:13, 8 December 2012 (UTC)

Internet links have normal forward slashes as in http://en.wikipedia.org/wiki/Wikipedia:Village_pump. Backslashes are often used for file paths in operating systems as in C:\Windows\system. Preventing IPs from adding forward slashes to edit summaries would have too much damage. And it's often good to include a url in an edit summary. I don't think it should be prevented. PrimeHunter (talk) 16:43, 8 December 2012 (UTC)
Please explain the basis for your belief that edit summaries can sometimes be substantively improved by including urls, as opposed to just summary text NewsAndEventsGuy (talk) 18:21, 8 December 2012 (UTC)
If a url is given in both the edit and edit summary then you often get an idea what is going on before deciding whether to spend time examining the diff. For example, if a known unreliable web source is added then I consider it an advantage that it's also shown in the edit summary so other editors can easily spot it. And I don't think they get any exposure worth worrying about. Edit summaries are aimed at editors and not readers. All pages showing edit summaries are excluded from search engines, and not viewed by normal readers. And here are some cases where I, in order to explain an edit in a way others could examine, mentioned a url which was not and should not be in the diff: [13][14][15][16]. PrimeHunter (talk) 05:56, 9 December 2012 (UTC)
That reason (1) provides examples from a registered user and I am talking about IPs - your continued use of edit summaries with urls would be unaffected; (2) involves a lot of trust (i.e., it saves the rest of the time of inspecting the diffs only after we truth-check enough diffs to get confirmation of our assumptions of good faith... and for IP editors is a whole lot higher); and (3) you have completely missed the point about visibility. It is not whether external links do in fact get greater visibility. Rather, the question is whether this particular disruptive editor has a sufficiently plausible reason to believe there is greater visibility. And what is his target audience? Apparently it is us editors, at least those who frequent the subject areas this guy targets. NewsAndEventsGuy (talk) 15:17, 9 December 2012 (UTC)
I have never noticed a problem with excessive use of urls in edit summaries. We shouldn't ban a useful feature just because somebody may have abused it, and it would annoy many constructive editors if their edits couldn't save before a perfectly reasonable edit summary was changed. I don't know who you refer to but how do you know their motivation? Maybe they just want to tell what they are adding and would still make the same edits if they couldn't include the url in the summary. It's common to make the summary by copy-pasting from the edit. It even happens automatically in some cases. PrimeHunter (talk) 16:38, 9 December 2012 (UTC)
Please introduce me to three regular editors and three IP editors - where the IPs use external links in edit summaries to such an extent that the regular editors would be annoyed if those IPs were no longer able to do that. NewsAndEventsGuy (talk) 16:49, 9 December 2012 (UTC)
I searched the 5000 most recent IP edits for edit summaries containing "http". There were eight: [17][18][19][20][21][22][23][24]. None of them look abusive and most of them benefit from the url in the edit summary (the third was a good faith misunderstanding where the edit page url was copied to the edit summary). Some use the edit summary for a source which is better than no source at all. As for introducing you to regular editors who would be annoyed if IPs were no longer able to use url's in edit summaries, I doubt this have ever been proposed before so nobody has had reason to comment on it. It would be canvassing if I contacted other editors with the goal of getting such statements from them. But if this proposal is taken further then I guess other regular editors will oppose by themselves. We encourage use of edit summaries. If IP's cannot save because of the edit summary then they may just remove the whole thing and stop using them. PrimeHunter (talk) 18:53, 9 December 2012 (UTC)

New browser window on clickable content

Hi, this may be an old issue. If so, please disregard. But could we please have a new browser tab/window open when we click on items in articles? It would be a great help as I often will navigate to another page but need to reference the page I was on previously. — Preceding unsigned comment added by DragonHeart335 (talk • contribs) 16:11, 8 December 2012 (UTC)

I hate websites which do this. It should definitely not be default behaviour but in most browsers you can easily do it on an optional basis by holding down Shift or Ctrl when you click a link, or right clicking a link and selecting what you want. PrimeHunter (talk) 16:31, 8 December 2012 (UTC)
Or by clicking using the mousewheel, usually. --Izno (talk) 16:45, 8 December 2012 (UTC)
Indeed, middle click to open a new tab if you need to, left click if you don't. It's that standard Internet behavior. You can also configure your browser to open a new tab/window on left click (or at least Firefox) so if it's really so important, just do that. ♫ Melodia Chaconne ♫ (talk) 17:51, 8 December 2012 (UTC)

"as all get out"

Where did the comparison phrase "as all get out" come from? Is it from another language? Is it regional? Is it particularly dated?Jweswig (talk) 18:27, 5 December 2012 (UTC)JWeswig

This is really a question for the Reference Desk, but does this help?--ukexpat (talk) 18:52, 5 December 2012 (UTC)
The english language contains many nonsensical phrases such as this one. In most cases the phrase in question is an inoffensive substitute for a more vulgar alternative, and it is not uncommon for a person to express an idea in many different ways depending on the audience. In my experience "all get out" substitutes for a range of vulgar and/or sexual and/or racial phrases when the alternatives are deemed inappropriate for the present audience. Its value is in its simplicity and portability, allowing the speaker to emphasize an attribute of something without the need to correctly express an inoffensive specific property. Consider the following example:
  • General - slippery as all get out
  • Vulgar/sexual/racial - slippery as (use your imagination)
  • Specific - slippery as an eel

Downsize43 (talk) 04:07, 14 December 2012 (UTC)

Offline communication

I am trying to talk about electronic communication using OpenOffice-Writer by creating a page on Wikipedia using a new word: 'augscend'.

My 'augscend' page was rejected although my text used neutral tone English words.

I'm having a hard time inserting images to illustrate the concepts I talk about on the page.

This is frustrating since I have put a few hours into this effort and I'm getting nothing to show for my effort.

All I'm trying to do is share an idea - why is it so hard to share?

The web is not the only way to communicate≥ electronically. — Preceding unsigned comment added by Kind2afault (talk • contribs) 05:22, 11 December 2012 (UTC)

WP:MADEUP is why. ♫ Melodia Chaconne ♫ (talk) 05:50, 11 December 2012 (UTC)
Sharing new ideas is a great thing to do, but it isn't what Wikipedia is trying to do.--SPhilbrick(Talk) 14:05, 11 December 2012 (UTC)
That's right. Wikipedia is trying to share old ideas. Signed: Basemetal (write to me here) 14:52, 11 December 2012 (UTC)
not so much "old ideas" as "verifiable knowledge" (which also happens to include knowledge about notable ideas...) 209.6.137.153 (talk) 03:44, 16 December 2012 (UTC)

CSD for MfD

Having participated in a few MfD discussions recently, I've noticed that many deletion nominations sit ignored for a time. Perhaps a more efficient process would be beneficial, along the lines of CSD but regarding MfD? It would take the drafting of some criteria to determine what could be addressed through this process (userspace fake articles and other uncontroversial deletions), but I think this would be an easier and simpler way than the current method. A user would mark it, and an admin would check it; gone would be the long periods of articles waiting at MfD. dci | TALK 05:17, 16 December 2012 (UTC)

You know, I've been thinking that WP:CSD needs a G13. Non-admin close and uncontested deletions. for a non-admin who closes a successful XfD, or for a participant in an XfD that has gone through a full deletion discussion without being contested, but has not yet been closed. Such a proposal should probably be at CSD, though. VanIsaacWS Vexcontribs 10:33, 17 December 2012 (UTC)
Yes, that would help with efficiency. To increase the chance of input on these ideas, I'll make a note at CSD's talk page. dci | TALK 21:40, 17 December 2012 (UTC)
While I personally would support such a system, I expect there would be a lot of resistance to allowing non admin delete closes. Monty845 22:41, 17 December 2012 (UTC)
Are you suggesting this for MFDs that sit longer than 7 days or are you trying to speed up the process? Currently MFD defaults to 7 days partly to give people who only contribute once a week time to participate if they so choose. Moving MFD to something speedier may not be an efficiency gain, it might just be a further tilting of the tables in favour of very active editors to the disadvantage of less active ones.
That said there are some userpages that need to go quickly as either copyvio or attack pages. But in those cases CSD already applies, for what other sorts of userpages is there a need for urgent deletion? ϢereSpielChequers 23:11, 17 December 2012 (UTC)
Though it would be ideal, in my opinion, to speed up the process altogether, I think it's more reasonable to do this for noms sitting for 7+ days. I understand potential concerns about this disallowing less-active users' contributions; this would apply to many less-active editors whose userspace items might be up for deletion. The material that would be going through this process would really be the uncontroversial items, however, and I don't think it would concern most users if this occurred. The users whose pages often sit around for a long time haven't edited in years. dci | TALK 23:39, 17 December 2012 (UTC)

Bot Idea

I was wondering if there was a bot that's only purpose was to fix swear, rude, or pointless hateful words. I want to make a bot, but I have no experience at all for programming, yet I am O.K. at typing. I want to make one if there is none like it. --DPandaOPande (talk) 20:30, 16 December 2012 (UTC)DPandaOPande

There are various anti-vandalism bots that will take into account certain words when deciding whether to revert, but please note that Wikipedia is not censored, so any word, if used in an appropriate context, is acceptable here. I would also point out that making a bot, particularly one that can make sensitive judgements about language, isn't really a suitable project for an inexperienced programmer. Phil Bridger (talk) 21:44, 16 December 2012 (UTC)
And if you're talking about a talk page, it would be bad. You don't change other peoples' words on a talk page unless it's vandalism or something else that needs to be removed otherwise. ♫ Melodia Chaconne ♫ (talk) 21:58, 16 December 2012 (UTC)

Thanks for your replies, I just am interested in creating a bot. I also don't like swearing, so a bot for that seemed perfect for me. It was just an idea. --DPandaOPande (talk) 22:42, 16 December 2012 (UTC)DPandaOPande

There already is a bot that does that. It's called ClueBot (talk · contribs).
There was some talk at WT:WikiProject Council a while ago about wanting a bot to clean up lists of participants in WikiProjects (mostly removing or marking the usernames of people who haven't edited in years). It would also be nice if the WP:WikiProject Directory were automagically maintained. Perhaps something like that would be a good project for you. WhatamIdoing (talk) 00:47, 17 December 2012 (UTC)

Ref-code obscuring main text

Hi! I have been thinking for a while that as Wikipedia backs up more and more material in articles with sources, it gets harder and harder to identify and navigating in the main text when making quick edits. I also think that it feels way more intimidating to a casual visitor maybe trying to make a first edit. Any thougts on this? Has it been discussed before? My first idea at a solution is putting bots on making automated ref-name tags, (that editors can change to more suitable names if needed), and so systematically collect reference-code at the bottom. -- Kiewbra (talk) 22:47, 16 December 2012 (UTC)

Have a look at shortened footnotes, which allow you to specify all the references at the end of the article and not clutter up the body text. — Hex (❝?!❞) 00:15, 17 December 2012 (UTC)
Or WP:LDR, which just moves them all to the end.
Also, WikiEd (see Special:Preferences > Gadgets) cahnges the colors so it's easier to read while editing. WhatamIdoing (talk) 00:49, 17 December 2012 (UTC)
WP:LDR was what I meant by "ref-name tags". The problem as I see it, is that most pages aren't written like that. So I thougt that maybe the work could be done automatically, to clear up the body text. Thanks for the other tips. – Kiewbra (talk) 14:37, 17 December 2012 (UTC)
Ah, I see. It would be a massive amount of changes to be made by such a bot, so I don't think it would ever be accepted by the community, which has quite a conservatively high threshold for "if it ain't broke, don't fix it". However, such changes can be made on an article by article basis when it seems like the references are overwhelming the text - that's down to editors in each case. If it would be a very big change to the structure you might want to raise the suggestion on the talk page first so as not to surprise anyone.
Incidentally, shortened footnotes are basically the same thing as LDR, except more flexible and powerful - a big advantage is that you can define a reference once, and then cite different pages from it individually, instead of having to define a reference for each source-page combination. — Hex (❝?!❞) 15:53, 17 December 2012 (UTC)
with all due respect, suggesting "shorter footnotes" does not make sense to me. we have a "Cite" button in the toolbar, and this is what it squirt into the article when used (i selected "cite book", but the others are pretty similar, as far as length is concerned): <ref name=y group=z>{{cite book|last=a |first=b |title=c |year=d |publisher=e |location=f |isbn=g |pages=h |url=i |author=j |edition=k |authorlink=l |coauthors=m |editor=n |accessdate=o |archiveurl=p |archivedate=q |page=r |language=s |format=t |chapter=u |date=v |month=w |quote=x }}</ref>. admittedly, i filled every single field of the template which is not the typical case (OTOH, in the "typical case" the content of the fields is significantly longer than the single letter in above example), but i don't think it would be a fair suggestion to use less fields than actually make sense for a particular footnote just so we can have "shorter footnotes". peace - קיפודנחש (aka kipod) (talk) 16:15, 17 December 2012 (UTC)
I think you've misunderstood. Shortened footnotes refers to using the {{sfn}} template or similar to produce a parenthetical (Harvard) reference footnote that links to a full {{cite book}} (or news, journal, etc.) in the references section. — Hex (❝?!❞) 16:33, 17 December 2012 (UTC)
you are absolutely correct in saying i did not understand. my bad - thanks for the clear explanation. peace - קיפודנחש (aka kipod) (talk) 20:50, 17 December 2012 (UTC)
Actually, there's a script at User:PleaseStand/References segregator that lets you convert a single article to LDR in a few clicks. I recommend manually naming all the refs first, and IMO the LDR approach is best suited to an article that cites a handful of sources several times, rather than many sources once each. (Of course you don't do it against consensus.) WhatamIdoing (talk) 21:02, 17 December 2012 (UTC)
Great find. Bookmarked. — Hex (❝?!❞) 21:32, 17 December 2012 (UTC)
I'm a big fan of LDR, although it isn't perfect. It means you can't easily edit a single section. But I do think it helps clean up the editable version considerably.
The LDR can co-exist with the more traditional approach. When I add refs to an existing article, I often add them using the LDR approach, the others do not need to be converted. One should not convert refs added by others without getting consensus,; I did that once and got my hand slapped, so I check first if I decide to do a conversion.--SPhilbrick(Talk) 16:56, 18 December 2012 (UTC)
That sounds harsh, I'm accustomed to just do stuff that looks reasonable, and accept a revert if it wasn't appreciated. However, I still think editing would look less frightening for new learners with the default LDR. I rarely see it, as it is. (And I never saw shortened before.) But well, thanks for the tips anyway! -- Kiewbra (talk) 23:42, 18 December 2012 (UTC)

In category display, optionally also include subcategories in alphabetic listing

When displaying a category an alphabetical list of topics at the top-level of that category is shown, as well as a list of subcategories above. Typically, however, I want a complete alphabetical list of the articles in that category *and all subcategories*. Currently, to get that information requires manually descending into every subcategory! I suggest an optional link on each category page for "alphabetical display of articles in category and all subcategories". Technically I imagine this would be straightforward and I think would substantially improve the use of the category system for browsing. Any comments or suggestions how to initiate this change? 121.45.193.118 (talk) 10:36, 18 December 2012 (UTC)

Geolocalisation

Hi !

We are a group of students of a French engineering school in Lille. We are actually working on a new project based on Wikipedia geolocalisation. In that respect, we need to understand the needs and what is missing. So, we created a questionnaire, if you don't mind, fill it, we need as many answers as possible. Here is the link : https://docs.google.com/spreadsheet/viewform?fromEmail=true&formkey=dFZiSV8yWnV3bkxRUU5oaUhCT1d1SHc6MQ

Thanks ! — Preceding unsigned comment added by 193.51.52.41 (talk) 15:41, 18 December 2012 (UTC)

  • Would you mind providing a few more details about your project? I would also suggest creating a user account, and probably multiple so that the other students involved can access this more easily. dci | TALK 20:03, 18 December 2012 (UTC)

A bot for MetroLyrics links

Reader feedback has made it clear that many people who visit Wikipedia articles on musical artists, albums, and songs are looking for lyrics. Obviously, we can't provide them here due to copyright reasons in most cases. Until now I had been linking official sites of artists, which often host some (but not always all) of their lyrics with a proper license. However, this is very taxing, as each site uses a different layout, many don't permit linking lyrics of individual songs directly, and many sites change their layouts over time.

However, I recently discovered, to my surprise, that GraceNote has an extensive lyrics licensing service. Their first and biggest partner is MetroLyrics, which describes themselves as "the most comprehensive database of legal lyrics in the world with over 700,000 titles." They also license lyrics to Lyrics Wikia. GraceNotes also claims they employ "live editors to capture and review each song lyric to provide the maximum accuracy and consistency for all lyrics content," which would also seem to make their lyrics a reliable source.

I think an intriguing possibility is the idea of creating a bot which will automatically link every article on a song or album to its corresponding page on MetroLyrics (if it has one). Nothing in WP:EL would prevent this, and it would serve readers looking for lyrics. There are some obstacles, such as reliably matching articles up to specific songs, but there are many good heuristics for this (e.g. using infobox data, common title forms, etc). Some unresolved issues: should MetroLyrics still be linked if the official site is already linked? (as mentioned above, this may be a good idea due to official links being too indirect or unstable) Is it too promotional to link MetroLyrics in particular instead of a different GraceNotes partner? How prominent should the links be in the external links listing? Do we believe the MetroLyrics URLs will remain relatively stable over time? Thanks for your input! Dcoetzee 18:15, 21 December 2012 (UTC)

I think this is a great idea. I, too, often look for lyrics when reading an article about a musician or song. I must admit that I do have some slight concerns. If there are multiple sites that are reliable and provide lyrics with the proper copyright compliance, then I would like to use more than one. I'd rather not have people think we are favoring one site. Also, I'd sorta like to see some human oversight to verify the links are to the proper song and the lyrics are correct. Perhaps we could use a bot in two stages. The first stage would have the bot place a note in the external links section saying "add a link to a lyrics site by clicking here". The second stage would manually start the bot when the user clicked the link, then the bot would do its stuff and the user could verify that the link was proper before hitting the save button. This could also be used to get new users more involved with the project as it would be an easy first task they could try. These are just my initial thoughts, so I would welcome constructive criticism. Cheers. 64.40.54.83 (talk) 11:35, 22 December 2012 (UTC)
Well the thing is - all Gracenotes partners are going to have exactly the same lyrics (since they all come from the same place). So there's no meaningful reason I can see to prefer one site over another. An exception is Lyrics Wikia which maintains editable versions of each song, but I'm not sure if that'll make them more or less reliable (it certainly makes them less stable). One alternative we do have is to do something similar to what we do with ISBNs - which is to have an extension or special page that links to the lyrics on multiple commercial providers (e.g. Special:BookSources/0072970545). While this would help disperse the feeling of being promotional, it runs up against at least two problems: one is that there is no unique identifier for songs (the ISRC and PUID are not widely used); the other is that often only one of many lyrics sites will legally host lyrics for a particular song, and it seems unfortunate to make our readers search through links trying to find them. So I think at least for now it's best to start with just a single site, even at the risk of appearing promotional. I also don't think there's a need to get others involved, as I believe it could be done with very high accuracy given the available information - two stage might make sense for ones where there isn't enough information to confirm a match. Dcoetzee 13:34, 22 December 2012 (UTC)
Some more notes: upon review it seems like a lot of other Gracenote partners (e.g. mp3lyrics.org, Lyrics Wikia) also host some works illegally, which could be problematic, although it does seem possible to identify which is which. There is word in the news of a Yahoo! partnership with Gracenote, but I can't figure out how to access their lyrics database. So for now I think MetroLyrics is really the best bet. Dcoetzee 14:16, 22 December 2012 (UTC)
Went ahead and took this to Wikipedia:Village_pump_(proposals)#Linking_lyrics_from_legal_providers. Thanks for feedback! Dcoetzee 13:07, 23 December 2012 (UTC)


Fork mining?

When Wikipedia is forked, new developments are divided between its forks. Fork mining is the extraction of changes or improvements from one fork for inclusion in another fork. Porting from forks such as Citizendium is currently done by hand (See WP:CZP), and can be very time consuming and tedious.

Are there automated methods of updating Wikipedia by mining (or porting) new material from its forks? Tools that come to mind that might be applicable include document comparison, and the natural language processing methods for information extraction and text mining. Do any of tools of these types exist that can be adapted to fork mining?

Forked versions are still versions, and so document comparison should be useful. WP has a document comparison feature. One method available is to replace a WP article with the forked version (with attribution in the edit summary), and then revert. Then you can use diff to see how it differs from the current WP version, and cut and paste worthy changes to the WP version.

But cutting and pasting is cumbersome. It would be nice to find or develop tools that can amalgamate two articles offline, so the editor can edit it without having to do the cutting and pasting himself. Once he is done editing, the integrated result could then be posted as the current WP version. (With attributions, of course).

Do such tools exist? The Transhumanist 01:26, 24 December 2012 (UTC)

You can export and article, then import it into a wiki. Note that import is disabled for enwiki. --— Gadget850 (Ed) talk 00:49, 27 December 2012 (UTC)

Suggestion to have edit link for lede/introduction section by default

Every section on a page has its own "edit" link to allow editing and previewing of only that section, rather than the entire page, except for the introduction/lede section. Such a link can, however, be optionally enabled when logged in, so it is implemented in the wikimedia software. I suggest having this enabled by default, and when an introduction is edited using this link a short summary of, and link to, WP:LEAD given (e.g. "An introduction should be a stand-alone summary of recommended length < xx. See WP:LEAD".) Also, ideally, a word count of the current introduction section could be given, and a warning given if it seems too long. I think this simple suggestion could go a long way to improving the quality of introduction/lead sections. Any comments? 121.45.193.118 (talk) 12:41, 26 December 2012 (UTC)

I feel this is a good idea that would also increase the quality of leads. As most of the content is contributed by unregistered users, this would be very helpful.···Vanischenu「m/Talk」 15:43, 26 December 2012 (UTC)
I like this idea, and I'll note it is in the perfect place, which I think of as the incubator for new ideas, to get polished, then written up as a proposal.
I like the idea about suggested length, although I want the techies to tell us whether it is infeasible to do; in theory, one could write a conditional template that uses the article length to suggest the proper lead length.
I agree it should have a link to WP:LEAD, and might include some of the more pertinent advice as part of the message, for example, referring to the convention that the lead is a summary of material presented in the article body, and does not need to have references, if the body is properly referenced.--SPhilbrick(Talk) 19:35, 26 December 2012 (UTC)
I dislike the idea because it encourages driveby editors to merely tinker with leads instead of doing the preliminary grunt work of developing the body. They still do that of course, but why make it easier? NewsAndEventsGuy (talk) 20:25, 26 December 2012 (UTC)
I see it differently. While we know that some newbie editors don't know how to edit the lead, so there may be a few who have chosen not to (as opposed to those who ask and learn how), I suspect most editors, even new ones, can easily figure out that clicking the top edit button allows you to edit the lead. Clicking that button doesn't provide any feedback that there are special requirements for the lead. If this idea is enabled, then a new editor deciding to add some random fact to the lead, might see some warning that the lead has special considerations, and make a better edit. However, I'm speculating and cannot be sure. If the problem is viewed as a big deal, it could be implemented as a test, and we could monitor the results.--SPhilbrick(Talk) 21:11, 26 December 2012 (UTC)
Ok 180... I like the idea much more than the status quo, because of the educational component whenever a lead edit link is clicked. I skimmed too fast to notice that, thanks for correcting me. NewsAndEventsGuy (talk) 00:11, 27 December 2012 (UTC)
Comment: This is not "implemented in the wikimedia software." It is a Gadget using JavaScript at MediaWiki:Gadget-edittop.js. --— Gadget850 (Ed) talk 00:55, 27 December 2012 (UTC)
Oh yes, that is true- it is currently implemented in Javascript. Presumably that is why is was not originally enabled by default. Still, I can't immediately see why it could not be implemented in the base wikimedia software- perhaps a developer could comment on the technical feasibility if reading. Still, the current Javascript implementation shows that the lede and related figures can be robustly extracted and displayed. Actually, from previous experimentation, I found the ability to preview the lede with its associated figure(s) to be most useful to ensure that the intro can be understood independently. 121.45.193.118 (talk) 01:32, 27 December 2012 (UTC)

Semi-automatic signing

At present the bottom of the edit window has three buttons and a link:

  1. Save page
  2. Show preview
  3. Show changes
  4. Cancel

How hard would it be to add an option to sign edits?

  1. Save page
  2. Show preview
  3. Show changes
  4. Sign and save page (talk pages only)
  5. Cancel

If an editor clicks the new fourth option, the software would add the signature to the end, and save.--SPhilbrick(Talk) 16:07, 27 December 2012 (UTC)

I think that would make the edit window too complex. We already have an editnotice on every page reminding people to sign their posts—and you can easily insert a signature by clicking a link right below the edit window. David1217 What I've done 09:22, 28 December 2012 (UTC)

Revamping WP:non-free content review

Almost a year ago or half, this was nominated for deletion because of lack of activity. However, consensus was "keep" and no merge into other processes, like WP:files for deletion or WP:possibly unfree files. Since then, there have been too many backlogs. If we can improve this process, then we must prevent it from becoming a copycat of other processes. Ideas? --George Ho (talk) 21:40, 27 December 2012 (UTC)

Arabic Wikipedia

Hello. Anamasry contribute in Arabic Wikipedia (I leave study now), not good at only Arab (so use automatic translation by Google), but I want to take part in the English Wikipedia because it sister major and leader of our major, so I want to introduce my service to administratorsin the English Wikipedia: This is a list of the pages you've created in the Arabic Wikipedia, but some is not in the largest electronic scientific encyclopedia, I want create a project to translate the articles we present in Wikipedia and Arab non-existent in the English version --ديفيد عادل وهبة خليل 2 (talk) 21:05, 28 December 2012 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_9&oldid=1109646032"