Wikipedia:Village pump (proposals)/Archive 114

I don't know what the best venue for contacting the developers is, but I might try to register a bugzilla account and bring the issue up there as suggested by Xeno. I guess that's about it for this discussion for now.

23:02, 11 September 2014 (UTC)

Normal English does not use leading zeroes (e.g., 02 September 2014), so I wish we wouldn't in non-technical places. I am against have publication/birth/death/start/end dates in the right-hand boxes listed with leading zeroes in dates under 10 followed by a month and year. I couldn't find this in perennials. Has this been discussed? Is there a policy? Kdammers (talk) 03:27, 11 September 2014 (UTC)

Wikipedia:Manual of Style/Dates and numbers doesn't seem to mention anything about it. --NaBUru38 (talk) 03:42, 11 September 2014 (UTC)

Please link to an article showing the issue. Johnuniq (talk) 03:58, 11 September 2014 (UTC)

Yes it does, see table at

MOS:BADDATEFORMAT, it's in the second column as "09 June"/"June 09" and in the third col as 'Do not "zero-pad" month or day'. --Redrose64 (talk

) 07:00, 11 September 2014 (UTC)

O.K., then I'll start cleaning up sites that don't comply. Kdammers (talk) 07:13, 11 September 2014 (UTC)

@Kdammers: BattyBot removes the leading zeroes in citation dates where they cause CS1 errors. (e.g. this edit) If you notice places where BattyBot isn't making the fixes, please let me know so I can tweak my script. Thanks! GoingBatty (talk) 02:32, 12 September 2014 (UTC)

Hi all,

You may be interested in

12:50, 12 September 2014 (UTC)

Can we set off in the direction of more Help

I'd like to suggest that we write manual pages for the most-often-linked-to (at personal talk pages) policies, including documentation on frequent mistakes and misunderstandings (which admittedly have no place in policies), so that policy is only used for edge cases (assessing deletion criteria and the like) — not for getting started.

I suppose I could do this by myself, but that'd not be collaborative, and I'm not currently comfortable with the lengthy FAQ pages format or contributing to them (I'd personally have 1 page for each FAQ or perhaps a separate namespace, or really anything close to a structured help section of the site with each help item of small size, focusing on a single point). --Gryllida (talk) 11:34, 13 September 2014 (UTC)

Category:Expired editnotice currently contains two types of editnotices:

• editnotices which don't have an expiry time set, and
• editnotices which have an expiry time, which has passed.

At Wikipedia_talk:Editnotice#Category:Expired_editnotice, I have proposed that editnotices which don't have an expiry time set (which are possibly/probably intended to be "permanent") should not be included in this category, in order to better identify editnotices which have an expiry time, which has passed (which are probably obsolete and likely candidates for deletion). In the interests of keeping the discussion in one place, please express any views you may have on the matter at Wikipedia_talk:Editnotice#Category:Expired_editnotice. Thanks. DH85868993 (talk) 03:16, 11 September 2014 (UTC)

The template error has been fixed. The category is now named Category:Expired editnotices with an "s". -- John of Reading (talk) 06:27, 14 September 2014 (UTC)

Background

The Draft namespace was enabled in December 2013 (see Wikipedia:Drafts) and some WikiProjects (currently 1,482) have opted to use the Draft-class assessment to keep track of draft articles within their scope. The advantage is that it facilitates editors in a project to work on improving draft articles within their knowledge and interest to get them ready for mainspace.

Proposal

This proposal is about whether this usage should be widened by making it one of the default assessment classes used by projects. There are 3 options:

1. Status quo: projects can opt-in to using Draft-class.
2. Add Draft-class to FQS: all projects currently using the "Full Quality Scale" (FA, A, GA, B, C, Start, Stub, FL, List, NA, Category, Disambig, File, Portal, Project, Template) (approximately 1300) will automatically have Draft-class enabled, unless they choose to opt-out.
3. Add Draft-class to all: all projects using the standard quality scale (FA, A, GA, B, C, Start, Stub, FL, List, NA) (approximately 1900) will automatically have Draft-class enabled, unless they choose to opt-out.

For more details (including how this would be done), see Template talk:Class mask#Protected edit request on 1 September 2014

Discussion

• The Draft namespace is here to stay and is proving to be a useful place to develop articles. Currently, virtually all namespaces (e.g. templates, portals, categories, project pages) have their own assessment class and are included in the full quality scale. The File-class was the most recent one to be added. Therefore projects which have selected to use the FQS are probably interested in using the Draft-class, so I think option 2 is probably the most sensible. — Martin (MSGJ · talk) 13:22, 3 September 2014 (UTC)
• I choose Option 2 (Add Draft-class to FQS). --Redrose64 (talk) 13:58, 3 September 2014 (UTC)
• Good thinking, Martin. I support option 2. --122.109.102.172 (talk) 11:19, 4 September 2014 (UTC)
• Well, on the one hand, there are already a lot of rating classes as it is, but on the other hand, "Full" should really mean "Full", so I guess I would weakly support Option 2... Cooljeanius (talk) (contribs) 16:01, 4 September 2014 (UTC)

Note, Full doesn't include Book either. -- WOSlinker (talk) 11:46, 5 September 2014 (UTC)

It also doesn't include User, MediaWiki, Help, Education Program, TimedText, Module, Topic. --Redrose64 (talk) 12:10, 5 September 2014 (UTC)

As those namespaces do not contain articles, draft articles, or components of articles such as templates, they are not actually relevant. Roger (Dodger67) (talk) 09:24, 9 September 2014 (UTC)

Modules are components of templates (see, for example,

TimedText talk:03 Pink Try.ogg.en.srt). --Redrose64 (talk

) 11:32, 9 September 2014 (UTC)

• I prefer option 2, but I won't be heartbroken by option 1. Protonk (talk) 13:00, 5 September 2014 (UTC)
• As a regular AfC reviewer I prefer Option 3 but Option 2 would be acceptable too. The lack of a mechanism to routinely "notify" WikiProjects of the existence of drafts within their scope has been a perennial issue at AfC - thus I support the full implementation of this proposal. Roger (Dodger67) (talk) 09:24, 9 September 2014 (UTC)
• I was summoned here via Feedback Request Service, and I'm really not sure what Draft class provides that isn't already catered for by stubs, specifically as draft class seems to be intended to be used in conjunction with the draft namespace, which hides articles from potential contributors. Maybe someone can explain how this is a benefit to the everybody-can-edit model. Samsara (FA • FP) 00:29, 13 September 2014 (UTC)

  @Samsara: As you surmise, many drafts get created with few people knowing of their existence - the page creator, and those people who routinely check Draft: space for new creations. In order to bring these to wider attention (and hopefully encourage others to assist with bringing the draft up to a suitable standard for mainspace), Draft talk: pages may be tagged with WikiProject banners in the same way as the talk pages of regular articles. For those WikiProject banners which have already opted in to Draft-class, such as {{WikiProject Albums}}, if the banner is given |class=draft, or if the |class= parameter is left blank or is omitted, then the talk page is placed in a category like Category:Draft-Class Album articles. For those WikiProject banners which have not already opted in to Draft-class, such as {{WikiProject Jazz}}, the talk page is placed in a category like Category:NA-Class Jazz articles, even if the banner is explicitly given |class=draft. As I write this, there are two Draft talk: pages tagged for WikiProject Jazz, but Category:NA-Class Jazz articles has 81 members. Segregating the Draft talk: pages into a category of their own - which would be Category:Draft-Class Jazz articles - will help those two to be found more quickly, and shouldn't go unnoticed among the 70+ pages marked with |class=redirect that seem to comprise the bulk of the cat. This segregation may either be done by WikiProject Jazz opting in, in a similar manner to WikiProject Albums; or it may be done by a general change affecting the majority of WikiProjects. --Redrose64 (talk) 10:44, 13 September 2014 (UTC)

  I see that there's a complaint that the use of Draft space is associated with a growing review backlog. Is it really sensible to further encourage its use? In other words, is the review backlog a net benefit to Wikipedia, compared to allowing the articles to be stubs in regular space? For years, there has been concern that the rate of article creation is in decline. What has the effect of draft space on this been? It would seem possible to collect and publish some relevant data - maybe someone already has? Thanks for any further insights. Samsara (FA • FP) 15:13, 13 September 2014 (UTC)

  If the WikiProjects are made more aware of the drafts, perhaps some of their members will take up

  AFC reviewing, and so reduce the backlog. --Redrose64 (talk

  ) 19:36, 13 September 2014 (UTC)

• Support Option 2. It fits better in the full list than the cut down standard list. If the draft space is "here to stay" as mentioned above, it needs to included correctly in the pretty WikiProject article counts tables - see my query here. The-Pope (talk) 10:47, 14 September 2014 (UTC)
• Support 3, but 2 is acceptable as a first step, tho I don;t see why it has to go in steps--it is hardly going to be disruptive. Any wikiproject or individual editor that doesn't want to use the information can easily ignore it, but if even 1 person from each project pays attention to it it will help get better reviews. DGG ( talk ) 09:06, 23 September 2014 (UTC)

There is a proposal here that concerns our stance towards local interpretations of verifiability. Currently, most of the responses to the proposal are from members that are closely associated with the WikiProject that gave rise to the discussion. I believe the proposal could benefit from some broader perspectives. Thank you. Samsara (FA • FP) 16:54, 13 September 2014 (UTC)

This is primarily a discussion about whether you can use an image in an article if there are no published reliable sources that says this photo that looks exactly like the San Francisco skyline really is a photo of the San Francisco skyline (all the way down to far more complicated cases). WhatamIdoing (talk) 00:11, 16 September 2014 (UTC)

I feel that we need a space where people can create loose groupings, i.e. social groups or task-oriented groups, to gather some like-minded editors to help them edit entries in particular topics in areas of relevant interest. I propose that we have a new namespace, to be called "taskforce." alternately, it could be called clubs, but that is my second lesser preference for this idea.

I know we already have portal spaces for this and wikiprojects, but it is not the same. this would be more informal, and group on any topic or set of topics that people might wish.

It would have the benefit of drawing more interest here and generating more energy and activity in editing wikipedia.

comments? --Sm8900 (talk) 13:39, 12 September 2014 (UTC)

What would the difference betweeen this and WikiProjects be? Sam Walton (talk) 14:09, 12 September 2014 (UTC)

thanks for your comment. there can only be one WikiProject for a particular topic. this would allow any person or group of people to set up their own club for editing for a topic or for an area within a topic, even if there is already a wikiproject in existence precisely for that area or topic. --Sm8900 (talk) 14:19, 12 September 2014 (UTC)

Not seeing a difference. Project members will periodically do that now. Is your proposal designed to just add more social interaction into Wikipedia? GenQuest ^{"Talk to Me"} 14:24, 12 September 2014 (UTC)

WikiProjects often have overlapping areas. There can be more than one WikiProject for a particular topic, and these are often associated through the taskforce system. For example, railways come under WikiProject Trains; railways in the UK come under WikiProject UK Railways; railways in Scotland under WikiProject Transport in Scotland; and railway locomotives under WikiProject Trains/Locomotives task force. So a talk page like Talk:NBR 224 and 420 Classes has one WikiProject banner - {{WikiProject Trains}} - but with various parameters |UK=yes|Scotland=yes|locos=yes to bring in all those other projects and taskforces. Moreover, an article's talk page can have more than one WikiProject banner template. --Redrose64 (talk) 15:11, 12 September 2014 (UTC)

I think that our existing taskforce structure handles these things just fine. bd2412 T 16:33, 12 September 2014 (UTC)

I am trying to tap into the vast potential for interactive collaboration which exists on the Web. we can generate a lot more input if we give people much more leeway tos et up their own informal groupings of editors who can share interests and activities. I am saying that there should not be just one Wikiproject United States, for example; there should be ten, if people would like that. so this would be more informal, and more interactive. --Sm8900 (talk) 20:52, 12 September 2014 (UTC)

That sounds like chaos. If the ten groups agree with each other, it's duplication of effort; if five of them disagree with the other five, what happens then? --Redrose64 (talk) 21:07, 12 September 2014 (UTC)

well, any disagreements would only occur in the editing of the articles themselves. and there's no reason to think that this would generate that much more editing or conflicts on any single article in particular. It is much more likely that this would generate a marginally greater amount of activity on a number of separate articles which each appeal to different interest groups.

so therefore, for example, I would not expect 100 new editors to try to edit United States simultaneously; rather we might get one group which would pay more attention to the Civl War and the Old West, and another one to pay more attention to Theodore Roosevelt and the Progressive Era, and so forth. --Sm8900 (talk) 22:12, 12 September 2014 (UTC)

I still don't see why the article talk pages are not the most suitable venue for discussions which cover that specific article, nor why WikiProject talk pages are not the most suitable venue for discussions which cover more than one article. --Redrose64 (talk) 22:41, 12 September 2014 (UTC)

I'm also wary that it might encourage POV-oriented interest groups. Alsee (talk) 02:41, 13 September 2014 (UTC)

I'm sceptical as well. We already have article and user talk, WikiProjects, taskforces and various more specialized discussion venues. I don't see a use case that's not covered by this. And even if we would want to establish yet another type of discussion pages, why would it need it's own namespace? Even WikiProjects don't have that. — HHHIPPO 11:03, 13 September 2014 (UTC)

hm, ok. how about implementing this as a new type of item, but without a new namespace? let me know what you think. --Sm8900 (talk) 00:49, 14 September 2014 (UTC)

I still think the same as yesterday: I don't see a use case that's not covered by the existing types of discussion venues. — HHHIPPO 09:59, 14 September 2014 (UTC)

hm, ok. anyone else wish to comment? --Sm8900 (talk) 19:08, 15 September 2014 (UTC)

You wrote above, "there can only be one WikiProject for a particular topic". This is not true. The guideline says, "there is no rule that prohibits two separate groups of editors from being interested in the same articles". We don't recommend it, because it's inefficient, but it's perfectly "legal" to set up a WikiProject that happens to have the same scope as a pre-existing one. WhatamIdoing (talk) 00:08, 16 September 2014 (UTC)

Call to close

Consensus seems to be "not needed" (per HHHippo above), or it is too unclear/unfocused and needs refinement and resubmission at a later date. Call to close this proposal by lack of consensus. GenQuest ^{"Talk to Me"} 18:56, 16 September 2014 (UTC)

This portal's section "help out" should have "Create these articles", "Represent a worldwide view" and "Add historical information" as well, since in English Wikipedia there are still plenty of uncreated notable articles and articles requiring globalization or historical information, and these issues are not less important than articles requiring update. By the way, in the past this section has the block "Create" (I forgot its exact name, it refers to uncreated articles).--RekishiEJ (talk) 15:39, 16 September 2014 (UTC)

And {{Recent changes article requests}} should be transcluded to the block "Create these articles", since the template contains some uncreated notable articles.--RekishiEJ (talk) 15:41, 16 September 2014 (UTC)

• support. hm, that sounds good to me. --Sm8900 (talk) 20:26, 16 September 2014 (UTC)

As an encyclopaedia Wikipedia is a force for education, yet in the area of personal names it all too often fails. The particular names that I have in mind are East Asian names. In all parts of China, Japan and Korea surnames, clan names, call them what you will, are placed before given or personal names. Some articles follow this convention, but most don't.

Would it be polite for East Asians to call Jimmy Wales "Wales Jimmy" or Abraham Lincoln "Lincoln Abraham"? If not, shouldn't we use the proper order for other peoples' names? — Preceding unsigned comment added by 80.177.125.188 (talk) 10:56, September 18, 2014 (UTC)

It depends on the relevant Manual of Style. AFAIK, modern Japanese names should be presented in the western convention of Given name-Surname order, which is in accordance with

MOS:JAPAN, while most other East Asian names should be in Surname-Given name convention. The reason for this is because English-language reliable sources will almost always use the western convention for Japanese names, but isn't consistent with the other on East Asian names. —Farix (t | c

) 11:45, 18 September 2014 (UTC)

As TheFarix says, Wikipedia rules states tha we should follow the style of sources. So if the American and British press writes K. J. Choi, we don't use Choi Kyung-Ju. --NaBUru38 (talk) 17:57, 18 September 2014 (UTC)

My comment is not about article titles but just a note that the cite templates allow for this. If you have an Asian name where the family name comes first, instead of using "last=" and "first=" to give the author name, use just "last=" for the whole name, or as I prefer "author=". See, for instance, Template:Cite_book#Authors for details. Jason Quinn (talk) 19:04, 18 September 2014 (UTC)

It would be nice to have the watchlist NOT broken by day. When I log in in the morning, I want to see all changes for the last X hours. Not all changes since midnight, and then changes up to midnight somewhere else. Thoughts? Gaijin42 (talk) 14:38, 4 September 2014 (UTC)

• Support I would also like to see this. I tend to check multiple days worths of edits at a time on the articles on my watch list. The break down by days just adds a bunch of extra clicks I have to do to find all the changes since I last looked at the article. In particular the behavior of the preference "Expand watchlist to show all changes, not just the most recent" is less than ideal when a page has changes covering multiple days. I really would like a single click from my watch list to the diff of a page between the last time I checked it out to the current version. The changes since last visit link however is restricted to the current day. PaleAqua (talk) 00:24, 5 September 2014 (UTC)

@Gaijin42 and PaleAqua: I can see several days at once, so I'm trying to work out the problem here. What are your settings at Preferences → Recent changes for:

• Group changes by page in recent changes and watchlist
• Show Wikidata edits by default in recent changes

and at Preferences → Watchlist for:

• Days to show in watchlist:
• Maximum number of changes to show in watchlist:
• Expand watchlist to show all changes, not just the most recent
• Hide minor edits from the watchlist
• Hide bot edits from the watchlist
• Hide my edits from the watchlist
• Hide edits by anonymous users from the watchlist
• Hide edits by logged in users from the watchlist
• Show Wikidata edits in your watchlist

Not all of these will have a direct bearing on the matter: but I want to see how your setup differs from mine. --Redrose64 (talk) 08:46, 5 September 2014 (UTC)

I'm in the same situation as Gaijin42 and PaleAqua: I can see several days in my watchlist but they're grouped by day. The "n changes" link for a busy article that appears in yesterday's group and today's group too only shows that day's changes. The entry in today's group doesn't have a "changes since last visit" link for an article that's changed not just today but also yesterday since I last visited it. It would be great if you have a combination that works better. My settings are:

at Preferences → Recent changes for:

Y Group changes by page in recent changes and watchlist (de-activate for the "Show Wikidata" option below to work)

- Show Wikidata edits by default in recent changes and watchlist (does not work yet with enhanced changes)

and at Preferences → Watchlist for:

3 Days to show in watchlist:

999 Maximum number of changes to show in expanded watchlist: (I suppose I had a reason - I wonder what it was)

Y Expand watchlist to show all changes, not just the most recent

- Hide minor edits from the watchlist

- Hide bot edits from the watchlist

- Hide my edits from the watchlist

- Hide edits by anonymous users from the watchlist

- Hide edits by logged in users from the watchlist

Y Show Wikidata edits in your watchlist NebY (talk) 11:44, 5 September 2014 (UTC)

My preferences are very similar to NebY's. 10 Days, 1000 changes, Checked yes for expand, hide my edits, show wiki data, group changes. ( all else off ) PaleAqua (talk) 12:34, 5 September 2014 (UTC)

• Support. @Redrose64: I think the relevant settings are "Group changes by page in recent changes and watchlist" and "Expand watchlist to show all changes, not just the most recent". With those two activated, the watchlist basically contains, for each page, the part of that page's history within the given day. However, when there are unvisited changes from several days (which could be as trivial as last night before and after midnight), the history snippet for each page is not in one place, but there is one snippet for each day. In principle there are two possible solutions to this: a) get rid of the grouping by day entirely; b) keep the section headings, but show all changes to a certain page in a single expandable list positioned at the day and time of the last change. In both cases the disadvantage would be that we need to indicate not only the time, but also the date for each individual change. But I think that's a price worth paying for having all changes to a page in a single list, so this would be nice to have at least as an option (that is, user preference).

Regarding a single click from my watch list to the diff of a page between the last time I checked it out to the current version, that is not exactly the same: with or without grouping by day, such a link is available if and only if the last visited change to a page is within the chosen time span of the watchlist. In this case the "cur" link of the last visited change has the described (and very useful) function. It would be nice if such a direct link would be available even if the last visited change is not within the selected time span. For example, the link "xx since last visit" could refer to "all unvisited changes", rather than "all unvisited changes within the time span of the watch list" or currently "all unvisited changes on that day". — HHHIPPO 22:01, 7 September 2014 (UTC)

• Support: Any way this can be revived? It has always annoyed me that all your frequently-changing watchlist items appear twice in a watchlist that you bring up after an overnight break. Too common on this village pump page: someone comes up with an obviously good idea, a couple of people support, and there the matter ends and after no time here it is buried two archives back! I realise developers cannot pick up on every possible improvement but who decides what to pick up? and how?: Noyster (talk), 10:33, 22 September 2014 (UTC)
  • Based on the comments above, you can solve this problem either by turning off "Expand watchlist to show all changes, not just the most recent" in Special:Preferences#mw-prefsection-watchlist or by turning off "Group changes by page in recent changes and watchlist (de-activate for the "Show Wikidata" option below to work)" for Recent Changes.
    On the procedural question, when people have good ideas for software changes, they file them at bugzilla:, which is where most volunteer and staff devs keep track of software ideas. RedRose64 has an account there, as do many other people who read this board. (Accounts are free, but [a] they display your e-mail address to spammers and [b] Bugzilla is being replaced by Phabricator soon, which doesn't have that flaw.) Whatamidoing (WMF) (talk) 15:10, 22 September 2014 (UTC)
    • Thanks Whatamidoing, your first suggestion "turn off 'expand watchlist to show all changes...'" does seem to have achieved the desired result, namely that pages that changed both yesterday and today are now shown only in today's watchlist if it spans both days. (The second suggestion made matters worse). Problem solved.
      On the other matter do I understand then that 20 users can support Change A here at Village Pump, while a lone wolf requests Change B at Bugzilla which everyone else might disagree with, and it's Change B that gets made? A discussion that should no doubt take place elsewhere, but where?: Noyster (talk), 16:36, 22 September 2014 (UTC)
      • That's complicated. Ideas tend to be discussed all over the place. There have been some attempts to centralize discussions at Meta, but single-project editors (and people who don't speak English and/or German well) would ideally prefer that everything is discussed at their own project, in their own language, because it's hard to keep track of discussions that happen elsewhere (we need global watchlists, and we might get them...in a few years...assuming that SUL finalization is successful next year). However, there are 800+ WMF wkis and they cover more than 250 languages. You can't force someone to talk about Idea X at Location Y if they'd rather talk about it on a different page. (Think about how often you see a note that says "please discuss this on the other page!" and the replies are on this page.) The good news is that the larger projects, at least, have some good tech ambassadors, who spend a lot of time linking information from one to the other. With luck, one of them will notice your Change B request and provide the other side of the story. Also, the devs (staff and volunteers) will block bug tickets as requiring evidence of community consensus if it's something that their experience suggests is likely to be contentious.
        If you've got the perfect solution for this, then my boss wants to hear from you. Whatamidoing (WMF) (talk) 23:11, 22 September 2014 (UTC)
    • @Whatamidoing (WMF): No, that doesn't fix it for me. I do want to see all recent changes, not only the last one, so turning off "Expand watchlist to show all changes, not just the most recent" is not a viable option for me. But I would like these changes primarily grouped by page, and within each group sorted by date/time. Right now "Group changes by page in recent changes and watchlist" gives me the choice between (a) no grouping, only sorting by date/time and (b) grouping by date, within that by page, within that by time. So the primary grouping is always per day, even with "group per page" enabled. The only reason I can see for having this grouping per day is that it simplifies the timestamps for the individual entries. But then history pages don't do this and seem to work fine. — HHHIPPO 18:45, 22 September 2014 (UTC)
      • So if I understand this correctly, what you're getting is this:

22 September 2014

12:04 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Hajiguru‎; Pcoombe (WMF)‎]

20 September 2014

00:15 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [186.218.110.176‎; Jdforrester (WMF)‎]

and what you want is this:

22 September 2014

12:04 VisualEditor/status‎‎ (4 changes | history) . . (0)‎ . . [Hajiguru‎; Pcoombe (WMF)‎, 186.218.110.176‎; Jdforrester (WMF)‎]

Right? Or do you want this:

22 September 2014

22 September 2014 12:04 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Pcoombe (WMF)‎]

22 September 2014 7:41 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Hajiguru‎]

20 September 2014 00:15 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [Jdforrester (WMF)‎]

20 September 2014 00:07 VisualEditor/status‎‎ (2 changes | history) . . (0)‎ . . [186.218.110.176‎]

Whatamidoing (WMF) (talk) 23:11, 22 September 2014 (UTC)

Well, both, kind of. Your 'what I get' examples are the summary lines with the actual edit lists collapsed, and so is the first 'what you want' example. The last example is similar to the uncollapsed version of what I want, but it would actually look more like this:

22 September 2014‎, 12:04 (cur|prev) . . (-433)‎ . . Pcoombe (WMF) (talk | contribs)‎ (Undo revision 1177949 by Hajiguru (talk))

22 September 2014‎, 07:41 (cur|prev) . . (+433)‎ . . Hajiguru (talk | contribs)‎ (new status update)

20 September 2014‎, 00:15 (cur|prev) . . (-23)‎ . . Jdforrester (WMF) (talk | contribs)‎ (Undo revision 1173489 by 186.218.110.176 (talk) – test edit.) (Tag: HHVM)

20 September 2014‎, 00:07 (cur|prev) . . (+23)‎ . . 186.218.110.176 (talk)‎ (new status update) (Tag: Anonymous updated project status)

That, or just like the history page, if that's easier. — HHHIPPO 20:03, 23 September 2014 (UTC)

• This section is slightly TL;DR since I am sick and not feeling well, but if you set it to display the 500 most recent changes, and set the days to 3 or 7, then it doesn't break it by day because it always shows no more than 500 (about 24 hours worth for me, your number may be different based on how many pages and which pages you have on your list). — {{U|Technical 13}} ^{(e • t • c)} 17:52, 22 September 2014 (UTC)

No, that doesn't do the trick for me, I still have grouping by day. I guess works if the 500 edits limit restricts your watchlist to the current day, but I have only about 100 changes per day, and would like to see several days.

P.S.: Get well soon! — HHHIPPO 18:45, 22 September 2014 (UTC)

So, I wasn't clear. You get about 100 changes per day, and you want to see about 72 hours worth. So, you set it to display 300 changes over the last 5 days and it will always show the max 300 changes (which rounds it to about 72 hours). If you just want to get rid of the header lines for the days, that should be easy for you to do with a user script (without digging into it a little I can't say if it would be a css or js script) that hides them for you. — {{U|Technical 13}} ^{(e • t • c)} 13:37, 23 September 2014 (UTC)

Watchlisted pages are edited at unpredictable frequencies, it will not always be the case that 100 changes corresponds to 24 hours - or to any other duration. To show all changes within the last three (or five) days, set Days to show in watchlist: to 3 (or 5), and Maximum number of changes to show in watchlist: to zero. You can hide the watchlist date headings with CSS, there is no need for Javascript:

div.mw-changeslist h4 { display: none; }

That would go in Special:MyPage/common.css. --Redrose64 (talk) 16:49, 23 September 2014 (UTC)

I don't have a problem with defining what edits I want to see, it's just the grouping I don't quite like. Hiding the date headings doesn't really fix that, since the history snippet I get for each page will still be split in several non-consecutive pieces, one for each day. I guess that could be re-ordered by JavaScript, but I'm not very familiar with that. I'd be more likely to write a perl script that pulls the watchlist from the API and formats it as I like. But then, it's not really that urgent. I was just happy to see that somebody posted what I thought was the same idea. It would be nice if I manage to make clear what I suggest and why, but if it won't be implemented, so be it. — HHHIPPO 20:03, 23 September 2014 (UTC)

• Good idea, but imo not worth the effort. This is an enhancement, while we have some massive bugs preventing productive work. There are better things to do, such as fixing our broken diff viewer. Gryllida (talk) 04:16, 23 September 2014 (UTC)

As you can see, the mobile Wikipedia application has a navigation menu which allows users to navigate to other parts of the page without having to scroll just to look for a specific section.

I would like to propose that a similar navigation menu be added to the desktop version of Wikipedia to allow users to navigate to different parts of the page without having to go all the way back up to the contents table. Sam.gov (talk) 21:36, 23 September 2014 (UTC)

Hi! I'm a

operator and I wish to hear your opinion about a new task I'm working on. It's all about improving the wikilink specificity and clarity. In order to understand exactly what I mean, I suggest to take a look at

• Wikipedia:Manual of Style/Linking#Link specificity
• Wikipedia:Manual of Style/Linking#Link clarity

These guidelines could sound a bit pedant at first sight, but they are very important in order to get pages with useful links for the reader. For example:

• Flatline is an [[independent record label]].

is better than

• Flatline is an [[Independent music|independent]] [[Record (music)|record]] [[Record label|label]].

because

. Too many different links can make the choice difficult on a pc, and a matter of luck on a mobile device. Note that it is better also than

• Flatline is an [[independent record label|independent]] [[record label]].

because the link "

). Moreover there is no need to link also [[record label]] because clicking on the narrower topic (independent record label) the reader will find either a link to "record label" or an explanation of the meaning. There are around many wikilinks with a low level of specificity and lack of clarity/intuitiveness, but actually I noticed that some of them can be improved safely with a bot. Some examples:

• single specific link with unneeded piping
  • attack on [[Attack on Pearl Harbor|Pearl Harbor]] --> [[attack on Pearl Harbor]] (Will the link point the harbor or the japanese attack? Lack of clarity.)
  • canton of [[Canton of Bern|Bern]] --> [[canton of Bern]] (Will the link point the city "Bern" or the "canton of Bern"? Lack of clarity.)
  • [[Canton of Bern|canton]] of Bern --> [[canton of Bern]]
• general+specific pairs
  • [[golf]] [[Golf club (equipment)|club]] --> [[golf club (equipment)|golf club]] (Lack of clarity on the second link, it's better a single specific and intuitive link, inside
    golf club (equipment) there will be a link to golf
    if related)
  • [[Bible]] [[Bible translation|translation]]s --> [[Bible translation]]s (Lack of clarity on the second link, it's better a single specific and intuitive link, inside
    Bible translation there will be a link to Bible
    )
  • [[Central Intelligence Agency|CIA]] [[CIA World Factbook|World Factbook]] --> [[CIA World Factbook]]
  • [[Bristol Aeroplane Company|Bristol]] [[Bristol Blenheim|Blenheim]] --> [[Bristol Blenheim]]
  • [[Lake County, Ohio|Lake County]] [[Lake County Courthouse (Ohio)|Courthouse]] --> [[Lake County Courthouse (Ohio)|Lake County Courthouse]]
• specific+general pairs
  • [[weak base|weak]] [[basic (chemistry)|base]] --> [[weak base]] (the reader will find a link to
    basic (chemistry), or an explanation, inside weak base
    )
  • [[Newark, New Jersey|Newark]], [[New Jersey]] --> [[Newark, New Jersey]] (the reader will find a link to New Jersey in Newark, New Jersey, the topic here is Newark)
  • [[Hesychius of Alexandria|Hesychius]] of [[Alexandria]] --> [[Hesychius of Alexandria]] (as above)
  • [[open architecture|open]] [[computer architecture|architecture]] --> [[open architecture]] (as above)

I will pay some attention also to the letter case, for example I will not change the capitalization choice of the editor in order to avoid mistakes:

• [[Aurès Mountains|Aurès]] and [[Atlas Mountains|Atlas]] mountains --> [[Aurès Mountains|Aurès]] and [[Atlas Mountains|Atlas mountains]]
• the [[The Exodus|Exodus]] --> [[the Exodus]]

At the moment I'm not going to fix links like these:

• [[aqueous]] [[solution]] --> [[aqueous solution]] (Exists an article about the whole expression, but who knows, is the text talking about aqueous solution or another homograph topic?)
• [[Sand]] [[Casting (metalworking)|casting]] --> [[Sand casting]] (as above)
• [[web]] [[page]] --> [[web page]] (as above)

It could be useful to create a collection of substituions for some common "mis-linkings" of this kind, but it would be a drop in the ocean.

Later I could be able to fix also links like these:

• [[chemical]] [[base (chemistry)|base]] --> [[chemical base]] (the whole expression "
  chemical base" is a redirect to base (chemistry)
  , one of the linked articles)

As you can see I'm just enforcing the Linking guideline where I can be sure of the correct target article, nevertheless the overall linking quality will be improved. Few days ago I opened a discussion at Wikipedia talk:Manual of Style/Linking#Improving link specificity, but a more wider and deeper discussion was needed. So, what do you think about the idea? -- Basilicofresco (msg) 01:12, 24 September 2014 (UTC)

I like what you are setting out to do. I think you're more likely to find linkages like:

• [[Attack on Pearl Harbor|attack]] on [[Pearl Harbor]] (instead of attack on [[Attack on Pearl Harbor|Pearl Harbor]]) and
• [[Cantons of Switzerland|canton]] of [[Canton of Bern|Bern]] (instead of [[Canton of Bern|canton]] of Bern).

These could easily be built into that logic in your regexes.

Then, there are other commonly-seen combinations like

• [[List of Prime Ministers of India|15th]] [[Prime Minister of India|Prime Minister]] of [[India]]( or [[List of Prime Ministers of India|15th]] [[Prime Minister of India]]);
• [[President of the United States|President]] [[Barack Obama]] (or [[President]] [[Barack Obama]]);
• [[Secretary-General of the United Nations|Secretary General]] of the [[United Nations]], [[Kofi Annan]] (or [[Secretary-General]] of the [[United Nations]], [[Kofi Annan]]) that could be rationalised.

-- Ohc ^¡digame! 01:46, 24 September 2014 (UTC)

Thank you. Your suggestions 1 and 2 are already included by the regex scheme. What are you suggesting for #4? [[Barack Obama|President Barack Obama]]? -- Basilicofresco (msg) 06:09, 24 September 2014 (UTC)

• Your suggestion is fine, although I would see no utility of creating a piped link when a simple one (President [[Barack Obama]]) will do. -- Ohc ^¡digame! 08:54, 24 September 2014 (UTC)

I agree with your proposal, with the exception of the Newark, New Jersey example (i.e. hierarchies of places); especially in infoboxes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:47, 24 September 2014 (UTC)

I agree, but including the Newark, New Jersey case. There have been discussions elsewhere within the last five years- although it's hard to recall exactly where - but the feeling was that a separate link for New Jersey was superfluous, because if they don't know where New Jersey is, they're hardly likely to know where Newark is either; and if they really need to know where NJ is, it's only one click extra. Often I have seen people changing from the [[Newark, New Jersey]] form to the [[Newark, New Jersey|Newark]], [[New Jersey]] form - and I'm about to revert when somebody else does it first. --Redrose64 (talk) 11:57, 24 September 2014 (UTC)

Apropos of the discussion here, I would like to propose that the automatic generation of reference lists be turned off on talk pages. It is almost never the case that a reference list is wanted at the end of a talk page. It confuses the end of the talk page, and seems to be attached to the last thread, which is in fact normally unrelated. Most of the time, references are present on talk pages only incidentally due to content being copied and pasted from the article. Usually there is no requirement for these to be expanded. Where there is a requirement, users can explicitly include the list within the relevant thread, where it belongs. 86.190.50.118 (talk) 13:51, 23 September 2014 (UTC)

Already requested via T70324 - Cite: Add namespace detection for automatically generated reference list. Vote for it and some developer may work on it. --  Gadget850 ^talk 14:49, 23 September 2014 (UTC)

That is marked as "RESOLVED WONTFIX". I don't see any mechanism for voting on it. Do you mean we should comment that we would find it useful? I would think that a discussion here would be inappropriate. Personally, I'm a big fan of the idea. I can't think of a use case for automatic reference generation in anything but the main namespace and maybe in the "Wikipedia" namespace. Certainly it should be turned off in Talk.

The only question I'd have about the implementation is how you'd want it to handle <ref> tags - should the superscript numbers still be generated? Should the reference be placed in-line, or should the content be effectively ignored? I'm thinking content-ignored is the best way to go.0x0077BE [^talk/_contrib] 15:02, 23 September 2014 (UTC)

I'd be opposed to a change like this. Like I said on the other thread, if you don't want a reference list, then don't use ref tags. Jackmcbarn (talk) 15:03, 23 September 2014 (UTC)

I think that's a bad way to look at things. It's a design flaw if you're requiring users to be "smart" about things. People do use ref tags in talk pages, often times in one conversation thread of many, and often the people who do that are exactly the kind of people who don't know to put a references tag at the end of the section. What that means is that for everyone else there's now pointless citations (which no one wanted) at the end of the page, and someone else has to go find the relevant section and add a section reference tag to it. Even if you think people "shouldn't be dumb enough to make that mistake", they are making the mistake and it is annoying people. So the question is, is there a reason not to add this feature (i.e. is anyone actually making use of the automatic reference generation in Talk pages?). I would argue that they are not, so it's a no-brainer to put this on the to-do list, even if you feel the priority is relatively low. 0x0077BE [^talk/_contrib] 15:10, 23 September 2014 (UTC)

People copy chunks of articles without specifically wanting the refs, just that it's a nuisance to go through removing them. There are lots of existing talk pages where this change is now being applied retrospectively. At the time when people originally copied the content no reflist would have appeared, so there would have been seemingly no need to do anything further. Now the layout is suddenly messed up. In new cases, where a new thread now triggers the auto-reflist for the first time, it would presumably appear correctly positioned to the editor as the new thread would be the last one. Only later, as new threads are added, would the layout break. Many people in any case would not know how to suppress the reflist (I didn't; although I'm somewhat aware of the mechanism for putting them in articles, I did not realise that inserting the appropriate directive in the middle of the talk page would suppress the auto-generated list at the end.) The design of this is the wrong way round for talk pages. People who want to include the reflist should be obliged to do something to make it appear, not the other way around. 86.190.50.118 (talk) 17:07, 23 September 2014 (UTC)

• Agreed with 86.190. I find those autogenerated reference lists to be obnoxious, intrusive and utterly useless. Resolute 17:28, 23 September 2014 (UTC)
• Would it be possible to avoid the autogeneration of actual reference lists on talk pages, but still have working Reference Tooltips? — HHHIPPO 20:14, 23 September 2014 (UTC)

  If this is possible I'm very much in favor of it, though I'd say turning off the automatic generation should probably take precedence if leaving the tooltips in place is a lot of extra work.0x0077BE [^talk/_contrib] 20:19, 23 September 2014 (UTC)

  No, reference tooltips works by examining the link that you're hovering over, finding where that points to, retrieving the HTML for the pointed-to part of the page, then enclosing that in a box. If there is no reflist, there's no HTML to point to, so nothing to put in the box. --Redrose64 (talk) 21:41, 23 September 2014 (UTC)

  Unless, maybe, the HTML for the reflist actually exists, but is not displayed since it's hidden by a css style, which is not promoted to the tooltip since it's invoked in a tag encompassing the whole list? — HHHIPPO 22:01, 23 September 2014 (UTC)

  You may need to ask the gadget's author, Yair rand (talk · contribs). The gadget itself is MediaWiki:Gadget-ReferenceTooltips.js. --Redrose64 (talk) 22:13, 23 September 2014 (UTC)

The reflist can be hidden; see {{reflist hide}}, but I don't see where that helps. --  Gadget850 ^talk 23:43, 23 September 2014 (UTC)

The ideal would be for the automatic reflist on talk pages (and probably some other non-article pages) to be created at the end of the relevant top-level section. PamD 07:56, 25 September 2014 (UTC)

That is a pretty obvious idea! Support. — HHHIPPO 20:21, 25 September 2014 (UTC)

This would be an improvement on the current situation, but still not ideal. Generally the newest discussions are at the bottom of a given section, and having a bunch of references there is not always going to be a good thing - probably OK if it's one or two, if you get towards 6 or 7 that's a significant chunk of text to delineate from conversation.

I think the default should be that no reference list is generated on talk pages unless you explicitly ask for one. I think people are way more likely to be annoyed by unwanted references at the bottom of a given section than they are likely to be annoyed by having to put the <references /> tag at the end of their section. I also think people are way more likely to know to put <references /> at the end of a section to generate a reflist than to know to put {{reflist hidden}} to hide one, so it seems to me that the default on Talk pages should still be no reference list generated.0x0077BE [^talk/_contrib] 15:20, 26 September 2014 (UTC)

T32763 (Cite: If there's no <references /> block on the page, insert the wikitext for one automatically in the right place) --  Gadget850 ^talk 19:24, 26 September 2014 (UTC)

Please see Wikipedia:Bureaucrats' noticeboard#Should we transition the rename process to m:SRUC? and discuss. –xeno^talk 18:42, 29 September 2014 (UTC)

GUIDANCE REQUEST: Instrumentalism in the 21st century. I propose updating the article on “Instrumentalism” to explain how John Dewey and Karl Popper have been reinterpreted, making instrumentalism an active part of the philosophy of science project relevant to inductive reasoning, technology, and pragmatism. Please evaluate my proposal at talk: Instrumentalism, entries 20 and 21.TBR-qed (talk) 19:44, 6 October 2014 (UTC)

This discussion should take it to the article's talk page. This is not the place for your proposal. Good luck. GenQuest ^{"Talk to Me"} 21:45, 6 October 2014 (UTC)

The

) 17:43, 5 October 2014 (UTC)

Yeah, just to explain this more generally (since this proposed change will not only affect the article in question), there is a technical limit that only allows three columns in the war infobox, and we basically want to enable a fourth one. Could be useful in other articles about complex wars as well. FunkMonk (talk) 17:57, 5 October 2014 (UTC)

I also think that we need make four distinct combatant "sides" in the infobox. And it would be a great solution to our problem. Hanibal911 (talk) 18:01, 5 October 2014 (UTC)

Fully support. I just edited the heading by adding "- 4 sides needed" to make the request easier to find. Legacypac (talk) 18:03, 5 October 2014 (UTC)

I argee,we need a infobox for 4 sides.

) 18:04, 5 October 2014 (UTC)

I'll rework

Template:Syrian Civil War infobox to use it. Jackmcbarn (talk

) 18:13, 5 October 2014 (UTC)

Thank you very much, Jackmcbarn! -Kudzu1 (talk) 18:24, 5 October 2014 (UTC)

• I think the better solution is just to not have any "combatant" section at all. It is quite clear that situation in Syria is too complex to be adequately summarised in the infobox. Remember, the purpose of an infobox, as laid out by
  the guidelines on this matter, is to summarise key points, not to become an endless mire of information. The infobox is not a substitute for prose. Adding a fourth column will only create a giant mess that will be hard to read, and will infringe upon the page's layout. Given that this situation is so complex, and given that an infobox simply cannot do it justice, the best thing to do is to let the prose stand. Eliminate the combatants section. RGloucester — ☎
  18:15, 5 October 2014 (UTC)

Most people won't read the article, so the infobox gives a quick overview. In any case, we can discuss this further at a later point, right now it couldn't hurt just to make the fourth column possible. FunkMonk (talk) 18:20, 5 October 2014 (UTC)

There is nothing "quick" or "overviewish" about the present infobox, or about the idea of adding a fourth column. It flies in the face of the guidelines on infoboxes and their innate purpose. RGloucester — ☎ 19:22, 5 October 2014 (UTC)

Oh, the combatants infobox really helps get a grasp of the situation quickly.

• A | B | C | D or

• A | B

line here (hard to show this!)

• C | D

in the interest of not eating up too much width. Legacypac (talk) 18:18, 5 October 2014 (UTC)

Support creating a 4th side to a conflict. Although strictly speaking, the disputed Kurdish faction is in fact formally opposed to the Assad regime faction ("Syrian Kurds may have added appeal for the back channels they provide. Despite claiming to be opposed to Mr Assad’s regime, there are reports that they may be co-ordinating with his forces in the fight against Isis."), as well as only forming official alligences with the Syrian opposition factions since the conflict began, this is a complicated situation that could change. Nulla Taciti (talk) 18:20, 5 October 2014 (UTC)

• I would agree with this in concept, but the consequences could turn out to be a bit unpleasant (visually, I mean), especially with the amount of references we have. Right now I've temporarily dealt with the Kurds' issue (see [1]) and bordered them so that the dividers in the first 2 columns don't go up and down. I believe this solves the problem for now. Thoughts? Fitzcarmalan (talk) 18:23, 5 October 2014 (UTC)

It is an innovative solution, but can the Kurdish "Commanders and leaders" section and the Kurdish "Strength" section also be bordered in an identical manner to the Kurds in the "Belligerents" section, to avoid confusion? Nulla Taciti (talk) 18:35, 5 October 2014 (UTC)

I agree that a fourth column might be the solution. Hopefully it won't look too crammed... But that's just the nature of this conflict. Jushyosaha604 (talk) 18:44, 5 October 2014 (UTC)

I like Fitzcarmalan's layout (similar to an earlier one by Kudzu). Clearly shows Kurds have been fighting, depending on the situation and location, beside both the Assad forces and the opposition against ISIS (contrary to an earlier statement that the YPG has been fighting alongside the rebels only). But I would also support a fourth column for the Kurds (if it wouldn't be too cramped). EkoGraf (talk) 20:01, 5 October 2014 (UTC)

Guys, this section is not the place to discuss configurations that are already possible for us to make, but strictly for discussing stuff we need outside help to implement. FunkMonk (talk) 05:42, 6 October 2014 (UTC)

4 columns side by side infobox would be ridiculously cramped. If there is really desperate need for 4 side infobox then practical solution would be 2+2 columns. But current arrangement in Syrian civil war article is quite solid so I don't see need for 4th column there anyway.--Staberinde (talk) 18:14, 6 October 2014 (UTC)

Let's see how it actually looks, and not complain about how we think it might look. No one has seen a war infobox with four columns before. Also, this is a "ridiculously cramped" war, so an infobox that reflects this will be closer to the truth than whatever arbitrary compromise we come up with. FunkMonk (talk) 20:53, 6 October 2014 (UTC)

Ready to use

@

) 15:08, 7 October 2014 (UTC)

Thank you -- very good work! Just one note: is it an optical illusion, or is the third column slightly wider than the other three? -Kudzu1 (talk) 16:13, 7 October 2014 (UTC)

Thanks! FunkMonk (talk) 17:09, 7 October 2014 (UTC)

Awesome :) Legacypac (talk) 17:26, 7 October 2014 (UTC)

I believe it would be a noble move if the Wikipedia foundation assisted the Outernet project with server capacity or what minimal funding is required to cover (apparent) bandwidth limits on their web site during the start up phase. They share synergistic goals.

https://en.wikipedia.org/wiki/Outernet

https://www.outernet.is/ Over Quota This application is temporarily over its serving quota. Please try again later.

Perhaps someone who knows how such things are arranged would be kind enough to forward this suggestion to the correct offices.

Idyllic press (talk) 06:34, 2 October 2014 (UTC)

Hi, Idyllic press. I asked and was told that they might qualify for a grant, but it would need to be applied for. meta:Grants:Start would hopefully have the information necessary for you or, if you know somebody involved with the organization, them to proceed. --Maggie Dennis (WMF) (talk) 12:25, 7 October 2014 (UTC)

Maggie Dennis (WMF) Hi I have sent an email suggesting this with a link to here, perhaps they will apply. I am just a bystander who happened to bump into a quaota limit that should seldom be found these days in the western world so thought to see if connecting people could help. -- Idyllic press (talk) 17:34, 7 October 2014 (UTC)

I would like to subscribe to Wikipedia and to make yearly donations. I noticed that at https://wikimediafoundation.org/wiki/Ways_to_Give there is the "Monthly gift" option, but no "Yearly gift". For example if I decide to donate 30 euros / year, it's more convenient to pay each year a single payment of 30 euros (for example each 1st of January), instead of paying 2.5 euros every month. It's simply annoying to make such small payments every month. Is it possible to implement yearly payments with PayPal? —  Ark25  (talk) 14:08, 2 October 2014 (UTC)

Hi, User:Ark25. :) Your best bet is probably to address that question to donatewikimedia.org. Thanks for supporting Wikipedia! --Maggie Dennis (WMF) (talk) 12:21, 7 October 2014 (UTC)

Hi User:Ark25, just as a follow up, I can tell you we get this question occasionally on the Fundraising team. Unfortunately, at this time we don't have the technical capability to recur donations annually. We try to reach past donors once a year via email and banners as a reminder, but we are always looking into ways to offer more options, and annual recurring donations is on our list of potential future improvements. I'm sorry I can't be of more help at the moment, but truly thank you for the generous offer of support! --CCogdill (WMF) (talk) 18:12, 7 October 2014 (UTC)

Thanks for your answer. I hope you will fix this one day. Until then, I will make payments once every 5 years with 5 x 30 euros, so I can be sure that every year is paid (Somehow I forget to make donations every year, looks like it's too frequent for my speed). Thanks again. —  Ark25  (talk) 16:48, 8 October 2014 (UTC)

Hi, I appreciate the "Prompt me when entering a blank edit summary" - it reminds me when I occasionally forget to enter one or rarely accidentally save the edit before finishing. But I find it a bit annoyoing when I'm just making a minor change and I have checked the "This is a minor edit" checkbox. Can we have an option (preferably just below the "Prompt me..." option) such as "Don't prompt me when I'm making a minor edit" - preferably turned on by default? Keep up the great work everyone! Facts707 (talk) 13:33, 24 September 2014 (UTC)

I have concerns that that might encourage editors to inappropriately mark edits as minor rather than dealing with the "inconvenience" of entering an edit summary. In any case, I may be amenable to the inclusion of the option, but I oppose having it turned on by default, especially when turning it on would require minimal effort for editors who wish to utilize it. DonIago (talk) 13:40, 24 September 2014 (UTC)

With the existing system, you just have to add a space to the edit summary and it will not prompt you; is this not sufficient? —Quondum 16:34, 24 September 2014 (UTC)

Comment Perhaps, alternatively, checking the 'minor edit' box can be made to force a space, or even the single letter, "m", into the edit box. No need to opt in or out, just an automatic entry. As far as @Doniago:'s concern, some editors do that now. GenQuest ^{"Talk to Me"} 19:12, 24 September 2014 (UTC)

Shouldn't all edits have a summary, even if they're minor? Personally, when RC patrolling if I see a minor edit without a summary, I give the edit extra scrutiny for potential vandalism. Ivanvector (talk) 19:48, 24 September 2014 (UTC)

It's hard enough to get people to leave summaries as it is. Please don't encourage them not to, particularly not on minor edits which can be anything. Britmax (talk) 19:50, 24 September 2014 (UTC)

Same here. I feel we should have more edit summaries, not less. DonIago (talk) 20:17, 24 September 2014 (UTC)

Nonsense. Those who leave edit summaries will continue to do so, those who usually don't leave edit summaries will continue to not leave edit summaries. The proposal addresses an issue which is a time saver for

wikignomes and those editors who are constantly making maintenance and other minor edits to better the encyclopedia, and shouldn't be dismissed off-handedly. GenQuest ^{"Talk to Me"}

02:27, 29 September 2014 (UTC)

What sort of "maintenance edit" warrants a blank edit summary? I like knowing what changed without having to scour diffs. Ivanvector (talk) 03:03, 29 September 2014 (UTC)

I make lots of minor edits and I try to always use a summary. I don't see any valid reason to leave a summary off unless you're relying on

WP:AES. --NYKevin

14:15, 2 October 2014 (UTC)

FWIW, I understand what the OP is talking about. Casually reading thru Wikipedia articles, I'll often find typos, misspellings, minor grammatical errors, & so forth, which take maybe 15 seconds to fix -- depending on server latency at that moment. In many of those cases, I find that the edit summary is far longer than the edit, & will often require me to write multiple sentences to intelligently explain my change. (An example might be, "A previous editor confused double quotation marks with a pair of single ones; this results with the last half of the paragraph being italicized. So I changed the extraneous double quotation marks to a pair of single ones to fix this mistake." Some incidents are even more involved, & no matter how terse I try to be, a lengthy explanation may result.) As a result, anyone perusing my contribution history will find that many of the edits I marked as minor have cryptic edit summaries. I dare say, the simpler the edit, more cryptic the summary will be; sometimes I'll make my edit summary even more cryptic out of spite at the requirement to document the change.

Now I'm not arguing that edit summaries should never be left, but any veteran editor will find her/himself frustrated when the summary may require as many as 100 words to explain adding/removing a single character -- so we should all be a little sympathetic to the OP's proposal. Even if, in the long run, it isn't a good idea. (And if I really wanted to be a jerk, I could leave useless edit summaries with little effort. Hmm. Maybe I'll demonstrate.) -- llywrch (talk) 20:56, 8 October 2014 (UTC)

What he said. ;-) GenQuest ^{"Talk to Me"} 11:43, 9 October 2014 (UTC)

"Formatting", "fix typos", "fmt", "

WP:TONE", "misc. minor corrections", "clean-up"... DonIago (talk

) 14:04, 9 October 2014 (UTC)

Move pronunciations, other names and other language names from lead to a note or sidebox

Take this example. This is the lead of Hebron.

Hebron (

ISO 259-3: Ḥebron; Ottoman Turkish Halilürrahman, Ancient Greek Hebrṓn, Χεβρών) is a Palestinian^{[1][2][3][4][5]} city located in the southern West Bank, 30 km (19 mi) south of Jerusalem

.

What an average reader will wish to see is:

Hebron is a Palestinian^{[1][2][3][4][5]} city located in the southern West Bank, 30 km (19 mi) south of Jerusalem.

The problem here is, the pronunciations and other language names simply clutters the beginning of lead terribly decreasing its readability. This is worse in some other articles where there are other names for the subject of the article, meanings of each one explained inline.

Why shouldn't we make it a policy that such items should be placed in a note or a side-box? --

) 07:59, 2 October 2014 (UTC)

I quite agree overloading lead sentence with naming info is a bad habit on Wikipedia, and the Hebron example you cite is a particularly horrible example that needs to be changed. I'm not too certain though whether a sidebox is the best place for it (although I guess it could be optionally integrated in the infobox templates, as virtually all geographical articles do have infoboxes these days.) My own favorite solution, as long as it's just a simple list of two or three names in local languages, is an extra sentence at the end of the first lead paragraph ("The city is called "X" in A, "Y" in B and "Z" in C.) Anything more complex than thathe (such as multiple transcriptions or pronunciation guides for the same name, as here with Hebrew) should go into a separate "naming" section below. One of the things that makes the present state worse is the pedantic obsession with cramming all sorts of names in for purely political/historical reasons, such as giving a symbolic nod of recognition to all language communities that live in a place by listing all their name variants, or to all historical states that once governed it, as here by listing the – otherwise completely irrelevant – Ottoman name. As a rule, the slot at the beginning of the lead sentence should be reserved exclusively to names that are or have been used in English (including possibly the one current official name in the official local language, as that might also sometimes be used in English-language maps, atlases and so on.) Fut.Perf. ☼ 08:16, 2 October 2014 (UTC)

I've taken the freedom to remove the live "ref" tags from the examples above and replace them with fake ones, just so we don't have to carry a spurious references list around here on the talkpage. Fut.Perf. ☼ 08:19, 2 October 2014 (UTC)

Assuming that every place has "one current official name" or one "official local language" seems unwarranted. For example, it appears that part of Hebron is controlled by the State of Palestine (official language Arabic) while another part is controlled by Israel (which has two official languages, Hebrew and Arabic). For another example, Switzerland has four official languages: German, French, Italian, and Romansh. Anomie⚔ 11:28, 2 October 2014 (UTC)

The important point is that we should de-emphasize this whole idea of using the inclusion or non-inclusion of names as a symbolic sign of our recognition of the role of this or that state/ethnicity/historical period etc. We are not writing our articles in order to please this or that group of locals. We are writing them in order to serve the English-speaking reader, and the only reason names need to be included in that spot is because English-speaking readers might have been led to the article after seeing the place referred to by that name in an English-speaking environment. My reference to local official names was due to the fact that some otherwise English-speaking publications, such as atlases, may have a policy of using local names (such as München) even where English prose otherwise strongly prefers an anglicized name (e.g. Munich). That's the only reason "München" would have to be there. So, we should ask ourselves: would an English atlas that uses "München" and "Athīna" also include "Ḥevron" or "al-Khalīl", or maybe both? If yes, they go in; if not, they don't. For historical names, the question is similar: would history books in (present-day) English refer to the place by name XYZ (without immediately glossing it with the modern name)? If yes, the historical name goes in; if not, it doesn't. Everything else should be treated somewhere a bit further down, where it is less obtrusive (perhaps still in the intro, but not in the lead sentence). Fut.Perf. ☼ 11:50, 2 October 2014 (UTC)

We definitely need some way to make the ledes more visually appealing and readable. A side bar might be the best solution. But what other options are there? Mosue-over pop-ups, footnotes, a double lede? Kdammers (talk) 09:15, 2 October 2014 (UTC)

I support this - overloading the lede with alternate names and pronunciations hinders readability, and I agree that we're building an encyclopedia for English readers, thus only the

most common English name(s) should be in the lede, just like how we choose article titles. Frankly, this is one of the increasingly few proposals that comes along that actually quite significantly increases the readability of pages, and that should be what we're going for. I think adding an "alternate names" or "local names" or some such section to the infobox would be an elegant solution. In fact, if you look at Hebron, there is already an "other transcriptions" section right at the top of the infobox. Why not there? Ivanvector (talk

) 14:46, 2 October 2014 (UTC)

Strong support. Lead sentence cruft is totally out of control. Let's go back to having readable articles. Kaldari (talk) 19:59, 5 October 2014 (UTC)

Support this definitely impacts the reader and moving to a sidebar would be very useful. I know

talk

) 23:01, 5 October 2014 (UTC)

Strong support. As I've been saying for years, our lead sentence model is broken. The lead sentence is not a database table where every conceivable record related to the subject's name is stored for machines to read. The lead sentence is where we tell human readers what a subject is in a neutral, simple, plain-English, due-weight, and accessible format. The additional information – pronunciation, transliteration, obscure historical and geographical alternatives – are welcome but they absolutely belong outside the first sentence. A footnote, the article body, a sidebox, whatever. The lead sentence is not a database.

I know someone will come along to say "Hey, if a particular lead sentence gets too packed, then we can start removing those items on a case-by-case basis without creating a new rule." I just don't agree with this at all. Our standard should be only one name goes in the lead, with no pronunciation or transliteration, unless someone makes a strong unique case. Not the other way around. —Designate (talk) 23:39, 5 October 2014 (UTC)

Separate name section This is a classic case where the article should have a separate name section. This way, we can explain why there are so many names and where they all come from and why they aren't all the same. Oiyarbepsy (talk) 02:26, 6 October 2014 (UTC)

As much as I'm in favor of this idea, may I remind everyone of the naming disputes we had over German & Polish names a few years ago? I suspect in many cases this verbiage is the outcome of resolving numerous ethnic & cultural disputes. Unless you are willing to engage in dealing with the recrudescence of these disputes (few of which I suspect will be resolved rationally), I'd suggest that either (1) agree on a reliable source to use for place names to use to avoid these disputes; or (2) do a quick survey of places whose names are in serious dispute to see what the scale of these disputes may be. Better the devil we know (bad-looking lead paragraphs) than the one we don't (endless cultural & ethnic conflicts over what place name to prefer for places few of us have heard.) -- llywrch (talk) 22:21, 8 October 2014 (UTC)

Even if you stuff the lead with alternate names, article can reside only in one namespace to which all the alternate names should be redirected. So if we give in to the interest groups like those mentioned above, there may occur further conflict saying X must be redirected to Y rather than vice versa, etc. The rule of thumb here is this is English language Wikipedia and here

talk

) 11:20, 10 October 2014 (UTC)

I refer you to the well-known dispute over the name of the Baltic seaport, Gdansk/Danzig. Since then, at least one native Polish speaker has insisted that a certain river be known by its Polish name Odra instead of its more familiar English form Oder, apparently because the latter is identical with the German name. And then there are instances where a place with a name familiar to most English speakers has been renamed (e.g. Kolkata & Calcutta). The point is that a lot of these disputes don't pop up because someone has an agenda, but because most Wikipedians aren't aware a conflict actually exists, & the resulting misunderstanding often goes thru at least one cycle of name calling (one side are labelled "trolls" & cranks", the other "bigots" & "Wiki-Nazis") before cooler & more empathetic minds prevail with some form of a compromise.

If I'm being overcautious here, well I'll be happy to be proved wrong; I agree with the OP that the lead is getting mangled by inserting these alternative names in the first sentence. And I suspect that if handled with some sensitivity & wisdom, making this change could be a non-event. But, as I said before, I'm writing from what I've witnessed over these last 12 years. Making this change without first doing this kind of prep work will inevitably lead to bruised egos, nasty edit wars, work for ArbCom, & valued editors quitting. -- llywrch (talk) 15:57, 10 October 2014 (UTC)

This proposal doesn't alter the fact that we already have to pick one title for every placename article, providing redirects from alternative names. It refers only to the location on the page where alternative names are shown (together with any non-Latin scripts and pronunciation links). And I'd agree that the very first sentence is not the ideal location, even if it's traditionally been done this way in printed works of reference. Could we have a few proposed layouts to comment on?: Noyster (talk), 16:51, 10 October 2014 (UTC)

I was directed to this discussion from a post made at Wikipedia talk:WikiProject Infoboxes. It was about whether tennis player Peangtarn Plipuech should have her Thai spelling in the lead or above the infobox, as in the example. The page had it in both places and it seemed to me like that was overkill but I wasn't sure what guidelines or consensus was leaning towards here at wikipedia. In a new edit, an editor has left it in the lead but removed it from above the infobox and placed it inside the infobox with a "|native_name =" header. Now this particular instance only has one addition to the lead as opposed to the ridiculous Hebron example above. It seems like if there is one extra spelling and perhaps one pronunciation, it's no big deal. After that it gets very hard to read and should have a separate "name" section. But since you all seem to have a better grasp on this then me I wanted to ask what the general consensus is about having the extra spelling in both the lead and the infobox? I do like it better inside the infobox rather than two spellings above the box, but should it be in both lead and box, or is one place good enough? Fyunck(click) (talk) 18:46, 10 October 2014 (UTC)

which are intended to guide disputes. I suppose this proposal would be altering that slightly, and it might be worthwhile to link to this discussion from that talk page. Essentially, the vast majority of places have a single name widely given in English sources, or one which is far more commonly known to English readers. Such articles would read like:

London is the capital city of England and the United Kingdom.^[4]

Where there are places with different names substantially equally likely to be recognized by English readers, (and which have redirects from other common names):

Gdańsk, also known as Danzig, is a Polish city on the Baltic coast, the capital of the Pomeranian Voivodeship, Poland's principal seaport and the center of the country's fourth-largest metropolitan area.^[1] The city is known by several alternative names.

For places with a once-common name which is still used, but another name has become more commonly used in English:

Kolkata, known historically in English as Calcutta, is the capital of the Indian state of West Bengal.

As for the Oder river, with respect to the native Polish reader, the argument to use the Polish name as the title is a poor one. This is not the Polish Wikipedia, and it doesn't matter if the common English name is similar to another language or different from the native language. We use the English name. The other names (of which Odra is only one of several given in the article) would be indicated in the sidebar or whatever alternate location is decided.

The Oder is a river in Central Europe. It rises in the Czech Republic and flows (generally north- and northwest-ward) through western Poland, later forming 187 kilometres (116 mi) of the border between Poland and Germany, part of the Oder–Neisse line.

Just one more example, from my home and native land:

The Saint Lawrence River is a large river flowing approximately from southwest to northeast in the middle latitudes of North America, connecting the Great Lakes with the Atlantic Ocean.

The current convention calls for including local names in the lede, and I can see why but I think that advice is misguided. It interrupts the flow of what is supposed to be a summary. Much like in the Hebron example, the average English reader looking for a summary of the article is not likely interested in seeing the French, Tuscarora and Mohawk names, along with the meaning of the Mohawk name, stuck awkwardly right in the middle of the first sentence. This detail is important, but should be moved elsewhere. We're building an encyclopedia for English readers, so we should include this information elsewhere. Ivanvector (talk) 18:34, 10 October 2014 (UTC)

I support the comments made by Ivanvector. The guidance at

WP:LEADCLUTTER is weak, and I would like to see the examples at LEADCLUTTER replaced with Ivanvector's suggestions. Barryjjoyce (talk

) 07:22, 12 October 2014 (UTC)

• Support I support the idea of decluttering leads by taking out all the stuff that isn't in the English language. In the case of Hebron, that long string of footnote numbers should go too. Andrew (talk) 19:24, 10 October 2014 (UTC)

  I was gonna say, those five footnote numbers mid sentence are almost as bad as all the other junk. Fyunck(click) (talk) 19:39, 10 October 2014 (UTC)

That's a good point too. Per

WP:MINREF. Ivanvector (talk

) 13:31, 12 October 2014 (UTC)

• The Hebron example is just poorly done—it's unhelpful information that should be put somewhere in the body and not into a box. Curly Turkey ⚞¡gobble!⚟ 04:48, 12 October 2014 (UTC)
• Oppose sidebox - please no, have mercy (see disputes about infoboxes). Support decluttering lead sentences, but the best solution should be found case by case. Add a few recommendations from experienced editors to the guidelines, but no fix "rule" for it. GermanJoe (talk) 14:35, 12 October 2014 (UTC)

Seems reasonable. The "alternate transcriptions" infobox seems to work for

Gdansk uses an "alternate names" section instead. I think this proposal is limited to just "don't pepper the lede with them". Ivanvector (talk

) 15:05, 12 October 2014 (UTC)

AfC resubmit

One thing I've noticed on AfC is that there are a lot of resubmits without any changes, or ones that are resubmitted in minutes. We have over 2,500 AfC's that need to be reviewed at the moment, and that takes a long time. Therefore, I'm proposing that declined AfC's cannot be resubmitted without any changes, and/or that AfCs must wait 1 week to be resubmitted. The week will give the authors time to revise the article thoroughly.

17:50, 28 September 2014 (UTC)

I'd be more willing to support something like this if you were able to guarantee that all declined AFCs were validly declined, and not, e.g., because the AFC reviewer disapproved of the formatting of the sources or some other equally trivial point. WhatamIdoing (talk) 23:29, 28 September 2014 (UTC)

Note that new editors (who AfC is aimed at) aren't likely to know whether a decline is valid, so that's not really something this should focus on IMO. Anyway, I support this, and it's doable from a technical perspective. Jackmcbarn (talk) 14:23, 2 October 2014 (UTC)

& That is a wonderful proposal. Are you suggesting to make it a bit-task to monitor these submissions? --Tito☸Dutta 21:22, 12 October 2014 (UTC)

I propose that after someone becomes an admin, they should be required to spend a certain amount of time (I'm not sure how long, but it would be defined in # of admin actions) in a training program. This program, under my proposal, would involve them (in addition to making normal edits) making the same decisions (such as blocking and protecting) as real admins do, but it would have no effect. The purpose would be for existing admins to determine if they know how to conduct themselves in tough situations admins frequently find themselves in. I think this is a good idea because it will help ensure that new admins are at least a little experienced before they assume their new responsibilities. Thoughts would be appreciated.

01:35, 8 October 2014 (UTC)

BTW, I saw this at

talk to me

01:37, 8 October 2014 (UTC)

See Category:Administrator instructions.—Wavelength (talk) 03:25, 8 October 2014 (UTC)

The thing is...the vast majority of situations admins find themselves in are not "tough situations". The vast majority of uses of the admin tools are entirely uncontroversial and not at all difficult. Look at the raw block log. Look at the raw deletion log. What do you find? Clear and conspicuous vandals and vandalism. Gross edit warring. Obvious housekeeping. Out of several thousands of admin actions in any given day, you can usually count on one hand the number which are brought up at AN/I; only a tiny fraction of that minuscule number are overturned.

Any given admin will be 'first on the scene' of a controversial situation only seldom. No admins is ever compelled to take any action in any case—we can always leave the situation for someone who feels better able to handle it. Worse, the proposal implies – incorrectly – that any given "tough situation" will actually have a 'correct' response—that controversial admin actions are the result of a lack of admin education, rather than genuine disagreements about how to interpret or apply Wikipedia policy.

In any event, before this goes farther Jinkinson (or anyone) should make some effort to actually substantiate the implicit claim that (the very small number of) new admins actually represent a problem that would justify implementing such a clunky and bureaucratic process. TenOfAllTrades(talk) 04:02, 8 October 2014 (UTC)

Would they learn how to block badly behaved Admins? Most don't seem to be able to do it. HiLo48 (talk) 05:38, 8 October 2014 (UTC)

So like....

WP:ADCO. Legoktm (talk

) 07:56, 14 October 2014 (UTC)

A Simple Partnership with the Embryo project Encyclopedia

I am the editor in chief of the Embryo Project Encyclopedia, an online open access publication aimed for inclusive audiences. We propose to incorporate our content with Wikipedia pages.

Allow me first to describe the encyclopedia, then why we are posting here, and finally our proposal to partner with Wikipedia.

The Embryo Project Encyclopedia publishes articles about embryology, developmental biology, and reproductive medicine. The intended audience for the articles includes people with between roughly 9 and 16 years of education. The purpose of the encyclopedia is to increase scientific literacy among its readers about the fields of science listed above. To achieve that aim, articles in the encyclopedia use historical methods to situate scientific results in social contexts.

The encyclopedia is funded by the US National Science Foundation, and it is the product of a collaboration between the Center for Biology and Society at Arizona State University and the Marine Biological Laboratory. All articles receive rigorous peer and editorial review to be factual, non evaluative, and to connect readers to online resources for verification of contents. The publication has an ISSN of 1940-5030, all contents are Creative Commons licensed (CC BY-NC-SA 3.0), and the articles are indexed in scholarly databases like Google Scholar.

We'd like to partner our content with Wikipedia. Through various channels, we learned that that this forum provides the most appropriate venue to propose a plan to share our content on Wikipedia, but if we should instead use another means, please let us know.

The following plan describes an initial proposal.

Background We have just under 600 articles in our encyclopedia, but we publish three new articles per week.

Goal We'd like to incorporate into our editing process some steps to link our articles on relevant Wikipedia pages under 'External links' headers. For instance, as we just published an article on Francois Jacob, we'd like to include a link to it under 'External links' on the Francois Jacob Wikipedia page.

Issue In trials runs of that practice, Wikimedians have understandably deleted many of our links. They claim that such links are spam, self-promotional, and thus violate Wikipedia's principles of editing and posting. We appreciate the need for the antispamming principles, and we see how Wikimedians might construe our practices as potentially spam. We think, however, that the spirit of the antispamming principles shouldn't exclude us from linking to articles in the Embryo Project Encyclopedia. We aren't selling anything, we have no grant deliverables related to Wikipedia, nor do we bias our articles except to ensure that they they are accurate about their topics, as free from evaluation as possible, and verifiable.

Proposal

1) We'd like to designate a single Wikipedia account by which we'd post links on Wikipedia articles to articles in our encyclopedia. The one I'm using now works for that function.

2) We'd like that account to have limited immunity to the antispamming principle, in that it can be used to link to articles in the Embryo Project Encyclopedia, but no other website. Furthermore, the account can be used to link to Embryo Project Encyclopedia article only on relevant Wikipedia page. That way me might link to our Jacob article on Wikipedia's Jacob page and on it Pasteur Institute age, but not on the gauge physics page, for example.

3) We'd like other Wikimedians to be able to somehow see that limited immunity status of our account when they check our page edits.

4) We DON'T propose that such a limited-immunity account be indefeasible, and Wikimedians may still delete our links if they judge them inappropriate. We only seek to avoid deletions based on blanket application of the antispamming principle.

5) We propose a standard link syntax of:

• [url (EPE Article Title)] at the Embryo Project Encyclopedia

Example:

• Francois Jacob (1920-2013) at the Embryo Project Encyclopedia

Final Remarks Please treat our proposal as an initial step. No one on our editorial team has much experience with the policies and practices for Wikipedia, and we're not sure if our proposal maps on to Wikipedia's capabilities and policies. In one sense, we're not quite sure what to ask for, but given our explicit goal and the issue that prevents us from reaching it, we anticipate that you have ideas about how to move forward. — Preceding

) 20:38, 10 October 2014‎ (UTC)

I suggest you contact relevant wikiprojects (probably

WT:BIOG) and ask someone there to evaluate the proposal. The first step would be to see if people who edit in the area believe there would be some benefit. Johnuniq (talk

) 23:12, 10 October 2014 (UTC)

•Will do. We appreciate your advice.

talk

) 17:29, 11 October 2014 (UTC)

I don't this this is impossible, but:

Your account appears to break WP rules as a role account - see

WP:ROLE

. It is essential that whatever account you use has a user page that fully explains who you are and what you are doing. Yours is not yet set up.

You should look at

WP:MEDRS for medical articles. Johnbod (talk

) 20:27, 11 October 2014 (UTC)

• Oppose "We'd like that account to have limited immunity to the antispamming principle", in other words, you want an official license to spam. Absolutely not. Andrew Lenahan - Starblind 13:03, 12 October 2014 (UTC)
• Out of the five proposals only (#5) looks sensible. We could probably have a template for this. However since the license is compatible, material from the Embryo Encyclopedia could be used here. The target audience may differ however, so that editing may be required. Also User:Embryoproject please change your name to represent a person eg User:Francois Jacob at Embryoproject. Graeme Bartlett (talk) 22:33, 12 October 2014 (UTC)

• One example is Neurocristopathy that could be expanded from http://embryo.asu.edu/pages/neurocristopathies. But unfortunately there are no foot notes, just unsorted sources, so it would be a fair bit of work to get up to Wikipedia standard for sourcing. An interested project should look at embryo pages that are worth using. The Embryo encyclopedia could take some more of the good ideas from Wikipedia. Graeme Bartlett (talk) 23:12, 12 October 2014 (UTC)

The licence isn't actually compatible if it is CC-BY-NC-SA , as Wikipedia uses just CC-BY-SA. ie, any reuse by us would violate the -NC-SA (non-commercial share-alike) provisions, as we would be publishing under a different licence that allows commercial reuse. - Evad37 [talk] 11:55, 13 October 2014 (UTC)

You are right, I have struck out that part of my comment! Graeme Bartlett (talk) 21:55, 13 October 2014 (UTC)

• Wikipedia allows people who want to place an external link, but have a conflict of interest, to place said link on the talk page of an article (
  WP:ADV). That way a second, neutral editor can check the usefulness of the link and place it on the article for you. No special permission is needed to do this, and you could start anytime you want. Maybe acompany the sugested external link with a text explaining the link. You could make a standard text for this. Sincerely, Taketa (talk
  ) 12:11, 13 October 2014 (UTC)
• Your third item is problematic: We'd like other Wikimedians to be able to somehow see that limited immunity status of our account when they check our page edits. Editors that see a dubious link will often remove it without checking the history to see who placed it, especially if there have been many intervening edits or the editor is purging an accumulation of dubious links from one article. A technical solution might be to set up a template similar to {{IMDb title}} (as used in Embryo (film), for example). Editors might be more likely to leave such links alone, understanding that the existence of such a template implies community approval of such links. Of course, you'd still have to gain that prior approval. NebY (talk) 12:30, 13 October 2014 (UTC)

• Thanks for the input, everyone. It greatly clarified things for me. We'll pursue at least the following tasks:

o) I already requested a username change for my account.

i) We'll use the talk function on specific Wikipedia pages to ask editors to review our articles and link to them.

ii) We'll develop a user page that is similar to User:WilliamDigiCol/Working page 2014 as a means to systematically ask established wikipedians without COIs to approve external links to our pages.

iii) We'll look to establish a template for external links along the form of IMDB.

Given all of that, and I'm sorry to ask a simple question, but how do I find established Wikimedians in broad subject fields? Once found, do I propose to them a template for external links, or should I pursue other means?

talk

) 22:39, 13 October 2014 (UTC)

Welcome, Embryoproject. You can find some interested people at WP:WikiProject Anatomy, WP:WikiProject Medicine, and WP:WikiProject Physiology. Leave a note on the talk pages for these groups, and then check back later see if anyone has replied. WhatamIdoing (talk) 17:09, 14 October 2014 (UTC)

• See
  Win Win situation. --Aspro (talk
  ) 17:34, 14 October 2014 (UTC)

Watchlist-related

1. Add a toggling "unwatch"/"watch" link to the "diff | hist" links at the start of each entry (and use a dot/interpunct as the separator between them rather than a pipe?);
2. Means to view/reorder the list in reverse, i.e. according to how long pages on the list have remained unchanged.

I don't think these are persistent / perennial or already possible, but apologies if either or both are either or both (and please indicate how/where I should look). Sardanaphalus (talk) 11:54, 8 October 2014 (UTC)

1. Have a look at User:Js/watchlist.
2. That's not trivial, since the watchlist is getting its data from the recentchanges table, which only covers the last 30 days. So for showing anything older than that you would need not just a change in sort order, but a different way to extract these data from the database. It's probably possible, but would be less efficient. — HHHIPPO 21:41, 8 October 2014 (UTC)

• Thanks for your responses and sorry for the time before this one. I've just installed User:Js/watchlist – which looks interesting – and, yes, I wondered if the "reverse/inverse watchlist" might be relatively demanding. On the other hand, if the software has to work through a watchlist to see which items have been changed in the past N hours/days, wouldn't it be looking up when each item had last been changed and so would only be a step or two away from producing a list which it could then present in reverse..?

Regards, Sardanaphalus (talk) 23:02, 15 October 2014 (UTC)

) 16:53, 16 October 2014 (UTC)

New bot suggestion

I am not sure that this is the correct forum for such a suggestion. But I would like to suggest that a bot who combines duplicate references are created, such a bot would come in handy for editors who creates new articles or find it hard to combine references overall. One such bot is not operative at the present.--BabbaQ (talk) 15:20, 19 October 2014 (UTC)

@

WP:BOTREQ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

15:29, 19 October 2014 (UTC)

Yes, sorry I found it right after posting here. Made a request there now. --BabbaQ (talk) 15:30, 19 October 2014 (UTC)

As you may have heard, Editor Interaction Data Extraction and Visualization is an individual engagement grant proposal. I am working on this proposal with volunteer assistance and advice from Aaron Halfaker (WMF), Haitham Shammaa (WMF), and Fabian Flöck (Karlsruhe Institute of Technology).

We would greatly appreciate your comments on whether you support or oppose the general concept of this project, and any suggestions about how to refine the proposal.

Additionally, we would like to hear from you about which sets of editor interaction data, and what visualizations of editor interaction data, would be most relevant to your interests. We intend to prioritize our outputs with your comments in mind.

Please comment on the proposal talk page. Questions and feedback, both positive and critical, are helpful to us as the proposers, and also help the Individual Engagement Grants Committee [1] to assess the proposal.

Regards, --Pine^✉ 18:29, 19 October 2014 (UTC)

[1] I am a member of the Individual Engagement Grants Committee. I am recusing from reviewing proposals in this funding round.

I was thinking if somebody designed a bot to blank un-used/unusable User Talk Pages (such as some of the ones referenced in the headline) it could save Wikipedia's servers some space in the long run (the content of the pages might add up, trolls might realize they could waste Wiki resources by creating a very large or resource intensive user talk page and then purposefully get banned to decrease the likelihood of such content being deleted, etc). Thoughts? — Preceding unsigned comment added by 67.164.188.243 (talk) 03:02, 16 October 2014

Actually, that would slightly increases storage usage. Blanked and deleted pages are still stored in history (even if that history isn't visible to normal users). The proposed edit would just be adding to the page history. Alsee (talk) 10:41, 16 October 2014 (UTC)

A blanking might remove other things like link table and search index entries. I don't know the net effect but see Wikipedia:Don't worry about performance. It's best to keep the talk page content if some of their actions are examined later. PrimeHunter (talk) 11:07, 16 October 2014 (UTC)

Also, indefinite blocks are not necessarily perpetual; they just don't expire automatically. It's not unusual for an editor to appeal an indefinite block and return to making valuable contributions. They should be able to do so with their talk pages intact. Furthermore, some editors return by socking; old talk pages help us deal with that. NebY (talk) 11:12, 16 October 2014 (UTC)

@67, you may discusss this if you wish, but you are not permitted to unilaterally implement your proposal. I just reverted a change you made to a blocked (not banned) user.--Bbb23 (talk) 14:00, 16 October 2014 (UTC)

We used to do this, but stopped as it was kind of pointless. Mr.Z-man 15:08, 16 October 2014 (UTC)

Bad idea. It makes it more difficult to handle (and report handling) long term abuse by not-logged-in editors and by sockpupperts, if we cannot point to the user who was blocked and the reasons he/she/it was blocked. — Arthur Rubin (talk) 16:27, 16 October 2014 (UTC)

I support doing nothing at all. Just let them exist, and do nothing about them. --Jayron32 23:18, 16 October 2014 (UTC)

This looks like an example of the classic "solution in search of a problem", thus it's pointless. Indefinite ≠ Permanent. Roger (Dodger67) (talk) 10:51, 18 October 2014 (UTC)

You're probably thinking of something like

) 00:54, 23 October 2014 (UTC)

Repeal Wikipedia:Spam

At this instant, Wikipedia:Spam is severely undermined by the AfD-process. No matter how spammy an article is, they are hardly removed for that reason. A common reasoning with that is spam and advertising can be solved by normal editing, but nobody does the actual editing. Effect is that Wikipedia is slowly undermined by spammers and talking-but-not-acting-good-willing editors. latest example in my experience is Wikipedia:Articles for deletion/Mydala.

This makes WP:SPAM a hollow phrase and repealing it should be best. The Banner talk 05:17, 18 October 2014 (UTC)

I hope I have addressed most of your concerns about the article with my recent copy edit of the piece. No need to

throw the baby out with the bathwater. Regards, GenQuest ^{"Talk to Me"}

08:38, 18 October 2014 (UTC)

Thanks for the edit but it happens so often. The Banner talk 09:55, 18 October 2014 (UTC)

Absolutely oppose This proposal is like suggesting that because all burglars are not arrested red-handed at the scenes of their crimes, burglary should no longer be a crime.

WP:SOFIXIT is the usual cure for failure to act on the result of discussion. Roger (Dodger67) (talk

) 11:12, 18 October 2014 (UTC)

Strongest oppose, obviously.

snow-closed as an obvious keep when not a single editor !voted delete. We have a speedy criteria for articles that are obvious spam, and as for the repeated failures of your nominations at AfD, maybe you should take it as an indicator of community consensus that your spamming of the process with apparent pattern of frivolous nominations is itself undermining AfD. Ivanvector (talk

) 14:30, 18 October 2014 (UTC)

You are exactly using all the bogus arguments used in AfD's nominated as advertising in order to keep the spammy article. The Banner talk 15:46, 18 October 2014 (UTC)

But when I nominate an article for deletion as advertisement, I don't ask for clean up. I do ask for deletion. But nearly all the time I get replies as "AfD is not for clean up", something I am not asking for. The Banner talk 20:01, 18 October 2014 (UTC)

Right. "AFD is not cleanup" means "If the article could be cleaned up don't nominate it for deletion." AFD is used primarily for articles whose subjects don't deserve a Wikipedia article. If the subject deserves an article, but the text of the article is substandard (i.e. it is "spammy") then AFD is inappropriate. --Jayron32 01:11, 19 October 2014 (UTC)

The main problem is that after closure of such a AfD in most cases absolutely nothing happens and the dodgy and/or spammy article stays in place. With all the advertising problems, conflicting with WP:SPAM, still there. In effect, "AfD is not for clean up" acts as protecting promotion and advertising. By now, the only way to enforce WP:SPAM is by means of AfD or CSD and get the article removed, as the editing part to enforce WP:SPAM is hardly done. A policy without means to enforce it, is useless. The Banner talk 15:12, 19 October 2014 (UTC)

in most cases absolutely nothing happens

WP:SOFIXIT applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

15:32, 19 October 2014 (UTC)

Ever realised that AfD is also a way to fix spammy articles, but by deleting them? The Banner talk 03:04, 23 October 2014 (UTC)

If "nearly all the time" people tell you you're getting it wrong, try not doing the same thing again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 19 October 2014 (UTC)

Hi, I posted a set of suggestions here a week ago and have only been able to get responses by pinging people. Basically it boils down to this:

1. - I think the talk page should have an archive
2. - I think the DYK alert templates should link to the official versions of the rules in projectspace instead of the outdated version of the rules in userspace.
3. - I would like to make corrections to improper calculations based on the outdated rules.

I'm happy to do all of this myself if given the greenlight. Please review my suggestion and weigh in. Thanks in advance. -Thibbs (talk) 14:25, 23 October 2014 (UTC)

I was looking for a place where I could list my bookmarks on Wikipedia. I couldn't find one, so I propose that we make a bookmarks bar along the top of the page. It should go with the compact personal bar, so it would make the screen less cluttered with all of the bookmarks one might have.

--maximum_capacity12

Articles or any other Wikipedia pages can be linked from your

watchlist to flag up when any changes are made. By the way, please sign your posts to talk pages with four tildes (~~~~): Noyster (talk),

09:40, 25 October 2014 (UTC)

Tables with collapsible columns

I would like to be able to collapse (hide) certain columns of tables, sometimes. For example, when I (double-)click on the third column on the following table ("Motor vehicles"), to hide the fourth and the fifth column, because the third column is the sum of the fourth and fifth. And then, if I click it again, to show them. Sometimes tables can have too many columns and then, when you first look at the table, some columns would be better to be hidden, in order for the reader to see the essential. Then, if the reader wants, they should be able to able the not-so-essential columns.

Did anyone think about implementing such a feature?

Vehicle production of SouthVulcania (millions):

Year	Bicycles	Motor vehicles	Trucks	Cars
2010	30	100	80	20
2009	29	90	70	20
2008	28	80	65	15

—  Ark25  (talk) 22:23, 17 October 2014 (UTC)

Judging from MediaWiki:Common.js, section Collapsible tables, it should be possible with a little Javascript, but implementation will need a fair bit of testing. Adam Cuerden ^(talk) 10:35, 18 October 2014 (UTC)

I would find it useful. Keep in mind, per MOS, that columns should be open initially, but I could see value in giving the reader the option to close some columns. Please also note that in the case of a sortable table, one sorts simply by clicking on the column heading, so it the table is to be sortable and allow column hiding, one have to think through how to do each option separately.--S Philbrick(Talk) 21:56, 19 October 2014 (UTC)

More often than not I find collapsed by default content obnoxious. If an information relevant to the topic of an article, then it should be presented openly. Please don't play hide and seek and make me look for magic buttons to click on.-----<)kmk(>--- (talk) 03:44, 26 October 2014 (UTC)

I was looking for a while if a black or dark design of Wikipedia has been ever proposed. Like I was not able to find it, I start a proposal.

I think this is not something I only thought about. There is many people who suffer from white backgrounds. Most of the web services I use can be configured in black background (DuckDuckGo, Gmail, Google, etc.). Moreover, dark backgrounds help to save energy, which is better for everyone.

I was wondering if it is possible to set Wikipedia with a dark template. Cerilet (talk) 12:33, 24 October 2014 (UTC).

(Note: This is my first edit on Wikipedia. I would appreciate if someone can move this to a more convenient place or edit it if there is something that should be changed.)

Set Preferences → Appearance → Skin = MonoBook and save, then check Preferences → Gadgets → Use a black background with green text on the Monobook skin. --  Gadget850 ^talk 12:42, 24 October 2014 (UTC)

However, the energy savings are an urban legend, I'm sure a Google search can confirm this.--S Philbrick(Talk) 12:56, 24 October 2014 (UTC)

Yep. Unless you're using a cathode ray tube monitor where black is a result of the screen actually being off, and the green is the type that requires very little energy to be read (same reason night vision goggles are usually green). If your monitor was made this century (well, this side of the century mark), chances are that displaying a black screen uses as much energy as a white screen, plus the additional work of diffusing the light so it looks black. Now, I do recall that if you turn the overall brightness down on an LCD monitor, that can chew up less energy (and have experienced this with my phone).

Still there are lighting conditions where I have an easier time reading white or green on a black background, and could understand how some people would have trouble with black on white. Ian.thomson (talk) 13:06, 24 October 2014 (UTC)

LCD displays work by blocking/unblocking the backlight. Their energy consumption is basically independent of the pattern they display. In theory, there is a small energy cost when switching images, but that is very marginal. For OLED displays, the energy used does depend on the brightness of the image, and the effect is significant enough to affect battery life for portable devices. --Stephan Schulz (talk) 13:14, 24 October 2014 (UTC)

Old-school LCD screens (like Amazon Kindle) work the other way around, am I right? --NaBUru38 (talk) 22:12, 25 October 2014 (UTC)

Old-school LCD's (as in digital watches or many alarm clocks) work without a backlight, i.e.you only see the light reflected from behind the liquid crystal pane. Most Kindles use fancy

e-ink displays that work on a very different system - there the display itself reflects or absorbs light. But both don't need energy just to maintain a static picture (modulo minor technical losses, as always in real systems). --Stephan Schulz (talk

) 07:29, 26 October 2014 (UTC)

Proposal Trusted Tester user group

On 20:39, 14 May 2013 (UTC)

I suggested WMF

to create "trusted testers" user group. Someone from WMF called that a good suggestion. After that, I don't know what happened.

I can see someone has started an RFC in this page on MediaViewer. I clearly support that RFC, but, I am too reluctant to write there. Does WMF care?

Anyway, currently when WMF makes a change (call it VisualEditor, MediaViewer etc.), it is forced on all/thousands of editors and for next many weeks, hundreds of editors report dozens of errors, and WMF keep on fixing/improving those.

Can't we create a "trusted tester" (TT) user group like Google or Microsoft? The trusted testers (TT) will be the first editors to test a feature and report good" or "bad" or anything. --Tito☸Dutta 17:41, 13 October 2014 (UTC)

I don't think there was any shortage of people testing MediaViewer - the complaints about it started when it was in beta and have not stopped to this day. One of the biggest problems with MediaViewer is that it's been imposed not without consultation with the community, but rather over the community's vigorous protests. I'm not sure why we need a separate "Trusted Tester" user class when people can always opt in to the beta features from the WMF labs. 0x0077BE [^talk/_contrib] 17:53, 13 October 2014 (UTC)

Agree, no need for a usergroup that gets forced features that can just be handled by opt-in. I don't see a problem where "unauthorized" testers were using beta features that caused harm. — xaosflux ^Talk 18:11, 13 October 2014 (UTC)

The reply said:

"That's a good suggestion :). I know that Erik (Eloquence) is very keen on the idea of deploying things in a beta on enwiki, in future, rather than testing elsewhere; hopefully this will allow us to discover problems 'natively' before they become a problem for many users. Okeyes (WMF) (talk) 20:49, 14 May 2013 (UTC)"

Beta came six months later: Wikipedia:Village pump (technical)/Archive 120#Introducing Beta Features and Media Viewer. PrimeHunter (talk) 00:31, 17 October 2014 (UTC)

I see no benefit from a user right here. There is already far too much software-enforced hierarchy. If a group of "neutral" testers is to be identified so that "people who just want to find fault in everything" can be ignored, you can do that socially. To deny random users the opportunity to test and comment on beta features before they are made mandatory would be yet another major step backward in terms of community input. Wnt (talk) 21:36, 17 October 2014 (UTC)

This is not a user right. This is a user preference. Add a checkbox to the preferences panel "Always enable new experimental features." Oiyarbepsy (talk) 00:48, 23 October 2014 (UTC)

The term "trusted testers user group" is confusing. I agree with having an option to "always enable new experimental features", and I disagree with adding a new MediaWiki user permission group. --NaBUru38 (talk) 22:03, 25 October 2014 (UTC)

Are you aware that a checkbox "Automatically enable all new beta features" already exists? It's at the top of the beta features tab. — HHHIPPO 15:19, 26 October 2014 (UTC)

I see in this previous RFC there was a rejection of using "pseudo-namespace shortcuts" such as T: for Template: namespace. I didn't read the whole RFC but I do know that I get tired of typing "Template:" into the search box each time I want to find a template. The name space "T" is unused so I don't see why there can't be a change made where this could be implemented. Comments? ~Technophant (talk) 03:35, 20 October 2014 (UTC)

More reading material for you: Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. When re-making a proposal for something that has already been repeatedly rejected, you really should address the reasons for it being rejected previously. Anomie⚔ 10:38, 20 October 2014 (UTC)

Better idea

How about changing the search box so that if I type in {{infobox}}, the search box is smart enough to suggest Template:Infobox? That would address @Technophant:'s issue - they could just copy and paste it from the wikicode. Oiyarbepsy (talk) 01:03, 23 October 2014 (UTC)

How about alowing any page to be included/transcluded with parameters? If there is none, then it would render without any extra computing. --NaBUru38 (talk) 22:09, 25 October 2014 (UTC)

I'm not sure how that would help anything. Oiyarbepsy (talk) 21:05, 28 October 2014 (UTC)

The better place to raise this issue would be Wikipedia:WikiProject Football. --Jayron32 01:14, 30 October 2014 (UTC)

And I just moved it there - Wikipedia talk:WikiProject Football#Team divisions on player pages. Oiyarbepsy (talk) 06:20, 30 October 2014 (UTC)

As an IEG proposal, I have proposed making a user script which permits you to watch or ignore threads on talk pages. With this script, for talk pages your watchlist will only show the threads you have chosen to watch. Alternately it will show all threads except those which you have indicated you desire to ignore. In addition, the script will permit you to display entries from your watchlist on other Wikipedia projects and languages. If would like to see this functionality happen, please go to the IEG page and indicate your support (endorse). — Makyen (talk) 23:52, 30 October 2014 (UTC)

Hi. Since this seems to be mostly ignored on VPT, and someone on the RfC said it was not a good place to put it, I'll put this link here too: m:Requests for comment/Global file deletion review. πr² (t • c) 00:51, 31 October 2014 (UTC)

It's not obvious where to discuss Special pages, but it seems the typical place for them is Wikipedia:Talk:Special:Foo. On the other hand, sometimes they are at Help:Talk:Special:Foo, so it's not even consistent. In my view, this should instead be Special talk:Foo, and Special:Foo should have a discussion tab just like any other page. This would give a place for people to discuss special pages that they would actually be able to find. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)

Note: Please see Wikipedia talk:Criteria for speedy deletion#Proposal to update R2 criterion for "Special talk:" redirects for the discussion that prompted this one. Steel1943 (talk) 18:52, 18 October 2014 (UTC)

• Per my comment in the other discussion Steel linked to (please respond there), creating a
  NSA for the "Special talk:" to point to "Wikipedia talk:Special:" is pretty easy. To get a "discussion tab" on Special pages would be more difficult to do in core because, as I understand it (which isn't always the way it is), special pages aren't normal pages in a normal namespace (hence the NS number of -1); that said a gadget could be created that would simulate a "discussion tab" on most special pages (there are a couple where .js won't run for security reasons). — {{U|Technical 13}} ^{(e • t • c}
  ) 21:41, 18 October 2014 (UTC)

Struck-out text that is no longer pertinent to the current discussion, but has been retained here for historical purposes. Steel1943 (talk) 15:31, 22 October 2014 (UTC)

I wonder if the Special_talk.php from this very old bug report [2] is still a going concern? This was referenced in Wikipedia:Village pump (technical)/Archive_61#Enable Special talk.php. jni ^(delete)_{...just not interested} 20:33, 20 October 2014 (UTC)

• As I said below in the discussion before this became a RfC: "Special:" is a technical namespace, and it will be easier to create a technical solution (which had this RfC not been started could have been implemented within a week or so I'm sure, but now should wait until this has concluded) than it will be to add this exception and then enforce it. As such, I oppose the creation of this
  NSA^{[disambiguation needed}
  ] would do a much better job. For those that might not be clear on what this alternate proposal is exactly: I'm proposing to make an actual namespace alias that will load "Project talk:Special:" when "Special talk:" is given for a namespace just like "Wikipedia talk:" and "WT:" both take us to "Project talk:" themselves. Doing this means there will be no redirect involved at all and none of that hassle or issues that come with it.

Support the creation of the "Special talk:" namespace

1. As proposer. — {{U|Technical 13}} ^{(e • t • c)} 14:56, 22 October 2014 (UTC)

   Support, as above. Steel1943 (talk) 15:22, 22 October 2014 (UTC) I would rather see this as an actual functional namespace than an alias. I don't know why this discussion has had to be reconfigured as so. Now, the fine line between an actual functional namespace and an alias has been totally blurred. Steel1943 (talk) 19:51, 22 October 2014 (UTC)

   • It will be as much of an actual namespace as the
     Wikipedia namespace (which is an alias of Wikipedia:Project namespace). It can not be configured any other way. Since "Special:" is Namespace -1, there cannot be an actual "Special talk:". Before you say it could be -2, that is already taken by "Media:" (allows you to link to a file instead of using ":File:". — {{U|Technical 13}} ^{(e • t • c}
     ) 21:17, 22 October 2014 (UTC)

   • @Technical 13: I get how it works, and I still have my preference for an actual namespace. The "NSA" is my option in the event that it can't be done, but it's definitely not my first choice. Steel1943 (talk) 21:23, 22 October 2014 (UTC)

2. Support Oiyarbepsy (talk) 00:45, 23 October 2014 (UTC)
   • Comment The use of abbreviations is excessive and completely out of hand. I have no idea what NSA is (
     Don't insult yourself?) Please write stuff out, and also, check your links, since I'm pretty sure that NSA does not mean No Self Attacks. Oiyarbepsy (talk
     ) 00:45, 23 October 2014 (UTC)
     • In this instance "NSA" means "
       Namespace alias". Thryduulf (talk
       ) 00:57, 23 October 2014 (UTC)
3. Support --Fauzan^{✆ talk}_{✉ mail} 05:11, 23 October 2014 (UTC)
4. Support 2A02:8420:508D:CC00:56E6:FCFF:FEDB:2BBA (talk) 13:38, 1 November 2014 (UTC)

Oppose the creation of the "Special talk:" namespace

• Oppose as basically useless. You can't add Special pages to watchlists, severely reducing the chance of anyone seeing your comments. Comments about special pages can go to VPT or something similar, where they will get a lot more attention usually.
  Fram (talk
  ) 09:32, 28 October 2014 (UTC)

Discussion about the creation of the "Special talk:" namespace

• Comment if the closer of this discussion sees consensus for this change, I'll happily open the new ticket needed to enable the extension that has existed since 2005 for this exact thing (see Phabricator:T6078). Thanks. — {{U|Technical 13}} ^{(e • t • c)} 17:43, 9 December 2014 (UTC)

Alternate proposal 1: update speedy deletion R2 criterion for "Special talk:" redirects as exceptions

I propose that that the wording of the R2 criterion be updated to include this wording at the end as an exception to the criterion:

...and redirects titled "Special talk:Foo" that target the "Wikipedia talk:" or "Help talk:" namespaces.

I'm proposing this since the "Special talk:" namespace does not exist, and I have on multiple occasions found myself in a situation where I wanted to discuss the function behind a tool in the "Special:" namespace, but could not find its discussion page. I recently discovered that the naming convention for these talk pages seems to be "Wikipedia talk:Special:Foo". It makes sense for the talk page to be in the non-existent "Special talk:" namespace, but since the namespace doesn't exist, creating a page in that namespace defaults it into the main namespace, which would currently make it eligible for speedy deletion for this criterion if the "Special talk:" title was made a redirect. Steel1943 (talk) 16:49, 18 October 2014 (UTC)

Support the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

Assuming Steel1943, as proposer. I'd rather see the creation of the namespace as a whole, as stated in the above sections. Steel1943 (talk) 15:22, 22 October 2014 (UTC)

1. Assuming Thryduulf, per discussion below.

Oppose the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

1. Oppose creating as a CNR. Please see alternate proposal. — {{U|Technical 13}} ^{(e • t • c)} 14:56, 22 October 2014 (UTC)
2. Assuming Jni, per discussion below.
3. Assuming Oiyarbepsy, per discussion below.

Discussion about the wording of the R2 criterion be updated to add an exception for CNRs from "Special talk:" to "Wikipedia talk:Special:"

• Comment I updated my proposed wording addition due to finding that Wikipedia talk:Special:Contributions targets Help talk:User contributions. Steel1943 (talk) 17:03, 18 October 2014 (UTC)
• As it should be eligible... Redirects from mainspace (ie "Special talk:Foo") to project space (ie "Wikipedia Talk:Special:Foo") are
  NSA is created, are prohibited by policy. — {{U|Technical 13}} ^{(e • t • c}
  ) 18:07, 18 October 2014 (UTC)

• Exactly, which is why I'm trying to propose that it be made an exception. And as for this being a pseudo-namespace, if that's the case, then essentially "Wikipedia talk:Special:" is a pseudo-namespace in an actual namespace. The fact that these redirects currently don't exist is essentially harmful. The only other option I see is a proposal to actually create the "Special talk:" namespace. (I'm trying this route first, since it doesn't require an update to the actual function of the Wikimedia software built on the English Wikipedia.) Steel1943 (talk) 18:11, 18 October 2014 (UTC)
  • I'd actually rather see it implemented as a
    NSA. This is a technical solution that doesn't require a namespace to be created (that really can't exist as I understand it). Prevents all drama. @Steven (WMF):, can we get a little input from the developers, please? I'm sure Jackmcbarn could put this up for merge in Gerrit (or phab, if we are using that now).  :) — {{U|Technical 13}} ^{(e • t • c}
    ) 19:59, 18 October 2014 (UTC)

• @Technical 13: As stated below, another discussion has been started in regards to the technical aspects of the implementation: Wikipedia:Village pump (technical)#Special talk namespace. It may be of interest to also raise the question there. Steel1943 (talk) 21:15, 18 October 2014 (UTC)

I'm okay with this temporarily, but for the long term I oppose, since this exception is a hack. The real solution is a Special Talk namespace, which probably should exist. I'll bring it up at Village Pump Technical. Oiyarbepsy (talk) 18:43, 18 October 2014 (UTC)

Wikipedia:Village pump (technical)#Special talk namespace. Oiyarbepsy (talk) 18:48, 18 October 2014 (UTC)

@Oiyarbepsy: Essentially, I agree with your reasoning. Thanks! Steel1943 (talk) 18:50, 18 October 2014 (UTC)

I think that the exception to R2 should be something along the lines of "other than approved pseudo-napespaces", and not mention any true namespaces; at the same time, we approve the CAT:, H:, MOS:, Special talk:, etc. Any subsequent discussion about topics like this would then go to WT:Shortcut. עוד מישהו Od Mishehu 19:46, 18 October 2014 (UTC)

• Support this exception. Such redirects can still be nominated at RfD and discussed on their individual merits (or lack of merits) balanced against any harm that it does (or doesn't) do. Just because many CNRs are harmful, does not mean that all CNRs are or that being a CNR is harmful in and of itself (hence the need to have exceptions in the first place). Thryduulf (talk) 01:15, 19 October 2014 (UTC)
• Oppose this exception. This is just
  Template_talk:Db-r2 that the R2 warning template had had inconsistent namespace applicability instructions compared to CSD policy itself for over four years, and nobody noticed or cared. We will get more inconsistencies like that if start inventing detailed rules and exceptions for every marginal use case of our wiki-editing tools. jni ^(delete)_{...just not interested}
  10:45, 19 October 2014 (UTC)

• How is this instruction creep? The basis of this proposal is the usefulness of the creation of such redirects that are intended to target the talk pages for the discussion of pages in the "Special:" namespace. At the present time, there are no redirects titled "Special talk:Foo" that exist, (obviously, given my statement in the nomination.) Also, just because administrators, in practice, should know about the existence of the "Wikipedia talk:Special:" titles (I'm certain that several administrators do not know about that standard naming practice), the ability to find these pages should be easy to find by all editors who may need to discuss a page in the "Special:" namespace, admins and non-admins alike. However, I do agree that I'd rather just see the creation of the "Special talk:" namespace; however, as stated above, there is the possibility that it would not be technically possible due to how the "Special:" namespace is programmed in the English Wikipedia. Steel1943 (talk) 16:40, 20 October 2014 (UTC)

• I agree that it is instruction creep actually. It's an attempt to introduce wording to a social method of moderating what does or does not happen on wiki when there is a much simpler technical approach. I see no objection to adding the NSA here, and will request it added on bugzilla tomorrow afternoon (about 28 hours from this post) if it remains unopposed for the simple technical solution. The technical solution makes adding it to policy unnecessary and moot. — {{U|Technical 13}} ^{(e • t • c)} 17:01, 20 October 2014 (UTC)

• It's not necessarily instruction creep if the technical resolution is not possible. Steel1943 (talk) 17:12, 20 October 2014 (UTC)

• In regards to if the technical resolution is not possible, I assure you the technical resolution is not only possible, it's easier than trying to impose a change to existing social sanctions. Since your if clause is false, then it is reasonable to assume that it is indeed instruction creep. I can't see a use case where "Special talk:" shouldn't take the user to a talk space where they can talk about a "Special:" page (even in cases where "Wikipedia talk:Special:Foo" for "Special:Foo" where "Wikipedia:Special:Foo" doesn't yet exist). I welcome cases I may not have thought of, if you have any. :) — {{U|Technical 13}} ^{(e • t • c)} 18:45, 20 October 2014 (UTC)
  • Update: It's simply a matter of enabling mw:Extension:SpecialTalk on this wiki. — {{U|Technical 13}} ^{(e • t • c)} 17:47, 9 December 2014 (UTC)
• It is instruction creep because exactly 7 such pages have ever existed (at least after last time the deleted revisions were purged from database - and last time that happened was before I was made admin here close to 10 years ago!). No redirect with prefix "Special talk:" targeting the Help talk namespace has ever existed. 3 of the deleted pages were not redirects at all and were deleted per G2 (or close to it) reasons. Details are in User:Jni/Special talk redirects review, for benefit of non-admins participating to this discussion. For the 4 redirects, some of which were deleted multiple times, 2 deletions were done without citing a specific criteria, R2 was cited 2 times and G6 was given as reason 3 times. Note the prominence of G6; I would use it instead of R2 for deleting this kind of weird artifact relating to pseudo-namespaces myself. Your proposal seems to silently limit applicability of G6, making the already convoluted and somewhat arbitrary set of CSD rules even harder to remember or apply correctly. There have indeed been some misunderstanding about this matter - see logs for Special talk:Cite where Rossami makes a circular argument, claiming that his invalid use of admin's restore tool (assuming R2 was the same as today in 2007) invalidates a later G6 CSD as well. Overall, there has not been any need for this exact kind of redirect because only 4 were ever created during last decade. If something has hardly ever existed, there is no need to make special rules for it's deletion! jni ^(delete)_{...just not interested} 19:04, 20 October 2014 (UTC)

• Rossami's argument is not circular and actually is the heart of speedy deletion - if it's controversial, it should not be speedy deleted, period. Oiyarbepsy (talk) 19:34, 20 October 2014 (UTC)

• Oiyarbepsy, I called his argument circular ("dubious" would have been a better word), because there was a five year gap between the two deletionsrestores. The controversy, if any, cannot last for that long and later day admins are allowed to take a fresh look and are not bound by some very old actions of their peers. Besides, a really detailed analysis would require understanding the deletion policies, CSD rules and unwritten conventions as they were during each and every of the events in the log. jni ^(delete)_{...just not interested} 19:53, 20 October 2014 (UTC)

• On taking a closer look of several speedy restores Rossami did ~7 years ago (we all have important investigations like this going on from time to time, right?), it seems the then-controversial matter was eventually settled in RfD and consensus that "Special talk:Foo" redirects are not needed was established. Now it is proposed here to override this earlier consensus, but is this talk page or exception to CSD R2 really even the right forum or mechanism for this? jni ^(delete)_{...just not interested} 19:50, 20 October 2014 (UTC)

• (edit conflict) @Jni: I did not see it above, so would you be able to provide a link to the RfD discussion where consensus was formed (in one way or another) deeming the usefulness (or lack thereof) of "Special talk:" titles? (I'm, more or less, quite curious to see it, given that I had no idea that any form of consensus was established for this very matter in the past. I'm in no way saying that this changes my opinion at the present time.) Steel1943 (talk) 20:10, 20 October 2014 (UTC)

By the way, your question about if this is the right forum for this discussion, I'm actually wondering that as well, given that this discussion has turned into something more than just trying to add an exception to the R2 criterion; this discussion is turning into a discussion about whether or not a "Special talk" namespace (or an pseudo-namespace namespace alias, as

RFC if it continues to gain as much momentum as it has in the past day alone. Steel1943 (talk

) 20:24, 20 October 2014 (UTC)

• I've never said it should be a PNR, and I would oppose it being a PNR. What I've said, multiple times, is that it should be a NSA. A
  shortcut; A namespace alias is an actual case-insensitive virtual namespace just like WP or WT or Image. — {{U|Technical 13}} ^{(e • t • c}
  ) 21:01, 20 October 2014 (UTC)

• ...@Technical 13: That's what I meant. Fixed.Steel1943 (talk) 21:05, 20 October 2014 (UTC)

Looking at the deletion logs for those seven pages, it's pretty much adds a lot of strength to the idea that we need Special talk. Almost all of them were either redirects to a corresponding Wikipedia talk page or were the type of material that you'd expect to see on a talk page. The fact that these pages are so rare is because the special pages don't link any talk pages, so the majority of users just get lost and give up trying to discuss them. Others guess Special talk and either post a comment or make redirects. Oiyarbepsy (talk) 20:02, 20 October 2014 (UTC)

I suggest that any person who is listed as a "notable resident" (or similar) in any article should be removed from the article unless that person has an article named for them. There are far too many of these "notable residents" who are mentioned in many articles without justification. If they don't have an article named for them then they are not notable and therefore not "notable residents". Jodosma (talk) 19:27, 14 October 2014 (UTC)

I'm amenable to a third-party source discussing the individual as an indicator of notability, but if there's no article or sourcing, I can't imagine why they'd be listed. DonIago (talk) 19:36, 14 October 2014 (UTC)

All over Wikipedia individuals are mentioned as if they are "notable", e.g. in articles about colleges or schools or minor authorities (councils and the like), the tutors and senior members of the staff (or council) are often mentioned, in many cases stated in the article as being "notable", as if the statement that they are notable makes them notable. I would like to remove all of these if they don't have an article named for them. When these people are named then the person naming them should first of all create the article about them. This kind of thing also occurs in many articles about businesses or companies, with no justification. Jodosma (talk) 19:57, 14 October 2014 (UTC)

I think it is fine if a no-article notable resident is listed along with a third-party reference that establishes their notability. This sort of entry aligns with

WP:REDLINK, the expansion of the encyclopedia. Binksternet (talk

) 22:13, 14 October 2014 (UTC)

I agree with Binksternet. We do not tell

WP:Notable

is wrong: a person is notable when s/he qualifies for a separate article on the English Wikipedia. You can be notable for decades before anyone actually starts writing the article.

If there's no source for such an entry, then please find one yourself. If you're not willing to make that much effort, then add a {{

fact}} tag, and check back in a couple of months (yes, months, not days) to see whether anyone has done so. Don't just blank them because you don't like them and can't see the value in them. WhatamIdoing (talk

) 22:19, 14 October 2014 (UTC)

If red links obviously merit an article leave them. In most cases they do not and should be removed there and then.Charles (talk) 22:26, 14 October 2014 (UTC)

Comment: Red links in articles are different than those found in links lists. The ones in articles probably have a chance of being expanded someday, probably by the person who put it there to begin with. Lists are different, however. Any name can (and repeatedly are) added to lists that are never, ever going to be notable, or are actually tagging/vandalism. If they are in a list, the name, item, or whatever needs at least a reliable source citation if there is not an existing article in Wikipedia. Red links in wiki-lists are meaningless. PS: "Notable Residents" sections are, imo, list sections. GenQuest ^{"Talk to Me"} 23:30, 14 October 2014 (UTC)

The Notability standard only applies to creating an article. The standard for including information in an article is a lot lower. Alsee (talk) 10:32, 16 October 2014 (UTC)

On the other hand, many of these additions are supposedly living people. I say supposedly because they could be someone's boyfriend, dog, worst enemy, whatever. With no sources we simply don't know and such entries may be

talk

) 16:10, 16 October 2014 (UTC)

I agree that they are essentially lists, which on Wikipedia are advised to have inclusion criteria so they don't become

WikiProject Laundromat which is aimed at cleaning up such lists. Ivanvector (talk

) 16:28, 16 October 2014 (UTC)

If someone wants to put a non-linked name in a list, it is incumbent on them to show why that name belongs on the list. Otherwise, it is

OR and should be immediately removed as such. Lists inclusions are different from inclusions in articles; per the the comments above. GenQuest ^{"Talk to Me"}

01:20, 17 October 2014 (UTC)

No, that's not OR. "Original research" involves material that has never been published, anywhere on the planet, at any time. "Uncited" is what we call material that someone has added without showing why that name belongs on the list. WhatamIdoing (talk) 19:31, 17 October 2014 (UTC)

I should've also included "

BLP. GenQuest ^{"Talk to Me"}

22:41, 17 October 2014 (UTC)

The above discussion appears not to consider the situation where a good, referenced source document says "Bloggs, Smith and Jones did a very important thing (X)" but only Bloggs and Smith have WP articles, AND Jones was otherwise so non-notable that no WP article for him is even likely. IMHO his name (without a redlink) belongs in the articles for Bloggs and Smith (and for X if it has one) It also belongs (with ref but no redlink) in a list of people related to X, or of people in an occupational group etc related to X. Downsize43 (talk) 10:37, 19 October 2014 (UTC)

I think in a case like this it belongs in the article; it does not belong in a list of people associated with the subject. Article content does not have to be notable. The best rule for people in such a list is that they either have to have an article or be obviously qualified for one--with a reference. DGG ( talk ) 18:31, 20 October 2014 (UTC)

I propose to remove the term "notable" and just write: "City/town residents include Alicia and Bob". --NaBUru38 (talk) 22:05, 25 October 2014 (UTC)

No, no, no. That would result in a random list of self-publicisers who happen to have heard of Wikipedia. It would not be useful to our readers. DGG has it right - people in the list should either have an existing article, or be demonstrably

notable in Wikipedia's sense, with a reference to prove it. JohnCD (talk

) 11:14, 30 October 2014 (UTC)

Would cast lists be affected by any of this? A Greek Slave has a list which should be old enough not to be a problem. More modern plays might well have a mix of notable and not. Sorry if this is off topic.SovalValtos (talk) 19:10, 31 October 2014 (UTC)

To be included in a list of people with some characteristic it is not enough for the person to have their own article: it should be reliably sourced that they have this characteristic. We could create a List of people from Mars and add blue links for a lot of famous names, but that wouldn't mean they were qualified to be on this list, and some of them might even object: Noyster (talk), 09:50, 3 November 2014 (UTC)

An excellent proposal. And ditto for alumni lists.

Allahabad University currently has blue links, a significant minority of which actually come with references. Compare Tokai University, which Somebody Who Likes both Penicillin (band) and Capitalization has pumped with Penicillin, and Siddharth College of Law, with no-links. Yes, red links are fine. But if these people are notable, redlink them in a context that suggests their notability. Residence, birthplace and university (whether graduated from or dropped out of) don't confer notability. ¶ Of course it's possible that adding redlinks within these lists could prompt somebody to create an article. But if so, then more appropriate and more persuasive would be a paragraph within the relevant talk page. -- Hoary (talk

) 12:01, 3 November 2014 (UTC)

The guidance at

WP:NLIST is useful, particularly For instance, articles about schools often include (or link to) a list of notable alumni/alumnae, but such lists are not intended to contain everyone who attended the school — only those with verifiable notability and the much-neglected Furthermore, every entry in any such list requires a reliable source attesting to the fact that the named person is a member of the listed group. NebY (talk

) 14:03, 3 November 2014 (UTC)

talk

) 15:32, 3 November 2014 (UTC)

Do we need to replace RfA?

Result of clicking on a file

First off, let me note that this is intended to be completely separate from the Media Viewer issue: my proposal addresses only what happens when Media Viewer isn't used, whether because you disabled it or because you brought up the file in a new tab.

Numerous Wikipedias besides en: allow free and nonfree material, and many other Wikipedias (with exceptions, e.g. es:) permit people to upload images locally. Some that do both, e.g. fr:, have a direct link to the Commons page when a Commons-hosted image is clicked. For example, go to fr:Accueil principal and click the lead image for today's featured article, and you'll reach https://commons.wikimedia.org/wiki/File:US_Cr%C3%A9teil_-_Colmar_National_(1).jpg rather than https://fr.wikipedia.org/wiki/File:US_Cr%C3%A9teil_-_Colmar_National_(1).jpg. Wouldn't this be desirable for us to do as well? My proposal shouldn't affect locally hosted images. Again, back to fr: — if you go to fr:Liste des émissions de franc français depuis 1960 and select the image immediately above 10 francs Mathieu, you'll go directly to https://fr.wikipedia.org/wiki/Fichier:10_francs_Mathieu_1987_F365-28_revers.jpg because it's locally hosted.

In most cases, edits to image descriptions and image talk pages should be conducted at Commons, and the few exceptions (e.g. adding FP and appeared-at-DYK notes to descriptions) can always be done by changing the URL, e.g. adding en: before the filename. Inexperienced users won't know how to do things such as FP notices; they're only going to know how to edit the actual description and make talk page comments, so we ought to make it harder for them to add misplaced comments and create misplaced file description pages. Since most file notices are done by bots, it presumably wouldn't be that hard to tell the bot to follow a slightly different pathway in order to leave a note. By doing this, we can make it much simpler even for us experienced editors (we won't need to click an extra link every time we open a Commons file), and much simpler for inexperienced ones. Nyttend (talk) 15:45, 3 November 2014 (UTC)

• I'm sorry Nyttend, I am having a hard time following what you are saying, as you seem to be talking in circles around an idea (which should make it easier since I do the same thing all the time). Are you saying that if an image is hosted on both en and commons, then the software should default to the local copy. If this was the case (I don't see why it wouldn't be), then on the File: page, there would/should be a link to the commons version/page as well. Is this summary correct? — {{U|Technical 13}} ^{(e • t • c)} 16:28, 3 November 2014 (UTC)

• I actually wasn't addressing that idea. If an image is only local, clicking the image goes to the local image (as it does now). If an image is both local and at Commons, clicking the image goes to the local image (as it does now). If an image is only at Commons, clicking the image goes directly to Commons, as it does at fr: but unlike what it does here right now. I believe that this is something that's simple for the developers (they simply toggle a setting) but impossible for everyone else, comparable to the setting that is toggled to allow a wiki to use images from Commons. Nyttend (talk) 16:34, 3 November 2014 (UTC)

  We already have a gadget called "Redirect image links to Commons for files that are hosted there" that seems to do what you want. Jackmcbarn (talk) 16:59, 3 November 2014 (UTC)

• Wasn't aware of that. In such a case, our discussion need only center on whether such a gadget should be made default. Nyttend (talk) 17:22, 3 November 2014 (UTC)
• I wasn't aware of that either, and I apparently already have it enabled. I'm still unclear exactly what it is suppose to do or what the goal is here. Perhaps the gadget writer can help clarify it for me? — {{U|Technical 13}} ^{(e • t • c)} 18:12, 3 November 2014 (UTC)

• Technical 13, currently, if an image is hosted on Commons and is in an English Wikipedia article, upon clicking the image you go to a page on en-wiki, from which you can then click through to the page on Commons. This is assumedly to reduce confusion for readers who don't want to inadvertently end up on Commons. Nyttend was proposing an option to go directly to the page at Commons, which apparently already exists. Sam Walton (talk) 18:21, 3 November 2014 (UTC)

I'm not sure that I agree with the assumed rationale, but if we accept it (for the sake of argument), then that gadget, which I only recently discovered myself, should be default-enabled for all logged-in editors. WhatamIdoing (talk) 22:08, 3 November 2014 (UTC)

I agree with Nyttend, so I think that the option should be enabled by default. --NaBUru38 (talk) 19:19, 4 November 2014 (UTC)

• Agree, though I do respect the reasons for having "disable" as the default. All the best: Rich Farmbrough, 23:57, 11 November 2014 (UTC).