Wikipedia:Village pump (proposals)/Archive 136
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
Make it clear that talk pages are for discussion and not for info about the user
Frankly, I've been seeing a lot of new editors putting something like just their full name with no other content surrounding it on their user page (not quite sure what's causing that one), and then putting the actual user info on their talk page. I think we should put a statement like "Talk pages are for discussion with other users. If you want to add info about yourself, go to your user page." when an editor is creating their own talk page, so people don't get confused. – 🐈? (talk) 18:58, 8 December 2016 (UTC)
- Users can pretty well manage their talk pages and user pages anyway they care to. GenQuest "Talk to Me" 01:37, 9 December 2016 (UTC)
- Yeah. It's up to them, and they'll get the idea within a few days of editing anyway. Ramaksoud2000 (Talk to me) 17:56, 13 December 2016 (UTC)
- OK to give general guidance, but strong opposition to enforcement: if they want to put some non-discussion information on their own user-talk: so what? I personally do this all the time - on most other language projects I use a SUL userpage, but make the top section of my talk page include local project information (e.g. a xx-0 template if I don't speak that language, a collection of local project links, etc). — xaosflux Talk 18:39, 13 December 2016 (UTC)
In the edit toolbar, make "search and replace" viewable outside of "advanced"
In the Wikipedia edit toolbar, the "search and replace" button it only viewable in the "Advanced" submenu. I spend a lot of time switching between the "Cite" function and "Advanced", and clearly there's room for the Search and replace function to co-exist. The placement of it could even go next to the bold/italic functions. --Jennica✿ / talk 16:37, 14 December 2016 (UTC)
Erm, where should I be now?
Sry to be on the wrong page but need direction as to where to go when someone is continuously referting a sensible Prod - Second city of the United Kingdom thanks in advance. MarkDask 23:26, 16 December 2016 (UTC)
- Just nominate the page for AFD. — xaosflux Talk 23:46, 16 December 2016 (UTC)
- Prods can be removed and should not be restored, but this was an AfD. The problem is that a new discussion page needs to be created. It would need to be at Wikipedia:Articles for deletion/Second city of the United Kingdom (2nd nomination). -- zzuuzz (talk) 23:54, 16 December 2016 (UTC)
Best translation of de:Wikipedia:Telefonberatung?
Hi, I'm looking for the most suitable translations for the German word "Telefonberatung": Wikipedia:Helpline, Wikipedia:Hotline, Wikipedia:Telephone support, Wikipedia:Telephone coaching, Wikipedia:Call a Wikipedian, or ...?
And is there already any similar project, or has there been one? The project is planned to start in January 2017 with a German toll-free 0800 phone number. As I am fluent in English, we are planning to spread this information also in the English language sister projects. Any helpful contributions are welcome :-) --.js (((☎))) 21:46, 8 December 2016 (UTC)
- Beolingus says "helpline" but our article helpline is all about psychological help. I think I'd pick "phone support" (friendly) or "telephone support" (proper) instead. These are described well at customer support. - Brianhe (talk) 05:39, 13 December 2016 (UTC)
- Who staffs this number? Who "owns" and manages the call distribution? — xaosflux Talk 19:09, 13 December 2016 (UTC)
- @.js: As for the naming convention - redirects are cheap - what is the goal of this number? What situations would it be used for? — xaosflux Talk 02:55, 14 December 2016 (UTC)
- Helpline was a redirect to Crisis hotline, and this was done because the original Helpline article was unreferenced. But that was a very inappropriate redirect, because it restricts the meaning too much. I've restored the original article. Having read the German article, I think WP:Helpline would be a good title. As you say, .js, redirects are cheap, and some of your other suggestions might also be good ones; especially hotline and call a Wikipedian. --Stfg (talk) 08:56, 14 December 2016 (UTC)
- @Brianhe and Stfg: Thank y'all for your answers and good ideas! @Xaosflux: Are you able to sufficiently read/translate de:Wikipedia:Förderung/Telefonberatung? It's similar to the WMF grants, but by the German Wikimedia chapter (WMDE). They will provide the number and telephone infrastructure and a room with a computer. I will be on the phone starting from January 2017 and hopefully some other volunteers, because we have to do it in our spare time. I would love to do it for longer hours, but we will have to see how it develops. It's a Versuchsballon :-) --.js (((☎))) 01:06, 18 December 2016 (UTC)
People born abroad
Do we have a category for people born abroad like Ted Cruz or Keanu Reeves where the parents were expatriates working temporarily in another country? --Richard Arthur Norton (1958- ) (talk) 02:49, 18 December 2016 (UTC)
RfC: AWB bot ref reordering
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.
Should an AWB bot reorder refs? ―Mandruss ☎ 21:12, 19 November 2016 (UTC)
This dispute has apparently been ongoing for seven (7) years, starting when Wikipedia:AutoWikiBrowser (AWB) was modified to support the reordering of a consecutive string of refs into ascending citation number sequence. This function is being used by bot(s) to do these edits on a large scale. I am not going to go into the history of the dispute, as (1) I am not very familiar with it, and (2) I don't think that is relevant or useful to this discussion. Let's pretend that this is 2009, an AWB developer has added reordering per WP:BOLD, and that has been challenged per WP:BRD. This RfC is the D phase of that BRD process. Most recent related discussion: Wikipedia talk:Citing sources/Archive 40#Reference re-ordering.
I am framing this as a question rather than a proposal, but I still think this page (Wikipedia:Village pump (proposals)) is the best venue for this. It could have been done on AWB's talk page with discussion notices here and elsewhere, but those notices don't seem to attract much attention. If someone strongly disagrees with that, they are free to move this.
Suggested !votes are:
Yes - AWB bots should reorder refs
No - AWB bots should not reorder refs
Reforder - Compromise solution described at #Compromise proposal: AWB bot ref reordering. ―Mandruss ☎ 21:12, 19 November 2016 (UTC)
Survey: AWB bot ref reordering
- (no threaded discussion)
- Comment - Note to closer: I strongly feel that a no-consensus result here should mean no AWB reordering; i.e. the consensus burden is on those who wish to reorder. Consensus should be required to make a controversial change, and that change occurred in 2009. ―Mandruss ☎ 21:18, 19 November 2016 (UTC)
- Comment I don't think a "let's pretend" (as in "Let's pretend it is 2009") RFC is a good idea. I would rather discuss either the substantive issue or a way forward. All the best: Rich Farmbrough, 22:47, 19 November 2016 (UTC).
- No. There should be no automated re-ordering of refs to retain the chronological appearance of footnote numbers, particularly not over objections. Previous discussion: Nov 2016, Nov 2016, May 2015, Feb 2015, Feb 2014, July 2010, May 2010, April 2010. The feature was added to AWB in 2009 with very little input. It should have been discussed more widely, because editors may add refs in a particular order for editorial reasons. A simple example:
Mary likes cake, but John doesn't.<ref name=Mary/><ref name=John/>
- Someone will argue that we could place the Mary ref inside the sentence, but when there are lots of refs and several clauses, it looks cluttered to do that. And there may be other reasons for the order, including that the first ref is a primary source and the second a supporting secondary one; that the first discusses the issue more clearly than the second; or that the first is the source most experts in the field will expect to see.According to WP:AWBRULES, "If challenged, the onus is on the AWB operator to demonstrate or achieve consensus for changes they wish to make on a large scale". Study 329 is one example of what happens instead: AWB reordered refs on 4 May 2015. I moved them back. A second AWB editor reordered them on 5 May. I added bots deny to stop it. The second AWB editor removed bots deny on 9 May. A third AWB editor reordered the refs again on 9 May. SarahSV (talk) 00:15, 20 November 2016 (UTC)
- Yes/Reforder Like I said before, refs should be in order. If you have [2][1][14][4], you're telling the reader to jump around a list of reference for no good reason. [1][2][4][14] is the natural way of presenting things. Now if some specific article warrants deviation from this for some obscure reason, then deny AWB on that specific article, but this is a legit fix in 99% of cases. The usual workaround is to use {{R}}, which AWB will leave alone. The <1% of articles that warrants a deviation from this behaviour shouldn't block efforts to improve the presentation on the >99%. I've cleanedup thousands of articles making those fixes for the last 6 or so years, and I've had 2 complaints. A fail rate of 2/10,000+ is more than acceptable. Headbomb {talk / contribs / physics / books} 00:35, 20 November 2016 (UTC)
- I wonder, Headbomb, if there is some misunderstanding here as to how cite numbers are used as cites are in order until someone using AWB comes along and changes them. The cite numbers relate to the order the cites were placed in the article as a whole, not necessarily in the sentence in question. When a cite is used more than once, the number remains the same throughout the article, so the numerical order of cites may appear disjointed in places. Sometimes there may be several cites in one sentence, and if placed next to the information they are citing (which is often done) then the sentence may read "Splot was born in Swansea,[13] on 13 March 2000,[7] to parents John Splot, an organ grinder,[5] and Mary Splot, a Suffragette.[14]" This is appropriate usage, and no AWB would change the sequence order, and the reader could check each item they were interested in by clicking on the number, and going to the relevant citation. However, in order not to inhibit reading flow unnecessarily, we encourage editors to place all the cites at the end of the sentence if none of the statements are likely to be contentious. When placing them at the end of the sentence or paragraph we keep them in order per WP:CITEFOOT: "it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." When someone using AWB shuffles the cites, they are no longer logical or natural, and the reader may well end up confused as to which cite belongs to which part of the sentence, because the natural order has been disturbed. It seems that at the moment when cites are grouped at the end of a sentence some well-meaning AWB user will shuffle the order without realising what they are doing. We should either stop AWB reshuffling the cites, or change our guidance on grouping cites at the end of sentences. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
- [Since SilkTork has repeated this in the #Clarification please section I have moved my reply there.] All the best: Rich Farmbrough, 20:24, 21 November 2016 (UTC).
- [Since SilkTork has repeated this in the #Clarification please section I have moved my reply there.] All the best: Rich Farmbrough, 20:24, 21 November 2016 (UTC).
- I wonder, Headbomb, if there is some misunderstanding here as to how cite numbers are used as cites are in order until someone using AWB comes along and changes them. The cite numbers relate to the order the cites were placed in the article as a whole, not necessarily in the sentence in question. When a cite is used more than once, the number remains the same throughout the article, so the numerical order of cites may appear disjointed in places. Sometimes there may be several cites in one sentence, and if placed next to the information they are citing (which is often done) then the sentence may read "Splot was born in Swansea,[13] on 13 March 2000,[7] to parents John Splot, an organ grinder,[5] and Mary Splot, a Suffragette.[14]" This is appropriate usage, and no AWB would change the sequence order, and the reader could check each item they were interested in by clicking on the number, and going to the relevant citation. However, in order not to inhibit reading flow unnecessarily, we encourage editors to place all the cites at the end of the sentence if none of the statements are likely to be contentious. When placing them at the end of the sentence or paragraph we keep them in order per WP:CITEFOOT: "it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." When someone using AWB shuffles the cites, they are no longer logical or natural, and the reader may well end up confused as to which cite belongs to which part of the sentence, because the natural order has been disturbed. It seems that at the moment when cites are grouped at the end of a sentence some well-meaning AWB user will shuffle the order without realising what they are doing. We should either stop AWB reshuffling the cites, or change our guidance on grouping cites at the end of sentences. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
- Yes As I said earlier, whatever purpose the non-chronological ref order serves may not be clear to the reader. The benefits of doing so, as stated by headbomb above, are clear. Pppery 00:54, 20 November 2016 (UTC)
- Poppery, I have replied to Headbomb's comment, making reference to our existing guidance on how cites are placed at the end of a sentence. Does that make it clearer? SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
- Yes per my discussion below, especially noting that article editors (assuming a consensus) can override the reordering. Ultimately there is no harm and having cites in chronological order should be seen as naturally more convenient for the reader. Stevie is the man! Talk • Work 01:01, 20 November 2016 (UTC)
- Yes - numerical ordering seems almost universal, if not universal, in modern publishing. The "John and Mary" example above is bad referencing. In the rare case that someone insists on out-of-order referencing they have the means to achieve it simply. All the best: Rich Farmbrough, 01:03, 20 November 2016 (UTC).
- Hi Rich, see my reply to Headbomb's comment. I wonder if there is some misunderstanding on how the cite numbering system is being used in an article, because nearly every article will have cite numbers appearing in non numerical order as some are being re-used. Perhaps what is needed is a piece of software that identifies when a cite is used more than once, so people could understand that the number relates to an earlier placing in the article rather than the current one. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
- It is not a question of non-numerical order, but of adjacent cites in non-numerical order. I don't think people have an issue with understanding that a footnote has been referred to again, indeed there is meta-data conveyed by seeing [3][43][128] - albeit unreliable and unintentional.
- I suppose that the superscripts could be of the form[2a] and[2b], but I don't think this solves any real issues.
- All the best: Rich Farmbrough, 20:34, 21 November 2016 (UTC).
- Hi Rich, see my reply to Headbomb's comment. I wonder if there is some misunderstanding on how the cite numbering system is being used in an article, because nearly every article will have cite numbers appearing in non numerical order as some are being re-used. Perhaps what is needed is a piece of software that identifies when a cite is used more than once, so people could understand that the number relates to an earlier placing in the article rather than the current one. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
- Supplementary Various editors have said that they arrange reverences in order of: i) relevance, ii) importance, iii) date and iv) the items they support - as well of course as the industry standard v) numerical order. While these schemes may have something to recommend them (except when they are WP:SYNTH) I see no way for a reader to know in advance which of the five applies, or whether it is actually vi) happenstance. Without this the value of these alternative schemes is pretty much moot. All the best: Rich Farmbrough, 19:55, 4 December 2016 (UTC).
- No. If an editor reviews the refs and decides they should be reordered, that's fine, but since there are occasionally reasons to have non-ascending order, this ought not to be done by bots or by semi-automated edits. Mike Christie (talk - contribs - library) 01:04, 20 November 2016 (UTC)
- No, but (see comment below) I think the wrong question is being asked here. And aside from personal preferences, why should it matter so much that ascending order should be mandatory? ~ J. Johnson (JJ) (talk) 03:04, 20 November 2016 (UTC)
- No Editors can, and do, arrange adjacent references to put to the most relevant one first, followed by more secondary ones; it is not "universal" for citation numbers to always appear in increasing order when they are adjacent. The usual rule in WP:CONTEXTBOT, part of the bot policy, is that bots should avoid making changes (such as changing spelling or rearranging references) which would require a human to review the context and determine whether a change is appropriate. That is the case here - only human review can determine the best order of the references. Given that the references are hyperlinked and numbered, there is no difficulty in finding them in the reference list regardless what order they appear in the body text. — Carl (CBM · talk) 04:34, 20 November 2016 (UTC)
- No I frequently arrange references in a particular order: sometimes most relevant first, sometimes in date order. (An example of the latter would be when writing something like: "Many studies between 2004 and 2016 have shown ..." – the references supporting this need to show clearly the time span involved.) Bots should not make context-sensitive changes, over-riding editors' choices. Peter coxhead (talk) 07:54, 20 November 2016 (UTC)
- Yes because it looks messy. In any given article, the ordering of the reference numbers could be accidental, or could be trying to signal some subtle distinction between the references. But readers cannot tell the difference. If editors intend the ordering of the reference numbers to mean something to the reader, then it would be better to find a different way to express that meaning. -- John of Reading (talk) 08:11, 20 November 2016 (UTC)
- Yes Having references appear in numerical order in the text is part of basic proofreading. Not doing it gives the appearance of a typed term paper prepared by a schoolboy for whom arranging for such niceties is real work, requiring the retyping of the entire paper. this is one of the many points of good style which were difficult to achieve with a typewriter but were the mark of professional work; they're now easy, and we should take advantage of it . DGG ( talk ) 08:24, 20 November 2016 (UTC)
- No - as per CBM and Peter's comments. Hchc2009 (talk) 08:30, 20 November 2016 (UTC)
- Yes; useful, not a problem for the vast majority of pages, and easily solvable for those which need a different order. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:50, 20 November 2016 (UTC) No per SlimVirgin aka SarahSV. In the precursor discussion, I showed an actual real-life case where I feel my ability to control the cite order was useful to at least some readers. That was not disputed. I strongly suspect other editors could point to other such cases. In contrast, to my knowledge no one has shown actual real-life cases where readers benefit from ascending sequence, and that claim is strongly disputed. The arguments in support of reordering are therefore nothing but unproven theories, unsupported assertions. ―Mandruss ☎ 10:13, 20 November 2016 (UTC)- "No one has shown actual real-life cases" How about nearly 100% of professional journals putting references in order? Headbomb {talk / contribs / physics / books} 10:52, 20 November 2016 (UTC)
- Taking your word for that, how does that show benefit to the reader? ―Mandruss ☎ 11:31, 20 November 2016 (UTC)
- For instance, many books that I read have endnotes divided by chapter, with numbering starting over for each chapter. When I go to look up the note, I see that here are the notes for Chapter 5 and for Chapter 6, but I have no idea what chapter I'm on, so I have to go back to the page where I saw the note, and if the chapter title isn't in the header, I have to flip back top the top of the chapter and find out what the chapter number is. Only then can I actually look up the note. That's pretty standard practice in book publication (although there are the nice books that list the name of the chapter in the notes section, or the page numbers the notes fall on), but it just because it is standard does not mean that it is beneficial to the reader. It's just the way things are done. To say that notes out of order are confusing is untrue because even when they're re-ordered, they don't go 1,2,3,4... in the body of the article, they go 1,5,8,14, because that's where the references just happen to fall. I see no benefit to 1,5,8,14 over 14,5,8,1 when 14 is the most important reference for that section and the others are less important. Give the reader what is primary first, not the reference that just happens to have a low number because it appears earlier in the article then another. There is no intrinsic quality to the number of a reference, it's all just happenstance. Beyond My Ken (talk) 23:49, 22 November 2016 (UTC)
- Taking your word for that, how does that show benefit to the reader? ―Mandruss ☎ 11:31, 20 November 2016 (UTC)
- "No one has shown actual real-life cases" How about nearly 100% of professional journals putting references in order? Headbomb {talk / contribs / physics / books} 10:52, 20 November 2016 (UTC)
- Reforder - reasonable compromise. Out-of-sequence limited to those cases that need it per editor discretion. The idea of the Reforder option is that intentional out-of-sequence ordering will be far more effective if not lost in a forest of unintentional out-of-sequence ordering. In that sense AWB can be the friend of editors who use cite ordering, not their adversary. ―Mandruss ☎ 12:30, 20 November 2016 (UTC)
- No. Automation should not override editorial discretion. There's no justification for the claim that refs not in chronological order would confuse readers. Few readers check references. Those that do -- the more scholarly ones, I'd say -- will be more than capable of choosing the order in which they check them. --Stfg (talk) 10:55, 20 November 2016 (UTC) Please note: I oppose the Reforder option added this morning. It would require editors who have already created articles to go back to them to add the option retrospectively. --Stfg (talk) 12:49, 20 November 2016 (UTC)
- No - It is reasonable that a more relevant source would be cited before one with less relevance when both are being cited back to back.— Godsy (TALKCONT) 12:35, 20 November 2016 (UTC)
- Reorder - per Headbomb's continuous remarks. --Dirk Beetstra T C 13:22, 20 November 2016 (UTC)
- No - As stated above, editorial decision should not be overridden by automation when there is a reasonable purpose in the decision designed to aid the reader. More broadly, we should be an encyclopedia which primarily cares about content, not one which is rule-bound to the detriment of content. Beyond My Ken (talk) 18:01, 20 November 2016 (UTC)
- No — "Quotation stating idea"10 (source of quotation)1 (ref supporting statement) should not be reordered. I also put the best reference for a statement first in the list. Glrx (talk) 18:35, 20 November 2016 (UTC)
- Yes – It makes no sense for ref 5 to go after ref 6 if it is invoked. Dustin (talk) 19:09, 20 November 2016 (UTC)
- No, although the damage is done. There are probably hundred thousands of articles[notes 1] with references in the wrong order (in the sense of being different than any actual editor intended). I see no benefit to the reordering, and some (often slight, but occasionally serious) damage to understanding. (As an aside, a bot should tag all articles with multiple consective references/notes which were ever touched by AWB or a bot, for potential errors caused by this mistake.) — Arthur Rubin (talk) 22:01, 20 November 2016 (UTC)
- Yes because non-ordered references only are confusing to readers -FASTILY 22:49, 20 November 2016 (UTC)
- No per Sarah. Nikkimaria (talk) 00:53, 21 November 2016 (UTC)
- Yes, reorder. I wasn't aware this had been disputed for seven years, or really ever, because it seems completely obvious they should be in numerical order. I don't much care what "professional journals" do - we're the 800-pound gorilla of book-report plagiarism material and bar-bet-settling, so we can do what we want ;) But I do care that readers actually understand what they're looking at, and [15][5][2][12] is harder to read and forces people to jump around in the reference list. "But the order I wrote them in is important!!" is the kind of thing I can imagine convincing myself of while in the middle of writing an article, but it's self-delusion; the number of readers who would see that, assume the order was significant, correctly interpret why the author ordered them as they did, and actually care about the result, is indistinguishable from zero. Worse, without automatic reordering, the likelihood that any given out-of-order reference list is significant actually declines, because almost nobody is going to reorder them manually. There are workarounds for the rare circumstance where order actually does matter; use those if you must and let the rest of us sit back and let the bots fix our sloppiness. Opabinia regalis (talk) 04:10, 21 November 2016 (UTC)
- "Nobody is going to manually reorder them," means that the order is not that important. I reordered several long, ref lists a few times, before stumbling upon a bot edit that was undoing my work. The edit description gave no indication of what the bot was doing. Workarounds make it more difficult for other inexperienced editors to understand and participate in updating, correcting or improving the text. Bcharles (talk) 09:57, 23 November 2016 (UTC)
- No. I complained ref reordering in gen fixes last year. The main reason is because while it might be more aesthetically pleasing to some, I order my refs by priority (best refs first, secondary or duplicate refs second). If a sentence needs multiple footnotes and the citation style doesn't suit shoving both lines into the same ref, ordering by priority makes the most sense. (This has not been contested across multiple FARs so I consider it a common sense understanding. It's also silly to call this "delusion"—readers check the refs in order.) Gen fixes are supposed to be inoffensive, which is why they minimize white space disruption and so on. Gen fixes should not impede productive work in drive-by ref reordering. czar 05:39, 21 November 2016 (UTC)
- No unless we change WP:CITEFOOT to alert editors that a bot may change the logical order of end sentence cite into a purely numerical one, so if the order if relevant then the cites should be placed right next to the relevant information, and if this inhibits reading flow (so making grouped cites preferable) then to put in a command to prevent a bot changing the order. I do think though that it would be simpler to stop AWB from reordering cites. SilkTork ✔Tea time 14:09, 21 November 2016 (UTC)
- No I often will place references in a particular order, with a more specific reference first up and a more general secondary source to follow. Jumbling up will be a disservice to the reader. The foot notes are not hard to find in our online edition, since you just click on the number and the brower navigates and highlights the reference. Graeme Bartlett (talk) 22:41, 21 November 2016 (UTC)
- Yes with the understanding from several of the "no" !votes above that there is a legitimate time and place to use references in non-numerical order (several valid examples cited), and that we have at least one way, via {{R}}, to "protect" that order from bots or random gnomish editors that would otherwise come by and fix it. I understand the concern of this being added to AWB, but there are lots of wikignomes that will do this ref order adjustment to, and, unlike something like DATERET where we have templates to alert editors to a selected style, a reforder aspect will not be clear unless one uses inviscomments or a template like {{R}}. Setting up guidelines when one should force a ref order, and how to indicate that to any other editor without minimal of fuss, would be useful result from the above discussion. I think what we have to recognize is that most readers and editors appear to see the mixed numerical order of a forced reforder as "wrong" and will want to try to fix it, being just as unaware of any previous talk page or consensus discussion that AWB has, and we should find a way that doesn't affect this but does keep editorial discretion, of which there is at least one way; more options should be explored. --MASEM (t) 17:17, 22 November 2016 (UTC)
- This argument amounts to saying "We won't be able to stop gnomish editors doing it anyway, so let's allow AWB to do it." It seems a very unsatisfactory reason to me. Peter coxhead (talk) 17:44, 22 November 2016 (UTC)
- No. There are good reasons for manual control of reference order, for example so that they reflect the logical sequence of the statement they substantiate, or emphasising a key reference over subsidiary ones. The burden shouldn't be placed on content editors to "protect" these decisions from AWB operators. No professional copy-editor in an academic context would arbitrarily re-order the references as written by the author! Joe Roe (talk) 18:57, 22 November 2016 (UTC)
- The idea of the Reforder option is that intentional out-of-sequence ordering will be far more effective if not lost in a forest of unintentional out-of-sequence ordering. In that sense AWB can be the friend of editors who use cite ordering, not their adversary. ―Mandruss ☎ 19:39, 22 November 2016 (UTC)
- This isn't the case at all; in my field (biochemistry/bioinformatics) I can't find any journals that would allow multiple numbered references in non-sequential order. Here's the American Chemical Society guide, for example: [1]
When citing more than one reference at one place by number... list the numbers in ascending order
. Opabinia regalis (talk) 20:03, 25 November 2016 (UTC)
- No. The use of references in Wikipedia has historically been tolerant of a wide range of reference styles and philosophies. There have been arguments and controversies, but the consensus is that uniformity is not necessary. We have two major styles of templates (now wrappers of a single implementation). We use parenthetical as well as numbered references. We have references declared in the text and references instead declared in lists at the end. We have many editors who avoid templates in favor of manually formatted references. In this spirit automating a reordering of reference numbers (I assume "chronological" doesn't mean the date of the reference) in the face of even a minority opposition goes against this long standing consensus. StarryGrandma (talk) 19:20, 22 November 2016 (UTC)
- No. Wiki articles are continually changing, and the numerical order of refs will sometimes change over time. The placement of refs in a sequence is often deliberate and should not be altered without consideration given to the context (by a human editor). The diversity of contexts in which issues of ref order occur indicates that one rule will not satisfy all cases. The numerical order in text is trivial relative to other considerations (e.g. primary, secondary, tertiary importance; relevance; clause order; list item order). Bcharles (talk) 09:57, 23 November 2016 (UTC)
- Big no. In a string of multiple refs, the most relative and directly supporting should be first, even if that makes the ref numbers not be strictly increasing. This is particularly true of the first ref because in practice I often have situations where one source cites 90% of the material in a statement and the remaining refs are much less important to the overall verifiability. I don't want the highly import ref to be shuffled among those less important refs. I want it to be first. Jason Quinn (talk) 00:28, 24 November 2016 (UTC)
- No - proposal is ill-prepared as to describing the mechanism, what necessitates it, and what the other consequences might be. It seems an frivolous automation that would be restricting possible editor wishes that might cause problems. Just because one can isn't a reason to do it, it's a reason things go wrong. Markbassett (talk) 20:58, 24 November 2016 (UTC)
- No. A substantial quantity of unordered refs is intentionally "disorderly", and the vast majority of those doesn't use {{R}}. In addition, there is also likely just as large a quantity of currently ordered refs, whose order is meaningful but not protected with {{R}}, because it has not yet occured to the article editors that a future edit can mix up ref numbers. All in all, this is a job that should be left to humans who leave human edit summaries, and not to AWB users, whose edits I never check on the watchlist, because I assume that the app knows what it's doing. Daß Wölf 00:40, 25 November 2016 (UTC)
- No If an editor spends significant time fixing issues in a particular article, they might reorder or otherwise rearrange some refs as part of that work—good! However, mindless reordering by bot is not helpful because someone who actually understood the topic and who actually read the references took a decision about how the references should be arranged. Many inconsistencies are tolerated (WP:ENGVAR and WP:CITEVAR) and always displaying numbers in ascending order is trivia. Johnuniq (talk) 02:22, 25 November 2016 (UTC)
- Well said! Beyond My Ken (talk) 17:31, 25 November 2016 (UTC)
- Alternatively, the editor who has spent significant time fixing an article was concentrating on the content and didn't try to redistribute the references so they'd come out in some allegedly significant but in practice inscrutable non-sequential order, because they knew that a bot would eventually stop by to fix it ;) Opabinia regalis (talk) 20:03, 25 November 2016 (UTC)
- I frequently modify my notes so that the bot that eventually comes by won't break them by trying to merge them using named-refs. ~ J. Johnson (JJ) (talk) 22:58, 25 November 2016 (UTC)
- That is probably the case quite often, Opabinia regalis, but not always, and it isn't fair to assume it. We're talking about an automated assumption here. If I read "Smith said 'the sky is green' and Jones agreed.[m][n]", then I'd expect m to refer to the Smith reference and n to refer to the Jones. If Jones has been cited before Smith earlier in the article, then numerical ordering won't give this. The numbers reflect the order in which sources were introduced in the article, not the order in which they apply to a specific sentence. What is done in the journals in one specific field is irrelevant here, as is any opinion about what is "better"; the latter depends on your mileage. All we're talking about here is the extent to which automation should automate one way of going about it. --Stfg (talk) 13:50, 26 November 2016 (UTC)
- Obviously, the correct way to write that in a context where someone might come along and edit the text is "Smith said 'the sky is green'[m] and Jones agreed.[n]" Less obviously, but importantly, if you really want your out-of-order references to communicate anything to the reader other than "this article was sloppily edited", then you should be all for automated reordering. Since most instances of non-sequential references are unintentional and meaningless, removing them makes your intentional ones more likely to stand out. The simple solution to this problem is for people who think they're communicating something significant with their reference order choice to annotate this by using one of the already-available workarounds. Opabinia regalis (talk) 04:44, 27 November 2016 (UTC)
- I used to be in favour of mid-sentence citations for precisely that reason, but turned against them after seeing an experienced FAC reviewer give them very grudging acceptance. I'll reconsider that. For the rest, if language like "obviously", "if you really want ...", "sloppily" comes into it, I fear we'll just have to agree to disagree. Language like that does little to advance a rationale; more, perhaps, to express an attitude to those who disagree with you, but that's not my problem. This is only a matter of taste after all. I remain unconvinced. --Stfg (talk) 19:17, 27 November 2016 (UTC)
- The preferences of FAC reviewers, experienced or otherwise, is very much the tail wagging the dog; the huge majority of articles where this is done are not FA candidates. I don't mean anything by the language - "sloppily" was in reference to my previous vote, where I was talking about myself - but to be honest, I do think it's obvious that people who want to use non-sequential references to signal meaning are voting against their own interests here. Opabinia regalis (talk) 22:55, 28 November 2016 (UTC)
- Thanks. Fair point about FAC, but the reviewer did offer reasons. The main one was the appearance of fussiness. From my own experience, general readers can find those little superscripted numbers burdensome and may not realise that they don't have to check out every single one. There is a significant difference between an encyclopedia and a professional or academic journal here.
A thought that crosses my mind is that professionalism (if that is what it is) in the presentation of citations really only matters at the top quality end of the encyclopedia, where one might hope that an article would have several watchers interested in maintaining quality and would take care over this. (Or am I being naively optimistic in that? :)) At lesser quality levels, the order of citation numbers is rather the bicycle shed compared to the nuclear power station of journalistic writing, gushing fandom, misreading of sources, self-promotion, and all the other horrors we all see every day. So at one end, I suspect, this automated action may be a nuisance; elsewhere, it's almost certainly an irrelevance.
One point that I do think matters: I'm here because articles in which I took care over this sort of thing, and that I'm watching, suddenly got hit by this automation. Yes, I now know there are workarounds, but I didn't know them then and they are not widely advertised. The automation is implementing a preference of certain editors, not something the MOS requires. I am unhappy that that was done without consensus to do it. That probably can't be undone now, but imho it shouldn't continue until the real discussion has been held: not about what automation is allowed to do, but about what the MOS should say about the presentation of citations. --Stfg (talk) 10:56, 29 November 2016 (UTC)
- Thanks. Fair point about FAC, but the reviewer did offer reasons. The main one was the appearance of fussiness. From my own experience, general readers can find those little superscripted numbers burdensome and may not realise that they don't have to check out every single one. There is a significant difference between an encyclopedia and a professional or academic journal here.
- The preferences of FAC reviewers, experienced or otherwise, is very much the tail wagging the dog; the huge majority of articles where this is done are not FA candidates. I don't mean anything by the language - "sloppily" was in reference to my previous vote, where I was talking about myself - but to be honest, I do think it's obvious that people who want to use non-sequential references to signal meaning are voting against their own interests here. Opabinia regalis (talk) 22:55, 28 November 2016 (UTC)
- Perhaps people who think cosmetic appearance should be more important than any other kind of significance could be persuaded to not use named-refs. That is the simplest solution. ~ J. Johnson (JJ) (talk) 22:35, 27 November 2016 (UTC)
- I used to be in favour of mid-sentence citations for precisely that reason, but turned against them after seeing an experienced FAC reviewer give them very grudging acceptance. I'll reconsider that. For the rest, if language like "obviously", "if you really want ...", "sloppily" comes into it, I fear we'll just have to agree to disagree. Language like that does little to advance a rationale; more, perhaps, to express an attitude to those who disagree with you, but that's not my problem. This is only a matter of taste after all. I remain unconvinced. --Stfg (talk) 19:17, 27 November 2016 (UTC)
- Obviously, the correct way to write that in a context where someone might come along and edit the text is "Smith said 'the sky is green'[m] and Jones agreed.[n]" Less obviously, but importantly, if you really want your out-of-order references to communicate anything to the reader other than "this article was sloppily edited", then you should be all for automated reordering. Since most instances of non-sequential references are unintentional and meaningless, removing them makes your intentional ones more likely to stand out. The simple solution to this problem is for people who think they're communicating something significant with their reference order choice to annotate this by using one of the already-available workarounds. Opabinia regalis (talk) 04:44, 27 November 2016 (UTC)
- No For reasons given by many others, this is placing 'tidiness' over any editorial judgement (best source, most relevant source, most comprehensive source, before secondary or supporting sources that may merely confirm some detail). A tool capable of ordering, in the hands of an editor familiar with content, might be useful for those who wish to use it, but having bots going around re-ordering with no notion of why the refs are ordered as they are, is not a net gain IMO. OK, many articles are reffed chaotically at present, not only 'un-numerically', but because of editors putting new refs at the end of the list, or conversely in 'pole position', rather than as a result of editorial judgement, but having refs look neat, but remain 'content/relevance chaotic' is not an improvement. The practical matter of checking a footnote in a printed text is completely different from clicking a ref-number. ps Summoned by bot Pincrete (talk) 18:36, 26 November 2016 (UTC)
- No Only a human being can determine the priority order of citation placements. At the very least, I can see an automated ordering wreaking havoc at DYK when reviewers start rejecting nominations because a citation is not readily where it should be. Oh, please, let's not go down this road. — Maile (talk) 02:41, 5 December 2016 (UTC)
- Provide an instance where this was an issue (at DYK). AWB already re-orders and has done so for a long, long time, so I am skeptical that that's a realistic issue. --Izno (talk) 23:31, 12 December 2016 (UTC)
- No - there may be reasons for the order, and only a human being has the ability to determine this. עוד מישהו Od Mishehu 15:47, 7 December 2016 (UTC)
- No, and I think we are doing our readers a disservice by presuming they are likely to get significantly confused by references in non-numerical order, much less so confused that they won't figure out what's going on after the first time they click on a few of those refnumbers. While a good portion of the 'numerically misordered' references may (or may not) be so by circumstance, there is enough reason to also presume that a significant portion is ordered so on purpose. This is not something a bot can determine. The main purpose of references first and foremost is and remains to be relevant to the content, not to look tidy, and forced numerical ordering is not likely to serve that purpose well. AddWittyNameHere (talk) 23:36, 11 December 2016 (UTC)
- No Humans are smarter than bots in this case. Should we also have bots re-order sections in alphabetical order of their title? Editors have a reason for ordering references, and sections, in the way that they do. It has nothing to do with math or alphabetizing. The John/Mary example above is a good one. First Light (talk) 04:02, 12 December 2016 (UTC)
- No, especially because in a case of WP:OVERCITE, an editor who is not an expert in the topic is liable to remove the second, third, etc., references as "redundant", when it might actually be the third one that is crucial, if they've been auto-rearranged by number. It's up to editors to decide which reference has primacy for a particular fact being sourced. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 07:01, 12 December 2016 (UTC)
- That seems like a misuse of OCITE and thus a bad example to use as a reason against cite ordering in AWB. Besides, if the third citation is crucial, why is it not alone in the list of references? Or why is the explanation not provided to the reader in a note of some sort? --Izno (talk) 23:31, 12 December 2016 (UTC)
- Editors can rightfully ask for evidence that more than one real expert supports a particular statement, especially when it's controversial. Even that overcite essay supports leaving the three most reliable (out of six) citations in the example it gives. Adding yet another rule or guideline for citations (that editors should give an explanation in an extra note that most editors don't even know how to format) is truly overkill for a problem that doesn't exist. First Light (talk) 00:58, 13 December 2016 (UTC)
- That seems like a misuse of OCITE and thus a bad example to use as a reason against cite ordering in AWB. Besides, if the third citation is crucial, why is it not alone in the list of references? Or why is the explanation not provided to the reader in a note of some sort? --Izno (talk) 23:31, 12 December 2016 (UTC)
- Yes, though apparently in the minority at this late date. My opinion is that we should mercilessly reduce the number of references in any given sentence, and for the remaining, ordering makes a general sense. The statement "editors order these things deliberately" surely refers to a tiny minority of all editors (and this is in the spirit of WP:IAR in that most editors probably don't care, so they won't place their references deliberately). --Izno (talk) 23:31, 12 December 2016 (UTC)
- Aside: I happen to agree with Mandruss's request regarding a NOCON close. --Izno (talk) 23:32, 12 December 2016 (UTC)
Notes
- ^ There can only be a visible difference if refs (or notes) are named and reused.
Discussion: AWB bot ref reordering
- The discussion section below was created precisely for discussion of the substantive issue, as in any RfC. This is an RfC that should have occurred in 2009 after it became clear that the issue could not be resolved outside RfC. ―Mandruss ☎ 22:53, 19 November 2016 (UTC)
- Anyone could have raised an RfC at the time. They didn't. There is no procedure for your "Let's pretend that this is 2009." idea above. This is 2016, and the status quo is established. To attempt to set up an RFC in such a way that "no consensus" means you get the change you want, contrary to normal practice, is not how we do things. All the best: Rich Farmbrough, 23:08, 19 November 2016 (UTC).
- No one knew about it, Rich. It was added on the say-so of two editors, one of whom now supports its removal. Every attempt to have it removed has been ignored. SarahSV (talk) 23:13, 19 November 2016 (UTC)'
- Not so. I removed it from my version of AWB. All the best: Rich Farmbrough, 23:41, 19 November 2016 (UTC).
- Rich, I'm not sure what "not so" refers to. Several people have objected to it, but it has made no difference. Magioladitis said he supported removing it last year, but seems not to be able to do it himself. I asked "how can we get rid of that AWB thing that moves references out of place?" He replied: "I support you on that. In the past I proposed that we make the ref reordering optional and disabled for bots." Can you say how you were able to remove it? SarahSV (talk) 13:50, 20 November 2016 (UTC)
- I downloaded the code and patched it. Later I created a patching system to help avoid regressions. Whether either have survived the intervening years, I don't know.
- I cannot speak for @Magioladitis:, but it is possible that when he said "I support you on that." he was replying to "Can you address the larger issues, M?"
- The 2009 discussion had four participants not two. three seemed to think it was a good thing, and the fourth that it was harmless. I read the discussion and did not join in as it seemed an unexceptional change. Doubtless I was not the only one.
- The Study 329 example isn't a great one, because it's a John and Mary example (and the cites, and arguably the text, should be in the body, not the caption of an image).
- All the best: Rich Farmbrough, 15:30, 20 November 2016 (UTC).
- Rich, I'm not sure what "not so" refers to. Several people have objected to it, but it has made no difference. Magioladitis said he supported removing it last year, but seems not to be able to do it himself. I asked "how can we get rid of that AWB thing that moves references out of place?" He replied: "I support you on that. In the past I proposed that we make the ref reordering optional and disabled for bots." Can you say how you were able to remove it? SarahSV (talk) 13:50, 20 November 2016 (UTC)
- Not so. I removed it from my version of AWB. All the best: Rich Farmbrough, 23:41, 19 November 2016 (UTC).
- Seriously? The status quo is established? Because the AWB folks who had control over the code refused to recognize the fact that they had strong opposition to the edits and seek consensus for them? Sorry man, de facto consensus is not established by obstructionism. As for my "no consensus" position, I didn't set anything up that way, I made a suggestion to the closer, clearly identified as a comment, which they can ignore if it doesn't make sense to them. Please don't misrepresent what I'm doing here. ―Mandruss ☎ 23:16, 19 November 2016 (UTC)
- The question of when the status quo has been established long enough to count as the status quo, is, of course, a vexed one. However on Wikipedia seven (7) years would generally be considered ample time. And I council against using terms like "obstructionism" when, by your own admission you aren't familiar with the history. Rjwilmsi has bent over backwards to accommodate those who have legitimate issues with AWB (and some who don't), and together with the rest of the AWB developers has put in an enormous amount of work.
- All the best: Rich Farmbrough, 23:43, 19 November 2016 (UTC).
- If the reordering is removed pending consensus to include it, I will retract the obstructionism claim with apology. ―Mandruss ☎ 00:44, 20 November 2016 (UTC)
- No one knew about it, Rich. It was added on the say-so of two editors, one of whom now supports its removal. Every attempt to have it removed has been ignored. SarahSV (talk) 23:13, 19 November 2016 (UTC)'
- Anyone could have raised an RfC at the time. They didn't. There is no procedure for your "Let's pretend that this is 2009." idea above. This is 2016, and the status quo is established. To attempt to set up an RFC in such a way that "no consensus" means you get the change you want, contrary to normal practice, is not how we do things. All the best: Rich Farmbrough, 23:08, 19 November 2016 (UTC).
- The discussion section below was created precisely for discussion of the substantive issue, as in any RfC. This is an RfC that should have occurred in 2009 after it became clear that the issue could not be resolved outside RfC. ―Mandruss ☎ 22:53, 19 November 2016 (UTC)
- So,are we talking about AWB or bots that run under AWB? Mr Stephen (talk) 23:23, 19 November 2016 (UTC)
- The issue is AWB or any automated re-ordering of refs. SarahSV (talk) 23:28, 19 November 2016 (UTC)
- @SlimVirgin: I confess I wasn't clear on that point, and I should have been. Should we change the headings here and the RfC question? ―Mandruss ☎ 23:29, 19 November 2016 (UTC)
- These are two very different issues. Perhaps we want different questions? All the best: Rich Farmbrough, 23:51, 19 November 2016 (UTC).
- Mandruss, this is about AWB reordering refs. It is about the feature that was added in 2009. If we make it more complicated and it confuses people, we will end up with no consensus. SarahSV (talk) 23:55, 19 November 2016 (UTC)
- These are two very different issues. Perhaps we want different questions? All the best: Rich Farmbrough, 23:51, 19 November 2016 (UTC).
- These are two very different issues. Perhaps we want different questions? All the best: Rich Farmbrough, 23:51, 19 November 2016 (UTC).
- Well, since this is 2016 and not 2009, I will suggest that the burden is on those who want to end the reordering, as this is a long-established process. Having the footnote numbers in chronological order makes logical sense in many cases because it generally doesn't matter what citation is shown first and having the numbers in a sequence is naturally easiest on the reader's eyes. There are of course exceptions, as editors may think a particular citation is especially strong or backs up more of the content than other cities -- in these cases, they can override AWB by placing an HTML comment between the refs. If there is any change with how this all works, I wouldn't mind AWB adding an HTML comment that explains how to avoid reordering wherever it reorders. Stevie is the man! Talk • Work 23:56, 19 November 2016 (UTC)
as this is a long-established process
- As I said above, de facto consensus arises from the facts that (1) editors have had the ability to make changes to the content in question and (2) they have chosen not to do so. That is not the case here, because the AWB developers had control of the AWB code and were not responsive to editor complaints. They abused the power they had by virtue of technical control and it would be an exceedingly bad idea to reward that behavior by asserting "a long-established process". The message would be that if you just can be obstructive long enough, you will eventually win out. ―Mandruss ☎ 00:42, 20 November 2016 (UTC)- I'm looking forward to seeing the evidence behind these assertions that don't appear to assume good faith. At any rate, the fact is that it's a long-established process. And based on the experiences reported so far, any specific disputes over reorderings are highly infrequent. Now, if someone can show where anything other than highly infrequent disputes are occurring, of course we should consider that. Stevie is the man! Talk • Work 00:58, 20 November 2016 (UTC)
- Which of the following is incorrect? 1. Highly controversial changes require clear consensus. 2. No clear consensus has ever existed for AWB reordering. 3. A developer with the power to control bot-executed code should be expected to be aware of 1 and 2. 4. The consensus-free code still remains in AWB.
I cannot escape the logical conclusion that (1) someone has acted in bad faith, or (2) someone should not have control of the AWB code. As I've said elsehwere here, I will gladly retract all such claims if the reordering is removed pending consensus to include it, per item 1. ―Mandruss ☎ 01:16, 20 November 2016 (UTC)- Where is the evidence that demonstrates "highly controversial" in the first place? As I have noted above, I have done a *lot* of these reorderings, with only one complaint, which was resolved. Stevie is the man! Talk • Work 19:25, 8 December 2016 (UTC)
- How about the 24 No !votes in this RfC to date, for starters? ―Mandruss ☎ 19:28, 8 December 2016 (UTC)
- Well, that's not evidence of a problem, it's evidence of complaint. Voting in a discussion is one thing, but is there actually a problem that can be proved? Where is the evidence of harm to articles? Where is the evidence of disputes in articles, especially any lengthy ones? Prove the actual problem. Stevie is the man! Talk • Work 19:40, 8 December 2016 (UTC)
- It's evidence of "highly controversial" by definition. Whether there's a problem is a matter for discussion and consensus, which is what we're doing here, and which we should have done in 2009, which is what I said. ―Mandruss ☎ 20:22, 8 December 2016 (UTC)
- Well, that's not evidence of a problem, it's evidence of complaint. Voting in a discussion is one thing, but is there actually a problem that can be proved? Where is the evidence of harm to articles? Where is the evidence of disputes in articles, especially any lengthy ones? Prove the actual problem. Stevie is the man! Talk • Work 19:40, 8 December 2016 (UTC)
- How about the 24 No !votes in this RfC to date, for starters? ―Mandruss ☎ 19:28, 8 December 2016 (UTC)
- Where is the evidence that demonstrates "highly controversial" in the first place? As I have noted above, I have done a *lot* of these reorderings, with only one complaint, which was resolved. Stevie is the man! Talk • Work 19:25, 8 December 2016 (UTC)
- Which of the following is incorrect? 1. Highly controversial changes require clear consensus. 2. No clear consensus has ever existed for AWB reordering. 3. A developer with the power to control bot-executed code should be expected to be aware of 1 and 2. 4. The consensus-free code still remains in AWB.
- I'm looking forward to seeing the evidence behind these assertions that don't appear to assume good faith. At any rate, the fact is that it's a long-established process. And based on the experiences reported so far, any specific disputes over reorderings are highly infrequent. Now, if someone can show where anything other than highly infrequent disputes are occurring, of course we should consider that. Stevie is the man! Talk • Work 00:58, 20 November 2016 (UTC)
- It would be useful to have some statistics:
- How many refs have been reordered by AWB?
- How many were out of order due to the refs renumbering, and how many were placed out of order?
- How many cases have been documented where the re-ordering was alleged to be wrong?
- Secondly it would be useful to understand if people think that, as a matter of style:
- Reference numbers should be ascending:
- Always
- Except where there is clear priority between references
- Let them be random
- Personally I subscribe to either the first or second, tending toward the first. If the distinction is sufficiently strong to warrant out-of-order numbers then there may well be a better way of handling it.
- All the best: Rich Farmbrough, 23:59, 19 November 2016 (UTC).
- Like I say above, AWB ref reordering skips refs separated by an HTML comment, so editors (assuming a consensus) can decide to have the footnote numbers out of order to their heart's content. Stevie is the man! Talk • Work 00:07, 20 November 2016 (UTC)
- Indeed (I edit conflicted with you). I suspect that's one of the reasons that hardly anyone is bothered about this either way. All the best: Rich Farmbrough, 00:15, 20 November 2016 (UTC).
- Indeed (I edit conflicted with you). I suspect that's one of the reasons that hardly anyone is bothered about this either way. All the best: Rich Farmbrough, 00:15, 20 November 2016 (UTC).
- Like I say above, AWB ref reordering skips refs separated by an HTML comment, so editors (assuming a consensus) can decide to have the footnote numbers out of order to their heart's content. Stevie is the man! Talk • Work 00:07, 20 November 2016 (UTC)
- Statistics I have some preliminary numbers. Approximately 100 pages every day have the references put out of order, approximately 100 pages every day have order restored. I have a sample of both over an elven day period in late July.
- Needed Analysis of how the new out-of-order refs arise (i.e., accidentally by editing other parts of the article, deliberately by re-arranging the refs, or can't tell, by adding a ref.)
- All the best: Rich Farmbrough, 19:06, 23 November 2016 (UTC).
- Mandruss, I've added a link to the 2009 discussion to your post introducing the RfC. I hope that's okay. (Sorry, I should have asked you before doing it.) SarahSV (talk) 00:00, 20 November 2016 (UTC)
- The only "objector" there said "Not bothered if you continue as it isn't doing any harm, except wasting effort" - this seems like consensus was established - no reason it can't change of course. All the best: Rich Farmbrough, 00:13, 20 November 2016 (UTC).
- The only "objector" there said "Not bothered if you continue as it isn't doing any harm, except wasting effort" - this seems like consensus was established - no reason it can't change of course. All the best: Rich Farmbrough, 00:13, 20 November 2016 (UTC).
- OK, once again. Where, in the real world, is the guidance that the order of references indicates the order of importance? There must be a style guideline or an 'instructions to authors' page somewhere that suggests this. I've never seen one on my travels, and nobody ever comes up with one when I ask in these discussions. Somebody must be familiar with this style and can point us (well, me) at it. Mr Stephen (talk) 00:25, 20 November 2016 (UTC)
- I believe I saw one journal which allows this. But I could be wrong. All the best: Rich Farmbrough, 00:56, 20 November 2016 (UTC).
- I just put myself in the place of a reader who only has the time and inclination to look at one source of several cited. In certain cases, which are rare but still important, I want to control which source that is, and I don't know why they wouldn't choose the one physically first in the string (Westerners tend to think left-to-right). I gave a good example of such a case in the precursor discussion. I think I as a Wikipedia editor should have that discretion, regardless of whether this is some widely recognized practice or not. Most readers won't know whether such a practice exists or not, and we are writing for them, not us. ―Mandruss ☎ 01:03, 20 November 2016 (UTC)
- I believe I saw one journal which allows this. But I could be wrong. All the best: Rich Farmbrough, 00:56, 20 November 2016 (UTC).
- Mandruss; you write " I don't know why they wouldn't choose the one physically first in the string". I suggest that they would not because that is not standard practice. Mr Stephen (talk) 10:46, 20 November 2016 (UTC)
- As I indicated, few Wikipedia readers know anything about standard practice regarding citation order. Do you disagree with that? I've personally been a Wikipedia editor for 3.5 years and a Wikipedia user for about 7 years, and I didn't know about any such standard practice until a few days ago. Am I some aberration? ―Mandruss ☎ 11:38, 20 November 2016 (UTC)
- You are not the matter at hand. Where did you get the idea that references are ordered by importance? I've never seen guidance suggesting it; somebody must have if it's not something that's been made up. Link please. Mr Stephen (talk) 13:28, 20 November 2016 (UTC)
- It is in fact something that's been made up, which is not a Bad Thing. The word is innovation, and we are not bound by conventions created by external "authorities". That kind of thinking is simply rigid pedantry. If I'm wrong, link please. ―Mandruss ☎ 04:22, 22 November 2016 (UTC)
- As an aside to the main discussion, my recollection is that the Bluebook system of legal citation has some rules about ordering citations by importance. I don't know if the handful of Bluebook afficiondos here at WP observe that, but it could be a possibility.
- More to the point here would is the matter of having the notes/citations immediately follow the material they apply to. But some editors believe all note-links (hyperlinks) should be at the end of a sentence. In that case the citations need to be in order as used in the text, and changing that will really confuse the readers. ~ J. Johnson (JJ) (talk) 00:24, 23 November 2016 (UTC)
- @Mr Stephen and Mandruss: This study found that (student) readers assume Wikipedia refs are ordered by importance / quality. Nikkimaria (talk) 00:41, 2 December 2016 (UTC)
- I found that article painful to read on a tablet, I will have a look at it on a proper screen or dead tree later. It's obviously related, but seems to a very small study (30 freshers), and doesn't really address the issue under discussion here. At first sight (please correct me) it seems to be that the participants started – reluctantly – at the top of the endnotes, rather than looking for a reference to support a particular viewpoint. Mr Stephen (talk) 18:39, 2 December 2016 (UTC)
- @Mandruss and Nikkimaria: I found it an insight into the cohort's inability to read an article (though maybe they simply wanted to finish the task and get a mark) but possibly not much help to us here. Mr Stephen (talk) 20:59, 3 December 2016 (UTC)
- I found that article painful to read on a tablet, I will have a look at it on a proper screen or dead tree later. It's obviously related, but seems to a very small study (30 freshers), and doesn't really address the issue under discussion here. At first sight (please correct me) it seems to be that the participants started – reluctantly – at the top of the endnotes, rather than looking for a reference to support a particular viewpoint. Mr Stephen (talk) 18:39, 2 December 2016 (UTC)
- It is in fact something that's been made up, which is not a Bad Thing. The word is innovation, and we are not bound by conventions created by external "authorities". That kind of thinking is simply rigid pedantry. If I'm wrong, link please. ―Mandruss ☎ 04:22, 22 November 2016 (UTC)
- You are not the matter at hand. Where did you get the idea that references are ordered by importance? I've never seen guidance suggesting it; somebody must have if it's not something that's been made up. Link please. Mr Stephen (talk) 13:28, 20 November 2016 (UTC)
- As I indicated, few Wikipedia readers know anything about standard practice regarding citation order. Do you disagree with that? I've personally been a Wikipedia editor for 3.5 years and a Wikipedia user for about 7 years, and I didn't know about any such standard practice until a few days ago. Am I some aberration? ―Mandruss ☎ 11:38, 20 November 2016 (UTC)
- Mandruss; you write " I don't know why they wouldn't choose the one physically first in the string". I suggest that they would not because that is not standard practice. Mr Stephen (talk) 10:46, 20 November 2016 (UTC)
- I'm pinging the other editors who were discussing it at CITE before Mandruss opened this: @Bcharles, CBM, WhatamIdoing, GoingBatty, B, Johnuniq, Magioladitis, Izno, Kmhkmh, Headbomb, Blue Square Thing, Arthur Rubin, Peter coxhead, Stfg, Mike Christie, and Pppery: SarahSV (talk) 00:40, 20 November 2016 (UTC)
- I think this discussion would go better if a couple of points are sorted out at the outset, so that we are all "on the same page".
- First, let's have an understanding of the basic terminology and concepts. E.g., what (I believe) we are talking about is whether instances of (e.g.) [1][2][3][7] are better than [3][1][7][2]. (That is, I believe the issue is about the ordering of consecutive strings of numbered links, not the ordering of such links through the whole article.)
- Second, we should be clear that those are not "references", they are HTML links. But not links to references, as what is contained in the the mis-named
<ref>...</ref>
entities is not necessarily a "reference". (Yes, I know, it seems most of you use them that way, but that is certainly not the only way. Hear me out; such distinctions are necessary to avoid ambiguity, confusion, and conflict.) What the<ref>...</ref>
tags create are notes (footnotes, endnotes, whatever). What you use them for (whether "references", "citations", "explanatory notes", etc.) is largely irrelevant for this discussion, but we might avoid getting stuck in conceptual dead-ends if we use the most general term, "notes". And "note-links" (or "footnote-links") for the specific element of concern here.
- Third, this RfC would be better formulated as whether having strings of note-links in ascending order is merely preferred, or should be mandatory. If that is resolved one way or the other then appropriate measures can be considered, such as adjusting AWB.
- Fourth, "random" is not an alternative to "ascending". Notes, and the links to them, are numbered in the order the s/w finds them. Note-links come out of order where a named ref (the <ref=name ...> entity) has been used to point to another instance. (That is, to "re-use a reference".) Don't use named refs, and I believe the ordering problem goes away.
- Which then leads us back to other potential problems that underlie the issue considered here. ~ J. Johnson (JJ) (talk) 02:54, 20 November 2016 (UTC)
- J. Johnson, yes, ref name is what causes this problem. But if we don't use it, AWB editors add it. SarahSV (talk) 13:13, 20 November 2016 (UTC)
- SV: I think you are referring to this automated merging of notes (<ref>s) deemed to be duplicates, replacing one with a named ref. I think that is a problem that needs to be dealt with. (I often modify my notes so they are not duplicates, to avoid this merging.) But behind that is the challenge of "re-using" entire biblographical entries ("full citations"). In the end I think it comes down to: how do you feel about the use of "short citations"? ~ J. Johnson (JJ) (talk) 23:04, 20 November 2016 (UTC)
- Pinging others who have discussed this: @Beyond My Ken, Ryan Norton, Beetstra, and Afterbrunel: SarahSV (talk) 13:10, 20 November 2016 (UTC)
- I cannot find the comment where it is most relevant, but professional journals do not reuse references/notes. They almost always use Ibid. and Loc. cit. (Discussion of Op. cit., which I wrote first, is off topic.) Discussion of what professional journals do is only relevant for the few professional journals which reuse notes.
Compromise proposal: AWB bot ref reordering
CURRENT CONSENSUS IS THAT THIS IS NOT AN APPROPRIATE PROPOSAL. PLEASE IGNORE. ―Mandruss ☎ 13:23, 20 November 2016 (UTC)
- I think the simple solution here is to add something like
{{AWB-no-ref-reorder}}
in the reference section that'll tell AWB to leave ref order alone. This way the minority can be happy, and the majority can continue cleaning up. Headbomb {talk / contribs / physics / books} 10:49, 20 November 2016 (UTC)
- I think the simple solution here is to add something like
PROPOSAL:
- @Headbomb: Or, a new way to protect only a single ref sequence without requiring the use of list-defined references, as I've explored in the precursor discussion. -
{{reforder |refs=<ref>...</ref><ref>...</ref><ref>...</ref><ref>...</ref>}}
-I personally have no objection to that, once AWB gains consensus to reorder in the first place, which should have been done in 2009. First things first.I like this. ―Mandruss ☎ 11:44, 20 November 2016 (UTC)
- @Headbomb: Or, a new way to protect only a single ref sequence without requiring the use of list-defined references, as I've explored in the precursor discussion. -
- Comment Mandruss, do you think this could feasibly be done only for articles created in the last two or three months by non-extended-confirmed editors? It seems from the discussion above that many experienced editors would rather have it at their own discretion, although IMHO it looks a little weird and unprofessional to have the citations be ordered [14][2][5][3] for no reason. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 11:58, 20 November 2016 (UTC)- Sorry, I don't understand the question.
In hindsight, maybe I should have framed this RfC as a proposal for that compromise. I am a stickler for process, for doing things the right way, and that may have affected my thinking in an unconstructive way. If so, I apologize, and the question for me is whether it's too late to change directions in this RfC. The question for others may be whether that's the best approach. ―Mandruss ☎ 12:03, 20 November 2016 (UTC)- Mandruss, you say you're a stickler for process, so please let this run. The broader question is whether editors should be making context-sensitive edits with AWB. Telling us we have to use special templates or html to stop it misses that point. SarahSV (talk) 13:00, 20 November 2016 (UTC)
- @Mandruss: I guess if it's possible (if it is, it would slow down AWB just a little bit because of the API querying), then there's not really anything stopping you from adding a third option. The extended-confirmed part might be unnecessary if it's for pages created in the last month. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:07, 20 November 2016 (UTC)- @Jc86035: Considering that the {{R}} template is already being used to protect sequences from AWB reordering, I don't see why using a Reforder template instead would slow down AWB. As far as I know the protection works because AWB ignores cites inside a template transclusion. All I'm doing is eliminating LDR from the equation. I still don't understand what you're saying about extended-confirmed and pages created in the last month. ―Mandruss ☎ 12:13, 20 November 2016 (UTC)
- @Mandruss: Sorry for the confusion. I just realised I put this in the wrong subsection; my idea was to limit reordering of references to pages created recently by inexperienced editors, regardless of whether the blocking template was used. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:33, 20 November 2016 (UTC) - Added the third option, Reforder. ―Mandruss ☎ 12:34, 20 November 2016 (UTC)
- @Mandruss: Sorry for the confusion. I just realised I put this in the wrong subsection; my idea was to limit reordering of references to pages created recently by inexperienced editors, regardless of whether the blocking template was used. Jc86035 (talk) Use {{re|Jc86035}}
- @Jc86035: Considering that the {{R}} template is already being used to protect sequences from AWB reordering, I don't see why using a Reforder template instead would slow down AWB. As far as I know the protection works because AWB ignores cites inside a template transclusion. All I'm doing is eliminating LDR from the equation. I still don't understand what you're saying about extended-confirmed and pages created in the last month. ―Mandruss ☎ 12:13, 20 November 2016 (UTC)
- Sorry, I don't understand the question.
- How is one making a reasoned choice to order back to back refs un-sequentially expected to know about the proposed "
{{AWB|no-reorder}}
" template? Though I fail to see a majority in support of reordering references in this manner at this time, and would oppose this template as such; if it were implemented it should be required in the edit summary of bots reordering back to back references into ascending number sequence, so users would know how to prevent it from happening again.— Godsy (TALKCONT) 12:47, 20 November 2016 (UTC)- Sorry, I included the
{{AWB|no-reorder}}
comment only for context, the proposal in this subsection is for Reforder. I have attempted to clarify that by adding PROPOSAL above. ―Mandruss ☎ 13:03, 20 November 2016 (UTC)
- Sorry, I included the
- Mandruss, please don't change the question mid-RfC. The compromise is another version of yes. First you were no in the discussion at CITE, then yes, then no again, then you opened a parallel discussion here, and no, and now yes again (sort of) and changing the question. Please just let it run. SarahSV (talk) 12:51, 20 November 2016 (UTC)
- Let it never be said that I am inflexible! :) Your reasoning is like accusing a politician of being a "waffler" because they changed their mind. Sorry I failed to get it right the first time, or the second (or the third? I don't know, I'm not counting). RfCs add options all the time, because it's difficult to predict what options will be necessary in advance. Wikipedia decision-making is messy. As for "the compromise is another version of yes", I think that's a matter of perspective, and I disagree. ―Mandruss ☎ 12:56, 20 November 2016 (UTC)
- It's another workaround, another version of yes. SarahSV (talk) 13:05, 20 November 2016 (UTC)
- @SlimVirgin: I would like to voice my strong objection to your removal of the third option[2], but I am not going to edit war this with you. You are now being disruptive and exhibiting WP:OWN of this process in my view. Editors who agree with you may !vote No. ―Mandruss ☎ 13:08, 20 November 2016 (UTC)
- @Mandruss:, I'm sorry, but you've caused a lot of extra work here. We had an ongoing discussion at CITE. You flipflopped back and forth there, then opened this before that had ended, without any warning. Now you're doing the same here, and trying to change the question. What you're calling a third option is really option yes(b). SarahSV (talk) 13:19, 20 November 2016 (UTC)
- Deferring to this two-to-one opinion, I have retracted the proposal for now by adding a comment at the top of this subsection. Thank you. Sorry for causing a lot of extra work by trying to help move this issue to a resolution, after seven years. In hindsight I should have ignored your first ping at CITE and stayed the hell out of it. ―Mandruss ☎ 13:23, 20 November 2016 (UTC)
- Thank you for fixing it. SarahSV (talk) 13:52, 20 November 2016 (UTC)
- Deferring to this two-to-one opinion, I have retracted the proposal for now by adding a comment at the top of this subsection. Thank you. Sorry for causing a lot of extra work by trying to help move this issue to a resolution, after seven years. In hindsight I should have ignored your first ping at CITE and stayed the hell out of it. ―Mandruss ☎ 13:23, 20 November 2016 (UTC)
- @Mandruss:, I'm sorry, but you've caused a lot of extra work here. We had an ongoing discussion at CITE. You flipflopped back and forth there, then opened this before that had ended, without any warning. Now you're doing the same here, and trying to change the question. What you're calling a third option is really option yes(b). SarahSV (talk) 13:19, 20 November 2016 (UTC)
- @SlimVirgin: I would like to voice my strong objection to your removal of the third option[2], but I am not going to edit war this with you. You are now being disruptive and exhibiting WP:OWN of this process in my view. Editors who agree with you may !vote No. ―Mandruss ☎ 13:08, 20 November 2016 (UTC)
- It's another workaround, another version of yes. SarahSV (talk) 13:05, 20 November 2016 (UTC)
- Let it never be said that I am inflexible! :) Your reasoning is like accusing a politician of being a "waffler" because they changed their mind. Sorry I failed to get it right the first time, or the second (or the third? I don't know, I'm not counting). RfCs add options all the time, because it's difficult to predict what options will be necessary in advance. Wikipedia decision-making is messy. As for "the compromise is another version of yes", I think that's a matter of perspective, and I disagree. ―Mandruss ☎ 12:56, 20 November 2016 (UTC)
- @Mandruss: Your third option is, really, just "yes", because it was implicit that the minority of editors who wanted deliberately to put them out of order would have to do something like that anyway. I still think it'd be best if we only reordered the refs for pages recently created by non-extended-confirmed editors (I doubt most newcomers would find out that they're supposed to do that). Would you add that to the RfC? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:11, 20 November 2016 (UTC)- Fine. I added a third option because you said, "there's not really anything stopping you from adding a third option", later realizing that you were in the wrong place. Sheesh. You guys sort it out. ―Mandruss ☎ 13:17, 20 November 2016 (UTC)
- Nothing needs to be sorted out. Let it run, then a closer will summarize the consensus. SarahSV (talk) 13:20, 20 November 2016 (UTC)
- Fine. I added a third option because you said, "there's not really anything stopping you from adding a third option", later realizing that you were in the wrong place. Sheesh. You guys sort it out. ―Mandruss ☎ 13:17, 20 November 2016 (UTC)
- I suggest to the closer that there is no consensus here, unless it be that: everything is confused, the question is poorly put, we haven't worked out what the problem is, and – there is no consensus. ~ J. Johnson (JJ) (talk) 23:21, 20 November 2016 (UTC)
- Just 26 hours after the RfC was created seems a little soon to be drawing conclusions about the level of consensus, don't you think? Why do you think the closer needs the advice of commenters on how to do their job anyway? --Stfg (talk) 00:44, 21 November 2016 (UTC)
- Yeah we should have had a separate pre-RfC RfC to decide what question to ask in this one, as I'm certain there is wide disagreement about how to frame this issue. Or, we can all learn how to give a little for the sake of moving on, and that none of this is all that fucking important in the end. This has become obsessive on the parts of many. High intelligence is counterproductive in the absence of wisdom. ―Mandruss ☎ 08:43, 21 November 2016 (UTC)
- I don't know that a pre-RfC RfC is needed, but as a lot of these kinds of questions arise where various editors are running on different interpretations, I think it is generally good to work out a mutually acceptable formulation of the question beforehand. Of course, to get the question right you pretty much have to be half-way to the answer. ~ J. Johnson (JJ) (talk) 00:24, 22 November 2016 (UTC)
- Based on what I know about the history of this issue, the personalities involved, and Wikipedia culture in general, I strongly suspect any attempts to "work out a mutually acceptable formulation of the question beforehand", outside RfC, would have been fruitless. ―Mandruss ☎ 04:30, 22 November 2016 (UTC)
- The first time you tried to walk it probably didn't work so well, either. I agree that success in these matters is difficult, rare, and even fleeting. But I hope that eventually we'll get the hang of it, and the rock will crack. ~ J. Johnson (JJ) (talk) 02:29, 24 November 2016 (UTC)
- Based on what I know about the history of this issue, the personalities involved, and Wikipedia culture in general, I strongly suspect any attempts to "work out a mutually acceptable formulation of the question beforehand", outside RfC, would have been fruitless. ―Mandruss ☎ 04:30, 22 November 2016 (UTC)
- I don't know that a pre-RfC RfC is needed, but as a lot of these kinds of questions arise where various editors are running on different interpretations, I think it is generally good to work out a mutually acceptable formulation of the question beforehand. Of course, to get the question right you pretty much have to be half-way to the answer. ~ J. Johnson (JJ) (talk) 00:24, 22 November 2016 (UTC)
- It is not appropriate to need to add templates to articles to prevent bots from making changes; bots are meant to avoid inappropriate changes on their own. The characterization as "majority"/"minority" reveals a kind of bias, as does the description of rearranging references as "cleaning up". Remember there is no guidance at all that reference numbers should be in increasing order; that idea is something that a small number of AWB operators invented. The solution is for AWB to back out that change until WP:CITE actually requires a particular ordering of references. — Carl (CBM · talk) 13:47, 21 November 2016 (UTC)
Reorder end-notes, not the references
If it is deemed desirable for references to refer to end-notes in increasing order, then the MediaWiki software should assign numbers to the end-notes accordingly, rather than simply in sequential order of first reference. It can't resolve all cases (if a pair of end-notes are referred to in opposite order in different places in the main text, for example), but I imagine most cases would be dealt with. Reordering the references is just a work-around for the underlying issue. isaacl (talk) 20:52, 20 November 2016 (UTC)
- It seems to me you have an idea of possible interest, but I can't quite make it out because of various ambiguities. E.g., what exactly do mean by "references: the numbered-links (e.g.: [1]) in the text? The actual end-notes the link goes to? Or the full bibliographic citation of the source that is frequently the content of the note? And are you assuming the bibliographic citations themselves are scattered through the text, or gathered in a "References" section? Are you considering the use of LDR? ~ J. Johnson (JJ) (talk) 23:15, 20 November 2016 (UTC)
- To clarify: if it is desirable for a sequence of adjacent superscripts to be in increasing numerical order, the numbering of the corresponding end-notes can be selected appropriately to maximize this occurring. (*) It doesn't matter where the contents of the end-notes are defined; the software can reorder the final output as desired.
- (*) As noted, there are situations where preserving increasing numerical order would require re-ordering or relocating one or more superscripts. For example, an article using a couple of authoritative sources throughout may have occasion to refer to the sources in opposite order. isaacl (talk) 05:48, 21 November 2016 (UTC)
- I think this would likely cause even more confusion. It is not true that every style makes the first endnote be number 1 (e.g. endnotes might be sorted by author name, so the first endnote to appear in the text could be number 14). But many styles do make endnotes sorted by number, so the first to appear is 1, etc., and more people would likely be confused if this did not happen.
- The underlying cause of the issue on Wikipedia is that our reference notes are not purely endnotes or footnotes (in which case no number would be repeated) but they are also not purely numerical pointers to a list of references (because references lists would not include comments like endnotes and footnotes do). So our reference numbers are somewhat ambiguous, leading different people to interpret them differently. Which is fine, but changing the system more would be confusing. — Carl (CBM · talk) 13:44, 21 November 2016 (UTC)
- Strictly speaking, no "style" (or method) of citation "makes" the notes (end-notes) be "
sorted by number
"; that's just the order the wikimedia s/w finds them in the text. If an article's first note-link is [14] it is not because the end-notes were sorted by author name (presumably using LDR); it is because that link results from a slave named-ref (e.g.: <ref name=xxxx \>) that points to the fourteenth actual note.
- Strictly speaking, no "style" (or method) of citation "makes" the notes (end-notes) be "
- The underlying cause is not that "
reference notes are not purely endnotes or footnotes
", but that named refs are being used to make a note-link appear in more than one place. Don't use named-refs, and this problem won't happen. It is not so much that your so-called "reference numbers" are ambiguous, but that a list of notes referenced by number is confused with a list of sources referenced by an editor.
- The underlying cause is not that "
- Which is why I oppose this bot-reordering: changing a basically okay system (aside from named-refs!) to conform to ambiguous and confused understandings of what it should do makes the system more confusing, and the editors more confused. ~ J. Johnson (JJ) (talk) 00:30, 22 November 2016 (UTC)
- With hypertext links, I don't think readers notice or care if the first superscript is a "1" or "14". In theory, the MediaWiki software could turn named references into a list of references and generate individual end notes pointing to the same reference, instead of reusing end notes. I suspect it may be challenging to gain consensus support for this approach, though. isaacl (talk) 01:39, 22 November 2016 (UTC)
- I think you have missed the main point: some editors care. Also, you seem confused as to what constitues a "
list of references
" and how that differs from "individual end notes pointing to the same reference
". (Particularly: how does re-use of an end-note differ from re-use of a reference?) Depending on how you understand this, I would say that the mediawiki software already does what is necessary. It's just a matter of getting editors to use the tools available, rather than inventing new tools that don't get to the heart of the problem. Which is, indeed, challenging. ~ J. Johnson (JJ) (talk) 00:39, 23 November 2016 (UTC)- There was a suggestion that named references not be used in order to avoid reusing superscript numbers. The MediaWiki software can still avoid reusing superscript numbers with named references: the resulting end notes can either replicate the citation, or point to a citation list that is automatically generated from the named references. isaacl (talk) 03:14, 23 November 2016 (UTC)
- Not using named references is not a viable option in long articles with hundreds of refs, some used in 10 or 15 different places in the article. Both keeping ref list bloat down, and managing corrections or refinements to refs mean using named refs is essential. Defining named refs in the reflist section is one way to manage them, but that means new editors will need to learn that system. Bcharles (talk) 10:42, 23 November 2016 (UTC)
- If the MediaWiki software were enhanced to create a reference list automatically out of the named references (or even automatically grouping identical un-named references), as I suggested, then editors would no longer need to do it manually. isaacl (talk) 02:05, 24 November 2016 (UTC)
- Not using named references is not a viable option in long articles with hundreds of refs, some used in 10 or 15 different places in the article. Both keeping ref list bloat down, and managing corrections or refinements to refs mean using named refs is essential. Defining named refs in the reflist section is one way to manage them, but that means new editors will need to learn that system. Bcharles (talk) 10:42, 23 November 2016 (UTC)
- There was a suggestion that named references not be used in order to avoid reusing superscript numbers. The MediaWiki software can still avoid reusing superscript numbers with named references: the resulting end notes can either replicate the citation, or point to a citation list that is automatically generated from the named references. isaacl (talk) 03:14, 23 November 2016 (UTC)
- I think you have missed the main point: some editors care. Also, you seem confused as to what constitues a "
- You are probably thinking that named-refs are your only option, but that is incorrect. What you really want is probably 1) to cite ("re-use") your sources multiple times, but 2) without replicating the "reference" (the end-note containing the full citation). You do not need named-refs to do this. Another option (and vastly superior, I think) is short citations (or "short cites"). The full citations get collected on any convenient area (or not), where they can be put in any order you want; in your notes (in the
<ref>...</ref>
tags) are the short cites (like "Smith, 2004", as created by the {{sfn}} or {{harv}} templates) which link to the full citations. For an example see Hockey stick controversy#Notes. (The big red error messages are where someone hasn't figured out how to use named-refs properly.)
- You are probably thinking that named-refs are your only option, but that is incorrect. What you really want is probably 1) to cite ("re-use") your sources multiple times, but 2) without replicating the "reference" (the end-note containing the full citation). You do not need named-refs to do this. Another option (and vastly superior, I think) is short citations (or "short cites"). The full citations get collected on any convenient area (or not), where they can be put in any order you want; in your notes (in the
- Isaacl: we already have bots "
automatically grouping [merging] identical un-named references
." That only creates more problems. ~ J. Johnson (JJ) (talk) 02:34, 24 November 2016 (UTC)- All I'm saying is the software could automatically gather up the citations and produce appropriate end notes in a manner such that any consecutive associated superscripts will be in increasing order. In this way, editors will still retain the ability to control the order of the hyperlinks in the superscripts. isaacl (talk) 03:59, 24 November 2016 (UTC)
- Isaacl: we already have bots "
- And what I am saying is that we already have that. Where it breaks is when named-refs are used. (Don't use named-refs, and this entire RfC is moot.) But this is perhaps unclear to you because you are not entirely clear on the difference, and the significance of the difference, between notes and citations, and their use. ~ J. Johnson (JJ) (talk) 19:39, 24 November 2016 (UTC)
- My apologies for failing to communicate clearly. I understand there are ways for editors to manually create citation lists and refer to them in end notes. I think that it would be nice if the software could take of the grunt work and automatically create a citation list. With this approach, it would be irrelevant if a named reference were used to refer to a citation. isaacl (talk) 03:12, 25 November 2016 (UTC)
- And what I am saying is that we already have that. Where it breaks is when named-refs are used. (Don't use named-refs, and this entire RfC is moot.) But this is perhaps unclear to you because you are not entirely clear on the difference, and the significance of the difference, between notes and citations, and their use. ~ J. Johnson (JJ) (talk) 19:39, 24 November 2016 (UTC)
- I wish I had time to write some code that would remove named-refs, and even extract all full citations from the notes and put them into a list. Until then, the fix to the problems created by use of named-refs is not more s/w functionality to paper over the problems of the last fix, but to just not use named-refs to start with. As to the "grunt work" of creating citations (manually?), it is not any more work to put them in a special section than into <ref> tags. (Unless VE adamantly insists on doing things its way.) Use of named-refs provides no savings of time or effort over the use of short cites; the only difficulty is that having already learned how to use a poor method of handing citations editors balk at investing any effort in learning a better method. ~ J. Johnson (JJ) (talk) 22:50, 25 November 2016 (UTC)
- I think this suggestion shows that the original statement of the RFC was not sufficiently clear. All the best: Rich Farmbrough, 19:45, 4 December 2016 (UTC).
Clarification please
I thought when I came here that this was a discussion about should AWB reorganise grouped cite links at the end of a sentence or paragraph into order according to the number assigned to the cite when first placed in the article. From comments above, I am unsure if that is what people are discussing, as it seems people are discussing the order of cites in the article as a whole, or how they are presented in the Ref section at the end of the article.
My understanding of how the system works. See if others agree with this, so we are discussing the same thing.
We use several sources to write an article, and we cite the sources at the point in the article where the information is used with an inline marker. The software identifies the cite with either a number or a letter or both and links the reader to information on the cite which is collected and placed in a section at the bottom of the article. The cite information at the bottom of the article has the same number or letter as was used in the inline marker. The numbers are purely for identification, and do not relate to sequence, as some cites are used in more than one place, so the number marker may appear several times. See Covent Garden. In the reference section the first source listed is Christopher Hibbert; Ben Weinreb (2008). The London Encyclopaedia. Pan Macmillan. pp. 213–214. This is listed first as it is the first used in the article. It has been given the cite number 1. Because that source is used three times, the places it is used are identified as a, b, c. If anyone clicks on 1 a, they will be taken to the first time the cite is used (in the opening sentence). If anyone clicks on 1 b they will be taken to the second time the cite is used (in the first sentence of the geography section, where it comes after cite 25 used in the previous section and before cite 26 which is used in the following sentence. Numerically it is out of sequence here, but that doesn't matter because the number is purely an identifier, and is not meant to relate to any number sequence). If anyone clicks on 1 c they will find the third use which is at the end of the Covent Garden square section, where it comes between cite 59 which has been used in the sentence before and the sentence after. So that cite appears three times, and two of those appearances are out of number sequence. But no editor and no bot would attempt to change the number of the cite or its position. So, no worries.
In some cases, though, we may use several cites in one sentence, and some of those cites may have been previously used, and so their numbers are not in numerical order. Such a case is in The Kinks article where we have this sentence: "The group's fourth single, "All Day and All of the Night", another Ray Davies hard rock tune, was released three weeks later, reaching number two in the United Kingdom, and number seven in the United States.[4][33][36]". Now, note that there are three numbered cites, and they are not consecutive numbers, which means at least two of the sources have been used elsewhere in the article. The sentence contains three pieces of information that have been cited: the single was the group's fourth, it reached number 2 in the UK charts, and it reached number 7 in the USA charts. According to WP:CITEFOOT instead of putting a cite next to each piece of information, we should group them at the end "so long as it's clear which source supports which part of the text." The order of the cites was originally 36, 4, 33 - 36 citing 4th single, 4 citing No 2 in the UK, and 33 citing 7 in USA, in the same order as those statements are given in the sentence. This AWB edit changed the order so the cite numbers are in order. So someone checking that the single was indeed the band's fourth would assume that would be the first cite listed, and would click on cite number 4, which tells us that the single reached 2 in the UK. That person may assume that we haven't cited that it was the band's fourth single, and may either go look for one to place in the article, or may tag that piece of information as uncited.
The numbers are to identify the cites, they are not to indicate any kind of sequencing. That's my understanding. SilkTork ✔Tea time 15:01, 21 November 2016 (UTC)
- Except this example violates WP:INTEGRITY. CITEFOOT doesn't say anything that the preferred place to put footnotes at the end of a sentence, but at the end of the phrase that the ref supports, as to support text-source integrity. The three cites given for the Kinks example should be placed throughout the sentence instead of grouped at the end. --MASEM (t) 15:09, 21 November 2016 (UTC)
- The Kink's sentence currently violates WP:INTEGRITY because the cites were rearranged into number rather than text order by an AWB edit. As regards the wording of WP:CITEFOOT, in full it says "The citation should be added close to the material it supports, offering text–source integrity. If a word or phrase is particularly contentious, an inline citation may be added next to that word or phrase within the sentence, but it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." My understanding is that if the information is likely to be challenged, put the cite next to the word or phrase, but if it's not contentious the cite can be placed at the end of the sentence. We generally don't have three cites for the same piece of information, so when there are three cites at the end of a sentence they will generally be supporting three different pieces of information - and they will generally be placed in the order in which the information appears in the sentence. Perhaps the wording of WP:CITEFOOT needs to be tightened to avoid misunderstanding? SilkTork ✔Tea time 17:18, 21 November 2016 (UTC)
- The keyword is "clause", which means, to me, where you have a comma is a very valid place to drop in a reference to support the clause prior to the comma. And I have done cases where I've done on individual works such as "Smith[1] and Jones[2] both agree that the sky is blue." so that I'm assured that reference won't move than rather playing with reference order issues.
- At least to me, when you do multiple refs at the same point, the weight of all those refs relative to the text in front of them and to each should be equal that reference re-ordering (moving refs around at that point to have increasing ref numbing) should not affect the understanding of the article in anyway. If the reference order is important, you've structured something wrong, and it is nearly always possible to rewrite a sentence to have refs appropriate distributed throughout so that you eliminate the reordering problem. --MASEM (t) 00:53, 22 November 2016 (UTC)
- You're probably right that it is nearly always possible to do this. To me, and perhaps to some other editors !voting "no" above, the issue is not that there might not be some way to finesse the issue; it's that bots shouldn't be doing work that requires me to finesse an issue. I wouldn't mind a human reordering the refs; I can talk to a human and discuss the issue. Having to format refs in a certain way to keep bots off is like having to put up a deer fence around the roses. I'd rather have deer that don't eat roses. Mike Christie (talk - contribs - library) 01:25, 22 November 2016 (UTC)
- The Kink's sentence currently violates WP:INTEGRITY because the cites were rearranged into number rather than text order by an AWB edit. As regards the wording of WP:CITEFOOT, in full it says "The citation should be added close to the material it supports, offering text–source integrity. If a word or phrase is particularly contentious, an inline citation may be added next to that word or phrase within the sentence, but it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." My understanding is that if the information is likely to be challenged, put the cite next to the word or phrase, but if it's not contentious the cite can be placed at the end of the sentence. We generally don't have three cites for the same piece of information, so when there are three cites at the end of a sentence they will generally be supporting three different pieces of information - and they will generally be placed in the order in which the information appears in the sentence. Perhaps the wording of WP:CITEFOOT needs to be tightened to avoid misunderstanding? SilkTork ✔Tea time 17:18, 21 November 2016 (UTC)
- "[W]e encourage editors to place all the cites at the end of the sentence" - I don't think that is true. I would only encourage it if the cites broadly supported the sentence as a whole. Where I am relying on a specific cite for a specific fact I will cite at the phrase or word level. For example "Aethelwulf's kingdom was claimed by Aethelhnoth,[1] Aelfric and Cynewulf.[2]" Here it is clear that any reader specifically interested in Aethelhnoth's claim should look at ref. 1, while ref 2 will cover at least the two other claimants.
- I read the guidance you quote as encouraging precisely the opposite behaviour, if placing the references together makes it unclear what they support, then they are best placed at the end a smaller semantic unit.
- Moreover your "logical and natural" system makes absolutely no sense. For example:
- "Aethelwulf's kingdom was claimed by Aethelhnoth, Aelfric and Cynewulf.[1][2][3]"
- could mean all three cites apply to the whole sentence, [1] applies to Aethelhnoth, [2] to Aelfric and [3] to Cynewulf, or that [1] demonstrates it was a kingdom, [2] that Aethelhnoth and Aelfric claim it, and [3] that Cynewulf also claimed it, or about thirty other possible interpretations.
- All the best: Rich Farmbrough, 20:11, 21 November 2016 (UTC).
- I think what you and Masem say makes sense. My understanding from the wording of WP:CITEFOOT and other discussions on this matter, is that the preference has been to reduce as much as possible the number of times that a cite marker is used in a sentence because it inhibits reading flow. We are encouraged to remove cite markers from the lead (even though the lead is the most read part of an article) because any information in there will be cited somewhere in the body of the article. I personally like having useful access to the sources. I dislike it when the double citation method is used when the cite marker directs me to a short citation rather than the full one, and then I have to go to the book details separately which don't tell me the page number, and now I can't go back automatically to the short cite with the page number or to my place in the article without rolling back my browser. I don't know why folks do that - it makes work for me when checking details, and simply wastes time. Anyway. Rant over. Perhaps what is needed is clearer wording in WP:CITEFOOT so we are not having discussions over its interpretation. I particularly like your Aethelwulf's kingdom example, and something like that in WP:CITEFOOT would clear up any potential confusion. That said, I still don't see why we should have a bot changing the order of the cite markers simply because they use numbers - if they used symbols we wouldn't even be having this discussion. Well, they do use symbols, it's just that the symbols are numbers which can be arranged in a sequence. SilkTork ✔Tea time 00:14, 26 November 2016 (UTC)
- I've been pinged in many reviews for footnotes out of numeric order. I thought there was something in the MOS about this. Can anyone confirm or refute this? I agree with Rich in that in SilkTork's example I would have taken advantage of the commas to insert the footnotes in mid-sentence, but this is not always possible. And Rich is quite right; without checking the references, you cannot know what parts of the sentence they support. Hawkeye7 (talk) 20:49, 21 November 2016 (UTC)
- I agree that it may not always be possible. But it seems to me that if the citations order is so important, we should at least be able to agree on what the order in a specific case should be. Silk Torq claims that it is in semantic order. Others claim that it is in "importance order". If either were the case then every consecutive use of cites following the other model, and every use which follows neither may very well be "wrong". (Or perhaps we should use [2][1] for importance ordered [4][3] for semantically distributed and [6][5] for the fortuitous occasions when both are valid?)
- Again, if they are that important, the citations could well be referred to in the text, thus:
Norden [1] says the name is derived from a wood called Hitch, but Ekwall believes this is a conflation Wychwood, for which the Old English is Hwiccawudu.[2]
- All the best: Rich Farmbrough, 21:02, 21 November 2016 (UTC).
- It's trickier than that. You get sentences like:
- Where the first reference is about the river, and the second merely supplies his first name. Hawkeye7 (talk) 11:25, 22 November 2016 (UTC)
- All the best: Rich Farmbrough, 21:02, 21 November 2016 (UTC).
- ^ Eilert Ekwall (1928). English River Names. OUP. p. 197-198.
- ^ Kitchen, Frank (2008) [2004]. "Norden, John (c.1547–1625)". Oxford Dictionary of National Biography (online ed.). Oxford University Press. Retrieved 28 October 2011.
- And again if that is sufficiently important, it can be set up accordingly.
- Norden (first name John[1]) says....
- All the best: Rich Farmbrough, 00:05, 24 November 2016 (UTC).
Red link landing page
When I open Blabla, it says:
"Wikipedia does not have an article with this exact name. Please search for Blabla in Wikipedia to check for alternative titles or spellings.
- This page is protected from creation, so only administrators can create it.
- Search for "Blabla" in existing articles.
- Look for pages within Wikipedia that link to this title."
When I open Adgf, it says:
"Wikipedia does not have an article with this exact name. Please [search for Blabla in Wikipedia to check for alternative titles or spellings.
- Log in or create an account to start the Adgf article, alternatively use the Article Wizard, or add a request for it.
- Search for "Blabla" in existing articles.
- Look for pages within Wikipedia that link to this title."
Those messages are hard to read, as the first line is too long. Also, the search link appears twice. "Search for Xyz in existing articles" should be the first item in the list, as most people want to search for articles rather than create them.
Can you fix those messages? Thanks! --167.58.148.225 (talk) 13:46, 21 December 2016 (UTC)
MarkAdmin.js
Hello.
I would like to transfer the following script to Wikipedia (the Gadgets list on Preferences) so users such as myself could identify which users are the following: (every user right you want showed is optional)
- Administrators
- Bureaucrats
- Checkusers
- Oversighters
- ARBCOM Members
- OTRS Members
- Edit Filter Managers
- Stewards
Example: User:1989/sandbox
1989 (talk) 00:34, 19 December 2016 (UTC)
- Support as proposer. 1989 (talk) 00:34, 19 December 2016 (UTC)
Oppose "by default". In addition, if you want to know who's who turn on the popup script. Hover over a name and all their usergroups will show up (including global groups).--Majora (talk) 00:36, 19 December 2016 (UTC)- As long as this is an optional script that you have to choose to turn on I'm fine with it. --Majora (talk) 04:09, 21 December 2016 (UTC)
- Comment. Surely using the API is a better way to determine the permissions of a user than having a bot update a massive honkin' list of everybody with advanced permissions? I don't think this function is a bad idea for a gadget, though. Enterprisey (talk!) 01:42, 19 December 2016 (UTC)
- Strongly oppose for reasons above, but in addition, signatures are already long enough; there's no need to add more clutter. As well, decisions on Wikipedia are made by consensus, not by authority. ⁓ Hello71 14:04, 19 December 2016 (UTC)
- @Majora: & Hello71: The user rights in which you want showed is optional, I fixed my descriptions. 1989 (talk) 17:58, 19 December 2016 (UTC)
- @Hello71: The purpose of this setting is that user such as myself knows who is who so I can have specific assistance, it's not really about what you think it is. 1989 (talk) 17:58, 19 December 2016 (UTC)
- I like this idea, but as Enterprisey said, API may be better for this. We do have already a mark admin userscript here but it only marks administrators and only with a blue hue over the user (talk) page link. Jo-Jo Eumerus (talk, contributions) 18:01, 19 December 2016 (UTC)
- Oppose at least as long as it uses a data file containing stuff that the API already makes available. Jackmcbarn (talk) 18:05, 19 December 2016 (UTC)
- Pinging the following users who are familiar with scripts who could maybe help. @MusikAnimal and TheDJ:. 1989 (talk) 19:05, 19 December 2016 (UTC)
- That's interesting... I did not know Commons used a bot to generate a list, and the script went off of that! That does seem a bit unnecessary. However when viewing very large discussions where there are many users, this approach might be more efficient than having to query for each user individually. Instead the script already knows who to look for, and there aren't any API queries to slow down the user experience. I could go either way... I will say the script is quite nice, I use it on Commons myself. Writing a bot task to generate the list is easy as pie — MusikAnimal talk 19:28, 19 December 2016 (UTC)
- The main issue is obviously that MediaWiki user groups do not necessarily exists for all groups of users, e.g. ArbCom. --Vogone (talk) 19:41, 19 December 2016 (UTC)
- Sure, but the bot would know where to look (Wikipedia:Arbitration Committee) — MusikAnimal talk 19:43, 19 December 2016 (UTC)
- @MusikAnimal: The API allows bundling user info queries in batches of up to 50 pipe-separated usernames. To guess the practical meaning of that, I did a momentary survey of WP:ANI by doing a rough count of unique user-related URLs. I used
var foo = [];var bar = $('a[href*="/wiki/User"]').filter(function (i, e) {if(foo.indexOf(e.href) !== -1){return false;}else{foo.push(e.href);return true;}});console.log(bar.length);
) and found 324 unique URLs. Trying that again while adding a colon to the initial selector ('a[href*="/wiki/User:"]'
), to get context on redundancy from user page/talk pairs, found me 165 unique URLs. This suggests that long pages would require around 3–4 queries overall. {{Nihiltres |talk |edits}} 22:13, 20 December 2016 (UTC)- Yeah definitely, I overlooked that well-known functionality of the API! I'm not for or against this script here, I already have too many on this wiki... but I personally wouldn't oppose this solely based on the bot dependency when it is a trivial task to implement, and presumably we could adapt the one that was written for Commons. I don't think going by the API is that big of a concern either: Performance isn't an issue, but you have to give thought that the list of admins/arbitrators/etc doesn't change much, and tag on each user of this script, and each time they load a page, that amounts to a lot of API queries (although I guess you'd also need at least one query to get the bot-generated list). Overall I would look at this proposal at face value, and not be concerned about the development effort — MusikAnimal talk 23:07, 20 December 2016 (UTC)
- Though we should also give thought to the fact there are a lot more admins here than on Commons, so the list would be that much bigger and have to be downloaded on every page load... Nevermind me :) — MusikAnimal talk 23:11, 20 December 2016 (UTC)
- The main issue is obviously that MediaWiki user groups do not necessarily exists for all groups of users, e.g. ArbCom. --Vogone (talk) 19:41, 19 December 2016 (UTC)
- That's interesting... I did not know Commons used a bot to generate a list, and the script went off of that! That does seem a bit unnecessary. However when viewing very large discussions where there are many users, this approach might be more efficient than having to query for each user individually. Instead the script already knows who to look for, and there aren't any API queries to slow down the user experience. I could go either way... I will say the script is quite nice, I use it on Commons myself. Writing a bot task to generate the list is easy as pie — MusikAnimal talk 19:28, 19 December 2016 (UTC)
- Pinging the following users who are familiar with scripts who could maybe help. @MusikAnimal and TheDJ:. 1989 (talk) 19:05, 19 December 2016 (UTC)
- Oppose Admins do not carry any more authority than the janitor at school. (Even when we did jump when he shouted) such a script in general use would infer otherwise. Agathoclea (talk) 22:49, 20 December 2016 (UTC)
- We're not marking hierarchies here. It's simply who has what to more quickly click to the user's talk page that can assist with something that needs that permission. I use an admin highlighter on this wiki. All admins are marked blue for me. What does that mean? It means if I need an admin to help me with something related to an open issue, I can quickly click one of the signatures that's highlighted in blue to reach an admin that's already familiar with the issue. It's quite helpful.—cyberpowerMerry Christmas:Unknown 23:58, 20 December 2016 (UTC)
- Support unlike the opposes, I support the gadget, as long as it doesn't up too many resources in the process. I already use a similar gadget for admins only, and my rationale can be taken from the above comment I made and expanded to apply to this gadget. I could see such a gadget being useful.—cyberpowerMerry Christmas:Unknown 23:58, 20 December 2016 (UTC)
- Support, provided that with all technical user rights, the gadget checks the rights in real time and doesn't depend on a hard-coded list. עוד מישהו Od Mishehu 04:06, 21 December 2016 (UTC)
- Oppose as presented but support the idea of calling the API to do it, as an optional gadget. We already categorize users by userrights (e.g. Category:Wikipedia template editors) so it's just one more way to present information we already collect. I weakly suggest implementing a way for users to opt out of identification by the tool, say by creation of a Category:Wikipedians who prefer not to be identified by MarkAdmin.js or some better name. Ivanvector (Talk/Edits) 14:04, 21 December 2016 (UTC)
Enable Visual Editor for Wikipedia: namespace pages in the same way as Wikidata has added VE (a small pencil icon inside the Source editor editing window)
Hi all
I would like to propose that Visual Editor is enabled for Wikipedia: namespaces in the same way it is enabled on Wikidata where VE is activated through a small pencil icon within source editor rather than having Edit VE and Edit source options on the page.
The reason I am proposing this is because the Wikipedia: namespace is used for discussion pages (e.g Articles for Deletion pages) and organisational pages including all Wikiproject pages.
Wikiprojects would be much more easy to contribute and develop if VE was enabled, including the ability to easily edit tables which is much much more difficult in Source Editor, especially if the table is large. Here is an example of a page that uses a number of large tables which would be very difficult to edit in Source editor.
I think that the approach of having the VE button as a pencil icon within Source Editor would minimise the number of people trying to edit the discussion pages within the Wikipedia: namespace, this could be further added to with a commented out message asking users not to use VE on those pages.
Thanks very much
--John Cummings (talk) 13:51, 22 December 2016 (UTC)
AIV Instructions
I note that at the WP:AIV page there is a lack of a concise instruction box, which can lead to poorly formatted reports, especially by newcomers. I have made one here User:TheMagikCow/aiv instructions. Do we think that this is a good idea to place onto the page? TheMagikCow (talk) 17:37, 22 December 2016 (UTC)
- I think the instructions are contained in Wikipedia:Administrator_intervention_against_vandalism/Header? Ruslik_Zero 20:47, 23 December 2016 (UTC)
- TheMagikCow's version contains more information about what templates to use, which is missing from the current header. Perhaps that could be added to the current header? @TheMagikCow: it's not a good idea to set the font size to a specific number of points, as this is unkind to users with poor vision. Just use tags like large/small etc, which don't override user settings. --Stfg (talk) 09:56, 24 December 2016 (UTC)
- Ahh that makes sense. I'll change that now Stfg - Thanks for that! TheMagikCow (talk) 10:02, 24 December 2016 (UTC)
- TheMagikCow's version contains more information about what templates to use, which is missing from the current header. Perhaps that could be added to the current header? @TheMagikCow: it's not a good idea to set the font size to a specific number of points, as this is unkind to users with poor vision. Just use tags like large/small etc, which don't override user settings. --Stfg (talk) 09:56, 24 December 2016 (UTC)
I could work on merging the information from the two to create a new header? TheMagikCow (talk) 10:05, 24 December 2016 (UTC)
Done I have merged key information from both. TheMagikCow (talk) 10:17, 24 December 2016 (UTC)
Machine learning and language detection
Machine learning in the past few years has advanced quite a bit and one of the classic uses is language detection of a web page. There are now dozens of APIs available for language detection (quality unknown). It seems like a natural fit to apply this to references and fill in the |language=
field or adding language templates to bare links. Has anyone looked into this or done any work on it? I've thought about looking into this but wanted to check if this idea has been done before. Obviously any such system would have to be verified against a known set of pages to see what the error rate is as part of the development process, for example it might need to run 2 or 3 APIs for agreement before applying. -- GreenC 16:31, 21 December 2016 (UTC)
- Could be a job for a bot if anyone is interested in programming one, along the lines of bots that check for dead links and such. I'm nowhere near qualified to do so. Ivanvector (Talk/Edits) 15:57, 22 December 2016 (UTC)
- It's a bot I've been thinking about doing. It needs to be tested to make sure the idea is viable to see what the error rate is, that's why I was wondering if anyone else has done something like it. Ultimately to check all links (10 million+) using machine learning would be considerable computing resources so that's a problem also that needs to be explored. -- GreenC 16:27, 22 December 2016 (UTC)
- Perhaps this should be filed at WP:BOTREQ? TheMagikCow (talk) 10:18, 24 December 2016 (UTC)
Actively ask shared IP operators/people related to organization used by shared IP for abuse info?
Should we actively attempt to get abuse info from shared IPs?
I feel like the ability to inform operators or managers related to shared IPs of when someone using it is misbehaving would quickly cause abuse from the shared IPs to become very manageable.
My specific thoughts were asking schools, as we have a large amount of abuse problems from the school IPs and letting the people who work with the students (who are likely the ones doing the abuse) deal with the problems would work out a lot of problems.
However, the current templates mention that the abuse info parameter should only be used if it's requested by the educational facility.
Frankly, I think shared IP blocks, instead of requiring accounts completely, should be:
- temporary as the organization is contacted for info on what should be done
- permanent for organizations that have refused to give abuse info or have no visible abuse info
- temporary but kept until contact info can actually be found (though this second reason should have an option in the block template so if someone there wants to rectify this they know how to)
- technically permanent for organizations that do not respond
The only minor issues I have with this way is worries of disproportionate punishment and if we should be involved in their affairs, but I feel that both can and likely would be dealt with by the actual organization, once again. I am curious about how contacting the organization should be done by Wikipedia. My suggestion is that an administrator contacts the school via their abuse info as part of the ARV process.
Thoughts? NOTNOTABLE (talk) 17:39, 1 December 2016 (UTC)
- I believe that most orginizations would probably deal with abuse from their computers if they know it's happenning; this would be a gain for both us (as the abuse will stop) and them (as they won't need to worry about blocks onece the issues stop). עוד מישהו Od Mishehu 17:51, 1 December 2016 (UTC)
- Most organisations have an abuse@ address listed in their whois. I have dealt with a number of school IT administrators in the last ten years. In my experience the vast majority don't care and will do nothing but ask for a block or block Wikipedia from their schools. We can do the former without them. ISPs, who make money from customers, usually simply don't care. -- zzuuzz (talk) 18:10, 1 December 2016 (UTC)
- The vast majority may not care, but the small minority should be considered here. I'm not talking about sending repeated complaints - only enough to allow them to know that there is a problem from their orginization and that we are interested in helping them deal with it. עוד מישהו Od Mishehu 11:51, 7 December 2016 (UTC)
- I've written requests to various abuse@ emails found from whois lookups myself over the years, and haven't ever had a response at all. My assumption is that network administrators have better things to do than sift through abuse reports from some guy at Wikipedia; we have no ability whatsoever to effect consequences for non-response, and they have no incentive whatsoever to care what their users are up to here. Ivanvector (Talk/Edits) 20:16, 8 December 2016 (UTC)
- The vast majority may not care, but the small minority should be considered here. I'm not talking about sending repeated complaints - only enough to allow them to know that there is a problem from their orginization and that we are interested in helping them deal with it. עוד מישהו Od Mishehu 11:51, 7 December 2016 (UTC)
- Would an organization care if their entire site was blocked from Wikipedia? Some companies might welcome that, but I suspect many schools (which is where much of the abuse seems to come from) would care, and that is an ability we do have. ~ J. Johnson (JJ) (talk) 22:12, 8 December 2016 (UTC)
- We should give the company's abuse@ a single report, and respond to subsequent communications from them; that will be relatively little wasted effort on our part, and give orginizations a reasonable warning on the other hand. עוד מישהו Od Mishehu 10:39, 12 December 2016 (UTC)
Blocking a school of 4000 from reading Wikipedia because one kid inserted jokes in an article during lunch is nonsensical. Ramaksoud2000 (Talk to me) 17:54, 13 December 2016 (UTC)
- I don't think anyone here is proposing a read-block for schools. Though, I have previously been told that they might do this when I've spoken to their IT administrators. It's relatively easy for schools to blacklist sites entirely; I've persuaded a couple that it might be in their interests to just blacklist *wikipedia.org/*[?&]action=edit instead. Others, for example in CAT:INDEFIPs are blocked at the explicit request of the school admins, which might be described as their favourite response. We have a historical project, Wikipedia:Abuse response, which would be the thing to revive in a reformed shape. Personally I think the project was not a great help - ISPs don't care (who seriously cares about writing 'poop' on a website that lets anyone edit), and schools can be easily anon-blocked. It's actually possible to get individual kids punished for vandalising Wikipedia, but this doesn't seem like a great sport. Abuse from company IPs are relatively rare, due to the consequences of abusing your employer's IT systems. Back to school IPs, I have found that blocking will get the attention of school admins, when they are either reported upwards or the staff try to edit themselves. Ultimately however, schoolkids will be schoolkids, and except in extremely rare circumstances the next batch of kids will just do the same thing. Give them a chance every now and then to show they've changed their whole IT culture, but if not just schoolblock them again. -- zzuuzz (talk) 09:56, 14 December 2016 (UTC)
- The problem with IP blocks that are "permanent for organizations that have refused to give abuse info or have no visible abuse info" is that IP addresses change. We don't have the technology to make IP blocks that are "permanent for organisations", we only have the technology to make blocks that are temporary or indefinite for accounts, IP addresses or ranges of IP addresses. If we permanently block an IP address we have no idea who we are blocking in the future. ϢereSpielChequers 16:09, 19 December 2016 (UTC)
WP:ABUSE is inactive, but I know that people used to do a bit more digging into IP abuse than they currently seem to do. One issue: who does this and when they make contact who do they speak for? I have contacted schools about abuse (not just run-of-the-mill vandalism, but when revdelled/oversightable edits from their IP indicate that particular students at their school, say, might be being targeted for abuse: racist/homophobic bullying, posting of mobile phone numbers etc.) but when I've done so I've made clear that I'm a volunteer admin rather than an official representative of Wikipedia or the WMF. If there's an expectation that functionaries or administrators (or even non-admins) are going to routinely contact managers of shared IP networks like businesses or schools, we probably want to at least set up some guidelines on what they should do, what the relevant community expectations are and so on. Otherwise you've got, at best, potentially untrained people wasting the time of network admins while acting according to Wikipedia policy, or at worst, you've got people contacting network admins to play out petty grudges and so on. —Tom Morris (talk) 10:41, 24 December 2016 (UTC)
Proposal for Indonesian spelling and naming conventions
An RfC regarding the promotion of an Indonesian spelling/naming convention proposal can be found at WT:WikiProject Indonesia#Proposal. --HyperGaruda (talk) 06:30, 27 December 2016 (UTC)
Wikipedia linking system
I just opened an Wikipedia account. The reason is the following idea: I propose that in mathematical and physical equations, when a reader marks a term, the page will offered to jump to a definition page of that. I don't refer to the well known linking system "blue links". If more clarification is needed please ask and I will provide.
Good night, Gal.
- You could just have the popup tool-tip giving you the definition. I have seen that on Wikipedia, so it must be possible. Graeme Bartlett (talk) 04:08, 28 December 2016 (UTC)
New template needed for "translationese"
Per discussion on the Talk page of the Template messages page, I'd like to propose the introduction of a new template for writing style. This has to do with articles that have been translated from other-language editions of Wikipedia, or articles chiefly written by people not familiar with the English language. The writing style then becomes a kind of "translationese" which needs to be converted into plain English. - Wwallacee (talk) 11:54, 31 December 2016 (UTC)
Include link to Wikipedia:User pages when editing in userspace.
Would it be possible to have a link to Wikipedia:User pages at the top when pages in userspace are edited?Naraht (talk) 01:23, 2 January 2017 (UTC)
I have a new suggestion
Being able to search blocked users by parameter as well (e.g. Finding only blocked users with auto-block disabled as a parameter)
The parameters are : anon only, auto-block disabled, account creation disabled, email disabled, cannot edit talk page, and that's all I can think of. --Brynda1231 [Talk Page] [Contribs] 12:59, 5 January 2017 (UTC) — Preceding unsigned comment added by Brynda1231 (talk • contribs)
Please add a link to the traffic statistics of an article to article-pages
Iirc there once was a link to the stats.grok.se (now disfunctional) stats found on every article page (somewhere at the bottom). It seems that the link has been removed.
I'd like to ask for a new link on article pages that leads users to the Pageviews Analysis traffic statistics of the article.
These statistics can be very interesting for users and even serve academic or journalistic purposes to some extend. With very few exceptions nobody knows that these statistics even exist.
There are various ways how it can be linked; I'd suggest adding a "Traffic statistics" item to the "Tools" links on the left.
I also suggested this at the pageview statistics's talk page here.
--Fixuture (talk) 13:34, 6 January 2017 (UTC)
- That is already available indirectly via the "Page information" link under "Tools". 86.17.222.157 (talk) 13:43, 6 January 2017 (UTC)
- As well as the View history tab just prior to the beginning of the revisions table. --Izno (talk) 14:28, 6 January 2017 (UTC)
Consensus on Wikipedia on groupings of Christian denominations
I have opened a discussion on groupings in Christianity, of which there currently seems to lack a consensus on Wikipedia. The discussion might be of interest for quite a public. Please see: Talk:Christianity#Denominations. Don't know if this is the right place for such a note. If not, please relocate it. Chicbyaccident (talk) 15:18, 6 January 2017 (UTC)
YouTubers Suggestion Suggestion
Red text warning for not logged in
Hello. Sorry for posting incorrectly (Somehow I know I am not doing this correctly), but this "suggestion" process is about 50 times as complex, arcane, and non-standard as it needs to be. I already sent this suggestion to the "Wikipedia Information Team", and Jason Kelleher replied that ne never saw any red text warning for logged out, so he suggested I use this Pump thing.
Until a year or so ago, if you were logged out, the warning message at top was in red text. Now it is black text, making it very much less of a warning. My simple suggestion is change that warning back to red text. Before 99 of you respond that you also don't remember the red text, let's just forget about that and call this my brilliant idea. Also, before 99 of you respond that this belongs in another suggestion box, just tell me the URL for that.
Your Truly — Preceding unsigned comment added by Wikievil666 (talk • contribs) 01:11, 30 December 2016 (UTC)
- @Wikievil666: this is the wrong forum - but I think you are referring to this message: MediaWiki:Anoneditwarning? If so you can discuss it at: MediaWiki talk:Anoneditwarning. — xaosflux Talk 01:13, 30 December 2016 (UTC)
- I submitted an edit-request to make this change. If anyone wants to support the change, oppose the change, or carry out the edit request, you can do so here. The approximate result is this:
![](http://upload.wikimedia.org/wikipedia/en/thumb/d/de/AnonEditWarning.svg/9px-AnonEditWarning.svg.png)
- Ping to notify Wikievil666. By the way, you can use four tildes
~~~~
to sign a comment. It automatically converts into a name and date. Alsee (talk) 07:07, 7 January 2017 (UTC)- This went live, if there are any serious issues revert, for further discussion see MediaWiki_talk:Anoneditwarning#Protected_edit_request:_Red_warning. — xaosflux Talk 18:47, 7 January 2017 (UTC)
Replacing File:Macintosh_II_motherboard.jpg with File:Apple_II_motherboard.jpg
File:Macintosh_II_motherboard.jpg is a very low quality image that's been around forever, and has lots of links to it, and is a more correct filename. File:Apple_II_motherboard.jpg is also ten years old, but much, much higher quality image, and should definitely replace the former, but only has one link. My question is, is it correct to delete the first one, then rename the second to the first to keep all of the old one's links? I can easily fixup the one link to the latter in the process. --SilverbackNet talk 00:51, 8 January 2017 (UTC)
- SilverbackNet the file is only used on 3 articles, feel free to edit the articles to the updated picture. — xaosflux Talk 17:14, 8 January 2017 (UTC)
- As far as the 14 ones on other projects go, you should feel welcome to update them as well - just leave a very clear edit summary like
File:Macintosh_II_motherboard.jpg --> File:Apple_II_motherboard.jpg
if you don't read that project's language. Both of these files are on commons: so forcing a name swap would have to be discussed over there. — xaosflux Talk 17:17, 8 January 2017 (UTC)
- As far as the 14 ones on other projects go, you should feel welcome to update them as well - just leave a very clear edit summary like
Garage rock Wikiproject Rock music task force
TheGracefulSlick and I have been working on plans for a Garage rock task force that would operate under the banner of Wikiproject Rock music. We have designed a page and user box (see Task force page prototype). We have several editors who have indicated that they would like to join the task force once it gets started. But, we would like someone to assist us in the process of launching the page. Can anyone help? Garagepunk66 (talk) 01:41, 9 January 2017 (UTC)
Addition of “lay-title” to Cite journal
I propose the addition of a parameter |lay-title=
to the Template:Cite journal. Currently when |lay-url=
or |lay-summary=
is set an external link is added the displayed static text “Lay summary”. In some articles editors have added a title after the url causing an error message "Check |laysummary= value". If an optional |lay-title=
was added then a title could be used without errors, and if not used the citation would be unaffected. Although a title would not be required it could potentially be useful to prevent linkrot should the lay-url given ever need to be replaced. I previously posted on the idea of a “lay-title” here: Help_talk:Citation_Style_1#Lay_summary_in_Cite_journal and think the method described by Trappist the monk would be the best way to implement any change.
Change hyphen (-) to dash (—) in page title
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.
Proposal: The page title displayed in browser currently takes the form [title] - Wikipedia. I propose changing this to [title] — Wikipedia like the Russian Wikipedia, the French Wikipedia and the German Wikipedia, seeing as it looks better and makes more sense grammatically (hyphens are generally used to join words). Laurdecl talk 03:24, 10 January 2017 (UTC) Note on technical issues: A lot of the discussion is focusing on technical issues, such as browsers without Unicode support not rendering the title properly. However this point is moot because a) any browser with HTTPS support is obviously modern enough to render a dash and b) the three most popular other-language Wikipedias use a dash in the title, so there cannot be any drastic issues due to this. It's 2017, if people are still using an abacus as their computer it's time for an upgrade. Laurdecl talk 14:36, 10 January 2017 (UTC)
- Why? Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 04:05, 10 January 2017 (UTC)
Nothing spectacular, I was browsing ruwiki and thought it looked betterLaurdecl talk 04:18, 10 January 2017 (UTC)- @Wugapodes: I updated the proposal wording and reasoning. Laurdecl talk 14:12, 10 January 2017 (UTC)
- Oppose -
Other stuff exists. Similarly, I oppose changing "Wikipedia" to "Википедия".Sorry, from "per the Russian Wikipedia" I gathered you were making an argument for consistency between Wikipedia sites. After your added comment above, I see that your argument is that it looks better and what the Russians are doing is irrelevant. That being the case, I question whether it looks much better, if at all. I also refer you to the way major sites do it, including Yahoo! Mail, The New York Times, YouTube, and Google Search. Can you point to four major sites that use emdash instead? ―Mandruss ☎ 05:44, 10 January 2017 (UTC)- @Mandruss: I proposed this because I think the dash looks better and because it makes more grammatical sense — hyphens are used to link words whereas a dash is used to indicate more information is coming (take your signature for example). It's more an aesthetic taste thing than anything else though. Laurdecl talk 08:32, 10 January 2017 (UTC)
- @Laurdecl: I understand. I think others may have better arguments against than just consistency with most of the rest of World Wide Web (when in Rome...). Like perhaps some little known HTML standard or convention, or problems with certain devices that can handle hyphens but don't play well with emdashes. Even without that, I think it's a toss-up. ―Mandruss ☎ 08:37, 10 January 2017 (UTC)
- @Mandruss: I proposed this because I think the dash looks better and because it makes more grammatical sense — hyphens are used to link words whereas a dash is used to indicate more information is coming (take your signature for example). It's more an aesthetic taste thing than anything else though. Laurdecl talk 08:32, 10 January 2017 (UTC)
- Oppose. Back in October when it was proposed to remove "the free encyclopedia" from the page title, I suggested changing the hyphen to an en dash. According to CFCF in that discussion, this would be impossible as some older devices (as Mandruss says) have problems with Unicode characters. I doubt that the situation has changed in the last three months. I would suggest waiting about a decade and posting this again. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:13, 10 January 2017 (UTC) This may not be entirely accurate in terms of how severe the problem actually is, but that is how I understood the discussion at the time and I did not ask for elaboration on the technical details. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:35, 10 January 2017 (UTC)- @Jc86035: Seeing as the three other biggest Wikipedias (French, Russian and German) use a dash I doubt it breaks compatibility, or they wouldn't use it. Laurdecl talk 13:23, 10 January 2017 (UTC)
- @Laurdecl: I'm somewhat skeptical about the need to use the hyphen as well, but the English Wikipedia is used almost as much as all other WMF sites put together so there would probably be more statistical outliers here. (I myself have never used an OS old enough not to support Unicode without modification, so I would rather editors with more computing experience than me decide.) Then again, anyone using an OS without HTTPS can't access the site anyway… Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:44, 10 January 2017 (UTC)
- @Laurdecl: I'm somewhat skeptical about the need to use the hyphen as well, but the English Wikipedia is used almost as much as all other WMF sites put together so there would probably be more statistical outliers here. (I myself have never used an OS old enough not to support Unicode without modification, so I would rather editors with more computing experience than me decide.) Then again, anyone using an OS without HTTPS can't access the site anyway… Jc86035 (talk) Use {{re|Jc86035}}
- @Jc86035: Seeing as the three other biggest Wikipedias (French, Russian and German) use a dash I doubt it breaks compatibility, or they wouldn't use it. Laurdecl talk 13:23, 10 January 2017 (UTC)
- Comment — This was discussed and part of an RfC in October. I would suggest closing this as a perennial proposal. Laurdecl It would have been good to bring this up as a discussion before starting an RfC. Carl Fredrik 💌 📧 10:06, 10 January 2017 (UTC)
- @CFCF: being discussed once in an somewhat unrelated RfC hardly makes this a perennial proposal. RfCs are the natural place to get comments on a proposal, which is what I was looking for. I'll just withdraw this if there's any more opposition, no big deal. Laurdecl talk 12:05, 10 January 2017 (UTC)
- It wasn't meant as any major criticism, just a comment in favor of closing this without running a full RfC. I understand the reasoning and agree that it makes sense — but there are problems with implementation on older machines. I don't think we have to wait 10 years though, give it 5 and that's enough. Carl Fredrik 💌 📧 12:24, 10 January 2017 (UTC)
- I'm a little confused. Unicode and HTML#Web browser support and Unicode#Web seemsto indicate that IE7 and later support the Unicode blocks of interest out of the box and even IE5.5 and 6 support it with a bit of tinkering. From whence are you sourcing your information that browsers do not support the blocks of interest? Since we offer only basic functionality for the affected versions of the web browsers, would it be so wrong to use a proper dash? --Izno (talk) 13:23, 10 January 2017 (UTC)
- In large part it has to do with downloading files, where a number of iterations of Windows do not support such characters. Carl Fredrik 💌 📧 13:27, 10 January 2017 (UTC)
- @CFCF: For clarity, which operating systems are these, and are they still able to access the Wikipedia website? (Also, are there actual documented cases of this being a problem?) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:25, 10 January 2017 (UTC)- If I'm not mistaken it has to do with the format of the file system. FAT32 and older variants of NTFS do not support such characters in file-names. This was the original reason why the character was chosen. Those filesystems are used in Windows XP and Windows 7 and would probably also be used if upgrading to Windows 8 or 10. I think W8&10 default to newer variants that support more characters on new installs. You might argue that downloading files from Wikipedia isn't important, but there are those that still do this. Remember, Wikipedia has a number of users who do not reside in first world countries and might be on seriously outdated software and hardware. I'm not saying this can't be changed, but you need to accept it is a more complicated issue and as may be quite evident, this RfC which does not explain any of the intricate details in the description isn't going to lead anywhere. Carl Fredrik 💌 📧 16:33, 10 January 2017 (UTC)
- @CFCF: For clarity, which operating systems are these, and are they still able to access the Wikipedia website? (Also, are there actual documented cases of this being a problem?) Jc86035 (talk) Use {{re|Jc86035}}
- In large part it has to do with downloading files, where a number of iterations of Windows do not support such characters. Carl Fredrik 💌 📧 13:27, 10 January 2017 (UTC)
- @CFCF: being discussed once in an somewhat unrelated RfC hardly makes this a perennial proposal. RfCs are the natural place to get comments on a proposal, which is what I was looking for. I'll just withdraw this if there's any more opposition, no big deal. Laurdecl talk 12:05, 10 January 2017 (UTC)
- Comment – I agree that a dash (a spaced en dash in my opinion) would look better, but, as above, not all browsers have unicode support. Having it work consistently on all devices seems more important to me than looking a bit better on most of them. ‑‑YodinT 12:27, 10 January 2017 (UTC)
It's done on most other language WikipediasIt's done on four of the most popular Wikipedias, so it can't be that breaking of a change. Laurdecl talk 12:51, 10 January 2017 (UTC)- I'm not entirely sure that is true. Carl Fredrik 💌 📧 13:10, 10 January 2017 (UTC)
- @CFCF: Can you elaborate? It's true that many other language Wikipedias use it (de, fr, ru) and it's unlikely they would do so if it broke compatibility. What kind of browser has HTML5 but can't render a dash? Laurdecl talk 13:20, 10 January 2017 (UTC)
- Hi Laurdecl, yep it's not the end of the world either way, but as above, I would personally rather it didn't break on any devices, even if that's only a few. Other users may be able to advise roughly how many readers would potentially be affected by this. Also, regarding the other Wikipedias you've added to the proposal, German Wikipedia only uses a dash on their homepage, not on articles, and French only seems to use hyphens, like us. ‑‑YodinT 13:11, 10 January 2017 (UTC)
- @Yodin: Uhh, the French wiki uses a long dash (—) and the German wiki uses a medium dash (–) both on all their articles. Laurdecl talk 13:17, 10 January 2017 (UTC)
- You've so far stated 4. That means there are ~290+ left that potentially don't use it. Add that to the fact that there are a number that use a comma instead (including the larger sv and ar) — makes me very skeptical of you claim that most use it. You can't make up facts like saying that most use the long dash without anything to support your argument. Carl Fredrik 💌 📧 13:25, 10 January 2017 (UTC)
- es-wiki, nl-wiki & ja-wiki use the short dash, pt-wiki a comma — this isn't checking out. Carl Fredrik 💌 📧 13:29, 10 January 2017 (UTC)
- I'm talking pageviews – fr and de wiki have 2 million articles and use dashes in titles. Ergo there cannot be a large technical problem. Sorry about the "most" claim though, seeing as I based it on 4 other wikis. Laurdecl talk 13:53, 10 January 2017 (UTC)
- es-wiki, nl-wiki & ja-wiki use the short dash, pt-wiki a comma — this isn't checking out. Carl Fredrik 💌 📧 13:29, 10 January 2017 (UTC)
- You've so far stated 4. That means there are ~290+ left that potentially don't use it. Add that to the fact that there are a number that use a comma instead (including the larger sv and ar) — makes me very skeptical of you claim that most use it. You can't make up facts like saying that most use the long dash without anything to support your argument. Carl Fredrik 💌 📧 13:25, 10 January 2017 (UTC)
- Here's what I see on French and German Wikipedias. I'm intrigued though as MediaWiki:Pagetitle on those Wikis matches what you say... ‑‑YodinT 13:38, 10 January 2017 (UTC)
- @Yodin: Yeah that's not what I'm seeing. I see — on both the French and German wikis, do you have some kind of custom title display? Laurdecl talk 13:56, 10 January 2017 (UTC)
- Weird, no, and I see em dashes on the Russian Wikipedia... would be interested to know what anyone else sees, to make sure I'm not going crazy... ‑‑YodinT 14:07, 10 January 2017 (UTC)
- @Yodin: I think I'll list this on centralised discussion seeing as it's a site wide change, then we can get some opinions on your... condition. Laurdecl talk 14:14, 10 January 2017 (UTC)
- lol, go for it! ‑‑YodinT 14:47, 10 January 2017 (UTC)
- @Yodin: I think I'll list this on centralised discussion seeing as it's a site wide change, then we can get some opinions on your... condition. Laurdecl talk 14:14, 10 January 2017 (UTC)
- Weird, no, and I see em dashes on the Russian Wikipedia... would be interested to know what anyone else sees, to make sure I'm not going crazy... ‑‑YodinT 14:07, 10 January 2017 (UTC)
- @Yodin: Yeah that's not what I'm seeing. I see — on both the French and German wikis, do you have some kind of custom title display? Laurdecl talk 13:56, 10 January 2017 (UTC)
- @Yodin: Uhh, the French wiki uses a long dash (—) and the German wiki uses a medium dash (–) both on all their articles. Laurdecl talk 13:17, 10 January 2017 (UTC)
- I'm not entirely sure that is true. Carl Fredrik 💌 📧 13:10, 10 January 2017 (UTC)
- While I personally favor the hyphen, I don't think it is doable until all systems that still update (assuming someone doesn't have a computer from a company that bankrupted or is no longer making updates) can read Unicode. I think that falls best under Wikipedias goal, to inform, not look pretty. Iazyges Consermonor Opus meum 14:19, 10 January 2017 (UTC)
- @Iazyges: The second and third most popular Wikipedias use a dash in titles, so there can't be too much of an issue with using them. Also, who has a computer that can't read Unicode? This isn't 1960. Laurdecl talk 14:31, 10 January 2017 (UTC)
- Comment Claims of "most other Wikipedias use the ..." really need elaboration, if not sourcing. We now have Wikipedia in over 280 languages, so I've looked at the first 20 listed at m:List of Wikipedias#All Wikipedias ordered by number of articles.
- Slightly over half (i.e. eleven) of these use a spaced hyphen-minus (U+002D) character, they are: Arabic, Catalan, Cebuano, Chinese, Dutch, English, Italian, Japanese, Persian, Spanish, Waray. Of these, five (Cebuano, English, Italian, Japanese and Waray) uses the Mediawiki software default for that language.
- Slightly over a quarter (i.e. six) of them use a spaced en-dash (U+2013): German, Norwegian, Polish, Portuguese, Swedish, Vietnamese. Of these, one (Norwegian) uses the Mediawiki software default for that language.
- The remaining three use a spaced em-dash (U+2014): French, Russian, Ukrainian. Of these, two (French and Ukrainian) uses the Mediawiki software default for that language.
- None use an unspaced character. --Redrose64 🌹 (talk) 14:38, 10 January 2017 (UTC)
- @Redrose64: Thanks for the info, I meant to imply that the most popular Wikipedias (besides English) use a dash – French, German and Russian. I struck the "most other Wikipedias" comment. Laurdecl talk 14:58, 10 January 2017 (UTC)
- Comment @Laurdecl: If we're actually changing it, I think it should be an en dash (–) rather than an em dash (—), since em dashes are usually used (AFAIK) without spaces between it and the adjacent words. Using an en dash would be, I think, somewhat more cromulent. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:14, 10 January 2017 (UTC)- @Jc86035: perhaps write "Support, but with en dash" and we'll see at the end which the consensus is in favour of (if either). Laurdecl talk 15:25, 10 January 2017 (UTC)
- @Laurdecl: I'm waiting until CFCF clears up exactly how big of a problem character support in filenames is (assuming encodings are a complete non-issue). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:33, 10 January 2017 (UTC)- @Jc86035: You should probably ping him again, but should we really be concerned about the off choice that someone wants to mass download Wikipedia on their MS-DOS computer? Laurdecl talk 15:51, 10 January 2017 (UTC)
- @Laurdecl: Windows XP could plausibly have filename issues, but it's not likely to be a problem because any sane person running their own mirror (if any) probably has a less antiquated OS… CFCF? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 16:09, 10 January 2017 (UTC)- This is not my field of expertise, but it could affect Windows 7 and later as well. Also, a surprising amount of users are still on Windows XP, and it is even supported in certain enterprise environments. Carl Fredrik 💌 📧 16:35, 10 January 2017 (UTC)
- @Jc86035: @CFCF:According to https://msdn.microsoft.com/en-au/library/windows/desktop/aa365247(v=vs.85).aspx NTFS supports Unicode names which suggests that Windows XP and on can handle a — in a file name. Laurdecl talk 16:49, 10 January 2017 (UTC)
- A lot of USB memory sticks, for example, still use FAT32 by default. Another factor that was brought up before by Guy Macon was support for screen readers for the blind. ‑‑YodinT 17:01, 10 January 2017 (UTC)
- @Jc86035: @CFCF:According to https://msdn.microsoft.com/en-au/library/windows/desktop/aa365247(v=vs.85).aspx NTFS supports Unicode names which suggests that Windows XP and on can handle a — in a file name. Laurdecl talk 16:49, 10 January 2017 (UTC)
- This is not my field of expertise, but it could affect Windows 7 and later as well. Also, a surprising amount of users are still on Windows XP, and it is even supported in certain enterprise environments. Carl Fredrik 💌 📧 16:35, 10 January 2017 (UTC)
- @Laurdecl: Windows XP could plausibly have filename issues, but it's not likely to be a problem because any sane person running their own mirror (if any) probably has a less antiquated OS… CFCF? Jc86035 (talk) Use {{re|Jc86035}}
- @Jc86035: You should probably ping him again, but should we really be concerned about the off choice that someone wants to mass download Wikipedia on their MS-DOS computer? Laurdecl talk 15:51, 10 January 2017 (UTC)
- @Laurdecl: I'm waiting until CFCF clears up exactly how big of a problem character support in filenames is (assuming encodings are a complete non-issue). Jc86035 (talk) Use {{re|Jc86035}}
- @Jc86035: perhaps write "Support, but with en dash" and we'll see at the end which the consensus is in favour of (if either). Laurdecl talk 15:25, 10 January 2017 (UTC)
- Oppose Any battle over hyphens versus en-dash versus em-dash inevitably comes down to outdated Edwardian (at best) proscriptivist grammar. Has any reliable study anywhere ever shown a difference in reader comprehension that can be traced to one- or two-pica differences in the length of a tiny horizontal line? I think not. In a previous life, I actually participated in at least two studies/surveys showing that readers mostly did not even notice different dash length, let alone have any difficulty with reading them. Making a mostly imperceptible change just for the sake of old printer's rules seems like a waste of resources. Eggishorn (talk) (contrib) 17:23, 10 January 2017 (UTC)
- Comment – This doesn't strike me as a big deal. As a technical matter, Jc86035 is correct above that an en-dash ('–') would be more appropriate than an em-dash ('—') for the use described (i.e. with the spaces on both sides). It does bother me when I'm reading article text with a hyphen in the place of a dash, since it is technically incorrect, but I'm okay with it in page titles and file names. If changing to a dash would cause issues in older devices, then it's probably not worth it. Mz7 (talk) 18:06, 10 January 2017 (UTC)
- A Modest Proposal. I propose that all editors be topic banned from issues regarding the substitution of hyphens for dashes, or vice versa, or of any type of dash for another. I see no downside to this proposal, and am sure it will reduce the amount of time-wastin nonproductive discussion. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. (talk) 18:13, 10 January 2017 (UTC)
- Support as proposer. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. (talk) 18:13, 10 January 2017 (UTC)
- Oppose as character assassination. ―Mandruss. Pampered by all administrators (except one) since 2013. ☎ 18:27, 10 January 2017 (UTC)
- Abstain, truth is sometimes stranger than fiction. But I'm afraid I must dash. Martinevans123. Hoping to find out what an administrator does one of these days (talk) 18:56, 10 January 2017 (UTC)
- Oppose still no compelling reason. Pretty much no one notices the page title, spending a month determining whether to align our page title with inconsequential typographic rules is a waste of time, and I simply don't like the look of the change. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 23:11, 10 January 2017 (UTC)
- 'Oppose - No, it's past time to stop fucking around with this issue. Beyond My Ken (talk) 23:14, 10 January 2017 (UTC)
- Oppose no reason to change anything. If it isn't broke, don't fix it. TonyBallioni (talk) 01:46, 11 January 2017 (UTC)
- Comment, as an editor I find all of these endashes and emdashes to be a weird pain in the butt. I would wager that few of our readers have ever even heard the names "endash" or "emdash". I'd wager that readers who copy-paste anything from Wikipedia find them to be an utterly confusing pain in the butt. If all endashes and emdashes were to mysteriously evaporate overnight, I would hesitate to support bringing back any of them anywhere. (Although I would carefully consider any strong support arguments in that discussion.) Alsee (talk) 03:41, 11 January 2017 (UTC)
Wiki Speaks Your Language
![](http://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Wiki_Speaks_Your_Language_logo.svg/200px-Wiki_Speaks_Your_Language_logo.svg.png)
Hello all. It is my pleasure to inform you about the launch of the Wiki Speaks Your Language initiative with the goal of enriching the Wikimedia projects with freely licenced audio (and video) files documenting spoken examples of every language, language variety and dialect in the world.
The idea originates from the curiosity of many readers viewing language articles not only to read about the language but also to hear how does it sound. In most of the cases, our language articles lack such files and readers usually end up searching videos on YouTube, notwithstanding that we have the capacity as a movement and the resources to meet their wish.
The initiative lists three possible ways of acquiring the freely licenced audio (and video) files: 1) by adapting existing audio and video files on Wikimedia Commons (mostly from the Spoken Wikipedia projects), 2) by liberating existing audio and video files from the repositories of GLAM and educational institutions, and 3) by engaging Wikimedia communities, GLAM and educational institutions in the recording of new audio and video files.
In the first phase of the initiative, the easiest way to start is by working with the resources we already have and therefore my proposal and kind request to the English Wikipedia community is to get involved in adapting existing videos from the WikiProject Spoken Wikipedia. There are some useful tips on what the existing files should be adapted to. Since English has many different varieties that our readers would be willing to explore, it would be very useful if the authors of the files also indicate the varieties (e.g. British English, American English, Canadian English, Australian English etc.). The adapted files should be categorised under "Category:Wiki Speaks English" (or "Category:Wiki Speaks British English", "Category:Wiki Speaks British English" etc.) and added to the list of languages.
Best regards.--Kiril Simeonovski (talk) 23:57, 12 January 2017 (UTC)
Social media names and achievements as roads into WP content
Quite a few new eds seem to think their hits/presence on social media is sufficient to achieve status for an article on wikipedia.
I have looked through the FAQ of perennial propoals and cannot see direct mention of this issue. Apology if I have missed this being discussed elsewhere or before...
If I havent missed other discussions - the suggestion here is: - that
- (a) Notability policies and procedures are re-written to limit/restrict social media activity or status as a legitimate lever into valid content.
- (b) CSD - extra component for CSD 7 - social media activity and content (and volume) are not items that are included in wp as 'stand alone' elements - details of other aspects of an individuals or group activity other than social media are required
- (c) Possible policy page on 'Social Media Names, Logos and Images' as not transferable to Wikipedia...
This has come from a recent stint on new pages patrol and exposure to articles with social media activity as the main component in potential autos JarrahTree 08:11, 8 January 2017 (UTC)
- @JarrahTree: I'm not sure we need to do anything about this - WP:N is quite clear that notability is established by the subject's coverage in independent reliable sources, and has nothing to do with how many followers they have on social media. (a) What exactly do you think needs re-writing? (b) A7 already states that a 'credible claim of significance' is required - and a claim of X followers on social media could demonstrate this, but it would be up to the administrator to decide. If someone has 5 million followers on Twitter then that's a credible claim of significance - it's likely they've done something notable; on the other hand if they have 500, that's not really a claim of significance. I think any addition to A7 along these lines would be long-winded and/or arbitrary. (c) I'm not sure I understand what you mean with this point, could you clarify what you mean by 'transferable'? Sam Walton (talk) 16:02, 13 January 2017 (UTC)
Thanks for your reply - maybe there is really nothing to do after all - having seen so many, it was an idea that arose, but as you put it - maybe it is not an issue.
(c) - was whether some social media users with their social media names/brands - were able to use the exact same names on wp - JarrahTree 00:58, 14 January 2017 (UTC)
Comments Requested - Article Name Change for Israel and the apartheid analogy
Fellow Editors, your input would be appreciated concerning a proposal to change the title of this article. I am posting the RfC here so as to attract the widest range of editors possible. A clear consensus would be invaluable. Your input can help make that happen. Proposed titles & discussion. Thanks for your participation. Veritycheck✔️ (talk) 02:17, 14 January 2017 (UTC)
AIV RfC
Pease see here for a relevant RfC on the AIV page. TheMagikCow (talk) 14:47, 14 January 2017 (UTC)
What kind of contributions that could be done by readers or casual contributors that would support editors at the same time?
Check out the suggestions here, the mockups are very detailed, but these are just ideas -- discussion and further ideas is required :). Thanks ..--Melamrawy (WMF) (talk) 21:42, 16 January 2017 (UTC)
Delay for A7 and G11 CSD Tags
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
![]() | I am closing this despite the fact that I particpated. After fifteen days of discussion, opposition is running at 4:1, meaning the proposal has clearly failed and given that the most recent comments are five days old it is unlikely that leaving it open would change that. Beeblebrox (talk) 07:32, 18 January 2017 (UTC) |
Proposal: A7 and G11 CSD tags should not be applied to new articles within the first 30 minutes of creation and that the templates be modified to alert editors when they are being applied too hastily. When templates are improperly applied too quickly to newly created articles they should be ignored and or removed. This proposal does not affect other CSD tags which may still be applied as needed. The CSD guidelines shall be modified to reflect this change upon adoption by the community.
Rationale: Tag bombing newly created articles within minutes, and sometimes seconds of creation appears to be a recurring problem. There have been instances where this has been done to new editors working on their first article and I can imagine how discouraging it must be. Giving editors a chance to flesh out their new article to demonstrate the notability of the subject and ensure that the language is NPOV compliant before nominating for speedy deletion does not strike me as a threat to the integrity of the project. -Ad Orientem (talk) 15:48, 2 January 2017 (UTC)
Support
- 30 minutes sounds like a more suitable time than 15 or 10 minutes. But other kinds of speedy delete nominations, A1, and A3 and A9 could benefit from this delay. Graeme Bartlett (talk) 20:51, 2 January 2017 (UTC)
- I can see where 30 minutes is a suitable amount of time. I am sometimes a little trigger happy myself on A1, A3, and A7. Even though many of these will end up being deleted, I guess it is always better to wait and see to make sure an article doesn't turn into something worth being kept when the creator is given a little time. United States Man (talk) 21:13, 2 January 2017 (UTC)
- Wikipedia:Perennial proposals#Grace period for deletion states, "As for speedy deletion, our criteria are carefully written so that articles can be speedily deleted only if no Wikipedia-compliant article is possible at this time..." More, "A mandatory grace period would also be excessively bureaucratic, and would make it more difficult to delete copyright violations and attack pages..." The audience for this text appears to be for other than the editors here. No, bureaucracy occurs when an editor must appeal a hasty deletion to the deleting admin, and possibly DRV; possibly resulting in two extra entries in the deletion log.
I also wonder if more can be done to move newly created articles that fail WP:V to draftspace. But the last I heard, we are still requiring deletion of the cross-space redirect. Unscintillating (talk) 01:42, 3 January 2017 (UTC)
- Support I'd like to bring in a concrete example, and as recently mentioned in BlooombergBusinessweek. Five minutes after an article was created in 2014 by a first-time editor an A7 was slapped on the article. Of course now we are sensitized regarding articles about women, about Africa, etc. and so I suppose this couldn't happen again in quite the same way, right? But then, a simple procedural waiting period without regard to sensitivities du jour could also have prevented the insult to sundry and embarrassment to Wikipedia. This has become a perennial embarrassment. Shenme (talk) 01:47, 3 January 2017 (UTC)
- reading the article, the ed. knew enough to appeal and the article was not deleted. So the one (and only) "concrete example" here shows the systems worked right in this instance. DGG ( talk ) 06:09, 4 January 2017 (UTC)
- Support I proposed this a while back, but it didn't really go anywhere. I'm not sure what the best "grace time" would be, but I definitely support the extension of the delay of tagging A1 and A3 to include A7. Adam9007 (talk) 02:32, 3 January 2017 (UTC)
- Strong support. The treatment of new editors in this regard has been utterly shameful. There are editors who pseudo-patrol the most recently created articles, tag-bombing articles still being written at a pace that makes clear they are making no effort to comply with WP:BEFORE or otherwise determine whether there is the potential for an appropriate article to be developed. There is no need for such hasty treatment; the delay of only a few minutes is inconsequential in terms of Wiipedia maintenance (it is typically several hours before the deletion tag is reviewed), while the repeated callous treatment of new, good faith editors damages Wikipedia on a daily basis. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by administrators since 2006. (talk) 04:09, 3 January 2017 (UTC)
- Support for all article criteria. If it's good enough that we would tolerate it in an other namespace, we can tolerate it for a little longer in the mainspace. עוד מישהו Od Mishehu 10:21, 3 January 2017 (UTC)
- Support I find the opposes both unconvincing and concerning. Jclemens (talk) 01:01, 5 January 2017 (UTC)
- Support - The proposal is about tagging, Wikipedia:Perennial_proposals#Grace_period_for_deletion is about deletion. Affording some breathing room to new editors could improve their experience and does nothing significant to harm Wikipedia. ~Kvng (talk) 15:33, 6 January 2017 (UTC)
- Support I was elated to see this, as this has happened several times to me. Great idea!--Kintetsubuffalo (talk) 07:16, 12 January 2017 (UTC)
Oppose
- Oppose per the arguments already outlined at Wikipedia:Perennial proposals#Grace period for deletion. Beeblebrox (talk) 22:45, 2 January 2017 (UTC)
- Oppose - Per Beeblebrox. There's very little upside, and the downside is that it will cause more garbage to slip though and discourage new page patrollers from wanting to keep push the boulder up the hill. A7 and G11 specifically give us the means to keep the flood of spam out of Wikipedia. Spam doesn't become more desirable or notable after 30 minutes.- MrX 23:13, 2 January 2017 (UTC)
- Oppose – Wikipedia articles are a live part of WP and should be treated as such, regardless of their age. We have Draft space and User sandboxes and Wikipedia:Your first article for a reason. – Jonesey95 (talk) 00:34, 3 January 2017 (UTC)
- Snow Oppose: Already listed at WP:Perennial proposals#Grace period for deletion. We have draft and userspace drafts available. KGirlTrucker81 huh? what I've been doing 00:58, 3 January 2017 (UTC)
- Oppose. I think the delays already recommended for A1 and A3 are fine, as "no content" and "no context" can't be properly judged until the writer has had enough time create some content. But by the time there's enough to see it's clearly an A7 then there should be nothing to be gained by waiting longer. We don't want to be forced to keep the masses of A7 junk we get along the lines of "Billy is a cool dude who goes to Plopville School", "Brunhilde is the cutest girl in class", "Ranjit is a top computer studies student"... for a second longer than the time it takes to delete it. Boing! said Zebedee (talk) 01:05, 3 January 2017 (UTC)
- Oppose - I see the logic in waiting longer and potentially seeing articles blossom and in theory it sounds great .... however in reality it rarely happens - Someone'll create a one liner or something well meaning but incomprehensible and then buggers off so in reality waiting longer just means more shit slips through and will eventually be caught and deleted anyway, As I said in theory it sounds great but in reality it'd just be a bloody nightmare. –Davey2010 Merry Xmas / Happy New Year 01:13, 3 January 2017 (UTC)
- Weak oppose per Boing! said Zebedee and my thoughts below. I think slapping A7s on articles within seconds of creation (this does happen) is almost always ridiculous. At the same time, I have put an A7 on a article about a little girl who played the harmonica really nice after around 15 minutes before. I believe in giving people a chance to meet the low standard of A7, and I especially give them this chance if the article is about a subject not in North America or Western Europe, but I think having it as a suggestion at WP:NPP is the way to go for now. TonyBallioni (talk) 02:03, 3 January 2017 (UTC)
- Obvious oppose The Draftspace and user space were created for this reason. Any article on the mainspace should be ready for reading by anyone. — Music1201 talk 02:36, 3 January 2017 (UTC)
- Oppose - Based on experience, most articles tagged for A7 have little-to-no chance of surviving anyway, adding a grace period will only prolong such articles' misery. In theory, this could work for articles tagged under A7 but whose subjects have actually been mentioned elsewhere, but in clear-cut cases it will just add more bureaucracy, which isn't what we need. As for grace periods in general, they should be done for A1 and A3 and have already been done, but sometimes it's necessary to ignore the rules if such articles have no chance at surviving anyway. In my case at least, in most cases before I tag an article for speedy deletion I first check and see if the subject of the article has been covered online (regardless if such coverage is significant or not) and based on what I see I try to make sure I only tag articles which are clearly not notable or do not assert notability at all, though of course I do make mistakes sometimes. Narutolovehinata5 tccsdnew 03:13, 3 January 2017 (UTC)
- Oppose I'm all for not biting the newbies but the way to do that is to have compatent patrollers not make up new rules which are likely to be applied pedantically by equally unqualified editors. The primary effect of the proposed rule is having a bunch of obvious A7s declined for "tagged too soon" which will then require that the article go to AfD and waste everyone's time. Most A7s are going to be A7s no matter how long the author has to work on them and the proper way to deal with them is to tag it and explain to the author why it was tagged. If a particular patroller is causing disruption by habitual early tagging they can be 'counseled' or brought to ANI. JbhTalk 04:09, 3 January 2017 (UTC)
- Oppose per MrX and my comment below. BethNaught (talk) 10:45, 3 January 2017 (UTC)
- Oppose, most editors falling innocently into creating A7 articles need guidance NOW not 30 minutes after they've surfed off elsewhere. The problems identified would be better resolved by modifying the wording of {{db-a7}} and the other templates which add the A7 request ({{db-person}}, {{db-animal}}, {{db-band}}, {{db-club}}, {{db-inc}}, {{db-web}}, & {{db-event}}) to point out that WP:NOTABILITY needs to be met, rather than have the author expend the effort to assert significance only to be slapped with an AfD for lack of notability a few minutes later.
- As noted by several in the comments below, moving to draft (with an explanation on the author's talk page, and deletion (WP:R2) or suppression (WP:PM/C#6) of the redirect) is a better solution. Either way the author's attention needs to be drawn to the deficiencies as kindly as possible, as soon as possible.
- Those instances where A7 combines with an author's WP:COI, WP:AUTOBIO, or WP:PAID problems (and WP:G11 comes into play as a consequence), the sooner the mop is applied the better.
- Vehemently oppose any extension of time delays to G11. Cabayi (talk) 15:33, 3 January 2017 (UTC)
- I strongly disagree that actual notability should be demonstrated to avoid speedy deletion. Speedy deletion is supposed to be only for uncontroversial cases, and notability needs proper research and is rarely uncontroversial. Boing! said Zebedee (talk) 15:43, 3 January 2017 (UTC)
- Boing! said Zebedee - that's not what I said. There's no user-friendliness in encouraging editors to jump the hurdle of significance/importance to get past A7 when it'll just lead them to being hit by notability & AfD as soon as they've jumped.
- Better to let authors know what the long-term requirements are so that they can ensure the retention of their article rather than to present them with the idea that wikipedia is a never-ending succession of unfriendly hurdles. Significance/Importance may be the criteria for applying/keeping/removing the A7 tag, but notability is the ultimate criteria for article retention. Cabayi (talk) 15:54, 3 January 2017 (UTC)
- Ah, I see what you mean, sorry! You don't mean change the criteria, just add to the message that ultimately notability will be needed. That's not a bad idea. Boing! said Zebedee (talk) 15:58, 3 January 2017 (UTC)
- I strongly disagree that actual notability should be demonstrated to avoid speedy deletion. Speedy deletion is supposed to be only for uncontroversial cases, and notability needs proper research and is rarely uncontroversial. Boing! said Zebedee (talk) 15:43, 3 January 2017 (UTC)
- Oppose – per all of the above. Neutralitytalk 17:32, 3 January 2017 (UTC)
- Oppose as there's no sensible amount of being overlenient with clear advertising and unsuitable cases for us, and such are allowed immediate deletion; as a matter of fact, our policies allow it. SwisterTwister talk 00:07, 4 January 2017 (UTC)
- Oppose it just becomes a management issue where you have to remember an article to go back to - I agree with the underlying sentiment but think there are 3 better ways to address it: First - make sure the speedy template warnings do not bite but inform - i.e. you must add references ASAP; second it's the action on a speedy that should be delayed not the adding - the creator needs to be informed as soon as possible of the serious issue, but given enough time to fix (so admins should maybe not deleted to xx mins); thirdly it should be a clear option to request a move to draft rather than delete, and even if not requested if the article looks possible it should be moved rather than deleted. A thanks for creating but it's not yet ready so we moved it to a draft area should not bite new users and encourage them to continue editing. KylieTastic (talk) 00:23, 4 January 2017 (UTC)
- Oppose. While thanking Beeb for reminding us of this, the proposal is simply a palliative for the still very poor standard of New Page Patrolling in spite of our efforts to introduce some competency into that area. I do feel that in debates of this kind, too few commenters have any idea at all of the sheer amount of total rubbish that gets created every day. Properly educated and properly authorised New Page Patrollers are the only answer, and even then, identifying problem patrollers is almost impossible. It's either that or activate WP:ACTRIAL. Kudpung กุดผึ้ง (talk) 03:49, 4 January 2017 (UTC)
- Oppose I'm an active patroller. With the amount of articles being created every half hour, I'm not convinced this is the route to take. I would rather suggest that if new editors need to be protected for half hour, then enforce through the software that all articles by new editors be held in a draft pen for a half-hour holding period, during which they would have time to improve the article. After half hour, let the article automatically come into the Special New Pages feed as a new article on top of the feed. This would then resolve even the no-context and no-content tagging of new articles. Lourdes 06:54, 4 January 2017 (UTC)
- Oppose: The incessant vanity articles susceptible to A7/G11 are not worthy of procedural hoops being put in the way of editors whose concern is the quality of the encyclopaedia. Prompt addition of a CSD and the associated User Talk message provide a good level of feedback to the user regarding the deficiency perceived in their article. Better that this is received immediately while they are likely to still be in their session and can therefore respond than that this is deferred. AllyD (talk) 08:33, 4 January 2017 (UTC)
- Oppose. Articles must meet inclusion requirements at all times while in main space. Waiting to have to remove obvious junk is pointless and bothersome. Sandstein 08:53, 4 January 2017 (UTC)
- Oppose We have a refund policy and a draft space for a reason; just as we have a speedy deletion process for a reason. If its axed under CSD then it can be refunded and moved to the draft space. TomStar81 (Talk) 00:31, 5 January 2017 (UTC)
- Oppose I have some experience with CSD and agree with the various reasons given above in this section. I see no need to repeat them. I will note especially per Beeblebrox, MrX, Davey2010, Jbhunley, Kudpung กุดผึ้ง and AllyD. Donner60 (talk) 05:42, 5 January 2017 (UTC)
- Oppose per all the good reasons already given. Obvious crap needs to be stamped out as soon as it is discovered, regardless of its age. Draftify should be used far more for A7 failures that could feasibly be fixed. Experienced reviewers have a term for the stream of freshly created articles; GFOO, Great Firehose Of Ordure - it's almost entirely crap with a few rough diamonds hidden in the dross.
- Quite frankly the only way this issue will ever really be fixed is to force all new page creation to happen only in draft-space, or rewriting the anyone can edit myth to anyone may try to edit, but only the competent actually can. Roger (Dodger67) (talk) 06:25, 5 January 2017 (UTC)
- Oppose Draftify can be used as a catch all for good-faith articles that would otherwise be deleted. Iazyges Consermonor Opus meum 06:30, 5 January 2017 (UTC)
- Oppose On the slim chance something good does get nuked by mistake, there's always WP:REFUND. Lugnuts Precious bodily fluids 08:06, 5 January 2017 (UTC)
- Oppose per Wikipedia:Perennial proposals#Grace period for deletion (which has already been referenced by many above).— Godsy (TALKCONT) 19:54, 5 January 2017 (UTC)
- Oppose as this is the very reason we created the whole draft space to begin with. Any article in main space should be ready for viewing from moment one. Also per Perennial and just plain common sense. GenQuest "Talk to Me" 20:16, 5 January 2017 (UTC)
- Oppose - If there are problems with the way specific editors use the tag, deal with those specific problems, but don't handicap other editors from tagging obvious crap the moment they see it. The tag can be turned down if an admin disagrees with it, and there's always WP:REFUND to fix any articles mistakenly deleted. Beyond My Ken (talk) 04:18, 6 January 2017 (UTC)
- Waiting 30 minutes for an A7 article, one supposed to reduce the number of non-notable topics, is futile. It is a miracle that Wikipedia is not yet deluged by dime-store crap new articles. Esquivalience (talk) 04:36, 6 January 2017 (UTC)
- Oppose just because some people don't properly tag articles doesn't mean we should prevent others who do when they see articles that obviously aren't warranted, regardless of how recently they were created. I concur with what Beyond My Ken said above. Snuggums (talk / edits) 05:38, 6 January 2017 (UTC)
- Oppose unless either (a) this is done programmatically so that an A7 tag simply cannot be added to an article for the first 30, or whatever, minutes or (b) this proposal is expanded to say exactly what happens if someone tags an article anyway during the first 30 minutes: Is the tag simply invalid and subject to removal? If not removed, does it become valid once 30 minutes have passed or once invalid is it always invalid? Is it valid from the beginning but the poster simply subject to sanctions? Depending on adoption of a fully-automated solution or the answers to the implementation questions, I might change my !vote to support, but at this point, I oppose. — TransporterMan (TALK) 18:30, 6 January 2017 (UTC)
- 'Oppose - Weak Oppose with regard to A7. No one needs half an hour to finish putting together a new article in article space, because no one needs to develop an article in article space, and too many new articles are crud anyway. Strong Oppose with regard to G11. Spam is usually obvious as soon as it hits article space, and is only a little less of a plague than attack pages, and more of a plague than patent nonsense. Robert McClenon (talk) 01:11, 8 January 2017 (UTC)
- Strong Oppose most A7s truly are hopeless, along the lines of "Bob Smith likes to play Pokemon and goes to Podunk Middle School", 30 minutes or indeed 30 weeks aren't going to nudge it away from A7. But let's talk about the more important issue: would a wait period be kinder to new editors? Absolutely not. Think about it: as an example let's say I'm 16 and just started a garage band with my friends, and heard anyone can write stuff on Wikipedia. I type out "Turd Airship is the coolest new band in East Podunk. The members are Josh R, Josh B and Kevin. We'll play at Podunk High's Battle of the Bands in March!" Two minutes later, it gets deleted and I get a message explaining why. Man, that sucks! But at least I didn't put a lot of time into it. On the other hand, if it takes a whole 30 minutes to delete it I'm given the false impression that the article is okay, maybe I spend the whole half hour carefully writing paragraphs about how Josh R has been watching Youtube videos on how to play guitar, Josh B got a FirstAct bass for Christmas, and Kevin gets to use his brother's drum kit twice a week, and the Battle of the Bands will be held in the cafetaria and tickets are $3 and the money goes to new music stands for the school choir. None of this, of course, makes it any more notable or encyclopedic, but it takes awhile to write, and when it does inevitably hit the bitbucket I'm (quite rightly) pissed. Sometimes a bit of upfront honesty really is the kinder way to go. Andrew Lenahan - Starblind 01:13, 8 January 2017 (UTC)
- Oppose especially on G11. The last article I nommed on A7 grounds said "Retrogamer3002 is a youtuber that streams every friday." A quick google showed a Youtuber whose videos had less than 100 views and nothing else that could form the basis for a sourced stub. I see no purpose or advantage gained in keeping such clearly non-notable articles around. Valenciano (talk) 10:06, 8 January 2017 (UTC)
- Oppose What? No context and no content CSDs have grace periods to let the author expand their article. An article about a non significant subject will never become significant given 5 minutes or 5 years. Laurdecl talk 11:09, 8 January 2017 (UTC)
- Weak Oppose as a rule, Support as a guideline for admins. I disagree with some of the reasoning above since there are certain instances where an article that contains no indication of significance or importance will be edited to include such claims. But since oftentimes the article already contains enough information that such claims will not manifest ("Bob is a middleschooler from Everytown who is the coolest guy ever"), waiting a certain time makes no sense as a hard rule. So I'd counter-propose adding wording that administrators should wait for a few minutes on articles that might be expanded further to fail A7. Since CAT:CSD is backlogged almost constantly, in practice it won't matter anyway. Regards SoWhy 11:43, 8 January 2017 (UTC)
- Oppose - New articles should be treated like every other article. But, I think that Wikipedia needs to be better at encouraging new editors. RileyBugzYell at me | Edits 22:36, 8 January 2017 (UTC)
- Oppose We have draftspace for a reason. ThePlatypusofDoom (talk) 17:16, 10 January 2017 (UTC)
- Oppose We have the draft space and sandboxes especially for this reason. More can be done to draw attention to these spaces for new users and WP:REFUND exists for userfication for articles that need to be retrieved. I am deeply concerned about the amount of material that would get posted and then slip past the recent page patrols because they've become hidden behind other updates and new articles created. As also mentioned above, this has been discussed many times and is listed at Wikipedia:Perennial_proposals#Grace_period_for_deletion. Mkdw talk 00:18, 11 January 2017 (UTC)
- Oppose for the usual reasons; putting in arbitrary hoops just means that it becomes more difficult to clear out cruft. Stifle (talk) 13:30, 11 January 2017 (UTC)
General Discussion
- Wouldn't just moving the article to draft allow them to flesh out their article undisturbed? Iazyges Consermonor Opus meum 16:21, 2 January 2017 (UTC)
- With regard to A7, there is already a community expectation that a grace period of 15 minutes be left, see here. A user was recently sanctioned for hasty tagging so I don't think a sufficient rationale has been proposed that reducing flexibility by imposing a mandatory limit is necessary. With G11, I want spam booted off the wiki as fast as possible, thank you. Also as an admin who works in CSD I observe the quality of G11 tagging is much better than A7. BethNaught (talk) 16:26, 2 January 2017 (UTC)
- You may have a point with G11 but A7 is a serious problem. To the extent that there is supposed to be a 15 minute waiting period I can affirm from regular experience that it is routinely ignored. -Ad Orientem (talk) 20:29, 2 January 2017 (UTC)
"With regard to A7, there is already a community expectation that a grace period of 15 minutes be left"
BethNaught hi. Where is this expectation? Your link doesn't contain that. Lourdes 06:58, 4 January 2017 (UTC)- Good point. It does now. I still believe the expectation exists, though disturbingly I couldn't find it anywhere. I would support a proposal making a 15 minute A7 grace period recommended, but not mandatory. BethNaught (talk) 07:31, 4 January 2017 (UTC)
- Ok BethNaught. I wouldn't recommend boldly adding the grace period of 15 minutes for A7 unless you get consensus. There is a precedent reason why A7 is not included in this grace period, while no-content and no-context are. Would you mind reverting your addition please? Thanks. Lourdes 08:02, 4 January 2017 (UTC)
- Good point. It does now. I still believe the expectation exists, though disturbingly I couldn't find it anywhere. I would support a proposal making a 15 minute A7 grace period recommended, but not mandatory. BethNaught (talk) 07:31, 4 January 2017 (UTC)
- You may have a point with G11 but A7 is a serious problem. To the extent that there is supposed to be a 15 minute waiting period I can affirm from regular experience that it is routinely ignored. -Ad Orientem (talk) 20:29, 2 January 2017 (UTC)
- I'm pretty sure there isn't actually a way for a template to determine when the article was created in order to "alert editors" as is suggested. Anomie⚔ 17:21, 2 January 2017 (UTC)
- There is a green box that pops up on G13 notices that tells you if a full six months have passed. -Ad Orientem (talk) 20:27, 2 January 2017 (UTC)
- I note that template requires a special parameter for that functionality. Anomie⚔ 23:10, 2 January 2017 (UTC)
- There is a green box that pops up on G13 notices that tells you if a full six months have passed. -Ad Orientem (talk) 20:27, 2 January 2017 (UTC)
- Mixed views on this. I definitely support not tagging A7 right after creation (pre-15 minute grace period.) It's BITEy and with articles from regions that are difficult to source, I am all for giving people more time to develop the article to meet the minimum A7 criteria. At the same time, if there's an article about a little girl who plays the harmonica from Upstate New York, I don't see an issue with tagging it after 15 minutes. Waiting the full 30 wouldn't hurt, but at the same time, this seems like instruction creep to me. The A7 issue is that we have a massive backlog and new people do want to help with it, but for one reason or another haven't taken the time to read the tutorial at WP:NPP, which in all honesty gives enough pointers that should fix these issues. Hell, we have experienced editors placing BLP PRODs on ineligible articles too at NPP. I'm not sure what the solution is here, but I'm also not sure that a mandatory 30 minute waiting period is the way to go. TonyBallioni (talk) 22:47, 2 January 2017 (UTC)
Neutralwith comments. The rationale for this proposal (and the corresponding language about A1 and A3 at NPP and Special:NewPages (which, I would point out, are not even information pages, much less guidelines or policies) is obviously BITE and considerations of editor retention. But I also have concerns about more-experienced editor retention. If we're going to sanction editors for hasty tagging, such as BethNaught pointed out recently happened, then the prohibition needs to be clearly defined and set out at CSD, which is a policy, not just at those other locations. At the current time, at least, I have no opinion about whether we should have such a restriction on hasty tagging and would like to hear what others here have to say. I would, however, point out that putting a time restriction on CSD deletion (as opposed to CSD tagging, as proposed here) is a perennially rejected proposal here; I can see some distinction between the two, but I'm not sure that it's enough. Regards, TransporterMan (TALK) 23:15, 2 January 2017 (UTC) Later changed to oppose, see above, but forgot to update this. — TransporterMan (TALK) 03:35, 10 January 2017 (UTC)- Cited above, [3] is an article on bloomberg.com. In this 22 December 2016 article about Wikipedia, here is a quote from the article, "This so-called filter-bubble problem, coined by Eli Pariser, co-founder of the viral video site Upworthy, is the idea that the internet can contribute to the insularity of certain communities." Unscintillating (talk) 03:47, 3 January 2017 (UTC)
- The article mis-represents CSD "The only people qualified to remove this designation are the encyclopedia’s administrators" and comes close to accusing Anthere of being a meatpuppet "If the only way to get an article about the developing world published on Wikipedia was to know a former board member," rather than acting as an impartial bystander contacted off-wiki. The reporters obviously got a better grasp of the issues of notability than any grasp of wikipedia's policies. Cabayi (talk) 15:44, 3 January 2017 (UTC)
- Well, I would not suggest to put too much weight on the exact words the journalist used. A journalist may understand decently well the policies and the context, but she has to grab the attention of the reader by saying something disturbing... So I guess it was a nice story to tell readers. That being said... to be specific... Anasuya did not call for my help because of former responsibilities... she called me for help because we were seating next to one another during that event, because she knew I cared about the gender gap, and because I have been around since 2002. And yeah... we have a friendly relationship. I am not sure trying to set in stone a "delay" until which an article can be proposed for speedy deletion is the right answer to what happened, though it clearly sucked that Anasuya was still working on it that it was already proposed for deletion. What is needed is a way to "flag" the article so that it will not slip through the cracks and can be quietly reconsidered for deletion after a few hours, without the flagging being so disturbing and demotivating to a new comer. Anthere (talk) 21:47, 3 January 2017 (UTC)
- As I recall, templates can get the current date. I believe this means that at most we'd need one value implemented by the implementors, and "DATEOFCREATION" would be general purpose. Unscintillating (talk) 03:53, 3 January 2017 (UTC)
- Unless I am grossly mistaken, there is no mention whatsoever in the policy governing A7 that a delay be observed before tagging. In many cases rapid tagging actually makes sense especially if the author is still logged in. A great many of today's new articles are created by SPA who will never return to know that their article has been tagged or even deleted. BITE and considerations of editor retention wouldn't need to be even part of this discussion - in fact the discussion wouldn't be needed at all - if the community had not demonstrated its aversion to having new pages patrolled exclusively by properly experienced and qualified patrollers who can be trusted to use some common sense. Under the current situation the only feature of the new New Page Reviewer group is that only they can release new articles for indexing by Google. Far too much of the tagging is still being done by raw newbies for whom all maintenance asks are a magnet, and there is no efficient way to identify them to tell them to stop doing it. We would lose the few reasonable patrollers we have if we have start telling them they must wait 30 minutes before tagging an obvious piece of blatant rubbish - which at least 80% of new articles by new users are. At this stage, one could almost argue now that BITE has become a necessary collateral damage. Amazingly, The WMF has also again rejected proposals that the new landing page they once began to develop should be revisited. WP:ACTRIAL which was carried by an overwhelming consensus seems more than ever to be the only tenable solution to address the issues of both BITE and unwanted content, and for which a precedent already exists. It can be implemented by a simple local script.Kudpung กุดผึ้ง (talk) 05:02, 4 January 2017 (UTC)
- Comment This has been suggest several times, including by myself. It unfortunately won't work at the present time, because in practice it is hard enough to get one single time to catch the problems. If we get NPP working properly, we can probably figure out a way to put some sort of time delay into the system. In my last year of patrolling, I've seen maybe five examples of a good faith article get deleted this way when it shouldn't . I've seen thousands avoid deletion because we don't get to them. There will be time to tweak the system later. The urgent need, immediately, is for all qualified editors to start patrolling a few articles a day at least. It will add up. DGG ( talk ) 06:06, 4 January 2017 (UTC)
- Why not enforce this on the template side? Why not add a timer to the deletion template that displays it only after X minutes post-addition by the tagging person? --Izno (talk) 13:30, 5 January 2017 (UTC)
- Because then the admins patrolling speedy deletion nominations won't even see the crap that needs to be quickly deleted? Boing! said Zebedee (talk) 14:33, 5 January 2017 (UTC)
- @Boing! said Zebedee: Are A7s (no asserted significance) really in the category of speedies that need to be quickly deleted? I would imagine G3s, G10s, G12s (perhaps A11s and F9s?) all fit within that category, but A7s? --Izno (talk) 14:43, 5 January 2017 (UTC)
- But, besides that, my suggestion would not just be to limit the tag display but also the category inclusion. Perhaps that was not obvious in my comment. --Izno (talk) 14:47, 5 January 2017 (UTC)
- In my opinion, yes, the majority of them do need to be expunged rapidly - the amount of sheer crap that gets added every day brings shame on Wikipedia's "everyone can edit" mantra. And limiting the category inclusion too would make it worse. Boing! said Zebedee (talk) 14:49, 5 January 2017 (UTC)
@Boing! said Zebedee: How? All a template with a 10 minute limit does is delay processing by 10 minutes for exactly 1 time (minding other unforeseen changes in the time period). The admin queue will stop growing for 10 minutes at the time the template is changed to add the 10m delay and then will continue as before. How does this change how much work is done on an every day basis after that point? --Izno (talk) 14:58, 5 January 2017 (UTC)
- I never suggested anything whatsoever to do with "how much work is done on an every day basis". I am talking only about delaying the deletion of crap. Boing! said Zebedee (talk) 15:00, 5 January 2017 (UTC)
- [Are A7s (no asserted significance) really in the category of speedies that need to be quickly deleted? - I would respectfully suggest that Izno spend an hour patrolling new pages. I feel sure he (and perhaps a few others here) would then clearly understand what this debate is about and why the proposal will not be carried. Kudpung กุดผึ้ง (talk) 20:23, 5 January 2017 (UTC)
- @Kudpung: I was merely making the technical suggestion; I have no opinion on the social issues or project goals at hand with this proposal, except obviously above where contrasted with the other criteria for speedy deletion (perhaps I-again did not make this clear—perhaps it should be obvious to the interested reader since I have not stated a position of support/oppose?). As regards "patrol some new pages and that will tell you why the proposal is [x] quality"--I have little interest in that process, but if you're willing to shell out the new page reviewer right, maybe I'll look into it. :^) --Izno (talk) 20:34, 5 January 2017 (UTC)
- @Izno: - which is why I had already said further up that a characteristic flaw in Wikipedia debates is that people join in without having informed themselves first. The current issue is neither a social one nor a project goal, it is as technical as the annual required technical inspection for a car - like a car, if an article fails at A7, nine times out of ten it will go to the scrap yard which is the only place for it. Disinterest is another issue - that's why people often comment without any intent to help out. User rights are accorded to editors with proven required experience, and with New Page Review we're actually rather careful about it. That said, you appear to be unaware that sadly (and that's the reason for this discussion) any registered user, raw beginner, and spammer can still patrol new pages; WP:NPR will tell you what is special about the right. Kudpung กุดผึ้ง (talk) 20:58, 5 January 2017 (UTC)
- @Kudpung: I was merely making the technical suggestion; I have no opinion on the social issues or project goals at hand with this proposal, except obviously above where contrasted with the other criteria for speedy deletion (perhaps I-again did not make this clear—perhaps it should be obvious to the interested reader since I have not stated a position of support/oppose?). As regards "patrol some new pages and that will tell you why the proposal is [x] quality"--I have little interest in that process, but if you're willing to shell out the new page reviewer right, maybe I'll look into it. :^) --Izno (talk) 20:34, 5 January 2017 (UTC)
- In my opinion, yes, the majority of them do need to be expunged rapidly - the amount of sheer crap that gets added every day brings shame on Wikipedia's "everyone can edit" mantra. And limiting the category inclusion too would make it worse. Boing! said Zebedee (talk) 14:49, 5 January 2017 (UTC)
- Because then the admins patrolling speedy deletion nominations won't even see the crap that needs to be quickly deleted? Boing! said Zebedee (talk) 14:33, 5 January 2017 (UTC)
- Most newbie article authors whose articles are eligible for A7 are most likely here just to create their article and not here to contribute productively to the encyclopedia. Also, if a newbie is unable to see that publishing subpar work in the most widely-used reference work is not a laughing matter, then once in a sighting of Halley's Comet will one of them be able to bring one of their articles to standard. Esquivalience (talk) 04:50, 6 January 2017 (UTC)
- On the one hand, early tagging can be bitey. On the other, it can alert the author to the problem that will get their article deleted while they are still here to fix it. Beyond that, I think TonyBallioni highlights an important point, a tagger exercising reasonable discretion will be able to identify some articles that obviously fail A7, and where it is equally obvious that no amount of grace period is going to fix it. I'm all for giving people a grace period when there is any hope of them fixing it, but I don't know how we would make a policy on that. While it doesn't solve the biteyness issue, maybe we should just encourage admins to give tagged articles more time before actually deleting in those cases were further work has a reasonable chance of getting the article past A7 territory. Monty845 22:18, 6 January 2017 (UTC)
Tweaking the proposal?
What about a tweak of the original proposal? Instead of requiring a grace period for tagging articles under A7 or G11, how about a guideline suggesting (rather than mandating or requiring) a grace period for deleting articles tagged under A7? (not including G11 as consensus seems to be emerging that G11 articles should be deleted as soon as possible). A7 can be a tricky case; most articles that are tagged under the said criterion clearly fall under it and thus it won't really matter if it's deleted one minute or one hour after tagging: it's still going to be deleted anyway. But there are occassional borderline cases where while the article in its original state suggests that the subject isn't notable or does not even assert a claim to notabilty, a simple search reveals that the subject of the article does at the very least not qualify for speedy deletion (PROD or AFD is another matter). This is particularly the case on articles about topics from outside the Anglosphere (I note that a fairly significant number of our new articles are about South Asia). How about a case-by-case checking of A7 articles and if there's at least a small chance the topic is notable, then the article can be left alone for a short time? I have no opinion on this suggestion other than that I'm slightly against it because it could theoretically cause bureaucracy and let a stinker or two slip through the cracks, but I'm opening the topic for discussion. Narutolovehinata5 tccsdnew 14:11, 8 January 2017 (UTC)
- Oppose, same reasons as the main proposal. First, we don't do well with suggestions. Certain editors would likely treat it as a rule whether it is or isn't (much like the many who cite guidelines or even essays as policy when they aren't). Second, why make something a suggestion when it isn't current practice and never has been? A7 isn't about whether something could potentially be an article someday, it's about whether the article as written includes a credible assertion of importance. We already have options to deal with poor articles on notable subjects (userfication, draft), as well as ways to proceed when the situation is ambiguous or unclear (PROD & AFD). Those should be used if there's a judgement call scenario. Andrew Lenahan - Starblind 23:22, 8 January 2017 (UTC)
- Oppose. The problem is with the tagging itself, and the deterrent effect it has on new editors. Actual deletion usually does not take place for as much as a few hours after the initial tagging. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by many administrators since 2006. (talk) 17:54, 10 January 2017 (UTC)
30/500 protect article of the day temporarily to prevent vandalism.
- 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.
- This is a perennial proposal without anything new to add to the discussion. Anomie⚔ 20:31, 18 January 2017 (UTC)
Hi. The article of the day is known to be prone to vandalism and I think that it should always be put on Extended Confirmed protection for 1-5 days so that much vandalism on it can be reverted. Very simple change. Creeperparty568 ~ Cool Guy (talk) 02:49, 18 January 2017 (UTC)
- Oppose. We've long held that the WP:TFA should be relatively lightly protected in keeping with our "anyone can edit" mantra. ECP should be used sparingly, not automatically on every TFA. -- King of ♥ ♦ ♣ ♠ 03:21, 18 January 2017 (UTC)
- Oppose per King of Hearts above. Generally the TFA has enough watchers that any vandalism against it is reverted quickly enough. If the vandalism gets overwhelming, we can use semi-protection or even higher if necessary, but only if it really is necessary. But thank you, Creeperparty568, for the good faith suggestion. –Grondemar 03:32, 18 January 2017 (UTC)
- Oppose per the above, the day's feature article should be as open as possible to encourage editing. — xaosflux Talk 03:59, 18 January 2017 (UTC)
- Oppose per all of the above in addition to opposing the general trend of proposals looking to expand the scope of EC protection. This was never intended to be a tool of first resort. Beeblebrox (talk) 07:21, 18 January 2017 (UTC)
uploading image choices: should be a third "ownership" IMHO
Folks, I'm a relative newbie who has uploaded several images to the commons and I believe there should be another category of ownership. I'm not even sure if I will use precisely correct terminology, but here goes... Currently, we are given the option to declare if an image is our own work or not our own work. What to do if the image is a derivative work???? That is, I think there should be a third choice of "my derivatie work". After declaring that, the uploader would be sent to pages that would allow listing of the original source(s) of the image, yet still allow the uploader to eventually declare it as their work and license it with cc4.0 or whatever. This issue has come up multiple times for me, since I've needed to make some "collage" images to illustrate scientific scenarios. If I gather 3 different images with 3 different cc permissions, combine parts of those images into a collage derivative image with other text, etc, shouldn't the derivative image become mine to license under cc4.0? Thanks, DennisPietras (talk) 14:08, 14 January 2017 (UTC)
- I often use the {{Photo of art}} template for such things. Maybe generalizing it for non-photo derivative works may make sense. Collages are more complex, though. Jo-Jo Eumerus (talk, contributions) 14:24, 14 January 2017 (UTC)
- @DennisPietras: I see that you are already uploading files to Wikimedia Commons. Thanks for that. Wikipedia mostly manages the encyclopedia, and Commons mostly manages the image repository. If you wish to talk more about this, I recommend going to Commons:Commons:Village_pump/Copyright for the most insightful copyright discussions you will find anywhere online.
- At that forum, I expect people would think about this in a different way. Instead of "yours" or "not yours", the only question is about copyright holders. If someone creates a new work then is one copyright holder, and any derivative work has the original copyright holder plus the copyright for the creator of the derivative. If you combine works of multiple copyright holders then the derived work includes the copyright for each plus an additional one for the derivative. Copyrights only add to each other. They are not replaced when a derivative is created. Blue Rasberry (talk) 20:28, 19 January 2017 (UTC)
- @Bluerasberry: "Copyrights only add to each other." is what I needed to understand. Thanks, DennisPietras (talk) 21:07, 19 January 2017 (UTC)
RfC on the future of G13 and AfC
Should G13 be suspended? Replaced? What should the future of AfC look like? Join the discussion at Wikipedia talk:Drafts#RfC on G13. — Preceding unsigned comment added by A2soup (talk • contribs) 05:38, 21 January 2017 (UTC)
Need assistance on NFLPrimaryColor
I need either a Template Editor or an Administrator looking at Template talk:NFLPrimaryColor#Template-protected edit request on 12 January 2017. Seems a little overdue, and I hope it'll be resolved as soon as possible. --George Ho (talk) 08:40, 21 January 2017 (UTC)
"In The News" should be past-tense
Have you ever noticed that documentaries on the Learning Channel have a bad habit of narrating everything in the present tense?
On the home page, I would prefer Wikipedia's "In The News" to be a paragon of English style, and properly relate past events in the past tense, instead of emulating The Learning Channel. Today's In The News is a barrage of this error, implying that the writer is unable to conjugate verbs beyond the present tense. For me, it's a reflection of credibility.
Thank you for your consideration Nei1 (talk) 02:44, 20 January 2017 (UTC)
- Oppose. Present tense is the standard for news reporting; just look at Google News. A majority of headlines are in present tense. -- King of ♥ ♦ ♣ ♠ 03:32, 20 January 2017 (UTC)
- Oppose Many people who see In The News will believe that it is what the news is covering now and not what is in the past. If this proposal is to go ahead then I would prefer it "In The News" was renamed. --SwiftyPeep (talk) 09:16, 21 January 2017 (UTC)
Notability proposal
A lot of time seems to be waisted on arguing whether an article about something, someone, some place, is or is not notable. Can we not triage into: (1) Encyclopedic notability (which need not be mentioned), (2) local notability (which should), (3) No consensus of notability (which is a must in the failure of a successful AfD, which is mostly due to it only coming to the attention of a too small cohort interested editors). It seems to me that many that fail to get AfD'ed are those minority articles that don't attract the interest of enough other editors enough to dissect and expose the lack of notability. This would reduce the size of a file that someone, educational or charity organisation needs to download when they have need for a copy of WP. As is said: WP is not a paper encyclopedia and so it now can accommodate millions of articles. There is no reason why another million can't be added but our reputation for reliability is getting evermore diluted as more and more non notable's and doubtfully accurate verbiage gets added by people that want to promote themselves, their company, their school, or their local hamburger stall, etc. Also, if articles that fall into categories (2) & (3) can it also have a different background colours to differentiate them from the truly notable pages? It may also put off (or make some people think twice) about asking a member of staff to create a WP page about them in the hope that having a WP page some how gives them more credibility than they really have in the hope that a WP article will promote their career. If the background is in another colour, they will relize it will only go to alert their prospective clients that they are really dealing with an also ran and perhaps self-promotional article rather than a WP Notable. This I think, continues our sprit of WP is not a paper encyclopedia and at the same time, allow new editors the freedom to create new (and hopefully great) articles. Obviously I haven't doted all the 'i' 's and crossed all the 't' 's so not ready for a ploicy change request. However, it could help us to take WP to a new level of being a font of all knowledge whilst saving 95% of our time on just sorting out 5% of the Paid and COI editors.--Aspro (talk) 21:02, 19 January 2017 (UTC)
- I have wondered, but not so far put into print, whether there should be a separate "Micropedia" where the test of notability is severely relaxed. Rather than pressing for full articles with pictures and detailed citations as in Wikipedia, such a space would consist of low notability, short articles. Obviously WP:BLP needs to be enforced, but a couple of text paragraphs on an obscure singer would be fine. If the singer becomes more notable, then the article could be prompted into WP. Keeping the micropedia separate will help protect WP's reputation whilst allowing Aspro's category 3 articles to exist. Restricting the length and graphical content would help mitigate the storage requirements for potentially millions of articles. Be gentle, I don't claim that this is fully worked out, just an idea to kick around. Martin of Sheffield (talk) 22:52, 19 January 2017 (UTC)
- No. Notability as a Wikipedia term d'art only means one and one thing only: the existence of sufficient independent reliable source material to use to help write a quality article from. If the source material exists, we write the article. If the source material doesn't exist, we don't write the article. All other considerations are distractions from the mission of the encyclopedia. --Jayron32 01:40, 20 January 2017 (UTC)
- Sorry Jayron, but is that no to Aspro's idea of colouring or no to my idea of a separate *pedia not part of Wikipedia? Martin of Sheffield (talk) 09:24, 20 January 2017 (UTC)
- Well, it's actually a three-part thing:
- sufficient independent reliable source material to use to help write a quality article from, and
- the subject isn't excluded by WP:NOT, and
- editors want to have it as a separate article (e.g., rather than merging it with a larger article).
- You have to have all three points (although #1 is usually the biggest problem). WhatamIdoing (talk) 02:04, 20 January 2017 (UTC)
- Agree that #1 is the main problem and the problem is that most craftsmen, artisans and professionals only need to be known locally to earn a living but other craftsmen and artisan that focus on niche markets need to promote their work also. They do so through more widely read magazines to reach a wider clientèle. There is a confusion that because these artisans, financial consultants, etc., get mentions in some widely read magazines and TV slots (that also need copy) that this makes them 'notable'. So many articles fail to contextually provide 'sufficient' reliable sources to back up the claim of notability. OK, some designer gets mentions in Vogue or some such. Does that make them notable? Many editors here have had scientific papers published. I have spoken on the radio and had some of my photographs reproduced many thousands of times – does that make me a 'notable' photographer or someone who has taken photographs that others reproduced because they need images - just like Fox, CBS Vogue and other magazines need copy? Sooner or later we have to bit this bullet of giving in to Wikilawyering.--Aspro (talk) 18:27, 21 January 2017 (UTC)
YouTubers Suggestion
Hello everyone!
Recently, I've noticed a lot of articles being created about different YouTubers. Many of them are stubs, for example this article was one of the YouTuber biographies recently uploaded. While the one I just referenced is quite well-sourced, many of them aren't and don't suitably pass WP:GNG.
So I thought I'd propose a guideline (not policy). Guidelines and essays seem to have been able to form community consensus, for example in WP:FOOTYN.
Maybe a specific guideline for YouTubers could be created, for example their main channel must have over 500,000 subscribers.
Opinions?
Regards,
DrStrauss talk 14:59, 15 January 2017 (UTC)
- I can tell you immidiately - this will never happen. English Wikipedia does not have these types of notability guidelines. What you see at WP:GNG is what you get. If they don't fulfill that, they don't belong on Wikipedia. Simple as that. No further responses necessary. Carl Fredrik 💌 📧 15:04, 15 January 2017 (UTC)
- If they are not notable they can be merged into one page titled "List of YouTubers". QuackGuru (talk) 17:17, 15 January 2017 (UTC)
- A subject-specific notability guideline implies a specific purpose: setting the bar of inclusion slightly above or slightly below the general notability guideline (GNG). I must strongly oppose a guideline that would set an easier threshold, given that virtually all YouTuber biographies will be biographies of living people (BLPs) and thus fall under our relevant policy. There is an interesting case for a guideline that's more restrictive than the GNG, but I suspect that wouldn't reach consensus. {{Nihiltres |talk |edits}} 20:36, 15 January 2017 (UTC)
- CFCF, QuackGuru, @Nihiltres:: I get the double standard point, probably wanted to set the bar higher but I envisage disagreement. Thanks for your feedback! DrStrauss talk 18:46, 16 January 2017 (UTC)
- User:DrStrauss, what about the idea for the "List of YouTubers"? That would solve the issue and preserve content. QuackGuru (talk) 19:08, 16 January 2017 (UTC)
- @QuackGuru: that's actually a really good idea but how do we "promote" it? DrStrauss talk 19:55, 16 January 2017 (UTC)
- You don't need to promote it. You can start a draft and add all the non-notable YouTubers. Once you have enough content you can start a new page. QuackGuru (talk) 19:58, 16 January 2017 (UTC)
- You could also check the edit history of the YouTubers articles. Others may be interested in helping to create a new page. QuackGuru (talk) 14:18, 17 January 2017 (UTC)
- There is page for YouTubers. It is titled "List of YouTubers". If any YouTubers article is not notable it can be merged to "List of YouTubers". QuackGuru (talk) 14:20, 17 January 2017 (UTC)
- @QuackGuru: that's actually a really good idea but how do we "promote" it? DrStrauss talk 19:55, 16 January 2017 (UTC)
- I doubt we'll ever have guidelines like that for Youtube or any social media. I'm not going to spill any WP:BEANS but there are definitely places you can go to spend a small amount of money (literally a few bucks) and get thousands of "followers", most of them actually compromised accounts or bot-generated fakes. I'm not going to get into the legality or morality of doing that, but it's a real thing that happens and it's one reason social media WP:BIGNUMBERs can't be trusted. Andrew Lenahan - Starblind 20:59, 21 January 2017 (UTC)
Infoboxes – optional plural parameters – removing (s) from labels
Hello all. Many infoboxes have labels that end with "(s)" (e.g. Template:Infobox person's "Opponent(s)", "Spouse(s)", "Partner(s)" & "Parent(s)", or nearly all labels on Template:Infobox video game).
For more than three years now, Template:Infobox book has had optional "plural" parameters for these, so instead of |author=
having the label "Author(s)", if you use |author=
the label says "Author", but if you use |authors=
it says "Authors". If someone accidentally fills out both parameters it only shows one item (defaulting to "Authors" in this case, as more than one parameter is filled out). In practice, this means that editors treat these as different aliases of one parameter (many infoboxes have things like this already), and find it easy to choose whether the "s" shows at the end or not.
"Incremental" changes like this don't make a massive difference on their own, and may not even be consciously noticed by readers, but in my opinion it's small things like this which together add up to make Wikipedia either look professional, streamlined, and easy to read, or messy and convoluted.
I'd like to test the waters to see what people think about rolling this out across more infoboxes, and, if there's a general consensus of support, propose that we start a trial with a few well-watched medium profile infoboxes (suggestions welcome!), and go from there. ‑‑YodinT 20:29, 29 December 2016 (UTC)
- I'd like any option that gets rid of the clumsy "(s)", especially if there's only one of a kind. {{infobox opera}} has also an example to do so: always
|librettist=
, - the reader will get it if more than one is shown, as here. --Gerda Arendt (talk) 21:33, 29 December 2016 (UTC)- @Gerda Arendt: +1 --User:Ceyockey (talk to me) 23:16, 21 January 2017 (UTC)
- The best thing is to replace most terms that don't require plural forms, or in the case of relatives, simply have a singular "Relatives" field and leave it plural in much the same way we keep "External links" section plural even when there is only one link in the section. — Preceding unsigned comment added by TheFarix (talk • contribs) 18:25, 30 December 2016 (UTC)
- Ok, thanks both. I'll start looking at which infoboxes would be suitable to have changes. ‑‑YodinT 14:31, 5 January 2017 (UTC)
- In {{Chembox}} I've implemented to cound the number of elements in an input list (comma separates, <br> separated), plus the editors option of 2 parameters. Double imnput could have a warning or maintenance category message. Can {{unbulleted list}} input be detected & analysed? -DePiep (talk) 12:43, 6 January 2017 (UTC)
- Lists in infoboxes should not be separated using commas (or other characters, such as dashes) or line-breaks, but instead should be marked up as lists (iusing
*
), which may be styled in-line with {{Unbulleted list}}, {{Plainlist}} or {{Flatlist}}, or the equivalent in the template code, as desired. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:12, 13 January 2017 (UTC)
- Lists in infoboxes should not be separated using commas (or other characters, such as dashes) or line-breaks, but instead should be marked up as lists (iusing
- In {{Chembox}} I've implemented to cound the number of elements in an input list (comma separates, <br> separated), plus the editors option of 2 parameters. Double imnput could have a warning or maintenance category message. Can {{unbulleted list}} input be detected & analysed? -DePiep (talk) 12:43, 6 January 2017 (UTC)
- Ok, thanks both. I'll start looking at which infoboxes would be suitable to have changes. ‑‑YodinT 14:31, 5 January 2017 (UTC)
Bot to publicize Good Article nominees
- 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.
- I have found that WP:FRS does the same thing that I want the bot to do. PhilrocMy contribs 15:10, 24 January 2017 (UTC)
The bot would pick three random pages from the "good article nominees awaiting review" category, use them as input to this template and then, with the massmessage right, send it out to everybody on a mailing list once a day. PhilrocMy contribs 16:17, 23 January 2017 (UTC)
- Oppose - A good deal of editors would be put off by the fact that it would be sent to everybody. Also, with this, a user's talk page would be very cluttered. Really, I think that it would be beneficial to perhaps integrate it into the community portal. It would also be good to integrate this with Wikipedia:Good articles or Wikipedia:Good article nominations. RileyBugzYell at me | Edits 22:59, 23 January 2017 (UTC)
- @RileyBugz: I send it to everybody on a mailing list which people could opt in or out of, as I said before. Did you not read that part? PhilrocMy contribs 23:08, 23 January 2017 (UTC)
- @Philroc: - Ohhhh... Well that makes more sense now. I thought that it said something like send it to everybody. Although, I will hold my position that it would clutter the talk page. Maybe it would be beneficial to just send it once a week, with five pages instead of three? RileyBugzYell at me | Edits 23:12, 23 January 2017 (UTC)
- @RileyBugz: Once a week would work, and I guess five pages would help get more GA nominees reviewed. Just made changes to the templates based on that suggestion.PhilrocMy contribs 23:14, 23 January 2017 (UTC)
- @Philroc: I think that it would probably also be a good idea to try and get this on to the community portal, along with possibly one featured article candidate with 1 review or less. RileyBugzYell at me | Edits 23:20, 23 January 2017 (UTC)
- @RileyBugz: The only problem with putting something like this on a page like the community portal or the GA nominations page is that it would be hidden in a galaxy of other things which would make it impossible to find. This is one of the reasons the GAN queue is so long. PhilrocMy contribs 23:25, 23 January 2017 (UTC)
- @Philroc: If the message goes out once a week, I would be happy to support it, I am just saying that it would be a good idea to also add it to the community portal. RileyBugzYell at me | Edits 23:28, 23 January 2017 (UTC)
- @RileyBugz: OK, I guess it's a good idea. Also, I've decided to make the message go out once a week instead of once a day. PhilrocMy contribs 23:30, 23 January 2017 (UTC)
- Why not have it set up to work like the feedback request service? Then users can control how often they're pestered. Sam Walton (talk) 14:11, 24 January 2017 (UTC)
- @Sam Walton: If it was like that, then it would be an exact copy of the feedback request service. It already notifies people in a milaing list about GA nominees, so that might stop me from doing this. Maybe it isn't working in publicizing GA nominees? PhilrocMy contribs 14:27, 24 January 2017 (UTC)
- @Philroc: Oh, indeed, I didnt notice FRS notifies on GANs. I'm confused about how this would be different then, could you explain? Sam Walton (talk) 14:44, 24 January 2017 (UTC)
- @Sam Walton: The problem is, I don't know how often FRS notifies people. If my proposal notifies people more often than FRS does, then it's different. PhilrocMy contribs 15:01, 24 January 2017 (UTC)
- @Philroc: The FRS is customisable for each user - see the page I linked - for example "3 per calendar month." Is there any other difference? Sam Walton (talk) 15:04, 24 January 2017 (UTC)
Not to derail the discussion, but I'll remind people that WP:AALERTS exists. There can be, obviously, other noticeboards and methods to advertise GANs, obviously, but Article Alerts is a very widely used system. First line of action should be to make sure the article is tagged with the relevant WikiProject's banner, which will automatically trigger an WP:AALERTS update for the project (updates run daily). Headbomb {talk / contribs / physics / books} 02:35, 24 January 2017 (UTC)
- @Headbomb: Not all projects have that. Also, some of the oldest unreviewed nominations are from projects which have AA set up. On a different topic, I found that WP:FRS already randomly sends out messages about unreviewed GA nominees to people in a mailing list. Would that stop me from doing this? Or is it not working to inform people about GA nominees? PhilrocMy contribs 12:52, 24 January 2017 (UTC)
- Oh for sure, WP:AALERTS is not the only way to notify people, some don't even know it exists, and some projects don't post the alerts prominently on their page. Just saying that people should make sure articles are tagged, since in many cases it will help. Headbomb {talk / contribs / physics / books} 15:02, 24 January 2017 (UTC)
Proposal regarding signatures
It's already posted here . Feel free to weigh in on it. KoshVorlon 19:48, 21 January 2017 (UTC)
- I've taken the liberty of retitling this section to describe what's actually being proposed. Anomie⚔ 20:18, 21 January 2017 (UTC)
- Please don't. I'm not really asking that the signature length be dropped or scrapped, thus the title change wasn't accurate. KoshVorlon 14:33, 24 January 2017 (UTC)
- Meh. I think the title I used accurately describes what you proposed, but at least the current title is better than "Proposition for your consideration" that you originally used. Anomie⚔ 01:30, 25 January 2017 (UTC)
- Please don't. I'm not really asking that the signature length be dropped or scrapped, thus the title change wasn't accurate. KoshVorlon 14:33, 24 January 2017 (UTC)
Translation of non-English articles
A discussion has been started at AN about adopting Duolingo's crowd-sourced translation system. This might help dealing with non-English article content which is often just replaced with faulty machine translations. Please feel free to participate here. De728631 (talk) 18:21, 20 January 2017 (UTC)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/ea/Purple_arrow_down.svg/20px-Purple_arrow_down.svg.png)
Duolingo has dropped its Immersion translation system; perhaps Wikipedia can get it; it's far better than machine translation
I know that there's been problems with Wikipedia's current translation system and the overuse of machine translation. Duolingo had the model of crowd-sourcing translations. I have often contributed to Duolingo translations from non-English Wikipedias and found that crowd-sourcing can lead to high quality translations. Perhaps Wikipedia can look into getting Duolingo's system. Lots of Duolingo users are upset about the loss of Duolingo's Immersion translation system. I think Wikipedia has an opportunity to step in and offer a crowd-sourcing translation system (either get Doulingo's or develop our own). This is also a win-win situation both for Wikipedia and the fans of Duolingo's Immersion tool who spend a lot of time translating articles for free. Duolingo's system was very general and went between any two languages they supported. This system had some features that encouraged people to think through their translation. ----RJGray (talk) 18:09, 20 January 2017 (UTC)
- I wonder if Wikisource would be interested in this as well, if WMF were willing to support it. ‑‑YodinT 20:10, 21 January 2017 (UTC)
- A wikiproject to provide a 'home' and some sandboxes for collaborative working would be enough to get started, without even obtaining/developing any new tools - is there an existing Translation Wikiproject? 4u1e (talk) 11:10, 24 January 2017 (UTC)
- This seems to be it: Wikipedia:Translation. Not much going on the talk page, though. 4u1e (talk) 11:43, 24 January 2017 (UTC)
- @4u1e: Wikipedia:Translation is a project for translating existing articles from other language versions of Wikipedia. This is usually done carefully and doesn't need any attention, and is not the project that would likely profit from the Duolingo method. The machine translations RJGray was referring to use to occur in completely new articles that were posted here at the English Wikipedia in another language. The proper way of translating such pages is the WP:PNT project, but often the original authors of such articles just add a faulty machine translation to speed up the process or to avoid the deletion of their page. De728631 (talk) 12:38, 26 January 2017 (UTC)
- This seems to be it: Wikipedia:Translation. Not much going on the talk page, though. 4u1e (talk) 11:43, 24 January 2017 (UTC)
Mass update of nytimes.com URLs
Hello all, a bot authorization request to update between 70,000 to 100,000 pages (mostly references in articles) to change nytimes.com links from http to https is currently open for discussion here: Wikipedia:Bots/Requests for approval/Bender the Bot 7. If you have any questions or concerns, please drop by the BRFA. Thank you, — xaosflux Talk 17:18, 26 January 2017 (UTC)
- For some background information, please read this. --bender235 (talk) 22:15, 26 January 2017 (UTC)
Consensus for semi-protection of all userpages
Since new and unregistered users are no longer allowed to edit pages in userspace, it would be best to semi-protect all userpages and require them to register and/or wait 4 days and make 10 edits.
It would be nice if there was an error message displayed when they click on the View Source button on the top of the page. It would look like this:
{{Divbox|red||[[File:Padlock-red.svg|left|64px]] '''You cannot edit this page in userspace because it belongs to the owner of this page.'''<br>It can be edited only by [[WP:AUTOCONFIRMED|established registered users]]; if you notice an error or would like to make a change, requests can be made on the talk page. Please ensure you have an account and are logged in to edit.}}
Which renders:
In many situations, however, when they try to edit and save the page, they are greeted with an error stating that "This edit has been prevented because new and unregistered users can not edit" another user's page. This was surprising on how Wikipedia started to prohibit this.
So, as I stated, let's make consensus to semi-protect all userpages and confort policy. 2600:1:B10E:7C33:8856:4BB4:A832:3354 (talk) 06:24, 20 January 2017 (UTC)
- I don't think semi-protection per se is the right solution. Is it possible to create an edit notice that would appear specifically in this situation? Note that I'm not endorsing that the proposed notice above should be used verbatim. –Grondemar 06:35, 20 January 2017 (UTC)
- This is already done via edit filter. There's no need to have an adminbot semi-protecting everything when we have a perfectly good edit filter taking care of it. ~ Rob13Talk 21:46, 20 January 2017 (UTC)
Probably distracting to the discussion
|
---|
|
- I'd recommend it be: "All pages but a user's main talk page would be given this protection." I like the idea of the protection, but it needs more solid standards. Iazyges Consermonor Opus meum 23:04, 20 January 2017 (UTC)
- I agree with Rob, if an edit filter is serving the same purpose as semiprotecting every root user page, then the purpose is met. The edit filter will work better anyway as it will not require ongoing action to apply the restriction to new user pages as they are created. Ivanvector (Talk/Edits) 00:04, 21 January 2017 (UTC)
Edit notice
I'm creating a subheading to get more attention on this portion of the IP's proposal, which I think is a good idea I don't want to be lost. Right now unregistered and new accounts do not learn they are not allowed to edit others' user pages until after they try to save the edit, which is WP:BITEy. Is it possible to create an edit notice that will appear only for unregistered and new accounts so they know they cannot perform the edit as soon as they open the editing window? –Grondemar 01:08, 21 January 2017 (UTC)
- I am not aware of any way to make an edit notice that functions like that. They usually appear to anyone trying to edit the page. Beeblebrox (talk) 03:40, 21 January 2017 (UTC)
- Yes. We can use CSS to only show it to non-autoconfirmed users. — JJMC89 (T·C) 03:50, 21 January 2017 (UTC)
- I'd tweak the wording a bit, since no one actually owns articles, using the sentance You cannot edit this page in userspace because it belongs to the owner of this page goes against that and implies that people do own articles.
I'm for clear wording, but that really needs to be changed. KoshVorlon 19:51, 21 January 2017 (UTC)
How about "If you are trying to message this user then you should edit the [[user_talk:UserName|talk page]] instead. You cannot edit this page because it is another user's profile page."? The word 'profile' feels a bit wrong, but "another user's user page" is awkwardly repetitive, and I'm wondering if some brand new users find it less clear. Alsee (talk) 19:50, 28 January 2017 (UTC)
- Two names for the same thing is always a bad idea. And the word "profile" implies a specific purpose for a user page, but an editor can use that for pretty much anything they want, within policy, and that doesn't necessarily have to be about themselves in any way. You could say "another editor's user page", but the repetitiveness you cite isn't prohibitively awkward in my view. ―Mandruss ☎ 20:10, 28 January 2017 (UTC)
Color of charts, graphs, and maps
About 10% of the population is partially or completely color blind. I included a page reference as my example.
https://en.m.wikipedia.org/wiki/United_States_presidential_election,_1812
I simply cannot tell two of the map colors apart. As an editorial guideline it might be worth suggesting to Wiki writers that they use primary colors in charts, etc. or use blank and striped contrasts.
This is a common problem with many publications and those of us sho can't make the distinction between colors would be very appreciative if you could keep this in mind. Thank you. — Preceding unsigned comment added by Beauregard Armistead (talk • contribs) 23:11, 20 January 2017 (UTC)
- This is already in place, per WP:COLORS, but since Wikipedia is so massive sometimes not everyone knows al the rules and things like this aren't noticed. Beeblebrox (talk) 23:32, 20 January 2017 (UTC)
- We should create a template to flag those for cleanup, if that's not actually already done. Headbomb {talk / contribs / physics / books} 00:30, 21 January 2017 (UTC)
- We have those, Headbomb: {{Overcolored}} and {{Cleanup colors}} – Finnusertop (talk ⋅ contribs) 20:28, 21 January 2017 (UTC)
- It should also be noted that most of these maps and charts are hosted at Commons. The corresponding maintenance template for images over there is Commons:Template:Colour blind. De728631 (talk) 20:12, 23 January 2017 (UTC)
- I tagged them on commons with {Colour blind}. Alsee (talk) 20:10, 28 January 2017 (UTC)
- It should also be noted that most of these maps and charts are hosted at Commons. The corresponding maintenance template for images over there is Commons:Template:Colour blind. De728631 (talk) 20:12, 23 January 2017 (UTC)
- We have those, Headbomb: {{Overcolored}} and {{Cleanup colors}} – Finnusertop (talk ⋅ contribs) 20:28, 21 January 2017 (UTC)
- We should create a template to flag those for cleanup, if that's not actually already done. Headbomb {talk / contribs / physics / books} 00:30, 21 January 2017 (UTC)
Request for a feature article
![](http://upload.wikimedia.org/wikipedia/commons/thumb/9/9d/Refd.svg/55px-Refd.svg.png)
(As far as I can tell, having searched for about five minutes, this is the place to make requests for featuring articles.)
The article Sarsaparilla is marked as a stub, but I think it is a nice, clear and sufficiently complete article, so I recommend it be vetted for featured-article status. Kdammers (talk) 05:48, 28 January 2017 (UTC)
- @Kdammers: The page you linked to is a disambiguation page and featured articles are discussed at WP:FA. Disambiguation pages are not valid nominations. Please see WP:FA? for more details on what they look for over there when deciding to promote an article to featured status. --Majora (talk) 05:55, 28 January 2017 (UTC)
- The article I meant is
Sarsaparilla (soft drink). At WP:FA, all I saw was a list of already featured articles (If I understand the page). Where are suggestions made? Kdammers (talk) 13:25, 28 January 2017 (UTC)
- @Kdammers: I think you should look at WP:FAC for that. עוד מישהו Od Mishehu 17:05, 28 January 2017 (UTC)
- @Kdammers: the Sarsaparilla article is not marked as a stub. MarnetteD|Talk 20:15, 28 January 2017 (UTC)
- Yes it is, MarnetteD. – Finnusertop (talk ⋅ contribs) 07:36, 29 January 2017 (UTC)
- Not anymore Finnusertop :-) For the record the article itself wasn't a stub nor was it marked as such. Now that you pointed out the talk page error I can certainly understand K's confusion though. Thanks for being more thorough than I was. MarnetteD|Talk 15:13, 29 January 2017 (UTC)
- Yes it is, MarnetteD. – Finnusertop (talk ⋅ contribs) 07:36, 29 January 2017 (UTC)
- @Kdammers: the Sarsaparilla article is not marked as a stub. MarnetteD|Talk 20:15, 28 January 2017 (UTC)
- @Kdammers: I think you should look at WP:FAC for that. עוד מישהו Od Mishehu 17:05, 28 January 2017 (UTC)
New Adminbot proposal - History Merge cleanup of another bot
Hello All, A BRFA has been opened for task approval for an adminbot to perform history merges related to cut-and-paste category renames performed by another bot. Please see the request here: Wikipedia:Bots/Requests for approval/Merge bot 2. Questions and comments for the operator are welcome. — xaosflux Talk 03:39, 29 January 2017 (UTC)
- Accusing "another bot" is unfair - until May 2014, this was the only way to do an importent task. עוד מישהו Od Mishehu 09:41, 29 January 2017 (UTC)
- Not meant as an indicator of fault. — xaosflux Talk 14:45, 30 January 2017 (UTC)