Jump to content

Wikipedia:Village pump (proposals)/Archive 112

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

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

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

Invitation to a discussion on admissibility of double redirects

I would like to invite the community to a few mutually related recent discussions on admissibility of double redirects at Wikipedia talk:Double redirects, especially Some double redirects are good or MDRAG Redux and Proposal to increase $wgMaxRedirects. — Petr Matas 13:05, 30 April 2014 (UTC)

A proposal is currently being developed in the idea lab. — Petr Matas 18:34, 2 May 2014 (UTC)

The proposal has matured and has been copied here as a separate section. Petr Matas 10:53, 7 May 2014 (UTC)

Should Articles for creation move to the Drafts namespace?

Discussion about whether Articles for Creation should move to the Draft namespace are underway at Wikipedia talk:WikiProject Articles for creation. Steven Walling (WMF) • talk 16:57, 7 May 2014 (UTC)

It seems that you mean the poll in the Proposed change section. Petr Matas 23:07, 7 May 2014 (UTC)
It should be noted that the one proposal is to have the Article Wizard output pipe that dumps into "Articles for Creation" pointed to the prefix "Draft:" from "Wikipedia talk:Articles for Creation/". A second proposal is to move currently pending submissions to draft space. The second one is being held up by concerns that new AFC creations must be put into draft space first before we move the pendings over. Hasteur (talk) 14:05, 8 May 2014 (UTC)

Hover/Tooltip Definition or Info

SITUATION

I'm reading along in an article and see that that a term is linked to another Wiki article. When I hover over the link, the same exact link text is presented in a tooltip.

Now, I've already followed wiki link after wiki link to get to this page and, as a reader, I'm faced with a choice:

  1. Keep reading without following the link and risk missing some clarification.
  2. Or, jump down another rabbit hole and risk losing my place / train-of-thought / how-did-I-end-up-here? .

DESIRED FUNCTION

It would be lovely if these tooltips actually contained useful information much like the single-line descriptions on Disambiguation Pages.

  • They should be brief: 140 character max?
  • Provide context for usage/significance.
  • Disambiguate between multiple meanings or individuals.
  • Help the reader decide whether or not to follow a link to the full article.
  • Allow the author to provide tangential information when a wiki article does not (yet) exist.

USAGE

For a word, technical term, or abbreviation:

  1. A brief definition of the word or technical term
  2. Expansion of the abbreviation (Most especially for all those Wikipedia-specific abbreviations -- WP:GNG, WP:NBAND, WP:SOAP ).
  3. The particular meaning that is intended for a potentially-ambiguous word.
  4. Possibly link to Wikionary definition(s) if there's no Wikipedia article.
  5. Example in a medical article: HBP --> "HBP = High Blood Pressure" ......... or ......... "HBP = Heartbeat Period"
  6. Example in a political article: oversight --> "here: oversight = administration/management" ......... or ......... "here: oversight = incident of accidentally not noticing"
  7. Example in a quotation: fag --> "in the UK: fag = slang for cigarette"

For people, a micro-biography:

  1. The years of a person's life.
  2. The person's nationality.
  3. The person's vocation(s).
  4. The person's title/status/affiliation as it relates to the article.
  5. Example in Dunning–Kruger effect article: Bertrand Russell --> "Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, social critic and political activist."
  6. Example in Isaac Newton article portrait caption): William Blake --> "William Blake (1757–1827), English poet, painter, and printmaker."

For companies:

  1. The years in business.
  2. The company's industry.
  3. The company's nationality.
  4. Corporate affiliations and/or other business names.
  5. Example: Datsun --> "Datsun (1931-1986, 2013-now), Japanese automaker, subsidiary of Nissan Motor Company."
  6. Example: AT&T --> "AT&T, Inc. (1885-now), US telecom company, originally a subsidiary of Bell Telephone Company."

OTHER BENEFITS

  • Help readers integrate info across disciplines ("That artist is the same guy that wrote that poem I liked!").
  • Remind readers of words/names they recognize but can't quite place.
  • Make note of historical definitions no longer in use.
  • Help avoid editing wars.

SoSaysSunny (talk) 07:25, 1 May 2014 (UTC)

COMMENTS

Go to Special:Preferences#mw-prefsection-betafeatures and check the box labeled "Hovercards". --Yair rand (talk) 07:30, 1 May 2014 (UTC)
A much less ambitious plan would be to simply have the tooltip resolve redirects, so when I hover over P:CANTAB I can see that it's Portal:University of Cambridge, when I hover over WP:DNGLA I can see that it's Wikipedia:Legal disclaimer, when I hover over WP:WINAD I can see that it's Wikipedia:Wikipedia is not a dictionary, etc. It already expands the WP: part to Wikipedia:, so why not do the rest? --Ahecht (TALK
PAGE) 23:44, 1 May 2014 (UTC)
@Ahecht: The thing about WP: is that it's one of the namespace aliases that are coded into MediaWiki - it's not due to a redirect. WP:WINAD, Wikipedia:WINAD, and indeed Project:WINAD are all exactly the same page - one redirect, not three; try hovering your mouse over each of those links. You will notice that the same sort of thing happens with e.g. Image:Example.jpg vs File:Example.jpg. --Redrose64 (talk) 11:07, 2 May 2014 (UTC)
The hovercards really seem to solve it including the redirects, it's only sad that they ignore text formatting, so you won't recognize the normally bold keyword at first sight. — Petr Matas 00:27, 5 May 2014 (UTC)

WP:POPUPS is your friend. KonveyorBelt 16:13, 8 May 2014 (UTC)

Notability (geographic features)

I've re-proposed Wikipedia:Notability (geographic features) for guideline status. Please join the discussion on the talk page. Kaldari (talk) 03:18, 9 May 2014 (UTC)

A modest suggestion about Net neutrality

Some of you may have heard of an appaling proposal of the US government to gut Net neutrality. This would make it very difficult for groups like Wikipedia to achieve their goal of bring knowledge to all people -- if not utterly destroy it. However, someone came up with what appears to be quite the effective counterprotest. A counterprotest Wikipedia/Wikimedia could easily copy, & would drive the point home to the lobbyists commissioners who proposed the idea.

Discuss. -- llywrch (talk) 06:11, 10 May 2014 (UTC)

  • Thank you for bringing this up, Llywrch - I'm strongly in favor of this as well, and was directed here by the Wikipedia regular "contact us" email option. How can we move beyond this small paragraph on this huge page to actually directing the mightiness of Wikipedia to doing something in this protest? How did Wikipedia do it for SOPA last time? Admiralthrawn 1 (talk) 14:57, 11 May 2014 (UTC)
  • Oppose I'm all for net neutrality, but I'm very much against Wikipedia getting involved in politics like this. It's unseemly for a website to portray itself as a politically neutral, non-country specific source of information, but also dive into American policy debates. I also find the scaremongering by Llywrch pretty appalling. I would urge him to read up on what is actually going on, before proclaiming that it would destroy Wikipedia. I can think of no plausible scenario where that would be the case. Sven Manguard Wha? 15:35, 11 May 2014 (UTC)
  • Oppose as one who disagreed using the same reasoning on SOPA, per Sven M above. This is not an activist website, it's an encyclopedia. Can we just stick with that please? GenQuest "Talk to Me" 15:57, 11 May 2014 (UTC)
  • Oppose, with apologies for piling on. I agreed with the SOPA blackout, because that posed a plausible threat to Wikipedia's continued existence. I don't see that as being the case for this, though. While I personally oppose the proposed rules, I don't think it's appropriate in this case for Wikipedia to take action. Novusuna talk 18:01, 11 May 2014 (UTC)

Google Doodle protection

This was originally proposed on WT:PP but got very little feedback over the last month or so since I posted it there. I propose that we preemptively protect the page about whatever the subject of today's Google Doodle as soon as we find out what it is (presumably as soon as the day starts). This is because this article, whatever it is, always gets vandalized after Google posts it as that day's doodle, so I think it is logical to conclude that this will continue to happen for the foreseeable future. This then means that when a topic is featured as a Google Doodle we should semi-protect it (just for a few days) since the unhelpful IP edits outweigh the helpful ones. Jinkinson talk to me 21:39, 12 May 2014 (UTC)

This would seem to have the same problem as Protecting Today's Featured Article on the main page. Wikipedia claims to be an "Encyclopedia that Anyone can Edit" so having the most viewed article every day protected would be contrary to that purpose. Also such articles are always watched by many editors so any vandalism is quickly reverted. --Ahecht (TALK
PAGE) 22:23, 12 May 2014 (UTC)
What Ahecht said. This idea is a non-starter for me. Sven Manguard Wha? 22:43, 12 May 2014 (UTC)

New user right being rolled out soon

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
While it is perhaps not the best venue, there is already a parallel discussion well underway at Wikipedia:Administrators' noticeboard/Archive262#Category pages will be movable soon. We should keep the discussion at one place, so I am closing this thread. Sven Manguard Wha? 14:33, 13 May 2014 (UTC)

I've just read on c:Village pump that it appears that all users will soon be able to move category pages similar to the way articles can be moved. However, this won't result in the movement of pages or files that were in the category as these will still have to be recategorised individually. I hope there is an announcement before it does happen but it is worth discussing this in advance of it happening. This is a significant new capability that has the potential to be abused in the wrong hands, which is one of the reasons we limit file movements to just admins and filemovers. Therefore I propose that when it does come into play, the new right should be limited to trusted users in the short term. Obviously admins would gain this right, but I think it should be assigned to other trusted users. There are two ways we could approach this:

  1. Assign it as part of the rights for existing user groups like admins, filemovers, template editors etc.
  2. Create a new user group specifically for this right.

Personally I think there are enough user groups at the moment and I would support including the right for the most trusted groups like filemovers and template editors, although it doesn't quite seem to fit into the latter groups. Any opinions on which groups of users should be allowed to move categories? Green Giant (talk) 13:54, 13 May 2014 (UTC)

It seems I'm in the minority, but I don't see a need that it should be restricted at all. A vandal can confuse readers just as much by cut-and-paste moving as he could by using this new ability, and it's just as difficult to clean up. Jackmcbarn (talk) 14:27, 13 May 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Allow some double redirects

Closing per a WP:ANRFC request.
There is a clear consensus to allow some double redirects. Armbrust The Homunculus 11:37, 26 May 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The problem

Consider the following example. Wikipedia does not have an article on Procol Harum's member Mick Grabham yet. Mick Grabham is therefore a redirect to Procol Harum. Because Mick Grabham could become a normal article in the future, it is tagged as a redirect with possibilities. This means that links to Mick Grabham should not be retargeted to Procol Harum. However, the wrong capitalisation Mick grabham is not a redirect to Mick Grabham, but to Procol Harum, because double redirects are currently discouraged. If Mick Grabham becomes an article, Mick grabham will continue to target Procol Harum, which will be incorrect.

Proposed solution

  1. Allow existence of double redirects X → Y → Z, where Y is a redirect with possibilities,
  2. Change the bots to not fix such double redirects, and
  3. Increase $wgMaxRedirects to at least 2 to make double redirects transparent to the reader.

Implementation laboriousness

Advantages

  • Infinite redirection loops are not a problem, because the redirection chain traversal is always stopped after at most n hops (n = $wgMaxRedirects).
  • A side effect of transparent double redirects: After a page move, prompt manual fixing of the resulting double redirects will not be necessary anymore, as the bots fixing them in a few hours or days will suffice. If the page move is reverted meanwhile, there will be no redirect updates whatsoever.

Disadvantages

  • Slightly more complicated site structure

See also

Alternative solutions

  • Add to each redirect with possibilities a notice for editors saying "if you change this to an article, you should retarget appropriate redirects to here." [Source of inspiration] However, this is complicated and error-prone.
  • Add to each redirect X, which should point to a redirect with possibilities Y, a tag, which states that X should be retargetted to Y if Y becomes an article. The retargetting can be done by bots, however each redirect like X (more of them can be created in the future) has to be tagged, not only the redirects with possibilities like Y.

Support proposed solution

  1. Support, proposer. My preferred $wgMaxRedirects value is 3. Petr Matas 10:50, 7 May 2014 (UTC)
  2. Support. {{R with possibilities}} already states "Do not replace links to this redirect with a link directly to the target page", which could be easily changed to "Do not replace links or redirects to this redirect with a link or redirect directly to the target page" (with the appropriate code changes to bots and $wgMaxRedirects). --Ahecht (TALK
    PAGE    ) 13:20, 7 May 2014 (UTC)
  3. Support. I've always found this problem disturbing, as there's no obvious way to find and update the relevant links to the target article when the RWP is changed into an article. (Valid) redirects with possibilities are potential articles, so they should be linked and categorized as the topic they represent. Diego (talk) 13:51, 7 May 2014 (UTC)
  4. Support. I think a $wgMaxRedirects value of 3 sounds good as well. It would provide extra flexibility to accommodate an occasional nested {{R with possibilities}} instance, or some such. I'll qualify that by adding that there would need to be some method in place for editors to derive the sequence/unwind the chain. Perhaps by iterating an appropriate "(Redirected from ...)" hatnote at each step when backtracking and/or extending the "(Redirected from ...)" hatnote on the end target to list (and link) the full sequence. --Kevjonesin (talk) 15:05, 7 May 2014 (UTC)
  5. Support. I can't see any problem with this, and it seems to solve a recurrent problem when creating articles out of redirects. VanIsaacWScont 18:53, 7 May 2014 (UTC)
  6. Support. Very good idea! I think in certain cases the current "one redirect only" rule is counter-intuitive and allowing double (or more) redirects will result in better organized "nested" redirects, as Petr Matas explained in the original post. I'd support increasing the max redirects value to 2 or 3. 2Flows (talk) 19:55, 7 May 2014 (UTC)
  7. Support; This makes a lot of sense and shouldn't be a burden on mergists or redirectors. GenQuest "Talk to Me" 14:52, 13 May 2014 (UTC)

Oppose proposed solution

Comments

It's not something that would cripple the wiki, but why not make things better? Petr Matas 20:09, 7 May 2014 (UTC)
@Konveyor Belt: I don't understand your question. If you are asking how difficult it is to implement the proposed changes, see #Implementation laboriousness. Petr Matas 17:37, 8 May 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

the tool tip text must show the defnition of the hyperlink when clicked

hi, whenever i mousemove over a phrase or word which is already described in wikipedia , tool tip text shows its name again... (pretty useless if we think rationally..)

I propose that u show the "definition of the terminology" as the tool tip text rather than the name itself.


Algorithmically speaking

onMouseMove(YourObject yo) { yo.tooltiptext = substring(yo.content, instring(yo.content,"From Wikipedia, the free encyclopedia"),instring(yo.content,"Contents [hide] \n 1.")) }

Please tell me if you liked my idea :)

BR/Utkarsh

Click on Special:Preferences#mw-prefsection-betafeatures and enable Hovercards. WhatamIdoing (talk) 22:15, 13 May 2014 (UTC)

History TV

I noticed a discrepancy between a couple of articles: History (TV channel) and H2 (TV network). Namely, that they are both channels (not networks). At first I thought it would be a trivial matter to move H2 (TV network) to H2 (TV channel). However, after some investigation I have found a mess of articles and redirects, many of which appear to be superfluous and/or contrary to naming conventions. Below is a complete list of the 6 main articles plus all of their redirect pages, along with suggested changes. What say you? nagualdesign 19:36, 14 May 2014 (UTC)


History (TV channel)

The History Channel
History Channel
History channel - Delete
History (channel) - Delete
History (television channel)
History (TV network)
History (network) - Delete
History (U.S. TV channel) - Delete
History (U.S. TV Network) - Delete
History.com
A&E History Channel - Delete
The Hitler Channel - Redirect to History (TV channel)#Criticism and evaluation  Done
Hitler Channel - Redirect to History (TV channel)#Criticism and evaluation  Done


H2 (TV network) - Redirect to H2 (TV channel)  Done

H2 (TV channel) - Should be the main article page  Done
History 2 - Redirect to H2 (TV channel)  Done
History International HD - Redirect to H2 (TV channel)  Done
History International - Redirect to H2 (TV channel)  Done


History (Canada)

History TV
History Television
History Television Channel
History (Canadian TV channel)


History (European TV channel)

The History Channel (UK)
The History Channel UK - Delete
History Channel (UK)
History Channel UK - Delete
History (UK TV channel) - Delete
HISTORY (TV channel) - Delete
The History Channel Scandinavia - Delete
History (Scandinavian TV channel)
History Channel Scandinavia - Delete
History (Dutch TV channel)
History (Germany)
Canal de Historia - Delete
Canal de História - Delete


List of programs broadcast by History (TV network) - Redirect to List of programs broadcast by History (TV channel)  Done

List of programs broadcast by History (TV channel) - Should be the main article page  Done
List of programs broadcast by History Channel - Redirect to List of programs broadcast by History (TV channel)  Done


List of programs broadcast by History (Canada)

List of programs broadcast by History (Canadian TV channel)
List of programs broadcast by History TV - Redirect to List of programs broadcast by History (TV channel)  Done
List of programs broadcast by History Television - Redirect to List of programs broadcast by History (TV channel)  Done
List of programmes broadcast by History TV - Redirect to List of programs broadcast by History (TV channel)  Done
List of programmes broadcast by History Television - Redirect to List of programs broadcast by History (TV channel)  Done
This sort of discussion should take place at WP:Redirects for discussion. Odds are high that most of what you want to be deleted does not actually qualify for deletion. I recommend reading the policy information at that page. WhatamIdoing (talk) 21:08, 14 May 2014 (UTC)
Okay, thanks. I'll copy/paste this discussion over to there. Regards, nagualdesign 00:50, 15 May 2014 (UTC)
...I've gone ahead and performed most of the changes myself, as they should be uncontroversial. Forget the deletes, it's more effort than it's worth. nagualdesign 01:54, 15 May 2014 (UTC)

Deletion discussions

When ever a Wikipedia article is nominated for deletion, the nomination template should automatically have a link to the page for its deletion discussion, even if that page hasn't been created yet. Blackbombchu (talk) 22:02, 14 May 2014 (UTC)

It does. Or, rather, the article notice template does. I'm assuming that's what you meant. Novusuna talk 22:14, 14 May 2014 (UTC)
I meant it should link the specific page for discussing deleting that article, not the general Wikipedia:Articles for deletion page. I know that page can be gotten to by clicking a link in the nomination edit summary but it would be better to be able to do it straight from the article itself. What about all those new inexperienced editors who never had an article they created nominated for deletion who happen to run into an article nominated for deletion who might otherwise not know where to discuss its deletion or don't even know there is a discussion. Blackbombchu (talk) 03:03, 15 May 2014 (UTC)
It does: there's bolded text for "this article's entry" in the notification template. —C.Fred (talk) 03:09, 15 May 2014 (UTC)

Possibility to add or change a comment to an edit

How often doesn't it happen that you simply forget to include an edit summary (or want to change it)? Should be a piece of cake to implement! YohanN7 (talk) 16:18, 8 May 2014 (UTC)

See WP:ES#Fixing. It's technically possible, but is undesirable because it would be open to abuse. Admins have the ability to redact the whole of an edit summary, but cannot alter what it says. --Redrose64 (talk) 17:06, 8 May 2014 (UTC)
You could close the door to abuse as well (by keeping history), but this makes it technically (just a tad) more difficult. YohanN7 (talk) 17:14, 8 May 2014 (UTC)
Oh, forgot to mention, an edit summary should not be open for anyone but the editor to edit. YohanN7 (talk) 17:15, 8 May 2014 (UTC)
Go to Preferences → Editing and check "Prompt me when entering a blank edit summary". Should solve half of your problem. 2Flows (talk) 17:17, 8 May 2014 (UTC)
Thank you, that solves almost all of my personal problem with this. As for my suggestion, consider it still to be there. It is sound in all respects, it is just easier (and cheaper) not to implement it. There are no abuse problems (a totally invented problem) worse than anything else, it is just functionality that you would naturally expect. YohanN7 (talk) 17:23, 8 May 2014 (UTC)
In practice, if someone has second thoughts about their edit summary (or lack thereof) they can make a Dummy edit and explain whatever they wanted to say about their previous change. If you allowed edit summaries to be edited, would edit summaries have their own edit history? This seems impractical. EdJohnston (talk) 17:30, 8 May 2014 (UTC)
Yes, of course they would. But this is nothing I'm insisting on anymore, since there is the option to have oneself warned for missing edit summaries.
Still, consider the proposal be be there. It makes some good sense. I'm personally almost always not going back and entering an edit summary (via a dummy edit), even if there really should be one. I don't like to see my name more in the history of the article than necessary. Nor should you. YohanN7 (talk) 17:44, 8 May 2014 (UTC)

How about only being able to append to it, with the "Appended" tag inserted automatically, like this: "Improving the claim. Appended: Per John Smith's suggestion at talk. Admin12 appended: Spam" Petr Matas 03:31, 12 May 2014 (UTC). Modification: Petr Matas 04:49, 15 May 2014 (UTC)

The vast majority of times I'd want to change an edit summary, it would be because I made a spelling mistake that I wanted to correct. Considering the role of edit summaries, I'm rarely terribly bothered by a mistake made there. I don't see this as an ability that would be particularly valuable. Sven Manguard Wha? 22:50, 12 May 2014 (UTC)
What do you have against it apart from the trouble taken in implementing this feature? Dustin (talk) 23:00, 12 May 2014 (UTC)
@Petr Matas: The edit summary is not the place to show sources, see WP:CITEHOW. If I forget to show my source (or want to add a source to somebody else's edit), I simply edit the page/section, add a <ref>...</ref> (with suitable content) and use the edit summary "ref"; like this. --Redrose64 (talk) 00:11, 15 May 2014 (UTC)
@Redrose64: I agree that refs should be given inline, I only wanted to demostrate the feature usage. Petr Matas 00:19, 15 May 2014 (UTC)
I modified the example above to avoid it being misleading. Petr Matas 04:49, 15 May 2014 (UTC)
Related: Help talk:Interwiki linking#Add link

I am reposting my proposal, which last month generated one support vote. If we can get few more people, maybe something can happen... the issue is still not fixed.

If a page has no interwiki links, adding one is simple: we click "add link", a nice and friendly box pops up, we define a project code and article's name, and it's done. If, however it has interwiki link, the "add link" friendly feature is gone; instead the "edit links" option is available, taking the user to a much less friendly page on Wikidata. I would like to propose that the "add link" functionality is retained for all instances where "edit links" is available. Let Wikidata-savvy editors go there, but let most of us use the friendly "add link" option. Ping User:Sillyfolkboy. PS. Anyone knows were to go if we want to act on it, if we get a consensus this is a change in interface we want to implement? --Piotr Konieczny aka Prokonsul Piotrus| reply here 10:03, 15 May 2014 (UTC)

Last time I checked I could not even add the first link. Agathoclea (talk) 11:04, 15 May 2014 (UTC)
The "add link" worked for me today, through I had to reload a page - maybe it was frozen for a few minutes? --Piotr Konieczny aka Prokonsul Piotrus| reply here 11:23, 15 May 2014 (UTC)
"Add links" is currently missing in the MonoBook skin (bugzilla:64741), for example https://wiki.riteme.site/wiki/Pineau_de_Re?useskin=monobook. In IE9 it's missing for me in all skins. PrimeHunter (talk) 11:35, 15 May 2014 (UTC)
That separate, but related, bug is definitely worth sorting. The "add link" function is by far the most user-friendly method of linking the other language articles. Personally, I'm bought into supporting the wider Wikidata project, but we shouldn't make it difficult for less tech-savvy users. This change would have most benefit to English Wikipedia users that write in multiple languages (who know where the language gaps lie), but aren't necessarily well versed in database categorisation. There are certainly thousands of people like this, and many hundreds who have formally Categorised themselves as such. SFB 18:26, 15 May 2014 (UTC)

How about we made images in articles link to articles and not to image files if ofcourse the image doesnt depict the same article?

Downfoot1 (talk) 19:39, 16 May 2014 (UTC)

At least one reason I can think of is for purposes of attribution of images. A large number of images on Wikipedia are licensed with some variant of CC-BY, which requires attribution. So, we need some easy way of getting to the image description page (thus, the status quo). Chris857 (talk) 19:45, 16 May 2014 (UTC)
Huh? I have no idea what Downfoot1 is talking about, or what kind of problem (if any) prompts this. ~ J. Johnson (JJ) (talk) 20:48, 16 May 2014 (UTC)
It's already possible with Wikipedia:Extended image syntax#Link, but it should rarely be done. Many images have a license which requires a link to the file page. Many readers may want to look for additional information about the image on the file page. The file page will often have a larger version of the image and many readers may want that. It's a common practice on the Internet that a click on an image leads to a larger version or a page with information about the image. Readers expect that. The image caption can have links to relevant articles. PrimeHunter (talk) 21:08, 16 May 2014 (UTC)
(edit conflict) Downfoot1 wants this: [[File:example.jpg|link=Main Page|caption]]
If you click on that image, you will be taken to the Main Page instead of to the file description page. It works for external links as well, and if left blank, prevents the image from linking to anything. See mw:Help:Image#Altering the default link target for the documentation.
You will find very few instances of this being used on wiki (or perhaps none at all) because of licensing/attribution requirements. It's possible that it could be used for public domain images, but I'm not even sure that this would be okay. WhatamIdoing (talk) 21:10, 16 May 2014 (UTC)
One of the rare places that you can find these is on WP:Service awards ribbon templates, which link to the service award description, not the image. In order to do this, all of us who had made service ribbons had to authorize non-attribution licenses (CC-0 or PD) for the images. VanIsaacWScont 23:02, 16 May 2014 (UTC)
Semi related, Wikipedia:Village_pump_(technical)#Media Viewer launches next week on the English Wikipedia. –Quiddity (talk) 00:48, 17 May 2014 (UTC)

Template categorization

There should be a project page that categorizes all templates in the same way is done for stubs at Wikipedia:WikiProject Stub sorting/Stub types. The highes level categorization should be done directly on that page either by diving it into sections for each type or having a project page for sorting of each type and should be categorized into 5 sections for each possible overall way a template could look: general article or section issue such as {{technical}} or {{empty-section}}; nomination, proposed, or speedy deletion; single sentence templates such as {{citation-needed}}; stub templates; and portal templates; and possibly some other type of template I don't know about. The stub section should link to Wikipedia:WikiProject Stub sorting/Stub types and the article issue section should be categorized into the different types of issues such as {{cleanup}}, {{unreferenced}} and {{expert}} and that project page should either link to a single WikiProject that sorts all templates of that form or one WikiProject for sorting each of those types of templates. Is it possible for me to create my own WikiProject that includes another already existing WikiProject like Wikipedia:WikiProject Stub sorting/Stub types? Blackbombchu (talk) 17:33, 21 May 2014 (UTC)

New types of page protection with accompanying rights for certain editors

I would propose the creation of new types of protection for specific types of pages. These new protection types would behave similarly to template protection, whereas administrators and certain types of editors would be able to edit these pages. For example, one possible type that I have been thinking about for a while would be an uncommon type of protection to be used on redirects called "redirect protection". Administrators and users with the "redirect editor" (or possibly "redirector") right would be able to edit these pages. On some redirects with a history of vandalism, administrators apply full protection instead of semi-protection because it is too easy to become auto-confirmed. My proposed type of protection would be especially useful for editors who often edit redirects, such as by adding categories or adding {{R from}} templates, and it would save them the hassle of waiting for an admin to make the requested edit(s). I myself have on occasion encountered multiple fully protected redirects in a single day. With the proposed "redirect protection," this issue would be solved; some people might argue that the editor can just make a request for a sysop to make the requested edit, but that takes time, and the talk page where you would make the request might not be watched. I am sure that other variants of this protection could be created for other purposes as well; they could each have individual processes through which an editor would be be able to obtain editing rights to pages with that type of protection. Dustin (talk) 01:30, 7 May 2014 (UTC)

Oppose administrative WP:CREEP. Protection should be treated as a last resort to be used sparingly; the amount of full-protected redirects should be low enough that this doesn't become a widespread problem requiring a new feature. If some editors become autoconfirmed just to perform redirect vandalism, it should be easy to detect and block them by watching the semi-protected redirects. Conversely, creating a complex hierarchy of permissions turn this project more and more into a WP:BUREAUCRACY, and encourages more pages becoming protected, which is a bad thing. If you encounter too many full-protected redirects, the proper action is to request that their degree of protection is lowered one step (i.e. to semi-protected, or to pending-changes). Diego (talk) 08:52, 7 May 2014 (UTC)
One step down from full prot is template-protected. Yes, article-space redirs are not templates, but the template-prot level is available in all namespaces - it's just not used much outside of template space (e.g. User, Wikipedia, Module). --Redrose64 (talk) 09:36, 7 May 2014 (UTC)
@Diego Moya First off, this wouldn't be part of a hierarchy required for adminship or other rights, so I would consider that argument to be non-applicable to this situation. Another thing to note is that with this proposal, the protection would only be used on pages that are not actually articles, and it could only be applied when there are signs of significant, continuous vandalism to a particular redirect. In having a type of protection for redirects, even if usage of that type of protection was uncommon, the current situation would be improved to some degree. I will also add that I do not want to waste a great deal of time waiting for an admin to remove protection from a page or take no action at all. Not all admins think in such a way as to remove protection upon request To give an example, I recently encountered a redirect that I wanted to edit templates on, but I couldn't; it had been fully protected long before for an instance of vandalism. It had been awhile since then, so I made a request for the removal of the full protection, which was promptly denied. It is not fair that admins are able to have so much more power when making edits when compared to almost every other user. Not all users are admins, or want to be admins, and so they are significantly less capable. I believe that there are too many actions that are restricted to only admins, and one shouldn't be forced to make a request for every desired edit, especially if it can be confirmed that this user is trustworthy. The main use of this protection would be for redirects; why would it keep more editors out? I think in a case of admins only vs all users confirmed to be trusted, the latter is better. Please reconsider what I have said. Dustin (talk) 22:14, 7 May 2014 (UTC)
A new protection level would necessarily be part of a hierarchy. The "protect" feature available to admins offers a number of selection lists - typically one for editing and one for moving. The selection list for Edit has four levels for every page: Allow all users; Allow only confirmed users; Allow only template editors and admins; Allow only administrators. Your suggestion affects how pages are edited, so it needs to be fitted into that list. A change to the MediaWiki software is needed for that, so a feature request would need to be filed at bugzilla. There is no means in the present "protect" feature which distinguishes one type of page from another, except by namespace (for example, File: namespace has a third selection list besides Edit and Move - it is Upload - but it has the same four levels). It cannot distinguish a redirect form any other page in the same namespace, so to add that capability is again bugzilla.
When an admin sees a request to change the protection level of a page (whether filed formally at WP:RFPP or requested elsewhere), they are not obliged to act on it without question. That is not the role of the administrator. If it were, we could simply give every non-admin (which would necessarily include the vandals) the "unprotect" feature - which would eliminate the need for RFPP. When considering a request to reduce a page's prot level, a good admin will at the very least check why it was protected in the first place, and ascertain if the reason for that protection is still applicable. They may take into account the editing history of the page, recent events on its talk page, its longer term protection history, even the recent behaviour of the person requesting that the prot be reduced. If you think that "it is not fair that admins are able to have so much more power when making edits when compared to almost every other user", you need to consider why we have admins - more generally, why we have more than one level of user rights. Do we want a situation where everybody is equal? Ideally, yes; realistically, no. If we want to retain the key principle of "the encyclopedia that anyone can edit", we will always attract the malicious as well as the good. So, when a particular page is receiving an undesirable level of bad editing, we need some way of stemming the flow; this is done by giving certain trusted individuals the ability to prevent damage and also to relax that prevention where desirable. If you want admins to have no more ability to unprotect a page than yourself, you have three ways of doing that: (i) try for adminship yourself; (ii) get all admins desysopped; (iii) get the software changed so that unprotection is available to all (bugzilla). --Redrose64 (talk) 07:01, 8 May 2014 (UTC)
Yes, that may work for those redirects that are indeed highly prone to vandalism from multiple different editors; reusing an existing permission makes it easier for trusted users to request access. For those redirects that were full protected once for some specific incident long ago, it would make sense to move them two steps down or more, then. :-) There's also Move protection, which together with pending changes should allow to take care of all problematic edits to a redirect page without much effort. Diego (talk) 10:08, 7 May 2014 (UTC)
Many if not most of the administrators I am referring to don't seem to care about much of this and will just fully protect a redirect anyway. In any case, template protection is meant for templates, and I don't believe it would be good to use it on pages in the main space. Another thing to note is the processes that one must undergo to become a template editor, which involve significant editing of templates. At the very least, I believe it would be good to create some sort of protection that it less than full protection but is more than semi-protection, so that vandals couldn't just create accounts and quickly become auto-confirmed. The right to edit pages with this type of protection could either be automatic (e.g. 300 main space edits, user for two months or something similar) or gained via requests at Wikipedia:Requests for permissions. If anyone is against my proposal, please give a reason other than there aren't enough places to use it; I also don't think that it is worthwhile to spend a great deal of time waiting for an admin to make requested edits to a page or unprotect it when there are still so many. Dustin (talk) 22:14, 7 May 2014 (UTC)
We agree to something - that administrators shouldn't have the last word in such matters. But the work-around you propose would only entrench that mentality, as it would be them one more reason to be unconcerned about them over-reaching their responsibilities. I'm against creating more byzantine layers of trusted, semi-trusted and wannabe-but-can't editors; anyone can edit is a core principle that should not be taken lightly, and one which excessive protection degrades.
An autoconfirmed editor is confirmed to be trusted, so they shouldn't be excluded from any regular editing without good cause. I would propose instead as policy that all admins must reduce the level of protection on request from uninvolved editors, unless there's strong previous consensus that full protection is the only admissible level for the article and no lesser protections could possibly work. Do you have examples of the redirects where your request was rejected? Let's work on improving the review process so that rejecting the unprotection request is not up to a single admin's whim. Diego (talk) 07:03, 8 May 2014 (UTC)
P.S. Part of the problem may be that we have a protection policy, but we don't have an unprotection one. Given that protection is supposed to be a temporary last resort, that's a flaming gap in the rules. Diego (talk) 07:10, 8 May 2014 (UTC)
Since all of you are against my proposal, can there at least be some sort of limit to how long a redirect can be fully protected? I am really getting tired of not being able to tag them, and it is a waste of my time to be required to make a request when the redirect was fully protected three years ago. Dustin (talk) 16:21, 11 May 2014 (UTC)
Some sort of reply would be very appreciated; I will not be happy if this section is just archived without all of my statements having been addressed. Dustin (talk) 21:36, 21 May 2014 (UTC)
  • As a  Template editor, I would support expansion of the protection level to include this type of use (and I believe it is already acceptable by the wording if the protecting administrator links to a discussion or give a defined reason for using that protection level on such a thing). The difficulty caused by this is that people will be wanting the TE userright for the ability to work on these redirects, and whereas that may be their only interest, they may likely be missing some of the other requirements of acquiring the userright. To deal with this, I wouldn't be opposed to the creation of a new protection level tied to the existing reviewer userright. — {{U|Technical 13}} (t • e • c) 22:27, 21 May 2014 (UTC)

I want to make a suggestion about browsing across articles in different languages. How about letting registered users choose what languages they want to access and exclude those they do not understand or are not interested in?

This option could be relevant for articles with tens and tens of different versions, especially for users who edit in several languages, and it would be quicker than scrolling up or down a lot. Also, it would be great to make it possible to organize languages according to one's criteria, like language families or level of fluency, with groups or labels (in a way similar to Gmail).

Gégène (talk) 19:47, 21 May 2014 (UTC)

To a certain extent, this is already possible, using some custom CSS. For example, if I wanted to hide all interlanguage links that lead to the Arabic, Assamese, Georgian, Kazakh, Chechen, Russian, Central Kurdish, Serbian, Telugu, Ukrainian, Urdu, and Cantonese Wikipedias, I would use 
li.interwiki-ar,
li.interwiki-as,
li.interwiki-ka,
li.interwiki-kk,
li.interwiki-ce,
li.interwiki-ru,
li.interwiki-ckb,
li.interwiki-sr,
li.interwiki-te,
li.interwiki-uk,
li.interwiki-ur,
li.interwiki-zh-yue {
  display: none;
}
This would be added to the user's common.css file. --Redrose64 (talk) 21:28, 21 May 2014 (UTC)
Have you looked at the Compact Language Links option in Special:Preferences#mw-prefsection-betafeatures? I don't believe it does much here, but it may be useful at other projects, where the list can get shortened quite a bit. WhatamIdoing (talk) 14:58, 22 May 2014 (UTC)

Summary Video for Wikipedia pages

Hi I propose having videos on the Wikipedia pages, where this video would summarize the written content or explain it. This summary video will be along side the text on the page. I think this would be very appealing for a lot people for different reasons, for example visually impaired people, people whom learn by listening and people who prefer watching and learning videos rather than reading. I think this option of having the video does no harm either but just benefits to the Wikipedia article. Also countless students are learning from watching videos so this will definitely appeal to them while helping them as well. For example, say one looks up factorization (the mathematical concept) on Wikipedia, although all the information is there it would be better for a student to have a video to accompany the informative text because instead of wasting his or her time by reading everything, by watching a quick five minute video on factorization, one can save so much time. I know that one could just go to YouTube to find videos but sometimes they do not have what you are looking for or they are not very informative. This recently has happened to me, which is the reason I propose this idea. So would it be possible to create a section for this video summary? — Preceding unsigned comment added by Divyaye (talk • contribs) 06:37, 11 May 2014 (UTC)

Videos are kept at a minimum in articles to help keep the server load from getting to be too much, so I doubt it'll work. I'd imagine, if it did turn out to be possible, that there'd be something like WikiProject Spoken Wikipedia for these lede videos. Supernerd11 :D Firemind ^_^ Pokedex 08:22, 11 May 2014 (UTC)
That's not really true. Videos are used at a minimum because making videos for Wikipedia requires a lot more effort than making images. Most video cameras and software use a patent-encumbered format like MP4 or a proprietary format like WMV, which Wikipedia doesn't allow because they aren't sufficiently free. Videos need to be in Ogg Theora or WebM format. So there is an additional step required to convert the video, adding complications and requiring additional software. So the reason videos aren't used much is just because few people bother to do all the extra work to upload them. Mr.Z-man 15:48, 11 May 2014 (UTC)
To a lesser extent, the 100MB upload limit (which can be bypassed, with some hoop jumping) is also a stumbling block towards a more widespread deployment of videos. I personally passed on uploading a few videos because the only way I'd get them under 100MB would be to heavily cut the quality. Sven Manguard Wha? 18:08, 11 May 2014 (UTC)

http://en.wiki-videos.com 120,000 video clips with Wikipedia information in 45 seconds. For example--Atlasowa (talk) 21:26, 14 May 2014 (UTC)

Wikipedia articles are already summarized (at least in principle): it's called the lead. They aren't done in video because Wikipedia isn't done in video. Having a talking head read the lead is extremely inefficient use of space and bandwidth for the information conveyed. ~ J. Johnson (JJ) (talk) 21:05, 16 May 2014 (UTC)
It wouldn't have to be a "talking head". It could be a slideshow of images or video of the subject. For example, Bread could show bread being made in a bakery, or Golden-crowned Sparrow could show the bird flying, feeding, or resting, while the article information is supplied as a voiceover. WhatamIdoing (talk) 21:13, 16 May 2014 (UTC)
How is a video showing "bread being made in a bakery" in any way a summary of Bread? How does a video of a Golden-crowned Sparrow "flying, feeding, or resting" improve on the existing static image in illustrating the subject? If the "article information is supplied as as voiceover" then supply that as an audio file, and drop the uninformative video portion. ~ J. Johnson (JJ) (talk) 22:43, 16 May 2014 (UTC)
I doubt that anyone agrees with you that a video showing the contents of a major section of Bread, or of an animal's behavior, is "uninformative". WhatamIdoing (talk) 17:16, 19 May 2014 (UTC)
There you go again, misinterpreting me. I did not say a video is "uninformative". I said that if the "article information is supplied as a voiceover" — which is your assertion — then supply that as an audio file. And drop the uninformative portion, which would be everything in the video beyond the audio part. The fact remains that a video showing how bread is made is in no way a summary of the topic of Bread. ~ J. Johnson (JJ) (talk) 00:34, 20 May 2014 (UTC)
Your exact description of a video showing someone making bread was "the uninformative video portion".
Here's what I'm saying: the visual-only video portion, even if there were zero audio of any sort associated with it, would still be "informative". It would not be "an encyclopedia article" (something I never claimed), and it would not be "complete" (something I also never claimed), and it would not be a duplicate of the text or even a good summary of a comprehensive article (something else I never claimed), but it would be "informative" and even "educational". It would, in fact, be informative and educational even if the article Bread had never existed. Material need not be the same as the encyclopedia article to be "informative". WhatamIdoing (talk) 01:18, 20 May 2014 (UTC)

Join this discussion

Well, at the Teahouse, there is a join this discussion option over every section. It would be convenient to have it implemented on every talkpage. Zince34' 10:44, 7 May 2014 (UTC)

No, it wouldn't. Teahouse does a lot of strange things, like adding new threads at the top of the page (contrary to WP:BOTTOMPOST), using a non-standard edit box, adding preformatted templates to your replies whether you want them or not. --Redrose64 (talk) 11:18, 7 May 2014 (UTC)
What is strange about this, may I ask ? It looks rather convenient to me if it is implemented with some buttons at the top.Zince34' 05:15, 8 May 2014 (UTC)
It's strange if you've spent years at Wikipedia, where bottom-posting is normal. It's normal if you've spent years pretty much anywhere else on the web, where top-posting is normal.
(If you've been around Wikipedia for approximately forever, you might even remember talk pages that were neither top- nor bottom-posted, but instead were organized to match the sections of the article.) WhatamIdoing (talk) 17:41, 8 May 2014 (UTC)
@WhatamIdoing: I was not talking about the top posting (I found it strange and irritating as well). I was talking about the subject. I was suggesting was to implement join this discussion with some few buttons on the top bar of the box you get when you click the link. Zince34' 08:26, 9 May 2014 (UTC)
There's already a "New section" tab at the top of talk pages, isn't there? I'm not seeing anything that could be it in my preferences or user scripts, so I think it's a default, and that automatically takes you to the the bottom of the page. Supernerd11 :D Firemind ^_^ Pokedex 08:31, 11 May 2014 (UTC)
@Supernerd11:We are talking about joining discussions, not making them. Zince34' 08:05, 15 May 2014 (UTC)
Facepalm Facepalm Supernerd11 Firemind ^_^ Pokedex 12:09, 15 May 2014 (UTC)

Well, the proposal has been so much been mistaken by users so I'll explain it again. At teahouse, there is a 'join this discussion' tab for every discussion. Rather than clicking edit and then finding your way through some magic words, that could completely change charecter when accidently changed. For example a mess can occur when {{Template becomes {Template to avoid something like that to happen, this box is used. You'll just need to type your comment and click go, it will create the response with some formatting. Zince34' 05:56, 16 May 2014 (UTC)

I think the proposer aims for talk pages to be more newbie friendly... though I'm afraid that some people simply don't read. Especially the "Sign your posts using ~~~~!" --k6ka (talk | contribs) 16:12, 21 May 2014 (UTC)
Actually, the box at the Teahouse doesn't let you post unless it detects the 4 tildes at the very end of the text. I wonder if there are statistics on how many people use that vs normal editing. 107.215.250.18 (talk) 21:33, 22 May 2014 (UTC) (also User:Ansh666)
Eh. I don't know exactly how it works, but it doesn't seem like it would be able to account for all the indenting that normal talk pages have (I just responded to one, and it set it at level 1 indentation (:) instead of the proper level 2 (::)). For a normal reply, something like templates being messed up should not be much of a problem; there should be an edit tab next to each section (I have it as an IP) which will allow easier access anyways. And besides, once WP:FLOW comes around it'll be moot anyways. 107.219.151.20 (talk) 07:18, 21 May 2014 (UTC) (former User:Ansh666)
I know it has some problems, but I think we can fix them. And at the same time, add some buttons as well. Zince34' 07:15, 23 May 2014 (UTC)
Unnecessary side discussion, sorry
Just to note, I cannot see "« Join this discussion [edit]" when I am logged in. But when logged out, I can see it. So you guys need to be logged out to see what the OP is suggesting···Vanischenu (mc/talk) 23:08, 21 May 2014 (UTC)
@Vanischenu: That's odd, I can see it both logged in and not. You went to WP:Teahouse/Questions, right? 107.219.151.20 (talk) 06:54, 22 May 2014 (UTC)
I know it has some problems, but I think we can fix them. And at the same time, add some buttons as well.Zince34' 10:14, 22 May 2014 (UTC)
Anyway I can see it logged in as well.Zince34' 10:14, 22 May 2014 (UTC)
I can see it form my alternate account but still can't see from my main account. So I thought it gets displayed only for new users, and Redrose64, WhatamIdoing and others would not be able to see it. But since Ansh can see it (whose is older and have more edits than me) it might perhaps be due to some of some gadgets or because of rollbacker rights.···Vanischenu (mc/talk) 15:24, 22 May 2014 (UTC)
Both Redrose64 (talk · contribs) (who is an admin, and therefore a rollbacker also) and Redrose64a (talk · contribs) (who is not even autoconfirmed) can see the "Join this discussion" link; it's between the section heading and the "[edit]" link. If you can't see a "Join this discussion" link, can you see the "[edit]" link? If not, you may have something affecting the mw-editsection class; if you can see "[edit]" but not "Join this discussion", you may have something affecting the wp-teahouse-respond class. --Redrose64 (talk) 15:52, 22 May 2014 (UTC)
You are right, I can see it when "Ask a question" feature for the Wikimedia Foundation's "Teahouse" project is selected on my preferences. I should have checked it. Sorry for this unnecessary side discussionVanischenu (talk) 16:20, 22 May 2014 (UTC)
  • I completely understand the request, and I have two points to make here. First, the script used to add that little drop-down box has quite a few major flaws of it's own such as the lack of a Show preview which makes it difficult to make sure that all of the templates and links that you add in the box are as you expect them to be (which is why I refuse to use it). Using the [edit] link for section editing is much more efficient. Second, once FLOW is fully rolled out, this request will be obsolete as that is an entirely different system. — {{U|Technical 13}} (t • e • c) 14:13, 23 May 2014 (UTC)

Proposed merging of Imishli (city) into Imishli District

I don't know whether I'm in the right place for this but here goes. I propose that Imishli (city) be absorbed into Imishli District. The main body of both articles is almost identical, as if the same person has written both articles or, dare I say it, the information for the text of both articles comes from the same place. Jodosma (talk) 11:21, 24 May 2014 (UTC)

The proper procedure is described at WP:MERGE#Proposing a merger; the page to start discussion would probably be Talk:Imishli District as it seems to have more watchers. --Redrose64 (talk) 12:18, 24 May 2014 (UTC)
Closing per a WP:ANRFC request.
There is a clear consensus to change link target in {{Expand section}}, and it should link to Wikipedia:Tutorial. @Kevjonesin: Armbrust The Homunculus 11:43, 26 May 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I propose modifying the target of the link displayed by Template:Expand section.

Specifically, regarding the word "expansion" that's presently hyperlinked to source editing mode. Example:

I was a bit surprised that the "expansion" link took me directly to source editing instead of some sort of tutorial (and/or guideline, explanation. etc.). It seems that it would be rather surprising for the 'average reader' to be dropped into an unfamiliar interface—with unfamiliar markup syntax—without the benefit of some sort of introduction.

I suppose elevating a 'curious reader' who clicks a link directly to 'naive editor' is one way to go about promoting editing, but personally, I suspect that inserting some sort of brief orientation step—with links to relevant resources—might help make for a more pleasant experience. For both the 'curious reader'/'aspiring editor' and for those who interact with a page after them.

There's probably already a page or section somewhere that would be appropriate (or easily tweaked to be so). Anybody have any suggestions?

[Above, mostly, copied from Template talk:Expand section. Feel free to copy/link elsewhere as appropriate.]

--Kevjonesin (talk) 10:35, 4 May 2014 (UTC)

Support

  1. Support changing the link to Help:Editing Wikipedia:Tutorial. Petr Matas 15:23, 16 May 2014 (UTC). Update: Petr Matas 01:29, 20 May 2014 (UTC)
  2. Support, though I'd recommend linking to Wikipedia:Tutorial. I think the content presented in its tabbed interface would be both accessible and relevant to neophyte editors taking interest in the link. Those more experienced would be unlikely to be 'clicking through' for elaboration in the first place. Help:Editing, with its higher information density, might not be as accessible. --Kevjonesin (talk) 01:22, 20 May 2014 (UTC)
  3. Change the link to Wikipedia:Tutorial, It's great we're sending new users to the editing part but not so great to the new users who have no idea how to edit or what to do, Linking to the tutorial would be extremely helpful IMHO. →Davey2010→→Talk to me!→ 03:04, 20 May 2014 (UTC)
  4. Keep the link going to an edit page to encourage new user editing but add &editintro=Wikipedia:Tutorial (or likely some shorter truncated version of that as an editing quick reference guide) to the URL so that they will still be able to figure out what to do in the edit window. — {{U|Technical 13}} (t • e • c) 11:40, 20 May 2014 (UTC)
  5. Support: Good idea. Tito☸Dutta 08:59, 21 May 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I just received a slightly annoying email from a user, asking to remove poor box office details from their film's article. There I noticed, the username of the sender was not linked. If you please link the sender's username with their Wiki user page, we can quickly check who actually sent the email. Tito☸Dutta 16:07, 15 May 2014 (UTC)

A useless discussion of the purpose
@Titodutta: As an email can be completely faked, including the sender field and links in the body, I think that the link should point to the wiki page, which shows that this particular user sent an email to you at this particular time. However, I don't know whether such page even exists. Petr Matas 01:47, 16 May 2014 (UTC)
The sender's login ID should be visible in your email program. Email programs vary, so I can't say how it would look in yours; but most email programs allow you to view the original message before it was mashed about by your email program. In the original, there should be a "From:" entry, normally on one line, like this: 
From: Redrose64 <my.email.name@example.com>
There are two items, the Wikipedia login ID, and an email address. The email footer (which is often visible simply by displaying the mail) should also have some text beginning 'This email was sent by user "Redrose64" on the English Wikipedia to user "Example".' --Redrose64 (talk) 14:54, 16 May 2014 (UTC)
@Redrose64: I know, but all this can be faked, unless the email is digitally signed by Wikipedia (which it isn't). Petr Matas 15:11, 16 May 2014 (UTC)
Petr, I don't think that he's asking for greater e-mail security. I think he's just asking for a convenient link to the userpage of the person who allegedly sent it. That is, he wants the bit at the bottom of the message, which currently says:
"This email was sent by user "Example" on the English Wikipedia to user "WhatamIdoing". It has been automatically delivered and the Wikimedia Foundation cannot be held responsible for its contents"
to instead say:
"This email was sent by user "Example" on the English Wikipedia to user "WhatamIdoing". It has been automatically delivered and the Wikimedia Foundation cannot be held responsible for its contents."
WhatamIdoing (talk) 18:54, 16 May 2014 (UTC)
It's a plain text mail (there are good reasons for that) so it cannot contain a link. It can contain a full displayed url like http://wiki.riteme.site/wiki/User:Example which will automatically be converted to a clickable link in many email programs (like MediaWiki also does here), but the whole url would still be displayed. PrimeHunter (talk) 19:07, 16 May 2014 (UTC)
More of the useless discussion of the purpose
  • Anyone? Tito☸Dutta 19:10, 19 May 2014 (UTC)
    • @Titodutta: I support your proposal, but do I get it right that actually you can't check anything related to the email on the user page, you just want a convenient access to it? Petr Matas 00:14, 20 May 2014 (UTC)
      • Yes, you've got it: he just wants a link in the e-mail to the userpage of the sender of the e-mail message, or, if it makes you happier, a link to the userpage of the alleged or purported sender of the e-mail message. He is not looking for proof that this person truly sent this message. WhatamIdoing (talk) 01:22, 20 May 2014 (UTC)
  • (Again) Exactly what WhatIAmDoing has said. They ask to link either user page or user talk page in Wikipedia signatures, so that one can easily access his user page and contrib page. It is a similar suggestion.
    The last time I received a "I'll sue/kill you if you revert my edit" type email, I could not remember who was that editor and which article he was talking about, I had to check his contribs and talk page warnings to understand the context.
    Now if you give a link the user page, I don't need to manually access his user page.
    About "plan text email", yes, it is a plain text email, but I have "HTML email" in preference. I don't why they send me plain text email.
    I thought it was going to be an uncontroversial suggestion. Tito☸Dutta 09:19, 21 May 2014 (UTC)
  • Is this doable here, i.e. can someone at en:wp flip a switch to get this to happen? Or do we need to file a request at Bugzilla? Either way, I'd support it; a simple change from "this email was sent by Example" to "this user was sent by http://wiki.riteme.site/wiki/user:example" wouldn't have any downsides, and it shouldn't require much work by anyone. Nyttend (talk) 15:09, 27 May 2014 (UTC)

Please note that I'm proposing changes in the presentation of what's already viewable (with a bunch of work) by everyone; I'm not attempting to change anything with the oversight or revdel policies. I'm an admin and am able to see things on which ordinary revdel has been performed, so I'm just guessing that ordinary users see it like I see oversighted stuff; if not, please correct me.

When oversight is performed, the link in the page history is greyed out, so it's impossible to access diffs that include that revision as the start or end. However, the URL for the revision still works, and it's possible to access the revision in a roundabout way by looking at older or newer revisions and clicking "previous revision" or "newer revision". For example, Talk:Japan–Korea Treaty of 1910 just had a revision oversighted, but you can still go to https://wiki.riteme.site/w/index.php?oldid=610336284 directly, or you can go to https://wiki.riteme.site/w/index.php?oldid=610333994 and pick the "newer revision" option.

Is the current situation desirable? I think it would be better if the page history retained links in some modified fashion, since there are occasionally good reasons (e.g. on a talk page discussion) to link an oversighted diff, and retaining some sort of link would make it a lot simpler. I assume that this is something that would require a software modification (i.e. can't be done just here at en:wp), but I figure it might get more favor from the developers if we had a consensus here that it would be a good thing. Nyttend (talk) 14:59, 27 May 2014 (UTC)

  • "I'm an admin" — you don't need to mention it, your suggestion shows that. That's a very good suggestion. There might be another way to access the link (for admins): go to "View and restore deleted pages", there in "page history", you may get the link. Tito☸Dutta 10:15, 28 May 2014 (UTC)

Requested project pages

There's already a place to request articles and a place to request templates so why not also have a place to request project pages and help pages. Without it, how is somebody supposed to submit a good idea of a project page that they don't have any knowledge of content to put in. Some of those requested project pages might end up really useful and cover a lot of information that otherwise gets asked at the tea house or help desk taking attention away from other questions that are asked there. Without the requested project pages feature, I can't request highly useful project pages such as Help:Determining which village pump lab to type a message into and Wikipedia:Village pump section deletion and closing policy. Blackbombchu (talk) 16:42, 23 May 2014 (UTC)

  • You mean like Wikipedia:WikiProject Council/Proposals which I found by simply going to Wikipedia:WikiProject? I've tried to AGF with you Blackbombchu, but I'm really reaching my limits with that. There have been others on a couple occasions that have considered requesting a CIR check for you and a possible blocking based on that, and I've stuck up for you. Can you please demonstrate some competence and tell everyone here why at very least there shouldn't be a topic ban for you to prevent any more of these poorly thought out and researched proposals of yours? — {{U|Technical 13}} (t • e • c) 17:24, 23 May 2014 (UTC)
  • Technical 13, your response is rude and "WP:CIR" etc are irrelevant here. Tito☸Dutta 17:35, 23 May 2014 (UTC) Note: I have not checked this guy's entire contribution, I am talking on what I can see "here" Tito☸Dutta 17:36, 23 May 2014 (UTC)
I fully understand why that response came across as rude, but if you review some history, it will sound quite restrained. Blackbombchu has been asked to use the idea lab rather than Proposals for valid reasons.--S Philbrick(Talk) 12:26, 28 May 2014 (UTC)
Agree 100% with the above comments by @Sphilbrick:. GenQuest "Talk to Me" 03:43, 29 May 2014 (UTC)

The articles of Wikipedia talk about real world things, and have names that they already have in the real world. The article about Barack Obama is named "Barack Obama", and if it was a red link, we would know which real life topic it would talk about. Starting a new article would be simply to reflect the information about that topic which is already out there in the real world. Project pages, on the other hand, are about concepts from within Wikipedia, or real-world concepts that get a specific meaning within Wikipedia. Such concepts are not the result of a single guy's initiative, but a result of a general discussion that agreed on the need and shape of such a concept. As such, we can't simply say that we need a page named "Wikipedia:Eviction" or "Wikipedia:Court martial", and sit and wait for some random user to come up with a new process that may fit in such name. Cambalachero (talk) 12:55, 28 May 2014 (UTC)

"This week's missing articles" at the Main Page

This is not a complete proposal, just a brainstorming session.

The purpose of the main page is partly to highlight the quality and diversity of articles we have, partly to lure readers in, and partly to encourage new editors (one of the reasons we have DYK). One approach to get new editors and improve Wikipedia which (AFAIK) hasn't been tried yet is a section on the main page for "Missing articles of the Day", a selection of redlinks with a short description of what they should be about and an invitation to create them. It would be similar to DYK, and could be a new section or replace DYK one day a week, or ...

I am aware that the time spent in searching, describing, and posting the "missing articles" could also be used to create the articles in the first place, but that's not really the point. The intention is to get new editors, to get more readers active, to indicate that Wikipedia is an eternal work in progress. To achieve this, the selected redlinks should not be for obscure topics with minimal notability, but for topics where peoples' reaction should be "hey, isn't there an article for this subject yet, that's odd". And yes, there are plenty of those left.

For starters, a rough indication of what I have in mind.

Please help us create an article on

It shouldn't be too hard to find five or six subjects a week which present a varied choice of missing subjects which could be of interest to a reasonable chunk of our readers. Whether such creations should be in draft or mainspace and other considerations are of less importance.

Thoughts? Fram (talk) 10:01, 28 May 2014 (UTC)

  • a) TAFI was a similar addition to the main page. b) 1 of every 100 readers will feel inclined to create an article. it'll not be very useful for other 99 readers c) we'll never be able to find "best suggestions" for all readers. You may see discussions at WT:GetteingStarted. The articles you have mentioned in your post, I have "0" knowledge and interest on those. Tito☸Dutta 10:09, 28 May 2014 (UTC)
  • Don't your arguments apply as well to DYK? Most of the items there are of no interest to the vast majority of our readers, but we still show them to attract new editors and to encourage existing editors. Fram (talk) 10:24, 28 May 2014 (UTC)
  • True, but that would be the purpose of this section. The exact text used can be changed of course, if it is too demanding or direct. Fram (talk) 12:13, 28 May 2014 (UTC)
I think we should show requests on recently updated content Hg andVenus 12:30, 29 May 2014 (UTC)
  • Fram, please check out our WP:TAFI project. I think you would really like it, and perhaps we can merge your idea because I do think there is merit to it. Essentially we choose a short stub to collaboratively work on over the week.--Coin945 (talk) 13:10, 29 May 2014 (UTC)

Removal of a redirect

I suggest removal of the following redirect: https://wiki.riteme.site/w/index.php?title=Oodles_of_Noodles&redirect=no The article that it directs to does not have 'oodles of noodles' anywhere in it. I came to this redirect searching for information on the Jimmy Dorsey composition. https://wiki.riteme.site/wiki/Jimmy_Dorsey#Compositions_by_Jimmy_Dorsey This redirect serves no purpose except to confuse.1archie99 (talk) 18:59, 26 May 2014 (UTC)

I would suggest that you bring this issue up as an RFD. Dustin (talk) 19:11, 26 May 2014 (UTC)
Thanks. It would be a first for me. I do small tasks. If this confusion still exists when I find time I will pursue. If someone else fixes please inform me.1archie99 (talk) 14:38, 29 May 2014 (UTC)

Draft space XFD discussions

Please see the discussion at Wikipedia_talk:Miscellany_for_deletion#Draft_space_XFD_discussions. Thank you, — xaosflux Talk 15:22, 29 May 2014 (UTC)

RfC: remove the attention flag from WikiProject banners

See the discussion here. RockMagnetist (talk) 03:47, 1 June 2014 (UTC)

Please change language labels for "čeština" and "slovenština"

This has irritated me for years:

Please change the language labels for "čeština" (Czech) and "slovenština" (Slovak) to "česky" and "slovensky" as this would make the labels consistent with every other slavic language in which articles are present on wikipedia (like Polski, Русский (Ruskij), Hrvatski, that is in Polish, Russian, Croatian...).

Note that the "Y" is important as Czechs and Slovaks use "Y" where Poles would use an "I"

However, "čeština" / "slovenština" mean "(the) Czech language" / "(the) Slovak language" while "česky" / "slovensky" mean "(in) Czech" and "in Slovak" in the same way as "Polski" and "Русский" mean "(in) Polish" and "(in) Russian"

Thanks.

(Fr) Dennis Zdeněk Kříž, OSM — Preceding unsigned comment added by Denniskriz (talk • contribs) 14:58, 3 June 2014 (UTC)

Do you mean in the "languages" list at the bottom of the left-hand sidebar? The labels for these are centrally generated for all Wikipedia sites and projects - they may even be part of the MediaWiki software itself; I don't think that we have any control over them. --Redrose64 (talk) 15:39, 3 June 2014 (UTC)

Request for Comments (RFC) notice

There is a Request for Comments (RFC) at Help talk:Citation Style 1/Archive 5#RFC: Citation Style 1 parameter naming convention proposing that a naming convention be institued for Citation Style 1 parameter names. Please add your comments there if you are interested in participating in the discussion. Thanks!—D'Ranged 1 VTalk 20:07, 3 June 2014 (UTC)

Sleeping Dogs (video game) - Peer review request

Sleeping Dogs (originally: True Crime: Hong Kong and Black Lotus) is an open world action-adventure video game developed by United Front Games in conjunction with Square Enix London Studios and published by Square Enix for Microsoft Windows, PlayStation 3, and Xbox 360. It was released on September 27, 2012 in North America; September 27, 2012 in Japan; August 17, 2012 in Europe; and on August 16, 2012 in Australia.

Set within the fictionalized version of Hong Kong, the single-player story follows Wei Shen, an officer of the San Francisco Police Department, who had been seconded to the Hong Kong Police Force. Wei has been assigned by the Organized Crime and Triad Bureau to go undercover and infiltrate the Triad society, gather information on Sun On Yee (the equivalent of the real-life Sun Yee On) and take them down. C Sleeping Dogs received generally positive reviews upon release, with many critics praising its open-world, gameplay, voice acting and sound design, but was criticized by some reviewers, who often commented on the game's poor graphics and stiff animations. The game went on to sell 1.50 million copies worldwide within less than a year of its release.

I believe this article is fantastic and well-written. I would really appreciate any reviews/opinions on the page, specially on the lead section, downloadable content, and development sections. URDNEXT talk URDNEXT (talk) 18:00, 7 June 2014 (UTC)

Make the background colour of Template:Historical more prominent

The background colour of Template:Historical is very unassuming, and almost blends in with WP's own background. This makes it quite difficult to see. Thus it is often lost visually among other templates. It's a rather vital notice, indicating a page is no longer used, and significantly changes the way a page is used (ie. pages won't be any more). I'm proposing that the background colour be made more prominent, so that the notice itself can be more readily seen. It doesn't look like the talk page gets much traffic, so I have proposed this here.

The discussion is here: Template_talk:Historical#Template_colour. --LT910001 (talk) 09:56, 14 June 2014 (UTC)

If you didn't notify, notification shouldn't be signed by you or in your contributions

This question on The Teahouse appears to indicate a situation that should be corrected. If a person does not actually notify someone, but the notification comes from him/her by some automatic process, that person's notification shouldn't appear in any history as coming from that person, or in that person's contributions. And yet Twinkle has an automatic notification feature which, in this case, sent a user a notification from himself on his own talk page. He was afraid his account had been compromised.— Vchimpanzee · talk · contributions · 21:09, 13 June 2014 (UTC)

I probably haven't explained this well, so I will include this description of the problem:

Hey Jodosma. Here's what happened. When you list a discussion at RfD using Twinkle it gives you an option to "Notify page creator if possible?"; if you don't take the checkmark out of the box Twinkle then provides a warning for editors of the category through your account automatically when you save. Here, since you are the only editor of Category:Mountain passes of the Appenines, when you listed it for discussion in this edit using Twinkle, you automatically warned yourself the same second (and then yelled at yourself for doing so:-)--Fuhghettaboutit (talk) 00:52, 13 June 2014 (UTC)

— Vchimpanzee · talk · contributions · 21:17, 13 June 2014 (UTC)

Twinkle isn't automatic. It is your responsibility to read the user manual. Legoktm (talk) 23:54, 13 June 2014 (UTC)
Thanks. I'll let them know.— Vchimpanzee · talk · contributions · 15:30, 14 June 2014 (UTC)

Elevate Wikipedia:Redirects for discussion/Redirects from foreign languages to guideline

We are seeing a lot of foreign-to-English redirects showing up on WP:RFD of late, with mixed outcomes, but generally either way with appeals to this essay. It seems to me that we should endorse this essay and promote it to guideline status so as to expedite these discussions. Mangoe (talk) 17:23, 16 June 2014 (UTC)

Edit notice for deceased Wikipedians

I propose that a way to add an edit notice to the talk pages of deceased Wikipedias be implemented. This will give a visual indication that messages left for this user will never have a response from the user. -- 65.94.171.126 (talk) 11:25, 7 June 2014 (UTC)

I don't believe that it would be possible (although I could be wrong) to have such an editnotice displayed automatically, but it would definitely be possible to go around creating editnotices for talk pages of deceased users. We could have the editnotice be simply {{Deceased Wikipedian}}. Nyttend (talk) 19:27, 8 June 2014 (UTC)
I think it would be dangerous per WP:BLP or WP:OUTING to have such a notice (I realize we're using it already). For Wikipedians who we know to be deceased (i.e. not editing any more) why not just add {{retired}} instead? Ivanvector (talk) 14:53, 16 June 2014 (UTC)
  • Why, Ivan, do you think it would be dangerous? In order to be marked as deceased, a reliable source is required just like in any other BLP article. I see no issues there, but welcome your insight. Nyttend, it would be easy to write a script that would add a notice similar to an editnotice if a user's userpage has the {{Deceased Wikipedian}} template on it && that userpage was fully protected. This would accomplish this goal without creating a bunch of editnotices around the wiki and without putting editors at risk of being intentionally harassed by being marked as deceased (since it would require an admin to protect the page or add the template to an already fully protected page). There could be other safeguards put in place if so desired. If there is community consensus for such a script, I'll happily write it. — {{U|Technical 13}} (e • t • c) 15:30, 16 June 2014 (UTC)
  • Apologies, I've misread the proposal. On the surface I see the potential for harm from a person's private information (their death) being published here, but I see also that there's an existing community tradition about this, along with well-developed process. Having {{Deceased Wikipedian}} plus full-protection seems like good criteria, as it ensures an admin has reviewed the case. Ivanvector (talk) 18:52, 16 June 2014 (UTC)

RfC: Should Template:Geographic reference be split into separate templates for each source?

I have no idea if this belong here but I started an RfC at Template:Geographic reference. Template:Geographic reference is a very extensively used template that, in my opinion, does nothing more than provide a hard-coded instance of ten separate and very loosely connected sources. The RfC asks if we should split the references out into separate templates. I imagine there are technical implications to it but I don't see how this is any difference than all the other templates at TfD where we discuss splitting or deleting. -- Ricky81682 (talk) 22:46, 16 June 2014 (UTC)

Special Symbols dictionary

I have long thought that a major difficulty with ordinary dictionaries is that there is insufficient attention paid to special symbols, such as letters with umlauts, accents and diereses, mathematical, musical and logical notation, notation from chemistry and physics, phonetic signs, and so on. Wikipedia has comprehensive lists on other matters, such as Latin phrases, and I think that a comprehensive list of special symbols with clear descriptions of where and how they are used, their relationship to other signs, and ideally, sound files to show pronunciation, would be a much used and appreciated feature.

Of course, there are some problems with listing such items, as often the user does not know what a special accent or symbol is called, and thus where to find them in a list. But, cultures with non-alphabetical languages have ways of doing this, and so can we. In particular, many letters with special accoutrements can simply be shown on the screen, where they could be selected by the user. Other symbols can be arranged according to the category they belong to (e.g. musical, mathematical) or arranged according to complexity of depiction. In the latter case, simple one stroke signs would come first, followed by ones which are more complicated. I know that there are disparate lists to be found in WP but I am thinking of something global, so that a user can look a a sign without knowing what category it belongs to.


I believe that the main reason that most people are completely flummoxed by even the look of mathematical equations is because they look like they are full of “squiggles”. If those squiggles had names and some simple description of what they do, then the reader would not regard them the same way. He or she might not be able to use the equations, or even follow them straight away, but simply by having some idea of what operations are performed by those symbols would give him or her a much better idea of what was being talked about. In other words, if you can READ a sentence with such includes such symbols, then you are a long way towards understanding it. It is the difference between looking at an English paragraph where you might only have a vague gist of its meaning, and seeing the same paragraph in a foreign language, where you have no idea at all.

Let me provide a simple example. The symbol “&” is called an ampersand, but many people do not know that. Thus, many people regard it as a doodle, and often do not know what it is, because they cannot look it up. Putting most such signs into Google, for example, brings up an error message.

Such a move towards clarifying symbols would require a special symbols dictionary with good search parameters. Nothing like that seems to be available, and Wikipedia would be the obvious place to compile one, because this is where such symbols must be used in articles where their occurrence is unavoidable, and also because this is where the world now comes to look for answers. And, after all, it is not as if we are talking about compiling another complete Oxford Dictionary. A thousand entries should pretty much cover all the symbols in question.

I am not sure how to go about compiling such a list, and I do not have the computer coding ability to construct search devices and so on. And for that matter, I do not even know if such an idea has been considered before. But at some language groups I visit, there has been considerable interest expressed, and I am wondering if there are any here thinks the idea has any merit. Myles325a (talk) 03:37, 15 June 2014 (UTC)

An interesting idea. One place many symbols are listed and named is the character table for Unicode: [1] --LT910001 (talk) 05:18, 15 June 2014 (UTC)
  • At WP:WikiProject Writing systems, we've been working on getting good coverage of the characters of the major script families - so all of the Latin characters, included accented, all the Greek and Cyrillic, Japanese kana, Braille patterns, and all the Semitic (Hebrew, Arabic, Aramaic, Phoenecian, etc). I've got one Indic family letter, Ka (Indic), with long-term plans to fill out the Brahmi-derived characters. But symbols have sort of taken a back seat in that effort, and could probably use an effort coordinated between Writing systems and some of the technical wikiprojects like Mathematics. I'd suggest heading over to the Writing systems talkpage and put this there; I'm sure that there are people who'd like to engage with some other wikiprojects to get this kind of content out. VanIsaacWScont 08:00, 15 June 2014 (UTC)
Very interesting indeed. --AmaryllisGardener talk 19:15, 17 June 2014 (UTC)

Discussion notice

A discussion is occurring at Template talk:Find sources regarding updating the Find sources template with links to the Google News and Google newspapers searches. Interested editors are invited to contribute to the discussion. The discussion is located here. NorthAmerica1000 08:09, 18 June 2014 (UTC)

Watch also all redirects to a page

There is consensus that this would be a good optional tool to have. Number 57 10:05, 20 June 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The proposal

For each page on the watch list, I would like to be able to choose whether all redirects to it should be watched too, without having to add them to the watch list. I would be notified about any new redirects to the page and they would become watched automatically (without a new entry being added to the watch list).

Motivation

Imagine that you watch Aaron Basketeer. Later, a redirect to it, Aaron basketeer, is created. After some time, the new redirect is changed to an article with nonsenses. Without the proposed feature, you will not be able to catch this change, while readers searching for "aaron basketeer" will end up on the bad article.

Support

  1. Proposer. Petr Matas 01:17, 16 May 2014 (UTC)
  2. I think this would be useful. –Quiddity (talk) 00:37, 17 May 2014 (UTC)
  3. I actually don't think this is a bad idea and perhaps would be rather useful. →Davey2010→→Talk to me!→ 02:58, 20 May 2014 (UTC)
  4. Assuming it's optional and opt-in. -- King of ♥ ♦ ♣ ♠ 23:24, 22 May 2014 (UTC)
  5. Support; would be a useful feature. APerson (talk!) 00:38, 24 May 2014 (UTC)
  6. Support. Not something I'd use, but I understand why some people would benefit. I don't think it should be opt-in — we should be given the option of watching all redirects. It seems a bit of extra work to program (with no particular benefit that I could see) if someone had to check a gadget or preference in order to have the option of watching redirects. After all, the proposal is asking that this be presented as a possibility when watching a page. Nyttend (talk) 15:06, 27 May 2014 (UTC)
  7. Support as opt-in. --AmaryllisGardener talk 19:48, 30 May 2014 (UTC)
  8. Support - So long as it is only something like a button you can choose to use or not use, what is there to lose? It sounds alright to me! I might think a little bit more about it if it was one of those pages with 50+ redirects, but I still like the idea. I am not sure how it would apply to section links though. Dustin (talk) 04:12, 13 June 2014 (UTC)
  9. Support It won't crowd your watchlist up since unlike regular articles it won't be regularly changed. This could be useful at times. Much easier than clicking "what links here" and adding each existing redirect to your watchlist individually. Dream Focus 09:02, 18 June 2014 (UTC)

Oppose

  1. Oppose, not really needed. GenQuest "Talk to Me" 04:20, 16 May 2014 (UTC)

Comments

  • Comment from Titodutta: Some comments
  1. If it is optional, then it is fine. Nothing should be forced.
  2. Imagine that you watch Aaron Basketeer. Later, a redirect to it, Aaron basketeer, is created. After some time, the new redirect is changed to an article with nonsenses — it happens very rarely.
  3. On the other hand, there are many pages with multiple/many redirects. So, by adding redirects to your watchlist, you'll badly increase your watchlist size.
  4. If someone change a redirect to an article, that can be CSD-ed as duplicate content.
    @Titodutta: The redirect could be also just retargetted, which will not trigger the WP:CSD process, I think. Petr Matas 02:17, 16 May 2014 (UTC)
  5. Finally, bot can handle such problematic/disruptive edits.
    @Titodutta: Can you provide a link to the documentation of such bot, please? Petr Matas 02:17, 16 May 2014 (UTC)
So, for now, I am not very interested in this proposal. Tito☸Dutta 02:00, 16 May 2014 (UTC)
  • I am replying here— the redirect could be also just retargetted, then we need to see if it is a valid re-targeting or not. I generally take redirects to RFD before redirecting. Can you provide a link to the documentation of such bot, please? — I do not any, most probably there is not one at this moment. --Tito☸Dutta 02:22, 16 May 2014 (UTC)
  • Idea/thought - I see the proposal as you click to watchlist something, and a dialogue asks if you'd "...also like redirects to this article added to your watchlist?", or similar. But as another suggestion, something kept on a talkpage (amongst the banners/article history) that is updated by a bot task, working and looking similar to WP:Article alerts. This could provide this type of information, and other important data, in a collapsible box that isn't intrusive. - Floydian τ ¢ 00:21, 23 May 2014 (UTC)
    • I think this is a good idea. The history of redirects to the page would be gathered in the collapsible box for anybody's future reference and each addition to the box would trigger the watchlist system naturally. Futhermore, this solution does not require any modification of the MediaWiki software. Petr Matas 13:02, 2 June 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Restoring sortable tables initial order

I've come across this problem many times and thought I'd discuss it here. There is a sortable table. I click on a field to see it in a different order, then I click on another and then I decide to go back to the original order. There is no way of doing it... is there? Maybe there should be some sort of a button or link to restore the original sorting of the table? What do you think? Le Grand Bleu (talk) 04:46, 23 June 2014 (UTC)

There isn't indeed. The original sorting is 'unsorted' or 'random' or 'sorted by a human'. I don't think we should have a state in the sorter that reflects that, it seems like an interface workaround to a problem that shouldn't really exist (if you human sort correctly and annotate the table correctly). —TheDJ (talk • contribs) 18:58, 23 June 2014 (UTC)
I think that the only "button" for restoring the original order is the "reload page" button on your browser. WhatamIdoing (talk) 19:30, 23 June 2014 (UTC)
I've noticed this, and occasionally thought it would be useful, but given that I can reload the page as WhatamIdoing notes, and that is extremely easy, I can't justify any time spent to find a solution.

At Panama Canal Railway, and presumably in other places too, there is a link to an "interactive version" of a map that is presented as an internal Wikipedia link but actually dumps out to an external commercial ad-driven site (sharemap.org). Behind the scenes, this link seems to invoke a special "sharemap"-specific syntax, which I know nothing about. Nevertheless, this unexpected behaviour needs fixing, I suggest, by changing this "sharemap" thing to show as an external link. 86.179.0.72 (talk) 20:46, 23 June 2014 (UTC)

Average edits per day

Can you please add "Average edits per day: " (calculated by "number of edits"/"number of days since account registration") in Special:Preferences under "General" next to "Number of edits: "? Average edits per day are good to know for anyone who strive after Wikipedia:Service awards. --David Hedlund (talk) 19:56, 23 June 2014 (UTC)

You can see that in the X!'s Tools (look at the "Ø [average] number of edits per day" in the top section) – https://tools.wmflabs.org/xtools/ec/?user=David%20Hedlund&project=wiki.riteme.site 2Flows (talk) 20:19, 23 June 2014 (UTC)
Thank you! @2Flows: --David Hedlund (talk) 06:16, 24 June 2014 (UTC)
How would this be useful? I can some use for total edits and length of time, but not the overall average. ~ J. Johnson (JJ) (talk) 20:41, 23 June 2014 (UTC)

Translation of earliest recorded cuneiform advice into other languages?

Please let me know where I can find help translating Siduri's Advice (Fill your belly. Day and night make merry. Let days be full of joy, dance and make music day and night. And wear fresh clothes. And wash your head and bathe. Look at the child that is holding your hand, and let your wife delight in your embrace. These things alone are the concern of men) from the Epic of Gilgamesh into other languages? I have current drafts for many languages at: Talk:Epic_of_Gilgamesh#Translation of Siduri's advice into other languages but I do not know if these translations are correct.

Once I have the correct translation confirmed, I/we intend to include the translation in an image that can be used on the Epic of Gilgamesh and Siduri wikipedia pages for that language.Gilgamesh-for-the-World (talk) 22:39, 23 June 2014 (UTC)

@Gilgamesh-for-the-World: The editors at Wikipedia:Reference desk/Language may well be able to help you. — Scott • talk 15:13, 24 June 2014 (UTC)
Wonderful, thank you Scott.Gilgamesh-for-the-World (talk) 21:28, 24 June 2014 (UTC)

Signing posts

Why should I have to remember to append my posts with the clunky ~~~~? Why can't that be added automatically? Eric Corbett 20:18, 21 June 2014 (UTC)

Because sometimes, what you post isn't all new, but a correction to something that you added earlier. Then there are new "posts" to talk pages which should never be signed, such as the addition of a template at the top, or when a thread is moved from the wrong venue to the correct one. --Redrose64 (talk) 20:24, 21 June 2014 (UTC)
Curious how many objections are raised when any change is proposed. I don't end my emails with ~~~~, so why should I have to end my posts with that detritus? Wouldn't at least a step into the 21st century make life a little easier for new editors? Eric Corbett 20:35, 21 June 2014 (UTC)
Wait. How does SineBot know when to sign unsigned "posts" then? Dustin (talk) 20:40, 21 June 2014 (UTC)
Quite. But maybe that's another one of those secrets that we mere peons are not privy to. Eric Corbett 20:43, 21 June 2014 (UTC)
To find out how SineBot (talk · contribs) decides what to sign and what to leave alone, have you considered asking Slakr (talk · contribs), the bot's operator? --Redrose64 (talk) 22:32, 21 June 2014 (UTC)
Why should I do that? You argued that it would be impossible to make such a simple change, and when faced with evidence to the contrary you try to put the onus back on me. Why don't you get off your arse instead? Eric Corbett 22:52, 21 June 2014 (UTC)
@Eric Corbett: "Why should I do that?" You don't need to: my reply was directed as much at Dustin V. S. as yourself: Dustin was the one who asked 'how does SineBot know when to sign unsigned "posts" then?', and you were the one who said that it was 'one of those secrets that we mere peons are not privy to' - I was merely offering a means by which you could find out. "You argued that it would be impossible to make such a simple change" - I said nothing of the sort, and certainly didn't use the word 'impossible': I offered three possible scenarios as to why it might be difficult. "faced with evidence to the contrary" - since Slakr seems to have overcome that difficulty, I say kudos to Slakr. "you try to put the onus back on me" - all I did was suggest that you ask Slakr how SineBot decides what to sign and what to leave alone. "Why don't you get off your arse instead?" - I don't care how SineBot works. I might not always sign my posts, but I fail to sign less than 5% of the time. SineBot does a pretty good job, all things considered; I'm not complaining about it. --Redrose64 (talk) 23:43, 21 June 2014 (UTC)
I would actually consider asking Slakr about it, but since you have already placed a user page link above, I do not think it will be necessary. Dustin (talk) 23:53, 21 June 2014 (UTC)
The actual answer is that there would be no point spending time changing the software, since in a couple of months WP:FLOW goes live, talkpages as we know them become a thing of the past, and signing talkpage posts becomes one with Nineveh and Tyre. If you want to see what talkpages will look like come Christmas, take a look at Wikipedia talk:WikiProject Hampshire which has the dubious honour of having been chosen to trial the new-look software. And yes, everyone except the WMF thinks that font size is ridiculously large, but unfortunately someone at the WMF read something, somewhere, that says people work better in giant boldface fonts so it ain't changing. 80.44.183.160 (talk) 21:07, 21 June 2014 (UTC)
Wikipedia talk:WikiProject Breakfast is where it's really at. Besides, user talk pages will still around for a while, possibly forever if enough people kick up a stink and climb the Reichstag. I'm curious where in the morass of documentation you say Flow goes live in a couple of months - I thought it would be limited rollout only for 2014. BethNaught (talk) 21:12, 21 June 2014 (UTC)
The rollout date used to be "Mid to late 2014". I didn't realise Maryana had quietly changed the date to 2015 a couple of months ago. 80.44.183.160 (talk) 21:21, 21 June 2014 (UTC)
I don't like the thought of not being able to use a custom signature. That would mean that regardless of what I tried to do, the "V. S." would end up being included. The other stuff sounds helpful, but... Dustin (talk) 21:35, 21 June 2014 (UTC)
I think I read somewhere that there will be a preferred name setting, but I have no clue if that is still on the cards or even where I read it. BethNaught (talk) 21:40, 21 June 2014 (UTC)
Why not just standardise the way that signatures appear? Who needs all the silly upside down stuff for instance? Eric Corbett 21:43, 21 June 2014 (UTC)
Flow will be just like VE, an opt-out disaster, and for much the same reasons. Eric Corbett 21:47, 21 June 2014 (UTC)
Yep, exactly. --AmaryllisGardener talk 23:53, 21 June 2014 (UTC)
I am going to be waiting in the enlistment line to protest. Those two Flow project test talk pages are just the saddest examples of design imaginable. Those dogs need to be taken to the pound. Fylbecatulous talk 12:58, 22 June 2014 (UTC)
I'm surprised there isn't a ban on bad-mouthing Flow. Anyway, if anyone really objects to tildes, they can always click the pencil-and-wiggle up at the top, like this: --Peridon (talk) 17:39, 22 June 2014 (UTC) which gives you a dash for free along with the tildes.
But why should you have to click anything? Why isn't it automatic? Eric Corbett 21:51, 22 June 2014 (UTC)
It's probably this simple: you can edit your posts later. Sites where you have no option to correct a post can auto-sign - no change possible except by moderators. Here, you can post in two parts of a thread in one go - with auto sign, where's it going to sign? It's going to look really clunky if you correct 'fro' to 'for' and find a new sig in the middle of a sentence - or even two or three if you missed things while correcting the first time. Peridon (talk) 10:08, 23 June 2014 (UTC)
With all due respect, that's a pretty silly objection. Eric Corbett 17:12, 23 June 2014 (UTC)
How is it silly when we often have a legitimate need to amend our posts? BethNaught (talk) 17:27, 23 June 2014 (UTC)
(edit conflict) Not an objection - a likely explanation. I can see quite some difficulty in auto-signing on a talk page. Listing in a History list is easy - but, as I pointed out, do you really want every addition of a missing bracket or correction of hte or yopu to have a sig attached on the page? And when there is more than one location for these corrections, which gets signed? The lot, or none? I would think THEY would have brought it in if it could be done easily. The best attempt seems to be SignBot - and that is hit and miss. I'll put a note at Technical to see if they have any ideas. Peridon (talk) 17:39, 23 June 2014 (UTC)

Someone could probably write a MediaWiki extension that automatically signs posts when a user saves a page, using much the same algorithm that SineBot does. However, a) due to the nature of wikitext, it wouldn't be perfect, and b) fairly soon we will have Flow, which will always sign posts correctly. There are a lot of things that we can't do because we are tied to wikitext, and perfect post-signing is one of them. — Mr. Stradivarius ♪ talk ♪ 02:07, 24 June 2014 (UTC)

@Eric Corbett: Discussion pages aren't forums, nor vice versa. Numerous formats exist for discussion pages and afford more flexibility than forums (i.e., no need for specialized programming knowledge) to make them whatever they need to be for improving the encyclopedia. Given this freedom, the general convention (i.e., the guideline) is that if someone will likely want to know who added (or changed, or WP:REFACTORed, etc...) something, you mark it in a way concordant with whatever format is in use on that discussion page. --slakr\ talk / 06:03, 24 June 2014 (UTC)
One of the things that's always puzzled me about WP is the constant eagerness to find reasons not to change anything. Eric Corbett 11:25, 24 June 2014 (UTC)
I hope Slakr weighs in. I raised this question years ago, and was told it was harder than one thinks, for reasons that have been mentioned here. However, sinebot seems to have figured it out, so I'm interested in learning why it is that sinebot can do it right, not making the mistake or re-signing when you re-edit your own post, not making the mistake of signing when you post at pages where you aren't supposed to sign, etc. yet we are supposed to believe that a user can figure out the coding, but a developer cannot. Something doesn't add up. If Flow were really two months away, it would be one thing, but Flow seems to be like Brazil, the country of the future, and it will always be so.
I didn't know that, but was noticing it wasn't being signed, and wondering if there were some hurdle. Oh well, takes away a bit of the point, but not all of it.
@Eric Corbett: Now, I was under the impression that the techie side both of en-wiki and WMF were usually getting slated for TRYING to change things that worked quite well before (Vector, Visual Editor, Flow, etc - OK, Vector does work, but for me it's a lousy bit of design and I stick to Monobook). Peridon (talk) 10:52, 25 June 2014 (UTC)

Stop the "citation needed" nerds

NOTE: The following was entered 12 hours ago, under Policy. I now understand that this is the correct location for this proposal.

I'm a well-educated, occasional editor of Wikipedia articles. I'm also a constant reader of Wikipedia, and appreciate greatly the vast areas of knowledge available easily and in depth.

Now for my complaint and policy suggestion: it appears that there are a number of editors who liberally sprinkle "citation needed" entries generously in serious articles, written by serious people. I have read many of these articles, where the author is clearly knowledgeable and authoritative on the subject matter - only to have the article put in question by all these "citation needed" entries. Enough. First of all, not all knowledge can be cited. In law, everything depends on precedent - but not for all knowledge.

When a fact is stated, a citation is not always needed. The nerds that go around devaluing others' work by entering "citation needed" everywhere do no one a service. They should be limited in this exercise by a change of Wikipedia policy. My suggestion: if they feel one is needed, then a comment should be made to the article's author or to an appointed editor.

My firm belief: these "citation needed" entries cast discredit on Wikipedia itself, and unnecessarily so.

NOTE RE MY FIRST SUBMISSION: I was surprised to see that a vehement response contra was entered within 5 minutes of my original submission. Although polite on the surface, its content was arrogant, dismissive and insulting - as if there was no possible value to this proposal. My belief is that the respondent was indeed one of the above-referenced citation-needed nerds: his response - literally within 5 minutes, no exaggeration or minimization - suggests one who remains, constantly watching, in the Wikipedia firmament and dismissing those who disagree with his worldview.

This idea is a serious one about our editing privileges, which can be used as a cudgel by those preferring form over substance. Wikipedia should be about the quality of its content, not (necessarily) the adherence to particular editing behaviors.

Personally, I am disappointed when I see an excellent article cheapened by unrealistic "citation needed" notations. These editors clearly are not knowledgeable about the subject matter, but can still carp over their perceptions of poor source-citation. There should be a balance here.— Preceding unsigned comment added by Oleh77 (talk • contribs) 22:10, 27 June 2014

It would be helpfull if you provide a link to the submission, so we can read what happened,a link to the mentioned article would be nice too Mion (talk) 22:18, 27 June 2014 (UTC)
First submission was Wikipedia:Village_pump_(policy)#Stop_the_.22citation_needed.22_nerds. I left a parody response (that earnestly explained policy) at Wikipedia:Village_pump_(policy)#Stop_the_.22unsourced_claims.22_fools.
We must never rely on supposed authority because on the Internet, nobody knows you're a dog -- but almost anyone can verify a cited source.
Now, if you were to say "citation needed tags should not be placed after a sentence when the citation for that part is later in the paragraph," I'd agree. But no citation needed tags? No, that's just being more concerned with article appearance instead of academic integrity.
If you don't want to be disappointed with citation needed tags, and you want people to just accept what's in articles, and you don't want Wikipedia to be a scholarly laughing stock -- cite your bloody sources. If you can't cite a source because you don't have a source (the code's easier than falling off a log), Google Books is a good place to start. If you simply cannot find any sort of source to justify a statement -- then why should we trust it? Ian.thomson (talk) 22:39, 27 June 2014 (UTC)
(edit conflict) This has been fairly thoroughly addressed already in the forum in which you first wrote about it. You don't need to ask again here. Regarding the speed of response to your original post, you posted it on a page intended for discussions on Wikipedia policy with more than 2,500 editors watching, and you're upset that your response was answered quickly by policy wonks? Ivanvector (talk) 22:39, 27 June 2014 (UTC)
When I write an article or some material for an existing article, and then someone adds a citation needed tag to a claim for which I failed to supply onea citation, that absolutely does not devalue the quality of the writing. It rather improves the quality of the writing, because it prompts me to correct my lapse and add the citation. --Atethnekos (Discussion, Contributions) 23:20, 27 June 2014 (UTC)
@Oleh77: Please wrap the original discussion (or this one, doesn't really matter) in {{discussion top}}/{{discussion bottom}} - per WP:MULTI the same discussion shouldn't occur in more than one place. --Redrose64 (talk) 10:31, 28 June 2014 (UTC)

Inactive interwiki bots

A proposal to de-authorize a batch of interwiki bots that have been idle for years is in progress at WP:BON#Bot that are inactive for the last 2-4 years and may lose bot flag. If you are interested in the discussion, please join there. Thank you, — xaosflux Talk 12:37, 28 June 2014 (UTC)

Free semi-auto edit bots for GNU/Linux

"AutoWikiBrowser (often abbreviated AWB) is a semi-automated MediaWiki editor for Windows XP and later, designed to make tedious repetitive tasks quicker and easier. (AWB also functions reasonably well under Wine on Linux but this is not officially supported.)" - https://wiki.riteme.site/wiki/Wikipedia:AutoWikiBrowser

I cannot find a single software for GNU/Linux in https://wiki.riteme.site/wiki/Wikipedia:Tools/Editing_tools#Semi-auto_edit_bots

Are there any free software development in progress that might not be on that list? --David Hedlund (talk) 06:18, 24 June 2014 (UTC)

David, PyAutoWikiBrowser is meant to be a cross-platform version of AWB which is written in Python; however, it's currently under development (as of this post). APerson (talk!) 00:26, 30 June 2014 (UTC)
In fact, it's been under development since at least 2009 (when the project namespace page for it was created) or 2007 (when the SourceForge project was created). APerson (talk!) 00:31, 30 June 2014 (UTC)
plus Added to Wikipedia:Tools/Editing tools. Thank you! --David Hedlund (talk) 06:28, 30 June 2014 (UTC)

Add an [edit] link for the bottom section of a page

The feature "Add an [edit] link for the lead section of a page" exists in Preferences - Gadgets (https://wiki.riteme.site/wiki/Special:Preferences#mw-prefsection-gadgets), under Appearance. However, "Add an [edit] link for the bottom section of a page" does not exist and a consequence people click on [edit] for the last section which typical is "External links" or "References", titles that are inserted automatically in the edit summary (eg /* References */). People do not care to remove this from the edit summary all the time they add templates and categorys. An edit link for that would solve this. --David Hedlund (talk) 03:53, 26 June 2014 (UTC)

Ironically, you created this section by editing the then-last section and kept /* Free semi-auto edit bots for GNU/Linux */ as your edit summary. I agree it may be odd that navigational templates and categories are actually in the last section of an article, "External links" usually, though for discussion pages there's a handy solution to a similar problem: the new section button.
I doubt whether it's technically possible to add this "edit bottom section" button, since categories and navboxes aren't actually in a separate section. The software would have to draw a line between the content that "belongs" in the last section ("External links", "References", or the last prose section if an article doesn't have either) and the stuff that's there because it should be at the bottom of the article. An easier solution would be to create an actually new section for cats/navboxes called "Navigation" or similar, or to stick navboxes into the more logical "See also" section (they contain internal links after all). SiBr4 (talk) 08:15, 26 June 2014 (UTC)
  • Let me see if I can understand this request, you want a link somewhere on the page to edit the last section of the page? Do you actually want to edit the last section, or do you just want to edit the invisible section below the last section of content that contains the categories and defaultsort and other assorted technical templates? Do you want your link at the top of the page or the bottom of the page? Do you want it to edit the existing last section, or create a new section? All that the gadget above you speak of does is at a link in the top section which will reload the page with &action=edit&section=0 attached to the URL. If you want to make a new section, it wouldn't be hard at all to make a similar link that adds &action=edit&section=new. If you want to edit the existing bottom section, it wouldn't be all that hard to create a script that counts the number of sections on the page and opens the edit window with the last counted section in there (this might be useful if we put that link at the top of the page in some cases I suppose, or you could just enable section editing and scroll to the last section and click that link). If you want the technical stuff that is after the last section, that can't really be done because of the way the software works. Let me know exactly what you want to be able to do (I don't really care about why, just technical details), and I might be able to write you up a userscript. — {{U|Technical 13}} (e • t • c) 10:57, 26 June 2014 (UTC)
    • BTW, "If you want the technical stuff that is after the last section, that can't really be done because of the way the software works." that is something that the mobile team has been struggling with as well. There is not really a solution, other than perhaps very long term making some fundamental changes to the core software or to how community uses the software, but there are no plans on that front yet. —TheDJ (talk • contribs) 11:07, 26 June 2014 (UTC)
@TheDJ, SiBr4, and Technical 13: A temporary solution that came to my mind would be to add a an edit link at the bottom of the page that actually edit the last section of the article but puts /* End of article */ in the edit summary. --David Hedlund (talk) 06:37, 30 June 2014 (UTC)
@David Hedlund: could you please describe what you consider to be the "last section" as requested by Technical 13 ? —TheDJ (talk • contribs) 08:36, 30 June 2014 (UTC)
@TheDJ: The last ==Section==. It can be detected with simple programming. --David Hedlund Sweden 08:59, 30 June 2014 (UTC)
So you propose renaming (most of the time) the See also or References or External links section into "End or article" in the edit summary ? That seems as wrong to me as the status quo is wrong. —TheDJ (talk • contribs) 09:04, 30 June 2014 (UTC)
No. He seems to be suggesting that the section name stays exactly the same, but when you click on the "edit end of article" button, instead of having /* External links */ or whatever, the edit summary has /* End of article */. They both edit the exact same content, and the section name never changes, it's just the default edit summary that differs. VanIsaacWScont 08:18, 1 July 2014 (UTC)
If the section that is really being edited is "External links", the edit summary must begin "/* External links */" otherwise the section linking in page history, user contribs, watchlist, recent changes, etc. will break. In case you've never noticed that section linking, have a look at the history for this page, look for the opening parenthesis of the edit summary and the little arrow → which often comes immediately after that but before the light grey text which starts the edit summary, click that arrow and see where you end up. It should be the section whose name matches the light grey text. If I were to edit the last section of Foobar, and save an edit summary like this:
/* End of article */ added category
it would show in the page history, etc. as
(→End of article: added category)
Try clicking that arrow. It goes to the article, but not to the right section - in fact it goes to the very top, since the anchor does not exist. Now try this one:
(→External links: added category)
which goes to the section where the categories are held. Therefore, the true name of the section that was edited must appear between the /* */ markers. --Redrose64 (talk) 10:46, 1 July 2014 (UTC)
Wouldn't it possible to give an element near the bottom of the page the id "bottom", so /* bottom */ results in a link to that (much like how /* top */ already works for edits to the lead)? SiBr4 (talk) 10:59, 1 July 2014 (UTC)
We've sort-of got one already: every Wikipedia page, in every namespace, includes the tag 
<div id='catlinks' class='catlinks'>
which marks the start of the categories box. Notice the attribute id='catlinks': an id that occurs on any element within the <body>...</body> of the page is valid as a URL fragment (provided that it is also unique within that HTML doc). Hence, Wikipedia:Village pump (proposals)#catlinks takes you to the category box on this page. However, if there are no categories, it's a bit different: 
<div id='catlinks' class='catlinks catlinks-allhidden'>
The additional class catlinks-allhidden is styled display: none; which means that the box is not drawn, although it is present in the page source. Some browsers won't take you to an undisplayed element, instead they leave you at the top of the page; for example, use Firefox or IE to view Wikipedia talk:Village pump (proposals)#catlinks - you don't get taken to where the cats would have been. --Redrose64 (talk) 13:56, 1 July 2014 (UTC)
I'd be very cautious advising people that #catlinks is at the bottom, as it is not in the Cologne Blue skin where categories are at the top of the page instead of the bottom. #footer should work in all skins however. — {{U|Technical 13}} (e • t • c) 14:12, 1 July 2014 (UTC)
Yes, footer is in all pages, but for a short page with a long sidebar (e.g. a stub with lots of interlanguage links), it can take the whole of the article content off the top of the screen. --Redrose64 (talk) 15:59, 1 July 2014 (UTC)

A lot of vertical navboxes are interfering with each other, infoboxes and lead images, making many articles extraordinarily messy. horizontal navboxes at the bottom of the articles are much better and don't interfere with readibility or layouts. I propose that we convert all vertical navboxes into horizontal ones. Aditya(talk • contribs) 18:18, 2 July 2014 (UTC)

Uh, no. This is bad policy. If you think a particular navbox should be converted, go ahead and do it. But some really need to be be available next to the information to which they pertain, and that means a vertical navbox that can be put to the right of the applicable section(s). VanIsaacWScont 20:20, 2 July 2014 (UTC)
Navoboxes are for articles, and generally not sections. They are almost never put to the right of the applicable section(s), rather they are put at the top or bottom of articles. And, what to do when it's not a particular navbox, but about tons of particular navboxes? Are expecting a concerned editor to discuss it out with dozens and dozens of wikiprojects one at a time? Aditya(talk • contribs) 03:27, 6 July 2014 (UTC)

Separate discussion from project tags

On most of our talk pages, there are two elements - a series of boxes about the article (Wikiprojects, deletion discussions, etc) and the actual discussion. I would suggest creating an "About:" namespace, which would contain the various project tags (in a few cases the talk FAQ would simply become the About page) and the Talk pages would be discussion only. Several advantages: First, if there is no discussion, discussion will be a red link, as opposed to now when the wikiproject tags turn it blue. Second, it will be easier to identify which pages should get wikiproject tags added (again, thanks to a red link). Third, it gives a place for edit notices or long FAQs for pages that need this sort of thing. This will also make implementing Flow a lot easier, since it would no longer need to accommodate these tags. I could see the Wikipedia template also having a Wikipedia About, while Template documentations could be moved to a Template About. Implementation could easily be done by a bot. Comments? Ego White Tray (talk) 05:12, 3 July 2014 (UTC)

I think WP:Flow already has a plan for this (a separate space at the top of the discussion page). In general, there would be some value to having metadata on a separate page (like categories: why should they be typed at the bottom of text, and disappear with any random blanking, instead of something inherently associated with the page itself?).
How would you handle FAQs and notices that people really need to see before engaging in any discussion? WhatamIdoing (talk) 05:41, 3 July 2014 (UTC)
I suggest you keep edit notices like we have them now, and also transclude them to the about page. Ego White Tray (talk) 14:30, 3 July 2014 (UTC)
As far as flow, I've seen the testbed at WP New Hampshire, and the tags look flaming ugly. Ego White Tray (talk) 14:32, 3 July 2014 (UTC)
It's not New Hampshire (U.S. state) but Hampshire (English county). --Redrose64 (talk) 15:18, 3 July 2014 (UTC)
Wait, a minute - you mean there is an old Hampshire? :) Ego White Tray (talk) 23:07, 3 July 2014 (UTC)
Yep. My brother lives there. WikiProject New Hampshire still has a sensible talk page, if a little quiet. --Redrose64 (talk) 23:26, 3 July 2014 (UTC)
WP:Edit notices appear when you start to edit a page. FAQs appear when you read a talk page. If you put the FAQs (e.g., "Q: Why does this page have the wrong name? A: Because it's actually the right name.") on "About:Example", how will people who are at "Talk:Example"see them? And if you're putting the FAQs on both, then aren't you defeating the goal, which you state as "Talk pages would be discussion only"? WhatamIdoing (talk) 18:32, 4 July 2014 (UTC)
Well, I'm proposing the big picture but we can discuss details. We certainly could transclude the edit notice to both the about and talk pages if there is agreement to do so. Nothing about my proposal prevents that. The point of the about is to tag articles and explain why the article is the way it is. If you want to put a simple link to the about page saying "read this first" on the talk page, I suppose we could do that. Again, this is details, not the overall concept. Ego White Tray (talk) 05:01, 5 July 2014 (UTC)
See also mw:Requests for comment/Associated namespaces. Helder.wiki 18:44, 4 July 2014 (UTC)
Partly off topic comment: The more I see of Flow, the worse it seems to get. If that and Visual Editor become compulsory, I'll very likely be saying goodbye. Peridon (talk) 14:39, 7 July 2014 (UTC)

Proposed template contest

See User:Casliber/Template blitz and discuss on talk - all input appreciated. Cas Liber (talk · contribs) 22:33, 7 July 2014 (UTC)

Proposal to define aliases, e.g. UT for the "User talk" namespace

There was pretty strong consensus in this archived pump discussion but it was never officially closed or acted upon, just archived. Would an admin revive, act on and close it - I'd say there was consensus for the UT alias.

The proposal is/was to define "UT:" as an alias for the User talk namespace.

WP:Namespace warns:

In the search box, an alias is a real namespace, resulting in a search for the pagename in its namespace, but the "pseudo-namespace:pagename" search is in mainspace, not its pseudo-namespace. For example, the search "H:S" will not search Help.

I think that a number of the pseudo-namespaces should be 'upgraded' to true aliases. Users should be able to type T:quote into search, and get straight to Template:quote; likewise for T:fv, and the like. I'm not aware of any significant negative side effects of the existing 6 aliases. 4 of them probably only exist for historical reasons; they're essentially redirects, though I bet even the least used one is used many times. Why not add to WP and WT? UT seems like a great idea. U, not so much (User Talk pages are edited and accessed far, far more often than User pages.) I'd love to see T added; I'd use it a lot and 'Template' is a lot to type. I don't see much downside to converting the lot of them - T, CAT, MOS, P, and H. (And why not TT, CATT, MOST, PT, and HT?) Can a regular admin create an alias? --{{U|Elvey}} (t•c) 00:00, 9 July 2014 (UTC)

That discussion was four years ago. Rather than close or act upon it now, it would be better to start afresh.
The existing shortcut prefixes WP: and WT: are not redirects - they are aliases, coded into the MediaWiki software to be exactly the same as the full namespaces Wikipedia: and Wikipedia talk. If I put a link here to [[WP:Village pump (proposals)]] it comes up black and bold (WP:Village pump (proposals)) because it's a direct link, and doesn't go through a redir. Of the various new aliases that you suggest:
  1. T: does not currently have a defined meaning, but please see Wikipedia:Village pump (idea lab)/Archive 14#A template redirect? regarding that
  2. tt: is an interlanguage link prefix for the Tatar Wikipedia, and since these prefixes are case-insensitive, TT: is as well
  3. MOS is unsuitable for a namespace alias, since the true names of pages linked by the MOS: prefix are in more than one namespace - most are in Wikipedia: space, but many are in Help: space. An alias can only map to one true namespace.
  4. MOST is unsuitable for a namespace alias for the same reason as MOS:
  5. P: like T: is ambiguous - it could mean Project: or Portal: - compare Project:Trains with Portal:Trains.
  6. PT: and HT: cannot be used for the same reason as TT: - pt: is the Portuguese Wikipedia, and ht: is the Haitian Creole Wikipedia
  7. The five others that you mention - CAT: CATT: H: U: UT: - are not currently defined; but as mentioned above, aliases are coded into the MediaWiki software, and altering that is not something that an admin can do - it would need a feature request at bugzilla:. --Redrose64 (talk) 10:50, 9 July 2014 (UTC)


Kudos for looking into that, Redrose.
Re. #1: I could find no good reason not to make T an alias; the fact that "Several T:s are used as shortcuts" doesn't seem to pose a problem, AFAICT. Am I missing something?
Re. #2: That seems to rule out TT.
Re. #3: That seems to rule out MOS.
Re. #4: Do you see that as a big problem? How so?
Re. #5: That seems to rule out PT and HT. --{{U|Elvey}} (t•c) 23:15, 10 July 2014 (UTC)


Namespace aliases are configured through $wgNamespaceAliases. --  Gadget850 talk 17:39, 9 July 2014 (UTC)
Thanks, Gadget! So there's a roadmap for moving forward with CAT: CATT: H: U: UT: and perhaps T: and P:.--{{U|Elvey}} (t•c) 23:15, 10 July 2014 (UTC)

Cleanup after Project Tagger

I have noticed that the now-abandoned Project Tagger tool (which could be used to add WikiProject templates to article talk pages) did the following things:

  • Added a "quality" parameter instead of a "class" parameter
  • Added new WikiProject templates above existing WPBIO templates (which is bad, right?)

See this edit as an example.

On the assumption that as a result of the use of this tool there are possibly hundreds of article talkpages with misplaced/malformed WikiProject templates (this user alone used the tool to tag dozens of talk pages, many/most of which are still the current revision - no reflection on that user, by the way; I assume they were just using the tool in good faith), would it be worthwhile (getting a bot to) go through and change all the "quality="s to "class=", and move any existing WPBIO template to the top?

Or would that not be worthwhile, because:

  • WikiProject Tagger only added an empty "quality" parameter (i.e. "quality=") and presumably if/when someone goes to assess the article, they will change "quality=" to "class=xxx", and/or
  • there are already bots which go around moving WPBIO templates to the top (is that true?)

Thanks. DH85868993 (talk) 03:07, 10 July 2014 (UTC)

@DH85868993: Moving WPBIO above other WikiProject templates is important when |living=yes to ensure the BLP box appears at the top of the talk page. It's not so important if the WikiProject templates are within {{WikiProjectBannerShell}}. I'm now running my BattyBot against Magiciandude's edits to see where {{WikiProjectBannerShell}} can be added, and changing |quality= to |class= in the process (e.g. See the revised Talk:Roberto Torres). Magioladitis and Josve05a have been doing a lot of cleanup on talk pages, so maybe they have some input too. GoingBatty (talk) 04:34, July 10, 2014 (UTC)
Thanks, @GoingBatty:. This list indicates other possible users of the tool, although it's not a complete list (note that Magiciandude is not listed). I think Project Tagger always includes "Project Tagger" in the edit summary, so that might be a way to find other edits made using the tool? DH85868993 (talk) 04:40, 10 July 2014 (UTC)

I've been using User:Kephir/gadgets/rater recently, and I'm pretty happy with it. WhatamIdoing (talk) 23:32, 10 July 2014 (UTC)

This tool is amazing and I recommend it to everyone :-). For best effect, combine it with the "Display an assessment of an article's quality as part of the page header for each article." option in Preferences > Gadgets. Andrew Gray (talk) 21:06, 12 July 2014 (UTC)

Drafts and sandboxes can be visible in mainspace categories

If you include a category template anywhere, for instance in a user page or an article submitted for creation, then that "anywhere" will be visible in the referenced category. I consider this being a bug.

A similar, but reverse phenomenon, is that inline citation popups don't work in user space pages and articles submitted for creation. Highly annoying and costly in time for developing well-referenced articles. YohanN7 (talk) 01:11, 16 July 2014 (UTC)

@YohanN7: Not quite sure I understand your first point about "category templates". If you're referring to a category link such as [[Category:Living people]], then you may be interested to know that my bot comments out article categories from pages in userspace and draftspace. GoingBatty (talk) 02:11, 16 July 2014 (UTC)
If you have a local copy of an article you are working on, then it will be visible in any category you list in your local copy of the article. The same applies to articles submitted for creation. (This can even be embarrassing if your local copy is crap, since people might go and look at it).
It's nice that you have a bot cleaning up, but the template shouldn't kick in in the first place. YohanN7 (talk) 02:25, 16 July 2014 (UTC)
@YohanN7: There are categories that are appropriate for user pages and AfCs. I don't think Mediawiki is smart enough to differentiate an article category vs. a non-article category. GoingBatty (talk) 02:34, 16 July 2014 (UTC)
Okay, I can live with it. Any hope for popup citations working in sandboxes/user pages? I can't see why they shouldn't work. YohanN7 (talk) 03:01, 16 July 2014 (UTC)

Idea for specialized blocks

I have posted an idea at Wikipedia:Village pump (idea lab)/Archive 14#Specialized blocks for a proposal which I may soon present here. I am not sure if it is already ready to be put forth though, so I have posted it there. Dustin (talk) 02:18, 16 July 2014 (UTC)

Yeah, this sounds like a WP:Wikilawyer's dream, and seems to have no productive use. Editors are either a part of this community, and hence they need to follow any topic/page/interaction bans that the community has established under their own recognizance, or they act outside of the this community, and we block them from participating contributing at all. Technical issues aside, this doesn't look like something that should be pursued. VanIsaacWScont 02:34, 16 July 2014 (UTC)
I am afraid that I do not understand your reasoning. Why should someone who cannot keep him/herself off of a certain topic which he/she was banned from be left only with the option of indef block? That kind of thing can only cause harm to Wikipedia. If that person doesn't think he or she can do so, he/she should be able to request that him/herself to be blocked from x pages as a better way of enforcing bans. In that way, Wikipedia can trust that this editor no longer causes any problems in one area of the encyclopedia while remaining constructive in another. An indef block destroys the chance for any constructive contributions in or outside of that topic ever again. And that isn't even addressing the other two main points. Please reconsider. Dustin (talk) 02:47, 16 July 2014 (UTC)
In any case, I just brought this topic up to discuss whether or not that proposal has been crafted well enough to be presented here, not to discuss the idea in practice. The section for discussing will simply be under the name "Specialized blocks". Dustin (talk) 02:52, 16 July 2014 (UTC)
A system of specialized blocks would not be helpful. An editor who is so passionate that they cannot voluntarily follow the terms of a topic ban is not a good fit for Wikipedia as they will inevitably find other ways of promoting their cause due to their lack of self-restraint. A collaborative community is required and that involves self-restraint. I know it's just an idea at this stage, but I'm commenting here in case it ever becomes a proposal. Johnuniq (talk) 04:03, 16 July 2014 (UTC)
What about my third bulletpoint? Dustin (talk) 04:11, 16 July 2014 (UTC)
If someone "cannot keep him/herself off a certain topic which he/she was banned from", then by their actions they have said that they do not consider themselves a member of this community. There is no halfway on this where someone who flagrantly flaunts the restrictions this community has put in place in order to protect itself from them can be trusted in any way. Disdain for the norms of this community isn't restricted to subject areas. If you consider yourself to be above the rules and restrictions this community has established to protect itself from you, then there is no area in which you can be trusted. We only leave the talk page open so that you can indicate your commitment to abiding by the standards of this community. Now, I'd be happy to support expansion of the talkpage access to all pages in the User talk:<username> area, if you think there is a recurring need for that kind of access (ie, that the point #3 example is not a one-off exception). But fragmented blocks can only be used to implement schizophrenic policy, and that's not really in anyone's interest, except for those who violate topic/page/interaction bans, who would try to wikilawyer their way out of the consequences of their self-professed antipathy for this community. VanIsaacWScont 05:29, 16 July 2014 (UTC)

Since this functionality does not currently exist in MediaWiki, there is also the question of who would implement this. There is currently no team at the Wikimedia Foundation who could own this work, so you'd probably need to find a random developer to implement this, too. --Dan Garry, Wikimedia Foundation (talk) 05:55, 16 July 2014 (UTC)

Hmm... well, I guess that would be an issue with my plan... in any case, thank you for the reply. At the very least, if the is ever implemented, regardless of who does so, I would support allowing blocked users to have single-page block exemptions (i.e., apart from talk page edits, a user could edit one other page if required such as the Administrator's noticeboard). Dustin (talk) 06:00, 16 July 2014 (UTC)

Why is this being discussed in multiple places? The original is Wikipedia:Village pump (idea lab)/Archive 14#Specialized blocks. --Redrose64 (talk) 12:32, 16 July 2014 (UTC)

RfC: Should deprecated/invalid/unsupported HTML tags be discouraged?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is currently no consensus to force people to not use any of the deprecated HTML tags, in either articles or signitures. However, there does seem to be support for an edit filter, or other technical measures, to log (not warn) users when these tags are used, to allow editors to give users some advide about why they should be used, and what the alternative is. The opposes mainly seem to centre around the fact it is the system dev's problem, and not induvidual Wiki's. However, if the devs suddenly decide to no longer support these tags, and we are caught unawares, all sorts of havoc may reign supreme. Therefore, I feel the overall consensus of this thread is to take small steps (eg. advising people to change sigs), in order to start to prepare for the transition. --Mdann52talk to me! 08:05, 17 July 2014 (UTC)
Background
There has recently been some discussion on Wikipedia talk:Signatures#"Font" Deprecated? specifically about if "* Avoid deprecated markup such as the <font> tag." should be in the WP:SIGAPP section of our police on Wikipedia. Because of this disagreement, and based on a comment from that discussion by Redrose64, which I quote, the FONT element has been deprecated since at least HTML 4.01 (24 December 1999); in the present HTML 5 spec, it is marked as obsolete., I started doing some research as these elements have been deprecated nearly fifteen years now. Visiting https://developer.mozilla.org/en-US/docs/Web/HTML/Element/font the first thing I'm struck by is a big red box that says "Obsolete: This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.", reading just a little further down the page, there is a usage note that reads:

Do not use this element! Though once normalized in HTML 3.2, it was deprecated in HTML 4.01, at the same time as all elements related to styling only, then obsoleted in HTML5.

<basefont> has the same Do not use this element! warning. <acronym>, <big>, <dir>, <strike>, and <tt> also all have the big red box that says "Obsolete: This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it." and even <center> has a big grey box that says "Deprecated: This feature has been removed from the Web. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time." Heck, even w3schools has a big red warning that these tags are not supported or deprecated (example).
Question
Should we technically discourage new instances of these HTML elements that are "in the process of being dropped" by major browsers? 02:43, 13 June 2014 (UTC)

Discussion (deprecated elements)

  • What counts as a new use? If I edit a section of an article that has some obsolete HTML markup in it, but I don't touch the passage with the obsolete markup, will it be treated as a new use? Jc3s5h (talk) 15:29, 13 June 2014 (UTC)
    • It will (or should) not per this proposal. Notifications for existing HTML that is obsolete is for another proposal if this one shows consensus. — {{U|Technical 13}} (e • t • c) 15:51, 13 June 2014 (UTC)
  • Note that similarly, deprecated attributes (bgcolor specifically) are already failing to work on Wikipedia (T68413). This should is a big red flag that we need to stop adding things that likely won't work much longer as they are already starting to be removed. — {{U|Technical 13}} (e • t • c) 16:03, 13 June 2014 (UTC)
  • FYI: we should have an analogous of de:Wikipedia:WikiProjekt HTML5 here on English Wikipedia. It is useful to have quick examples of how to update the markup to not use deprecated HTML code. Helder.wiki 16:39, 13 June 2014 (UTC)
  • The edit filter suggested below looks for deprecated elements in the new_html variable. I assume this is after templates are expanded. Which means if a template added to a page contains any deprecated elements, it will trigger the filter. So if we're going to use a filter, we need to make sure all templates are updated first. Mr.Z-man 03:53, 14 June 2014 (UTC)
    • The edit filter I used as an example is something I threw together in half an hour or so and didn't have time to thoroughly test. added_lines worked, but didn't seem to catch html that was injected by signatures (which I was using as the crème de la crème of templates), same with new_wikitext. I'm not sure what new_pst is suppose to be as it is new since last time I tried to create and editfilter and doesn't seem to be documented anywhere. I'm sure that someone more familiar with creating abuseFilters than I am (maybe Jackmcbarn) could adjust it to only catch new elements. There should likely be a second filter that only tags pages that are edited that contain existing bad code to make them easier for copyEditor HTML5 Nazis to find but not disrupt any other user. — {{U|Technical 13}} (e • t • c) 05:06, 14 June 2014 (UTC)
      • While I'm not sure about this, if signatures work similar to templates in terms of how they're treated by the parser, it may be rather difficult to distinguish between them. Mr.Z-man 14:08, 14 June 2014 (UTC)
        • Perhaps a more feasible way to do this is right in core, but this RfC is more about whether or not we should do it or not and much less about how to do it. Quite frankly, these tags will eventually stop working altogether, and the question is whether or not the techie types want to just let it break and then see how long pages stay broken and don't work while everyone that knows a thing or two about html tries to fix them, or if we want to try and filter out as much of it now as we can so that when browsers stop supporting them (mobile browsers are likely first so that they can be as compact as possible to be able to use less memory and bandwidth) we barely even notice. I like the idea of not running my stress and anxiety through the roof trying to fix all the bad code myself... — {{U|Technical 13}} (e • t • c) 15:27, 14 June 2014 (UTC)
  • I neither support nor oppose this, but do have a few comments:--LT910001 (talk) 10:04, 14 June 2014 (UTC)
    1. It's not ideal for WP to be supporting deprecated elements in HTML.
    2. I don't think the proposed technical solutions (bot or parsing edit attempts) are ideal
    3. The lack of clearly identified solutions may be contributing to consternation
    4. I suggest that a group of technically-minded users discuss how this might be achieved to find a more finessed solution, and then present that solution, which may have a greater chance of being accepted by the community.
    • There is a discussion above about <big> and replacing it with CSS. Obsolete tags are documented at Help:HTML in wikitext#Obsolete elements and replacement markup is discussed. For this case, <big> can be replaced with {{big}}, thus no raw HTML need be introduced into the content. We don't allow templates in signatures though. --  Gadget850 talk 10:48, 14 June 2014 (UTC)
    • LT910001, the only question in this proposal is if we should spend technically minded users' time to find a method to discourage users from using bad code. The edit filter is just one possible solution out of any possibility as posed in the question. — {{U|Technical 13}} (e • t • c) 13:46, 14 June 2014 (UTC)
  • I agree that we should start removing deprecated elements, but I'm not sure if an edit filter is the best way to do so. Jackmcbarn (talk) 14:33, 14 June 2014 (UTC)
    • Then you support this proposal, which is "Should we technically discourage new instances of these HTML elements that are "in the process of being dropped" by major browsers?" Once we determine that, then "how" we do it should be figured out by the techies. Once that is accomplished, then the community can be presented with the options we considered, which one we think is the best, and if there are any objections to that method being implemented. — {{U|Technical 13}} (e • t • c) 15:10, 14 June 2014 (UTC)
      • I'm not sure you can, by the way. For example, any bot that tries to move a signature with a ≶font> tag to an archive page might then fail. If anything you need to start this process with logging deprecated tags/attributes. Amalthea 14:01, 16 June 2014 (UTC)
  • Lets look at specifics. As I documented at Help:HTML in wikitext#Obsolete elements, there are six obsolete elements that are whitelisted by Sanitizer.php: <big>, <center>, <font>, <rb> (we should just have this one removed from sanitizer), <strike> and <tt>. But there are also a number of attributes that are whitelisted but obsolete, such as abbr, axis, align, charoff, char and valign for <table>. Each of the obsolete elements have either a replacement tag or template. --  Gadget850 talk 16:20, 16 June 2014 (UTC)
    The <rb>...</rb> element was marked as obsolete in the 17 December 2012 revision of HTML5; since 29 April 2014 it's no longer obsolete. HTML5 is still in a fluid state, and we should not forbid the use of any element or attribute unless (i) it was never a formal part of HTML or (ii) browsers don't support it. An example is the bgcolor= attribute when used anywhere other than the <body> tag (see Wikipedia:Village pump (technical)/Archive 127#Background colour on mobile devices). But the <font>...</font> element, obsolete though it is, was a non-obsolete non-deprecated part of the formal spec, in HTML 3.2 --Redrose64 (talk) 20:31, 16 June 2014 (UTC)
  • We need to be kind to editors with deprecated code in their signatures. I think most such editors might appreciate being told about it outside the context of trying to make an edit to a talk page (where any delays might tangle up into edit conflicts, etc). Would it be possible for a bot to leave a message on the user talk page of any active (define: edited in last year?) editor whose signature includes deprecated elements (or is it just a case of the "<font>" which used to be recommended for colour change?), and leave a very clear, very polite, message, explaining that this is now old code which present or future browsers might not handle properly, and advising them to go to "Preferences" and change "this code" to "this new code"?
Or even - I have no idea how signatures are handled - would it be possible for the message on their user talk page to include: "Click this button to make the change to your signature automatically", giving a popup box showing "Your old signature looked like this: xyz; Your new signature looks like this: xyz. Click "OK" if all is well or "Cancel" to revert the change", with a "Help" button to click if they had to revert because something went wrong with the change? I'd guess that most editors would be happier to do this, at a time of their own choosing, rather than having to cope with negative information about their signature while wanting to concentrate something else (adding a message to a talk page). PamD 15:37, 20 June 2014 (UTC)
@PamD: If possible (probably so for most sigs), I think this would be great. --AmaryllisGardener talk 15:42, 20 June 2014 (UTC)
  • So, it appears that something is happening here in the browser world. I have an old BlackBerry that I recently updated the built in browser, and most of these deprecated and obsolete elements are just dropped. I have a screenshot of a simulation that I made of what I see on that device. I admit, it's an old device and an edge case at this point, but it strongly suggests that this change is coming.
We really need to do something to fix these issues. I've already started going through the interface messages, and all but a couple scripts that still have some <tt>s in them are cleaned up. I've also already worked through module, book, portal, and most of the other minor namespaces. I have been working on templates, categories, and file recently and once all of those are done, I'll start looking over draft and article spaces. There's only about 100K pages with obsolete and deprecated code on them. — {{U|Technical 13}} (e • t • c) 16:08, 20 June 2014 (UTC)
Adam Cuerden and Nyttend ... --AmaryllisGardener talk 16:20, 20 June 2014 (UTC)
Surely, though, the CSS tags could cause exactly the same problems, given an old enough browser? They are more recent additions to HTML, after all. Adam Cuerden (talk) 17:06, 20 June 2014 (UTC)
To use CSS in a web page, you use the class= id= and style= attributes. These, together with the <span>...</span> element, were added to HTML with HTML 4.0 - way back in 1999, fifteen years ago (the <style>...</style> and <div>...</div> elements were included in HTML 3.2 but didn't provide full CSS capability). Support for these features had already been provided in some browsers, such as Internet Explorer 4 (1997). You'd need to still be using a browser as old as Internet Explorer 3 for CSS not to be supported. Wikipedia has trouble with IE 6 and isn't brilliant with IE 7, so anybody trying to view Wikipedia with IE 3 has difficulties more fundamental than the lack of CSS support. --Redrose64 (talk) 17:49, 20 June 2014 (UTC)
I found T26529 - Incrementally remove support for HTML elements removed from or deprecated in HTML5. The latest comment is "The Parsoid project is sponsoring a GSoC student to write "linttrap", a wikitext linter which can (hopefully) aid in the semi-automatic conversion of deprecated markup." --  Gadget850 talk 09:26, 25 June 2014 (UTC)
Note, there is currently a discussion on Wikitech-l about dropping support for Internet Explorer 6 and Internet Explorer 7. I don't see support for these being dropped, but the fact that the discussion is happening even should be a sign that those browsers are very very seldomly used with Wikipedia. Internet Explorer 5 and below are not considered supported by Mediawiki. So all people browsing Wikipedia ought to have at least some form of CSS support. Zell Faze (talk) 20:23, 3 July 2014 (UTC)
  • FYI... Currently, no article on enwiki has font tags or strike tags. Other Wikipedia sites have removed the big tags. We have been "fixing" the article when <font> or <strike> show up. This could be extended for other tags, but the <center> would take alot of work. Bgwhite (talk) 21:26, 26 June 2014 (UTC)

Support (deprecated elements)

  1. Support as proposer. We can do this easily with a new edit filter like testwiki:Special:AbuseFilter/139, we would just have to link the table in the warning message and give the user a few more details to go on. I would be happy to work up a sandbox for this and post an {{Edit requested}} if there is consensus. — {{U|Technical 13}} (e • t • c) 02:42, 13 June 2014 (UTC)
  2. Support—specifically I think three things should also be done. 1) A table should be created someplace, and linked from the appropriate policy/guideline, that lists what we should use instead of the unsupported tags. 2) A bot task should be created to replace the tags with the appropriate coding to ensure compliance going forward. 3) We need a way to assist people in updating their signatures ahead of time so that if an edit filter is put in place that we don't stop people from completely participating in discussions. Otherwise, I completely agree with the proposal. Imzadi 1979 → 03:13, 13 June 2014 (UTC)
    1. The warning table (like testwiki:MediaWiki:Abusefilter-warning-139) would hold all such relevant information.
    2. I worded this proposal with the intent of just reducing new errors from being introduced into the wiki, if there is support here, we can always come back and see if we should fix the existing errors after.
    3. The edit filter would warn with a table offering the acceptable alternatives and tag the edit if they choose to ignore the warning but would not prevent the obsolete code. This will give editors time to fix these things while still being able to edit.
    4. You do realize your post here includes both font and big tags which would be discouraged, right? — {{U|Technical 13}} (e • t • c) 03:29, 13 June 2014 (UTC)
    Support with caveat. As phrased, I'm not sure who would disagree with adopting the most contemporary standard practices, but I would append "where possible" before the "Avoid..." line we discussed at SIGAPP. It's one thing to leave a friendly suggestion that one's signature can be better expressed another way, and it's another to point to a policy and look like the signature police. "Where possible" is what I'd suggest to mitigate that. czar ♔ 04:09, 13 June 2014 (UTC)
    • Just to be clear here czar, this is a proposal to add a sitewide edit filter to inform users that these elements shouldn't be used at all and isn't a signature specific issue. — {{U|Technical 13}} (e • t • c) 04:46, 13 June 2014 (UTC)
    How can it be a proposal for a "sitewide edit filter" if it's not even mentioned in your proposal? czar ♔ 12:46, 13 June 2014 (UTC)
    When you read the question, it says "technically discourage" which means an edit filter or a core change to inform people that what they just added to the page is obsolete code and may break the page at any time and offer some possible alternatives so they can fix the issue for themselves. This will not prevent them from making the edit, but if they have bad code in their signature, it will nag them until they fix it. — {{U|Technical 13}} (e • t • c) 13:31, 13 June 2014 (UTC)
  3. Support: I probably started off this whole discussion: I objected when an editor edited my signature on his talk page and then discovered that I'd got deprecated code in it and that he was entitled to fix it as a non-compliant signature. There was at that time the added complication that WP:SIG pointed to a tutorial which recommended the use of "<font>": this has since been updated, as a result of the discussion I started. It seems sensible that Wikipedia, in signatures and elsewhere, should abide by current standards. We don't know what technology our readers will use - perhaps especially those using innovative assistive technologies to compensate for a disability - and we not risk causing avoidable problems. PamD 13:08, 13 June 2014 (UTC)
  4. Support. This should have been done long ago! Ruslik_Zero 13:45, 13 June 2014 (UTC)
  5. Support per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:05, 13 June 2014 (UTC)
  6. Support. The usage of these deprecated elements and attributes should only decrease. An edit filter would be a good way to ensure Wikipedia pages will get better markup over time and old code will stop proliferating in the articles (and from here to translated articles on other wikis). Helder.wiki 16:44, 13 June 2014 (UTC)
  7. Support - Not much point "endorsing" the use of markups that either don't work or are obsolete, I'd imagine there's going to come a time when a certain mark up or 2 stops working for good .... and then we'll all be fucked, So as the balls rolling we may aswell do something about it. –Davey2010 • (talk) 16:48, 13 June 2014 (UTC)
  8. Support This pretty much says it all. --AmaryllisGardener talk 17:39, 13 June 2014 (UTC)
  9. Support Even if us non-techs had a reference list to refer to for these kind of mark-ups, this is way easier than checking regularly to see if the mark-up is still valid. The sooner the better as far as I am concerned. GenQuest "Talk to Me" 19:36, 13 June 2014 (UTC)
  10. Support per nom. APerson (talk!) 20:32, 13 June 2014 (UTC)
  11. Support logging and edit tagging only. In other words, don't bounce back editors with a warning message. The suggested solutions for this problem (which is still only a potential problem, not an active one) all seem to involve getting all Wikipedia users to learn an aspect of HTML. That is quite a high barrier to editing for many. Our first focus should be to clean up and monitor template usages (which could in theory lighten the load for less techie editors). Frankly, a better solution is required for a successful implementation regarding general edits in article space. SFB 14:26, 14 June 2014 (UTC)
    I wouldn't oppose a few months of a couple EditFilters that find all uses of deprecated code and only tags the edits (one would check the actual wikitext that the user entered and mark it that they entered deprecated code and the other would check a comparison of the new parsed text minus the old parsed text to catch only instances of templates or signatures that add the deprecated code) with deprecated elements so our templateFu elitists can fix as many of the templates as possible before we start warning/informing people they are adding bad text. We can also easily create a single notice template that can be added to Twinkle to inform people that they physically added deprecated elements to a page and how they can achieve the same result without that old code. In the cases of signatures, I already have the workings of a template in my userspace ({{User:Technical 13/Templates/badsig|existing sig|suggested replacement|code=yes}}) that would allow anyone with HTML/CSS-fu to easily post "your existing code is this" and "would you consider changing it to that which looks exactly the same and doesn't have deprecated elements" (even offers character counts to make it easy to see the 255 character limit). — {{U|Technical 13}} (e • t • c) 18:35, 14 June 2014 (UTC)
  12. Support for content elements: articles, templates and the like. We still have a lot of templates that output invalid HTML. I wouldn't worry about user elements such as signatures. We will never fix old uses and new uses will get fixed if and when browsers stop supporting obsolete elements or break them. That is, if <font> is no longer supported, then users will be forced to figure out alternatives. --  Gadget850 talk 15:25, 14 June 2014 (UTC)
    See my above comment. :) — {{U|Technical 13}} (e • t • c) 18:35, 14 June 2014 (UTC)
  13. Support; seems sensible. Ironholds (talk) 17:41, 14 June 2014 (UTC)
  14. Support, though I'd prefer a bot replacing old and new uses of obsolete HTML elements and attributes over an edit filter that prevents edits containing such HTML from being saved. I don't think replacing obsolete coding with correct coding can be considered "cosmetic" since it ensures that the code works (and will continue to work) correctly on all devices and browsers (addressing a comment below). SiBr4 (talk) 21:35, 14 June 2014 (UTC)
    • The point of the proposal is not to prevents edits containing such HTML from being saved but instead to warn a user, and then if they decide they want to save it anyways, to tag it as such. I've also mentioned in reply elsewhere, above, that a couple, three, six months of just tagging certain situations (for examples to find templates adding bad code, which I'm going to run a database scan for tonight to try and fix most of them preemptively) without the warnings would be a productive start. — {{U|Technical 13}} (e • t • c) 22:33, 14 June 2014 (UTC)
    • I agree with this proposed approach, as long as any warnings or tags make it clear to the non-technically minded that they can still go ahead and save their edits with no immediate harm being done to the project. GenQuest "Talk to Me" 21:31, 15 June 2014 (UTC)
  15. Support: I was initially skeptical, but have been won over. Yes, we should technically discourage new uses of deprecated HTML. I am seeing in practice that editors will not be left in the lurch; mystified and without assistance. There are activists afoot who are capable and willing to help us sort it all out. So, better sooner than later. Fylbecatulous talk 20:51, 21 June 2014 (UTC)
  16. Qualified support per SFB. Λυδαcιτγ 03:47, 22 June 2014 (UTC)
  17. Support: While not needed right away, it will have to be done. Better to do it sooner. Bgwhite (talk) 21:22, 26 June 2014 (UTC)
  18. Support discouraging use provided that we allow the save to occur. Support logging any pages or edits found this way to a public place so editors interested in cleaning them up can do so. davidwr/(talk)/(contribs) 17:23, 1 July 2014 (UTC)
  19. Support. Jc86035 (talk • contributions) 12:22, 3 July 2014 (UTC)
  20. Support per the proposer. I subscribe to Wikitech-l. When this discussion is closed if someone pings me I can mention it on-list and see if anyone there is willing to try to come up with some technical solution to help us migrate already existing content away from deprecated tags. I'd also like to make them aware of the consensus of this discussion as I suspect it will inform discussion we have on-list in the future. Zell Faze (talk) 20:26, 3 July 2014 (UTC)
  21. Support. -- Magioladitis (talk) 13:24, 9 July 2014 (UTC)
  22. Support The future is rushing to meet us. ;) Protonk (talk) 15:23, 15 July 2014 (UTC)

Oppose (deprecated elements)

  1. No. Wikitext != HTML. Legoktm (talk) 05:34, 13 June 2014 (UTC)
    In the context of how MediaWiki handles these HTML tags, they are equal, as they are simply whitelisted HTML. Now that these tags are obsolete in HTML5 (which is the standard output now), they are invalid. To maintain obsolete tags and attributes as valid wiki markup, we would have to translate them to contemporary HTML/CSS. That makes issue a more fundamental one, where we need to investigate whether these tags are indeed regarded as 'official' wiki markup. — Edokter (talk) — 09:52, 13 June 2014 (UTC)
    Can't HTMLtidy or something similar convert the font tags? –xenotalk 10:55, 13 June 2014 (UTC)
    Tidy is of no use; its purpose is to fix invalid html structure. There was once code in the html pre-processor to convert old html attributes to CSS, which was reverted due to some minor side effects. But that would be the proper place. — Edokter (talk) — 11:58, 13 June 2014 (UTC)
    Plus, as Edokter wrote four months ago, not only is HTMLTidy no longer being maintained, it predates HTML 5. This means that it is probably unaware of all the HTML 5 obsolescences. Under HTML 4.01, the FONT element is merely deprecated, not obsolete, and deprecation of a feature doesn't mean "get rid of this because it no longer works" but "it is advised not to do it this way because it may stop working one day". There aren't actually that many obsolete features of HTML (that which were once part of the standard) that have ceased to be supported by browsers. <NEXTID> and <PLAINTEXT> are two of them; <FONT>...</FONT> isn't. --Redrose64 (talk) 12:47, 13 June 2014 (UTC)
    Right. Tidy isn't right solution. We know it sucks :). Doesn't mean we can't use something else. Legoktm (talk) 22:58, 13 June 2014 (UTC)
    • I'm currently not asking to convert existing uses, as I've seen that battle fought in the past at WP:BAG (IIRC) and apparently some think it falls under WP:COSMETICBOT. Once there is a consensus that we shouldn't be adding new uses because it will inevitably break the site, then we can discuss if the existing uses of these "bad" codes should be cleaned up, and how (I was thinking the best way would be to let the core developers do this since I'm sure that it is something that all wikis using this software would want/need). — {{U|Technical 13}} (e • t • c) 12:12, 13 June 2014 (UTC)
  2. Not necessary and can apparently be done in the html pre-processor when it is. –xenotalk 12:51, 13 June 2014 (UTC)
    Your load times aren't bad enough already? If we fix the templates, and we fix our signatures (which are just templates stored in core inaccessible to anyone but the user), and we break the bad habits of users that are adding these code which could quit working at any time, then the processor isn't going to have to work as hard and it won't take as long for pages to save and load. Forcing the parser to fix out mistakes is a band-aid and a bad idea. — {{U|Technical 13}} (e • t • c) 13:36, 13 June 2014 (UTC)
    The parser already does that... Don't worry about performance. Legoktm (talk) 22:58, 13 June 2014 (UTC)
    You seem to be overlooking the Wikipedia:Don't worry about performance#Editors still have a role to play clause. — {{U|Technical 13}} (e • t • c) 02:21, 14 June 2014 (UTC)
    I am not sure anybody is going to make necessary changes to the preprocessor. One day one of the major browser will simply stop supporting them and the encyclopedia will become less readable. Ruslik_Zero 13:49, 13 June 2014 (UTC)
  3. Oppose, I say we should discourage it as a practice, but we should not be bothering 'plain users' with this kind of stuff. Especially since it's still used in templates etc all over the stuff. I'd be interested in having the edit filter gather some logs on how much new additions there are being made in general, and perhaps to issue warnings to sysops/template-editors for uses in Template namespace, but other than that, I don't think this is a problem worth pursuing, the preprocessor should be fixing it wherever possible in my view (other then <center> perhaps and a few other related special cases). —TheDJ (talk • contribs) 14:09, 13 June 2014 (UTC)
    How do you propose we discourage it as a practice without notifying the user that they are doing it? It has no effect on readers (unless FireFox 31 doesn't support these tags at all for example and all of the pages with these tags fail to render, then it would be a major problem that we weren't prepared for) other than a positive one as we won't be turning them away because things are broken. So, this only effects those that edit. I dare say that "most" 'plain users' aren't familiar with HTML elements and most likely won't be adding the bad tags to start with; even if there are a couple that do, a simple warning with a table that says "rst are obsolete, please use xyz instead" is a lot friendlier and efficient than them trying to figure out why their code isn't working because they read some tutorial someplace on SE or something and the latest version of IE or whatever browser they are using doesn't render that element anymore. — {{U|Technical 13}} (e • t • c) 14:46, 13 June 2014 (UTC)
  4. No. How am I supposed to make something Huge in an editnotice, or a talk page message, or something like that? Maybe these old pieces of code aren't good for "formal" uses, but they get the job done simply and don't hurt anything in informal stuff like user talk messages and wikiproject pages. Perhaps its could be accompanied by something such as the suggested edit filter, so that HTML-savvy editors can come and clean up such uses in mainspace and templatespace, but we shouldn't have it add warnings after every use. Nyttend (talk) 01:04, 14 June 2014 (UTC)
    Can't you increase the font size with the span tag, Technical 13? --AmaryllisGardener talk 01:15, 14 June 2014 (UTC)
    @Nyttend: Aha, Like this! Code: <span style="font-size: 150%;">Like this!</span> --AmaryllisGardener talk 01:22, 14 June 2014 (UTC)
    Read Adam Cuerdon's note. Don't force me to ask for help leaving a simple message; you fail to remember that not all of us find span tags simple. Nyttend (talk) 01:50, 14 June 2014 (UTC)
    @Nyttend: I don't intend to be rude, but have you read my response to AC below? --AmaryllisGardener talk 02:00, 14 June 2014 (UTC)
    Yes. That's why I said "don't force me to ask for help", because people like me are getting along quite fine right now, and the only way you attempt to compensate for messing up my coding is an offer to help: all very fine for me, but it's just slightly more convenient for me to be able to code things by myself instead of asking you for help every time I'm attempting to write an editnotice for my talk page or emphasise something in a message — not to mention all the people who don't know about your offer. And what will you do about tons of uses of these tags in talk archives and old revisions of all sorts of pages? Nyttend (talk) 02:07, 14 June 2014 (UTC)
    Ah, I see what you mean now, I guess we'll just see if we have a choice in the future then. --AmaryllisGardener talk 02:09, 14 June 2014 (UTC)
    • I understand where you are coming from, but what is going to happen in three or six months or whenever <big> just stops working? All of those edit notices will no longer have big text where it was so important and everyone will be running around like a flock of headless chickens trying to clean up all the requests scattered across the dozen or two VPs and HDs and etc. For the record, what is wrong with {{Big}}, {{Larger}}, or any of the other {{Resize}} templates that we have just for this situation? — {{U|Technical 13}} (e • t • c) 02:19, 14 June 2014 (UTC)
  5. Oppose Not everyone knows CSS, and we're basically setting up a situation whereby people will get confusing messages they won't have a hope in hell of correcting. Adam Cuerden (talk) 01:38, 14 June 2014 (UTC)
    @Adam Cuerden: I'll volunteer to help people replace their sigs, not just say "Your sig has deprecated tags, change it!". I'm sure others would follow suit also. After all, what's worse, someone having to change their sig and it not be as pretty and work in all browsers, or their sig be pretty in IE but be broken in Firefox and Chrome? Please correct me if I'm wrong. --AmaryllisGardener talk 01:45, 14 June 2014 (UTC)
    That's a bold claim. You're saying Firefox and Chrome don't support <big> and <font>?
    Well, I don't know about Google, but Mozilla says it may be removed from browsers at any time here. --AmaryllisGardener talk 02:03, 14 June 2014 (UTC)
    Could be, but probably won't be. And, even if true, does that require us to make a big sweeping change now, when we can't actually defend our position to the users affected? Adam Cuerden (talk) 02:08, 14 June 2014 (UTC)
    • It's not a question of if it will be removed, it is a question of how harsh of a result we want that removal to be. Do we want to start warning people now, while still allowing them to save (even with the bad code), and give them an opportunity to ask on literally any of the help desks, noticeboards, VPs, or other forums why they got that message and what they need to do to fix it; OR do we just want them to be removed from the MediaWiki core and then we'll kill our editor retention because people won't be able to edit with the bad code and get frustrated and just quit? Wouldn't it be better to let them use crap, so they can ask for help learning how to avoid the issue? — {{U|Technical 13}} (e • t • c) 02:19, 14 June 2014 (UTC)
    It's not that much of a bold claim. MDN is full of elements which have been deprecated and then removed from broswers. The path is generally long because browser maintainers work hard to make sure they won't make sudden material changes to the web, but it still happens--the reverse, where deprecated elements are restored is incredibly uncommon. Continuing to use a deprecated element (especially in something like a signature, which can proliferate over many pages pretty easily) just makes the eventual and inevitable switchover harder. Protonk (talk) 13:17, 16 July 2014 (UTC)
  6. This needs to be solved on the MediaWiki level, not in individual wikis. It affects all installations, there are many possible strategies; taking action locally is premature, and as proposed too intrusive.
    Personally I've always considered those tags/attributes wikitext features that just happen to be translated 1:1 to HTML. With the changes to HTML this mapping is no longer as simple as a whitelist, but many tags can and should certainly be converted by MediaWiki: wikitext should continue to be simple, and it makes sense to have simple presentational features in the language. Some, like the alignment attributes, may need to be deprectated, but this should still happen on the MediaWiki level where the affected pages can e.g. be categorized automatically.
    Either way, bothering our editors at this point is in my opinion way premature. Amalthea 11:40, 16 June 2014 (UTC)
    I entirely agree that this is an all project issue that needs to be resolved on the software level; however, I don't expect the developers to make it slow gentle transition. I would expect there would be some transition, I would expect it to one day just refuse to save the edit with an error like "Invalid HTML, please check your code and try again" and nothing more. Then I expect it to all just stop working... This proposal is local to this wiki in order to soften that and give all of our editors a chance to improve their habits before this happens. Wouldn't a softer transition be preferred? — {{U|Technical 13}} (e • t • c) 12:13, 16 June 2014 (UTC)
    That question is a false dilemma on top of speculation, the softest transition is no change for the editors and MediaWiki handling it all. With lots of open bugzilla issues about it and no clear sense of where this is going we can only speculate, and I don't want to create work or distractions for editors until we know which way this is going. With that big a change we will have sufficient time to prepare, I see no reason for a hasty local decision here. Amalthea 13:55, 16 June 2014 (UTC)
  7. Opposed. The replacement aren't as easy for users to understand it seems. We abandoned formatting tables and later re-embraced. No sense in removing <big> while keeping <small>. It also very much bloats the wikitext. I wrote a table tags -> CSS convert and needed to limit the CSS expansion to keep some readability. About as stupid as the MiB vs MB issue. — Dispenser 21:42, 24 June 2014 (UTC)
    • How do you figure the replacements aren't as easy for users to understand? I must've offered help to a dozen or two users to get there signatures up-to-date in the last couple weeks, and I've not one that has objected to making the change (there is one pending that said they would "think about it", and if they choose not to accept my assistance, so-be-it, the ratio of better than 10:1 is fine by me). We haven't tried yet (which is what this RfC is suppose to facilitate, giving it a try. This has nothing to do with tables, which are very much still supported. I'm not sure why the W3 dropped big but kept small, that's a good question, but it's not the question here because content wrapped in small tags doesn't disappear from the page. Are you saying you think that pages that can't be read by some users on some browsers because these HTML elements are dropped is okay? I thought Wikipedia was suppose to be accessible and readable by everyone? — {{U|Technical 13}} (e • t • c) 22:12, 24 June 2014 (UTC)
      • Are you saying you think that videos that can't be viewed by some users on some browsers because these codecs are unsupported is okay? I thought Wikipedia was suppose to be accessible and viewable by everyone? Couldn't resit the H.264 bait. W3C flip-flops and any decent web browser will render these tags for legacy compatibility. I'm alright to deprecating <font> in signatures and had report and conversion tool done years ago, but articles are another matter. — Dispenser 22:16, 30 June 2014 (UTC)
        • I'm saying there is a huge difference between people not being able to read the text on the page and not being able to see an accompanying video that is suppose to help support that text. Everyone should be able to read all the text, if they can't see the complimentary video, they still have a basic understanding of the text and they can still print out the text and make use of the "create a book" feature. — {{U|Technical 13}} (e • t • c) 22:21, 30 June 2014 (UTC)
  8. Oppose. Obsolete tags should be interpreted by MediaWiki to produce correct modern HTML, but short tags that are easy to memorise are preferable to having editors write complicated span tags. Readable wikitext is important. —Kusma (t·c) 09:21, 27 June 2014 (UTC)
    • Kusma. 1) No need for span tags That is what {{font}} and other templates are for. You have a moot point. People already use the equally complicated font tag. 2) MediaWiki will be dropping HTMLTidy for Parsoid. Developers have already stated Parsoid will not convert all tags and will not convert tags in scenarios that HTMLTidy currently covers. For example, if you bring up the following text normally and in Visual Editor, it will be different: The brown fox jumps over lazy dog. Bgwhite (talk) 22:14, 1 July 2014 (UTC)
  9. Avoid the issue. The way to deal with these tags is at the back end, by having the software no longer parrot "<small>" to your browser, but to automatically convert it to "{{small}}" and then process it as such. They will simply be tags like <nowiki> instead of HTML then. Templates that are hardwired in this way can be indef-protected and exempted from rules against using templates in signatures and such. We shouldn't ask the users to change until we really need to, and we don't need to as long as someone is willing to arrange this to happen. Wnt (talk) 20:04, 8 July 2014 (UTC)
    Wayda minute. You're telling me that if this goes through, people will have to use {{big}} to make text big, but <small> will still be the standard for making it small? How the heck.......? Wnt (talk) 13:19, 9 July 2014 (UTC)
    • Nope, not what we are telling you at all. {{Small}} works for making text small just as {{Big}} works for making it big and people are welcome to go with that route for consistency if it makes it easier for them. — {{U|Technical 13}} (e • t • c) 13:30, 9 July 2014 (UTC)
    I understand they can, but ... a person expects big and small tags to be symmetrical. They do the same thing, just different numbers. How can it possibly be that one is a problem we have to fix and the other is not? Wnt (talk) 17:48, 9 July 2014 (UTC)
    @Wnt: In HTML5, big is obsolete but small is not. Further, the traditional use of <small>...</small> (to reduce text size) has been replaced by the semantic meaning of "side comments such as small print. Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements." Thus, if it's not a side comment, it shouldn't be marked up with <small>...</small>. Ever since HTML 4 was raised to W3C Recommendation (December 1997) the preferred method for varying the size of text has been the font-size property in CSS. --Redrose64 (talk) 20:09, 9 July 2014 (UTC)
  10. Oppose Excessive bureaucracy. And because I am reminded of the idiotic move to ban <s>, based on what I discovered to be false claims that it was deprecated. And of stupid messages about missing archivedate (when the date could be found in the archiveurl field. And per Legoktm, ... I take Wnt's !vote immediately above to be an oppose..--{{U|Elvey}} (t•c) 03:05, 9 July 2014 (UTC)
    @Elvey: The <s>...</s> element was deprecated in HTML 4.01 (and therefore in XHTML 1.0 also, which is what Wikipedia served until 17 September 2012), but is not deprecated in HTML 5 (which is what Wikipedia has served since 17 September 2012). --Redrose64 (talk) 13:00, 9 July 2014 (UTC)
    We shouldn't be leaving it up to the backend to fix our human error or laziness. — {{U|Technical 13}} (e • t • c) 13:36, 9 July 2014 (UTC)
    User:Technical 13: Yes, we should be leaving these unharmful tags alone. It's only an error in the eyes of folks who deem deprecated tags an error (and weird badly written stuff, since unsupported tags should be ignored, IIRC) and they should chill out. Not to mention, again: Wikitext != HTML {{U|Elvey}} (t•c)
    • Elvey, how do you construe the fact that in some browsers the sections contained in these tags are dropped instead of rendered breaking pages and making the wiki unreadable as unharmful? This comment confuses me. — {{U|Technical 13}} (e • t • c) 17:50, 9 July 2014 (UTC)
    Any such browsers are broken; their brokenness is harmful. Unsupported HTML tags are to be ignored. <elvey>this</elvey> should display 'this' , not nothing.--{{U|Elvey}} (t•c) 21:04, 10 July 2014 (UTC)
    User:Redrose64: Irrelevant, even assuming that's all true. The idiotic ban on <s> was a clusterfuck; the banned usage was not in fact deprecated at the time it was banned; the deprecation was only ever partial. I wonder if the same applies to these tags; I haven't looked. {{U|Elvey}} (t•c) 15:52, 9 July 2014 (UTC)
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.


Category:Articles with disclosed paid contributions

Hello! I would like to propose add a category called "Category:Articles with disclosed paid contributions" or similar to the articles which have disclosed paid contributions according to the new terms of use. I think it could be a good method to inform to the reader that the article has paid contributions. --Kelseycf (talk) 11:47, 15 July 2014 (UTC)

Straight off the top of my head I see a problem with this: How do we decide when a paid contribution is no longer present in the article? For example if a paid editor writes a sentence, and that sentence is changed by other editors over time, at which point does the article cease to have a paid contribution on it? Sam Walton (talk) 11:50, 15 July 2014 (UTC)
@Samwalton9: You bring up a valid point, but I would think that a paid contributor would have constant eyes on said article. In theory the tagging of said article could be done and undone by consensus. ♥ Solarra ♥ ♪ 話 ♪ ߷ ♀ 投稿 ♀ 12:16, 15 July 2014 (UTC)
They may have constant eyes on said article to begin with, but as soon as the payment stops they no longer have a reason to watch it. --Redrose64 (talk) 12:45, 15 July 2014 (UTC)
Since the new terms of use indicate that the paid contribution have to be made with an appropriate edit summary, it should be straightforward to tell what the paid editor added. If the contribution were to be totally removed or written for some reason, any editor could remove the tag; a consensus would only be needed if the contributions were just changed partially. —Anne Delong (talk) 15:20, 15 July 2014 (UTC)
Such articles could be automatically added to the category by {{Paid contributions}} or whichever notices are appropriate. Would it make sense for this to be a hidden category? Ivanvector (talk) 17:21, 15 July 2014 (UTC)
Anne Delong, I believe that the terms of use require an edit summary or a note on the talk page or a note on your user page. In some instances it might be more difficult to identify exactly what is added. WhatamIdoing (talk) 19:00, 15 July 2014 (UTC)
Hmmm... too bad... the notice on individual edits would be so much more precise. It appears to me that a person could be paid to edit a particular page, and yet make thousands of contributions on other pages which were not paid. —Anne Delong (talk) 19:17, 15 July 2014 (UTC)

I think it should be a hidden maintenance category not a reader one. Treat it similar to Category:Living people in that it can be reviewed periodically. -- Ricky81682 (talk) 20:09, 15 July 2014 (UTC)

It could be hidden, yes, but my point is to inform the reader that the article have or had paid contributions. I think this is important when the article was created by paid editors. In Europe for example it is necessary to inform the reader in the article page, the disclosure in the talk page or user page is not enough. Furthermore, in the future it can be used for doing statistics about the contributors. Another possibility is having several categories like Category:Articles with revised disclosed paid contributions.--Kelseycf (talk) 11:32, 16 July 2014 (UTC)
Hidden cats are...hidden. How would they inform readers unless the readers take special steps (which are not obvious if I recall)? That seems less visible than a boxed note on the talkpage (which is the place well known to have notes about the article content-development)? If there is a specific legal requirement, it would have to go through WP:LEGAL (i.e., we here as editors cannot choose to be illegal). I'm bit hazy on how a Europan law impacts a US-based system. DMacks (talk) 17:52, 17 July 2014 (UTC)

Wikipedia:Contributing to Wikipedia is a new article (revamped to be honest) that I believe would be a great asset to many potential editors. I have a simple proposal to add the link Contributing under the "Interaction" section on the main left hand-side navigational links. lots of work has gone into the article with videos and all. We currently have links to info about Wikipedia its self, where people can help (Community portal) and a link to "Help:Contents". I believe a direct link to our MAIN "how to page" is a good idea over having to read over the "Help:Contents" to find the how to pages. I am not sure if this is the right place or not - but nevertheless I am trying to get a feel for this idea. -- Moxy (talk) 07:48, 18 July 2014 (UTC)

Automating mergers

I hope it's okay to post here to draw a bit of attention to WT:Merging#Automating the perform. Anna Frodesiak (talk) 00:43, 23 July 2014 (UTC)

I tweaked your link to head to Wikipedia Talk space, hope you don't mind. Monty845 00:49, 23 July 2014 (UTC)
Thank you for catching that. :) Anna Frodesiak (talk) 05:30, 23 July 2014 (UTC)

Wibe | Surf Wikipedia with the Power of YouTube

Hi,

I am Akshit (Co-Founder of Wibe), we have made a Chrome Extension by which anyone will be able to watch relevant YouTube videos corresponding to the Wiki Article they are reading.

It is the deadly combination of Wikipedia and YouTube, it can really become a great new feature of Wikipedia. We developed it to solve our problem of switching to YouTube from Wiki to understand a particular thing.

I would be very thankful if you please try and review it. Then if you like Wibe, consider it to integrate as a functionality in Wikipedia for some days so that user can use and review this new feature.

Install the Extension and then try out "http://wiki.riteme.site/wiki/Wikipedia:About" page to see how it changes the original wiki page by integrating relevant videos from YouTube.

Cheers,

Akshit Agarwal (Co-Founder, Wibe)

Cool, But What Happens if Youtube is inaccessable? Wibe Messes up Chrome. Maybe we could integrate it into Wiki by having a <Youtube> Tag

Example:

Text Text Text <Youtube HTML= "https://www.youtube.com/watch?v=98uDPo7ZjVI">

Appears Like;

Text text Text [Youtube Video]

Just a Thought, TitusFox'Tribs 15:58, 21 July 2014 (UTC)

This cannot work with Wikipedia. First, you cannot embed external videos in a wiki article, unless they are explicitly published under a free license. 99% of the videos on YouTube are copyrighted and unsuitable for inclusion in Wikipedia. Second, even linking to such videos in the External links section of an article would not work without direct user supervision. Per WP:YT "Many videos hosted on YouTube or similar sites do not meet the standards for inclusion in External links sections, and copyright is of particular concern. Many YouTube videos of newscasts, shows or other content of interest to Wikipedia visitors are copyright violations and should not be linked. Links should be evaluated for inclusion with due care on a case-by-case basis." (emphasis mine) This means you cannot just automatically link to a bot-generated collection of videos in an article - they will be most likely either not completely relevant or possible copyright violations. 2Flows (talk) 16:53, 21 July 2014 (UTC)

It would be a pleasant notion for me and the Dell XPS-10 with Win 8.1 RT that I'm using today. Its built in browser cannot see Wikipedia's OGG videos and it cannot install other browsers. Sending a copy to a video site that allows ordinary video formats would be a somewhat clumsy solution if Wikipedia policy allowed linking to such a video. It makes me wonder why allow video at all, and yet so restrict it as to make it unworkable. Jim.henderson (talk) 18:19, 23 July 2014 (UTC)

Assuming that you were to manually evaluate the relevance and copyright status of a YouTube video and decide that it was worthy of inclusion, I wouldn't be too opposed to the superscript-form link. Dustin (talk) 18:34, 23 July 2014 (UTC)
Some time back I noticed another Wiki that did something similar to the above but didn't seem to last. I have always thought video was the one area that Wikipedia needs to grow in leaps and bounds but to do so might mean a project related to those editors that wish to create videos for Wikipedia and guidelines would need to be established to be sure copyright was being respected and adhered to. It could be opening a can of worms but I think the idea is sound. Sometime ago I made a video for an article I am a major contributor on. I did make a mistake and used an image that did have a copyright. I was lucky because the copyright holder liked the video and contacted me twice. Once in regards to attribution that I mistook for a take down request and so, removed the video. They contacted me after I removed the video and said I could use the images as along as I attributed the company and person who created it, so now the copyright has been granted (I reproduced the video to add the credit and not just drop it in the video summary on Youtube). Now...if we produced videos and ONLY used content from Wikipedia and Wikimedia commons, all that would be required is attribution. I wish we had a project where editors could produce videos for pages that are copyright free. I think it might be a good way to improve some of our articles.--Mark Miller (talk) 19:45, 23 July 2014 (UTC)
Just how would production of videos improve any articles? Is this an echo of the recent proposal of having video summaries? ~ J. Johnson (JJ) (talk) 20:17, 23 July 2014 (UTC)
That is a legitimate question and can only be answered with opinion I suppose but I know nothing about the "video Summaries" issue. In my opinion a video could be watched to enhance one's understanding of the topic or additional content could be provided to add to the article itself and not just summarize what is already written.--Mark Miller (talk) 20:41, 23 July 2014 (UTC)
Most tools and most sports ought to have video. Bark hack and Curling and many, many others. Jim.henderson (talk) 20:53, 23 July 2014 (UTC)


We are sorry for writing such a long comment but we request you all to please read it fully as we also want to improve Wikipedia and don't want to run a business behind it.

First of all thanks to whole Wikimedia Community for reviewing Wibe. I agree on most of the points, but let me tell you that why we developed Wibe, while we were in the college we always use to face a problem that while reading a Wiki article we were unable to completely gain whole information from it For E.g. While surfing "Breadth First Search" Wiki Article we had to switch to YouTube to watch a video corresponding to its demo/example for a deep and better understanding, not only this when we didn't know about "Suits (English Season)" then we opened Wikipedia to know about its theme but then we have to switch to YouTube for watching its trailer and this use to happen in most cases where we just use to read top 2-3 lines from Wikipedia and then switch to YouTube for a better understanding. And this was not only our problem we read many reviews and feedback of users about Wikipedia they also reviewed that they open Wiki Articles for quick facts as excess text reduces the interest in the topic while if you check similar topic videos on YouTube they have higher views. Also its scientifically proved that our mind are designed to understand images/videos better than text.

We are telling you all this because we found it useful and we think it will be very useful for others also as we are getting great feedback from other users and incubators/accelerators. So if you really like the idea of Wibe (Combination of Wikipedia & YouTube) then please DON'T NIP THIS IDEA IN THE BUD. We know there are many issues in it but we all can work together to make Wikipedia interesting by integrating videos in it. As we can discuss this idea with YouTube and ask them to include a option of Allow Wikipedia to Use Your Video corresponding to every video a user upload so that we can then include that approved videos in same format as currently shown in Wibe. Now if you are thinking that why YouTube will add this option then just have a thought that if they include videos on Wikipedia then there Popularity will INCREASE a lot because Wikipedia is world's 5th most visited website outranking YouTube also.

Just to let you know this idea popped into our mind when we read your comments so its just the beginning, if we want to make Wikipedia a Interesting and One Stop Place for users then just have a thought about it as you guys are most powerful community of World and we together can bring this change for whole world.

RFC: Naming of one and two digit numbers and years

See box. Formerip (talk) 11:14, 25 July 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Result: Consensus is against the proposal.

6 editors supported the proposal, of which 2 only supported one aspect of the proposal (pagemoving pages related to years) and opposed the rest of the proposal. 15 editors opposed the proposal.

The mains reasons for the opposes were (1) that the proposal was likely to run into trouble and drama over oldschool vs newschool year-naming and (2) that the proposal would cause inconsistency in the naming of articles about years. These are fair arguments. The case for support was that, for one and two digit numbers, the number, not the date, was likely to be the primary topic. This is also a fair argument.

On balance, though, I don't see anything in the discussion that would warrant not recognising the numerical victory of the opposes.

Background

For the longest time, it was necessary to link dates (e.g. January 1, 1970) so the wiki software could format them automatically. Because this was often used in mainspace, it was desirable to keep those links blue and relevant, so four-digit number articles, by convention, are about years (if it existed, the corresponding natural number would be at 1970 (number)). Since people write about lots of different time periods on Wikipedia, this also extends to three-, two- and one-digit numbers (but not five and larger, because we are (apparently) not the Long Now Foundation); 5 is the year 5, not the number 5.

However, this linking is no longer necessary. We had a nice long edit war over whether it should still happen, of course, but I digress. Currently, fewer than 50 pages link to 5,[2] while many more link to its numerical counterpart.[3] One wonders whether the year is truly the primary topic for the numeral.

Question

Should we rename 1 through 99 to 1 AD through 99 AD (the precise naming scheme here is negotiable), then rename 1 (number) through 99 (number) to 1 through 99, and finally amend WP:NCNUM to account for the change?

NB: This intentionally only extends to one- and two-digit years, because larger numbers are less important while more recent years are more important. We may later revisit this discussion for three-digit years, but they are not part of this proposal. --NYKevin 21:51, 21 June 2014 (UTC)

Threaded Discussion

Shouldn't the relevant WikiProjects be informed of this RfC? As I have a particular opinion, I don't think I can create a neutral pointer, but at least Numbers, Mathematics, Years, and possibly its parent Time, should be notified. — Arthur Rubin (talk) 09:32, 27 June 2014 (UTC)

Done, also Disambiguation. So minimal as to raise no question of neutrality. PamD 14:24, 27 June 2014 (UTC)

Support

  1. Support as proposer. --NYKevin 21:51, 21 June 2014 (UTC)
  2. Semi-support (first renaming only, i.e. years to include an indication such as AD or CE) – including up to three digits. But oppose renaming of articles on the numbers to remove the disambiguator: that would be unnecessary. However, I support that the freed up number like 5 become redirects to the correspond 5 (number) etc. On matters like this, a uniform convention should be the objective. —Quondum 23:49, 21 June 2014 (UTC)
  3. Support first half per Quondum. The current situation is truly awkward and needs to be solved. --cyclopiaspeak! 22:05, 22 June 2014 (UTC)
  4. The number is the primary topic at least for numbers up to a couple hundred. For consistency's sake, numbers and years should not be treated differently than chemical elements or countries: they occupy the un-disambiguated top spot only if they are the clear primary topic. —Kusma (t·c) 09:34, 27 June 2014 (UTC)
  5. Strong support I don't think of natural numbers below 1000 as years without an explicit AD/CE or BC/BCE. The number is clearly the primary topic until about then (rounding to an order of magnitude to be somewhat consistent and not have to decide on a case-by-case basis). Double sharp (talk) 10:38, 1 July 2014 (UTC)
  6. Strong support and people who will be upset will need to build a bridge and get over the AD/CE thing. Red Slash 05:46, 9 July 2014 (UTC)

Oppose

  1. Oppose for consistency's sake. --AmaryllisGardener talk 23:37, 21 June 2014 (UTC)
  2. . A year is not a number. A year is a space of time conventionally designated by a number, conventionally written as an cardinal number, but actually meaning the first [etc] year of the particular era. DGG ( talk ) 05:47, 22 June 2014 (UTC)
  3. Oppose for now. To much drama creation potential. You first need to solve the harder problem of AD vs. CE. --Stephan Schulz (talk) 22:07, 22 June 2014 (UTC)
    We already have a precedent: 1 BC, 50 BC etc. Given this, do you anticipate it to be the source of a holdup? —Quondum 23:07, 22 June 2014 (UTC)
    AD vs CE provokes quite deep feelings on both sides. I wouldn't be surprised if the BC precedent were challenged if this proposal moves forward. And AD's meaning is potentially more offensive than BC. The present approach is an effective way to avoid a conundrum with no right answer. Add me to the Oppose count.--agr (talk) 01:44, 30 June 2014 (UTC)
    Couldn't the AD-vs-CE debate be sidestepped entirely by using "(year)" as a disambiguator, as in "43 (year)"? — Jaydiem (talk) 22:27, 21 July 2014 (UTC)
  4. On balance, Oppose. I do see the point you're making, but we need to consider what people are likely to be thinking when they type a number into the search box. My suspicion is that people who are able to type '5' or '99' probably have an idea what these characters represent as numbers. When I look at 5 (number) I certainly see a lot of stuff, but it's of the form "the third prime number" or "there are five Exceptional Lie Groups" or "the atomic number of Boron", and so on. These sorts of things are certainly true, but I imagine they're more likely to be encountered as part of searches for prime number, Exceptional Lie Groups, Boron, and so on. The only interesting stuff that is not "accidentally" true of "5" is the history of the glyph. I might be persuadable, but I'm not persuaded so far. RomanSpa (talk) 06:39, 23 June 2014 (UTC)
    Of course you see mathematical information when you look up a mathematical object. How is that unhelpful or unreasonable? I just don't understand this objection. --NYKevin 01:51, 24 June 2014 (UTC)
    I think you've missed my point. Certainly the information that is presented is true, and, as you say, when you look up a mathematical object you see mathematical information. My point is that it's not interesting information. By this I mean that there is no particular reason why "the number of Exceptional Lie Groups" should be the same as "the third prime number" (or, at least, I'm not aware of such a claim). That the two have the same value is just coincidental, so the fact that they do is uninteresting. If it could be proven, knowing only the definition of a prime number, but not knowing that the third one is 5 that the number of exceptional Lie Groups should be the third member of the class of primes, then this would be an interesting result, but even then it would belong in the article on Lie Groups. What I'm trying to say is that most of the stuff about "5" is just a list of unrelated facts that only coincidentally apply to the same number. There's nothing deeper going on. RomanSpa (talk) 07:50, 1 July 2014 (UTC)
    This is an argument to not have articles on numbers at all. I don't believe it's germane to the discussion. If you'd like to do a mass-listing on AfD, feel free. --NYKevin 00:39, 2 July 2014 (UTC)
    It is indeed such an argument. However, we have the precedent that such pages exist, and I currently have no intention of proposing that such a precedent be reversed, as I don't believe that an AfD of the kind you suggest would succeed at the present time. I prefer to reserve my energies for matters of the possible, not the presently impossible. RomanSpa (talk) 04:56, 5 July 2014 (UTC)
  5. Oppose; the benefit from consistency seems to outweigh the benefit of a change (though both seem reasonably marginal). Andrew Gray (talk) 18:38, 23 June 2014 (UTC)
  6. Oppose; discussion on various WikiProjects (Numbers, Years, Mathematics) have lead to no consensus, I think the consistency argument dominates, but the newly created 2719 seems to have developed a local consensus that it shouldn't necessarily be done. — Arthur Rubin (talk) 03:38, 27 June 2014 (UTC)
  7. Oppose, for consistency sake. The benefit of the proposal is marginal (if any), while the drama potential and, more importantly, maintenance efforts (both initial and ongoing) are going to be high.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 27, 2014; 13:23 (UTC)
  8. Oppose: consistency is too useful here to overthrow, but we must be sure that every year page has a crystal-clear hatnote pointing directly to the number as well as the dab page. I think it's standard: I just picked 73 as a non-scientific sample and it looks fine. PamD 14:30, 27 June 2014 (UTC)
  9. Oppose. Consistency for me trumps other considerations. And anyway, this proposal would seem to exacerbate the whole AD versus CE business. Sławomir Biały (talk) 16:10, 27 June 2014 (UTC)
  10. Oppose; in this case, the consistency achieved by having years at all of the undisambiguated titles is more useful than not. Powers T 20:39, 29 June 2014 (UTC)
  11. Oppose at this time because AD vs. CE is not settled. Were that not an issue, I would support adding AD/CE/BC[E] to year articles. However, in any case I oppose dropping (number) from number articles. All bare numbers (1, 25, 308, 1904, 22545 etc.) should be dab pages given the vast possible selection of topics for each number, unless there really is only a single topic in which case the bare number should be a redirect (because they're cheap). This ensures consistency throughout the project, is simple, and avoids pointless conflicts over which article is the primary topic. Ivanvector (talk) 20:36, 4 July 2014 (UTC)
  12. Oppose Going through the archives, if they had decided to remove such they were correct. It is pretty obvious, anyone can understand the year. OccultZone (Talk • Contributions • Log) 10:19, 10 July 2014 (UTC)
  13. Oppose – The value of consistency sways me to oppose, and the dramah potential sways me even further. Mojoworker (talk) 15:33, 15 July 2014 (UTC)
  14. Oppose "A.D." is presumed when there is no A.D. / B.C. I don't think such a generally accepted rule has to be amended. For the disambiguation issue, almost everyone seeing "5" in most articles (that is, non-mathematical articles) would expect a link to the year, as no one links "5" in those articles to the number, but there are people linking it to the year.Forbidden User (talk) 16:09, 17 July 2014 (UTC)
  15. Oppose, the drama potential with this change just screams "what could possibly go wrong"... Titoxd(?!? - cool stuff) 22:54, 21 July 2014 (UTC)

Polls are evil

  1. I'm going to hang out here on the Group W bench and watch for a bit. — {{U|Technical 13}} (e • t • c) 22:42, 21 June 2014 (UTC)
    How is this related to the topic?Forbidden User (talk) 09:35, 13 July 2014 (UTC)
    There is something to be said for listening first and deciding second. =) — Jaydiem (talk) 22:49, 21 July 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Quality review for policy pages, guidelines, and high-impact essays

Would the project benefit if we had a semi-formal mechanism for submitting policy pages, guidelines, and high-impact essays to some sort of semi-formal assessment, from a quality and clarity of writing point of view? If that is of interest, as part of its execution I'd especially like to see a form of Usability testing where eds were asked to read and then say back what they think the text of these pages means. This is a way to

  • Identify matters where such pages have fallen behind the evolution of consensus, and
  • Sniff out technical writing that needs to be improved for clarity.

A semi-formal process would also help bring fresh eyes and new vigor to efforts at improvement, where the status quo is too strong for editors who stop by one-at-a-time to really market improvement ideas.

If this is a perennial topic, I apologize for not spotting the thread and would be grateful for a link. NewsAndEventsGuy (talk) 00:26, 24 July 2014 (UTC)

I actually have just had this put on my talk page and frankly ...I have no clue what this editor is attempting but is quacks too loud for me.--Mark Miller (talk) 04:30, 24 July 2014 (UTC)
Goal is to discuss an idea that could lead to even better technical writing to describe current consensus, in the belief this could reduce misunderstandings. That would have the following benefits
  • Lighten the load on administrators and DR volunteers,
  • Increase editor enjoyment, and
  • Make such pages more newbie-friendly thereby contributing to editor retention.
NewsAndEventsGuy (talk) 09:09, 24 July 2014 (UTC)
We already have a review process for new articles. How is this different?--Mark Miller (talk) 17:10, 24 July 2014 (UTC)
Sounds like you mean AFC for new articles as described at Wikipedia:So_you_made_a_userspace_draft#Ready!. This is different in that it pertains to things other than "articles" and it is about existing things instead of just new ones. NewsAndEventsGuy (talk) 17:27, 24 July 2014 (UTC)
No, I mean new articles as well as articles that have existed for a limited amount of time (in the main space), are all reviewed by editors to check if they are legitimate articles. AFC is for reviewing only drafts. So your proposal is to go back through every article (or, I guess a nomination process) and re-review it under new standards that, while your proposal states this to be akin to Usability testing sound more like Usability inspection because you are not testing the "product" (the article) on real users but asking for experts to evaluate the article. Giving you the benefit of doubt could you detail exactly how this would improve the load for the DR volunteers, increase editor enjoyment and contribute to editor retention? As an editor that volunteers at the DR/N and very much concerned with editor retention, I just don't see how this would improve those areas.--Mark Miller (talk) 18:04, 24 July 2014 (UTC)
It's a good but premature question about the mechanics, but the question is whether the community perceives a partially unmet need. If there is no need, then no one needs to spend brancells on suggesting possible mechanics.

For articles, we did decide that the "regular editing process" was good, but could be improved by creation of the Wikipedia:Version 1.0 Editorial Team/Assessment process. What about these other pages? The "regular editing process" is good for Policies/Guidelines/HelpPages/HighImpactEssays, no question about that. The question I'm asking is whether those pages could be even better with some sort of quality assessment process... not designed to alter their operation, but to provide another perspective on the presentation. NewsAndEventsGuy (talk) 18:38, 24 July 2014 (UTC)
We already have a quality assessment process. But I would like to understand your position on how any of this would effect the areas you mention. They are too important to me not to have those answered, since you brought it up as the reasoning for the change or addition of a new process.--Mark Miller (talk) 19:46, 24 July 2014 (UTC)
Are you referring to BRD, normal editing, and VPump discussions or something else? If the latter, and there is a link to a specific process please tell me what it is, because I don't know it. NewsAndEventsGuy (talk) 20:29, 24 July 2014 (UTC)
  • Strong oppose. We already have a well working quality assessment process and this proposal lacks specifics and the OP seems unwilling to discuss this adequately.--Mark Miller (talk) 05:56, 25 July 2014 (UTC)
If you say so. A better assessment is that the "proposals" pump probably wasn't the best location for this question. NewsAndEventsGuy (talk) 06:37, 25 July 2014 (UTC)
Could be...or it could be that you are not answering questions and don't know the processes that are already in place. I really tried to give you the benefit of the doubt here. I tried to give you the opportunity to explain yourself better than you did on my page before I deleted it as nonsense. You are clearly showing your competency here. I suggest you stop, take time to get to know Wikipedia and regroup. Just lacking competence is not something that will hold you back forever. All one need do is...research. Its what we do here. Try it. But, I also feel you don't fully understand the article link you left and that doesn't give me a lot of faith in your ability to understand what you are attempting.--Mark Miller (talk) 06:56, 25 July 2014 (UTC)
Whatever you say Mark. NewsAndEventsGuy (talk) 07:02, 25 July 2014 (UTC)
No. I am just one editor.....but the only one who has responded. It isn't as if this page has no editors viewing it. Seriously dude...if you have to have Wikipedia's quality assessment explained to you and are truly unaware of it.....I don't know what to say but....do you even read the article talk pages before you come to the village pump to make a proposal?--Mark Miller (talk) 07:44, 25 July 2014 (UTC)
The closest thing to this is probably Wikipedia:WikiProject Policy and Guidelines, which you could try to WP:REVIVE. There's also one for the Manual of Style and another WikiProject specifically for Essays. WhatamIdoing (talk) 18:47, 25 July 2014 (UTC)
Thanks, I may followup with one or more of those one day. NewsAndEventsGuy (talk) 19:15, 25 July 2014 (UTC)

A Wikipedian approach to digital democracy?

Hello everyone (and with apologies if this isn't the best place for this),

tl:dr - Wikimedia UK and Demos are looking to community-source a submission to the Speaker's Commission on Digital Democracy and we need your help! Get involved here

Recently the Speaker of the House of Commons established a commission to investigate the opportunities digital technology can bring for parliamentary democracy in the UK. This consultation is a public exercise which attempts to explore various themes relating to digital democracy.

Wikimedia UK and Demos, working with Wikimedians, have been exploring whether the norms and values of the Wikimedia community can be applied to this kind of consultation, especially the consensus-based approach to writing and enacting Wikipedia policy.

The experiment has been going well and led to a community-sourced submission to the first theme which was looking at how technology can facilitate better scrutiny of the work of Parliament. You can view this submission here – https://meta.wikimedia.org/wiki/Connecting_knowledge_to_power:_the_future_of_digital_democracy_in_the_UK_(Archive_1). The talk page is also worth a look as the discussion offered some really useful insights into how the content was reached.

However, we need your help. The second theme of the consultation has now been published and it is about digital representation. We would love for as many people to take part in this exercise as possible. The Commission was really appreciative of the efforts of the community first time around and it would be great to come up with another excellent community-driven submission. You can view the questions that are being asked, and participate in creating the submission, here.

A third theme will follow in the next couple of months and a similar approach will be taken then. Finally, once the Commission closes for submissions, Demos and Wikimedia UK will write up a comprehensive report on the process and what we have learned which we will, of course, make available to the community.

Thank you for any and all help, it is very much appreciated. Stevie Benton (WMUK) (talk) 15:41, 28 July 2014 (UTC)

Reducing the personalization of discussions by advocating WP:AVOIDYOU

PROPOSAL - Create Template:AvoidYou

GOAL - Teach about WP:AVOIDYOU and discourage personalization of discussions

USE - for use on talk pages; anyone can insert in others' comments

HOPE - Eds will be trained to WP:FOC

NewsAndEventsGuy (talk) 07:59, 29 July 2014 (UTC)

You must be kidding. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 30 July 2014 (UTC)

Anti-sabotaging actions on Brazilian Air Force article

I've recently updated the Brazilian Air Force article, but an anonimoous editor put it off and added wrong information. I do believe someone or some people are up to prevent the article for being updated. I ask, then, the administrators to limit edition to logged in editors only.

See changes here: https://wiki.riteme.site/w/index.php?title=Brazilian_Air_Force&action=history

Thanks, imtoohumble

Requests for page protection should be made at WP:RPP, but in this case there has been no vandalism for two days and so nothing is likely to come of it. Sam Walton (talk) 22:05, 31 July 2014 (UTC)

pathfinder

Good day,

I am a professional librarian who always recommends wikipedia to my customers as a great place to start their research obtaining ideas, up to date entries, search terms they might not have considered, and so forth.

I woul like to propose that you start a new project area, "Pathfinders" that provide an additional first stop for these same customers, or incorporate a pathfinder section in each wikipedia page.

A disclaimer that every effort is made to provide all sides to an issue if it is currently the realm of hyperbole, hyperpartisanship, reactionaries, as well as scholarly research and writing.

Here is an example of a pathfinder that I co-wrote with some librarian colleagues a few years ago and provides a basic structural outline that could be used:

http://odhitech.net/rose/womensciencepathfinder/index.htm

There are many, many professional librarians who would probably like to contribute the pathfinders they have aggregated for their various customer bases (public, academic, special library, etc).

Melissa V Rentchler

www.linkedin.com/in/melissarentchler/

Los Alamitos, CA USA — Preceding unsigned comment added by 71.107.71.219 (talk) 23:49, 27 July 2014 (UTC)

I've fixed the formatting for legibility. הסרפד (call me Hasirpad) 18:52, 28 July 2014 (UTC)
I'm not aware of anything in Wikipedia quite like your concept of pathfinders, but we do have a couple of facilities which might be of interest to you.
Outlines provide structured information to allow a user to see the overall structure and layout of the information related to a subject. See Portal:Contents/Outlines for a list of outlines.
Portals help readers navigate their way through Wikipedia topic areas through pages similar to the Main Page. Portals were most popular on Wikipedia about 8 years ago, and some are no longer actively maintained. There's a list of portals at Portal:Contents/Portals.
You might also find other entries in Portal:Contents of use to you.-gadfium 22:17, 28 July 2014 (UTC)
Hi Melissa, a tool/project that i am quite excited about is Wikipedia:Forward to Libraries by user:JohnMarkOckerbloom. It's not a content guide, but rather the "missing link" to libraries worldwide, by using the Wikipedia article title as a subject or keyword search in the user's library of choice OPAC (or VIAF, if available). I'd love to hear your thoughts on this and on how to improve this service. :-) --Atlasowa (talk) 14:37, 29 July 2014 (UTC)
See also: Wikipedia:WikiProject Libraries and WP:GLAM. --Piotr Konieczny aka Prokonsul Piotrus| reply here 08:47, 5 August 2014 (UTC)
What we mean by "pathfinder" is a structured page on a specific topic; I had to create one of these in library school. A portal page isn't precisely what Ms Rentchler is talking about, but it serves basically the same purpose and is laid out largely the same. Nyttend (talk) 01:48, 6 August 2014 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_112&oldid=1251383419"