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.
The consensus of this discussion is clearly against placing this banner on article pages. More generally, any link to the Google Play store (or equivalent commercial sites for other platforms) and/or any alternative banner that cannot be dismissed, including by users who are not logged in, placed anywhere in the body of the article would also be contrary to the consensus here. A link placed in the sidebar may be viewed more favourably, but should be the subject of a separate discussion before being added. Thryduulf (talk) 15:27, 6 March 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Summarizing my view from the MFD: adding advertisement banners like this to commercial websites (in this case the google application store) at the top of encyclopedia articles should not be allowed. — xaosfluxTalk18:19, 12 January 2017 (UTC)
That is is un-dismissable and is displayed to all users when it is only targeting readers using the Android operating system are secondary issues. — xaosfluxTalk18:23, 12 January 2017 (UTC)
The link is to the google play application store, (clarified above). Not sending readers to the play store would be a good start. As far as linking to project pages, I don't personally like it due to the non-dismissability for every reader - but I'd be much less strongly opposed. — xaosfluxTalk21:05, 12 January 2017 (UTC)
Concur with Xaosflux. Google Play is clearly a commercial website. The app itself was conflated with the external link provided in the banner by its proponents at the mfd as well.— Godsy (TALKCONT)22:12, 12 January 2017 (UTC)
Unfortunately, "side-loading": i.e. offering the app directly from Wikimedia or Kiwix servers doesn't work on the telephones without rooting (something that very few users do or want to do). The app will be available for other operating systems as well, it just requires too much setup to get going right now — so rest assured the is absolutely no commercial interest involved. I will see if the App page can be updated properly. Carl Fredrik 💌📧22:19, 12 January 2017 (UTC)
I don't particularly mind informing viewers of an offline version of the content, but it would probably be better placed after the body of the article where it would be less intrusive. Yes, less readers would be aware of it, but the banner just isn't appropriate at the top of the page in my opinion. If it could be x'ed out, then it might not be so much of an issue, but as is, the template is too intrusive in my opinion. That's all discounting the fact that the app is specifically for Android, which is another issue. Dustin(talk)21:23, 12 January 2017 (UTC)
There was considerable discussion and no consensus that stated it broke with any of those policies. Even if it might be worth discussing please don't misinterpret the results. Carl Fredrik 💌📧22:07, 12 January 2017 (UTC)
As much as I support the idea of making apps available to more people around the world so they can have access to our content, and I particularly appreciate the desire to help make medical information available to more places around the world, I oppose in the strongest possible terms allowing the banner in its present form to appear on any article pages. It is quintessential WP:NOT if used in this way. There are lots of alternative ways to put the information out there, and there needs to be serious discussion of alternatives to this banner, not stubborn efforts to justify it as it is. --Tryptofish (talk) 22:58, 12 January 2017 (UTC)
Few clarifications:
I add links to external websites all the time as references and as external links (pubmed and google books are some of my favorite)
The banner is dismissible per prior discussion. Looking at making it more easily dismissible.
Yes we could switch the link from google to the project page about the app.
Versions are avaliable for a bunch of operating systems including iOS, windows, and linux. Installing these versions is a two step rather than one step process.
English is a global language. Many in the developing world have intermittent access to the Internet. About 80% of the more than 100K downloads of the app have been from the developing world. This app has been critically important (per user feedback) for many in countries such as Syria and India. We are one of the only major health care information providers delivering offline content. Not everything on Wikipedia needs to be adjusted for those in wealthy countries. Doc James (talk · contribs · email) 06:41, 13 January 2017 (UTC)
Doc James please link to how an standard (anonymous) reader can dismiss this? The only thing I saw was how a registered editor to put a css hack in their own personal settings. — xaosfluxTalk14:01, 13 January 2017 (UTC)
It was the css hack I was referring to. Still working to figure out how to make it dismissible to a wider group. It is still IMO more useful than many of the clean up takes we currently use. Doc James (talk · contribs · email) 17:04, 13 January 2017 (UTC)
I looked at the current version, and for me there is no apparent way to dismiss it. Adding something to my css file is not a satisfactory solution. As a practical matter, it is not dismissible. --Tryptofish (talk) 23:23, 13 January 2017 (UTC)
As much as such the app can be a good thing, we should not be inserting into articles themselves meta-content which advertises some service, particularly when it is not dismissible. If as an administrator with non-zero technical knowledge, I cannot get rid of it without a CSS hack, how is a reader meant to? This reminds me of the debate about {{research help}}, except this is even more intrusive and goes outside the WP site. BethNaught (talk) 14:22, 13 January 2017 (UTC)
This is a great project, thanks to everyone involved! As WMF was involved in creating the app, could the project ask them to turn it into a standard site-wide (or category specific) banner (resolving all the problems of being able to opt-out of it, etc.) and also consider other more targeted ways of promoting the app (e.g. by contacting third-world hospitals and healthcare departments directly, running events, etc.)? If the group is willing to address these concerns, then this template could serve as a temporary way to promote the app (though it should definitely make clear that it's not android only, and link to the project page rather than Google Play Store), but I would personally be opposed to it being used permanently as a header to articles - as much for the slippery slope precedent that it sets as for the other issues raised above. ‑‑YodinT15:31, 13 January 2017 (UTC)
I'm not entirely against this - I think it's a great initiative and we should do more to make it known - but at minimum I would expect to be able to easily dismiss such a notice. SamWalton (talk) 15:55, 13 January 2017 (UTC)
Let me dig around some more. If someone knows how to do this with current templates let me know.
I probably lack the technical knowdlege and experience to give an in-depth opinion on this issue, but I think the app is after all Wikipedia and I see no problem in providing the tool for offline access. With total certainty, it is of great value in certain countries or situations in which it is not possible to access the internet.
IMO the modification of the link solves much of the controversy.
The next step would be for the WMF to create a section on the left hand side under "Apps". I recommend it be put after "Tools" but before "Print/export". QuackGuru (talk) 19:44, 13 January 2017 (UTC)
While the app can benefit people, and I'm sympathetic to that, I'm strongly opposed to the current banner presentation. Links to other official Wikimedia projects are usually only "advertised" at most in the "See also" or even "External links" sections of an article. We should hold this to the same standard, in the short term. {{Nihiltres |talk |edits}}18:09, 16 January 2017 (UTC)
Although I think the app itself is useful, and I do understand that it must be advertised in some way so its target market is aware of it, I strongly oppose the use of this banner advertisement in article space. The banner is an advertisement for the app and its use goes against WP:NOTADVERT and WP:ELNO in spirit, if not in letter. There must be a better way to make readers aware of this app. For example, the app could be advertised on the main page, or a link (not a banner ad) about the app could be put in the sidebar or footer, or the reader could receive an alert or notification with a description of the app, or the WMF could purchase ad space on google or wherever. These are just ideas off the top of my head; I'm sure there's an even better way to advertise the app on Wikipedia than by running a banner ad. Ca2james (talk) 06:00, 18 January 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The 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.
Redux
So, apparently Doc James has taken the above closure extremely literally - to only prohibit this project banner from being added to articles - but is maintaining that it can be kept on articles where it has already been placed (Special:Diff/769037644).(see below))Thryduulf as the closer, would you comment if the discussion above was sufficient to cover this use or if further discussion is needed? — xaosfluxTalk14:02, 7 March 2017 (UTC)
The consensus of the discussion is that this banner should not be used anywhere in article space, whether added before or after the discussion was closed. Thryduulf (talk) 14:15, 7 March 2017 (UTC)
Please note, my apologies to Doc James for causing confusion here - I followed links from the diff in my notifications box and did not review the page history to see this was already addressed. — xaosfluxTalk18:06, 7 March 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
For some reason, new users occasionally create articles in template namespace. Usually I run across a couple instances of this a day. I propose that an editnotice similar to {{Article creation editnotice}} be applied to the template namespace, using a parser function to hide it when editing an existing template, or creating doc/sandbox/testcase pages. Thoughts? — Train2104 (t • c) 15:09, 4 March 2017 (UTC)
I'm going to go out on a limb here and guess that people who are clueless enough to do this probably don't read the directions no matter how hard you try to show them to them. Beeblebrox (talk) 19:06, 4 March 2017 (UTC)
How do you think they are getting there? I'm not too familiar with how the Visual Editor behaves. I know that on wikEd, if you click a template name, it opens the template page. But the standard source editor doesn't do that. — Train2104 (t • c) 00:16, 5 March 2017 (UTC)
Thanks for the note. I don't remember considering this issue, so you messed up or I'm forgetting something :-) I'm leaning toward agreement with Beeblebrox. I'm more favorable toward the wording of the template warning; the project warning seems to assume that you've come to the wrong namespace, and since we create a lot of good project pages (yesterday, 141 projectspace pages were created, and with a quick look-through, I saw nothing looking like a mistake), it seems a bit BITEy to make such a statement. Nyttend (talk) 03:25, 5 March 2017 (UTC)
I saw User talk:Steel1943#Wikipedia: notice without bothering to read the linked thread, which is why I included you. Note that my suggestion is only for base-page creation, not subpage creation (so exclude things like manual AFC and AFD/MFD submissions) — Train2104 (t • c) 03:31, 5 March 2017 (UTC)
I didn't realise that your code for excluding "doc/sandbox/testcase pages" would avoid displaying on any subpage. Almost all projectspace creations are subpages and/or bot created (including some bot-created subpages), so this is significantly different from what I thought; aside from the unlikely-to-read issue that Beeblebrox mentions, I'm fine with using these pages as written. Nyttend (talk) 04:39, 5 March 2017 (UTC)
Like Beeblebrox, I question how effective it would be. That said, I don't see any reason to oppose. If these are used then the red stop sign on the WP: version needs to go. The first line should match the other version, merely saying it's the wrong place to create an article. Alsee (talk) 18:27, 6 March 2017 (UTC)
The red hand was taken from {{Article creation editnotice}}, which is currently used on the editnotices for WP:YFA, WP:ACR, and WP:RED (the last of which I implemented following a request on RFPP). As there is currently nothing in MediaWiki:common.csstohide content from user groups, only to show it to them, these editnotices are probably going to be visible to all users. Since there are many legitimate template creations every day, I toned that one down quite a bit. On the other hand, the only reasonably common reason I'm aware for new basepages in the project namespace is essays, and that doesn't come close to template creation. Nor do I want to mention that on the footer for fears of mass WP:NOTESSAY creations by new users. — Train2104 (t • c) 06:29, 7 March 2017 (UTC)
If you are going to push through on this and try to get it implemented, I think a formal WP:RFC and a listing at WP:CENT are in order, since this till add edit notices to two entire namespaces. Beeblebrox (talk) 20:28, 6 March 2017 (UTC)
I also would like someone to confirm that {{#ifexist:{{FULLPAGENAME}}}} has the expected effect in an editnotice (i.e. false when creating a page) before going any farther with this. — Train2104 (t • c) 06:29, 7 March 2017 (UTC)
Proposal: maintain a list of public sandboxes in a form bots can read, rather than rely on templates being left in place.
I noticed that for two and a half days, one of the tutorial sandboxes was a redirect to Field Tracing, which must have been confusing for the affected newcomers. I assume the reason this lasted so long is that the normal cleaning bot was thrown off fixing the page because the top of it had been edited, even though the template was still present as the second line. Modifying the bot to look further down the page would only be a partial fix. Public sandboxes should be robust to all kinds of vandalism, including the template being deleted.
A way to achieve that would be to maintain a central, admin-protected, list of public sandboxes (I'm working on the assumption that there's a relatively small, relatively stable set of these) in a form that bots such as Hazard-Bot could read from. Those sandboxes could then be regularly raked in the normal way even when the indicator templates are removed from them.
(Caveats: I could be wrong about how the bot works, wrong about the number of public sandboxes, or missing something fundamental about the dangers of having bots work off a list like this rather than templates on the pages themselves. I'm just proposing as a first stab at what seems like an issue.) Mortee (talk) 01:56, 12 March 2017 (UTC)
I have started an essay on narrative flow. Maybe someday it will develop into a guideline. We talk a lot about things like reliable sources and synthesis (which are, of course, very important) and even technical writing quality issues like grammar and punctuation, but we rarely offer any general guidance as to making writing good by having the article present the encyclopedic facts in an intelligible and smoothly flowing manner. Cheers! bd2412T03:18, 17 March 2017 (UTC)
We have articles that exhaustively list episodes of television shows along with summaries of each, such as List of Dexter episodes] (and sub-articles like Dexter (season 1)) or List of The Powerpuff Girls episodes. Should we similarly have lists of comic book issues? Articles about comic book titles can tend to have disproportionately long “Plot” sections (see for instance Old Man Logan), and this should help address that by splitting off the bulk of such information.
I see absolutely nothing wrong with this, as long as WP:NOT#PLOT size considerations are taken into. (The TV wikiproject just recently refreshed their MOS related to plot summaries that would reasonably apply to comics too). Elements like release date, writer, artist, etc. are very much in the right encyclopedic data set that a terse plot summary would help support. Mind you, there might be an consideration to be taken with soap operas, in that it is more about an overarching plot than individuals issues too. --MASEM (t) 19:14, 19 March 2017 (UTC)
Note: Edits to this page are subject to review (help).
I've always felt that this notice could be a little more descriptive. Sure, interested users can click the "help" button to learn more about it, but "subject to review" is rather vague and doesn't mean anything to someone who doesn't know what pending changes is. All edits are still "subject to review" in a general sense by other editors as part of the standard editing process, and pending changes doesn't change that. The following notice seems clearer to the reader what it's really about:
Note: Edits to this page from new or unregistered users are subject to review prior to publication (help).
Support, it makes it a lot clearer. I'd replace the word "review" with "approval" to be more consistent with normal language. — Train2104 (t • c) 21:22, 11 March 2017 (UTC)
Support. Current wording is rather lacking in description and clarity, proposed rewording (or the 'approval' variation, no strong preference there) is sensible and a lot clearer. AddWittyNameHere (talk) 06:40, 14 March 2017 (UTC)
For quite a long time now, Wikipedia has had a template heading people who have recently died, saying "This article is about a person who has recently died". (Surprisingly, at the time of typing (March 20 2017) the article on Chuck Berry is not headed by this template). Could we have a similar template for groups where an individual does not have a separate article in Wikipedia, but where the group contains an individual who has recently died? If you go to the article on Sister Sledge you will see that I put my initial thoughts on this there - indeed, what prompted this proposal was my hearing the news of the death of Joni Sledge and how news reports said that the cause of her death were not known.Carltonio (talk) 17:40, 20 March 2017 (UTC)
Template:Recent death is for articles experiencing "high levels of activity" as a result of a death, it's not - as the documentation for it says - "merely to tag the article of a recently deceased person". The template also has options to override the word "person" if the article is about a larger group, but is still attracting high levels of activity. --McGeddon (talk) 17:52, 20 March 2017 (UTC)
And in fairness, the template is of little use: if we are doing our jobs properly. I believe in general it detracts, except in the case of a very few sudden unexpected deaths. All the best: RichFarmbrough, 20:51, 21 March 2017 (UTC).
RfC: Deprecate terms "edit history" and "revision history"
Not done--The proposal failed to gain consensus.Many editors have expressed a lack of any meaningful benefit/purpose ariving out of the change.Winged Blades Godric06:42, 24 March 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
If a Yes consensus is reached, occurrences of "edit history" and "revision history" would be replaced by "page history". This would begin with what are arguably the most visible occurrences, the links "revision history statistics" and "revision history search" on the page history page itself, and the "Revision history" in its heading. At Help:Page history, the sentence "A page history is sometimes called revision history or edit history." would change to "(The alternative terms 'revision history' and 'edit history' are deprecated.)" Other occurrences would be replaced as editors run across them, citing this consensus. ―Mandruss☎22:37, 28 February 2017 (UTC)
Survey: Deprecate "edit history" and "revision history"
Yes - I see absolutely no benefit to having multiple names for the same thing. Meanwhile, there is a downside in that new editors have to learn that the various names refer to the same thing. This is a good example of widepsread unjustifiable complexity that, collectively, serves as a barrier to entry. ―Mandruss☎22:37, 28 February 2017 (UTC)
request clarification Are we talking about changing links in policies and so forth or are we talking about what editors choose to call it, because those are two very different conversations. Beeblebrox (talk) 22:48, 28 February 2017 (UTC)
Request clarification of your request for clarification. If you're asking whether it's about changing existing or future occurrences within editor comments in talk spaces, the answer is no. Communication is improved when we agree on the names of things, but we don't go around changing editor comments from "edit comment" to "edit summary", "intro" to "lead" or "lede", and so on. Rather, it's about non-talk occurrences in the WP and Help spaces, etc., and infrastructure software such as the page history display. We can't make the horses drink, but we can lead them to the water. ―Mandruss☎22:52, 28 February 2017 (UTC)
No, because the different terms are used in different contexts. When we're talking largely about the page itself, editors tend to say "page history". When we're talking about specific diffs, editors tend to say "edit history". When we're talking about specific revisions (but not necessarily which individual edit led to them), editors tend to say "revision history". The terms "page", "edit", and "revision" are distinct and editors have to learn them anyway. Any editor who struggles to understand what "page history", "edit history", and "revision history" means after knowing those three terms must not know what a "history" is, and that's something we're not going to be able to fix. This is a solution in search of a problem, and it actually has a small chance of causing harm. Removing the alternative terms that have different contexts from all documentation will just make discussions held in those different contexts more difficult to understand. ~ Rob13Talk08:27, 1 March 2017 (UTC)
Yes. As the OP poinyted out, we won't erase the terms from Help:Page history, and this will keep all current discussions consistant with the way major features of the software are refered to - this will make things easier for newcomers. Note that no automation should be used to fix anything here - each change needs to be reviewed by a human being (an admin inthe case of MediaWiki: namespace pages). עוד מישהוOd Mishehu09:18, 1 March 2017 (UTC)
@Od Mishehu: "Current discussion" will be unaffected, just documentation pages. We obviously cannot ban editors from using the alternative phrases which are more descriptive in specific contexts. ~ Rob13Talk09:20, 1 March 2017 (UTC)
Yes, but as we move towards the new terminology, the depricated ones will gradually fade out of use in discussions. We son;t ban editors from talking about the "Abuse Filter", yet I haven't seen anyone calling itby that name. עוד מישהוOd Mishehu09:21, 1 March 2017 (UTC)
No Outside technical and emergency contexts, there is no need for perfect consistency in language, especially in English. If I ask you for a pop from your ice chest, and you go and grab a soda from your fridge, we both know what I was asking for and effective communication happened. I see no evidence that effective communication is hampered by these terms. There isn't any real problem in referring to page history versus edit history versus revision history. They all refer to the record of past edits that revised the way a page displayed, and they all communicate effectively. We shouldn't try too hard to impose order on a usage area that will likely defy order. Eggishorn(talk)(contrib)16:48, 1 March 2017 (UTC)
No per there being no real reason to change. Not confusing and it doesn't hurt anything. Eggishorn also has a great explanation for why it doesn't matter. Just because it doesn't appear to hurt anything to change it doesn't mean we should do it. There should be a positive reason for the change, which I don't see here. TonyBallioni (talk) 14:37, 2 March 2017 (UTC)
no. I too can see no reason for this, no benefit it will bring to the encyclopaedia, just a bunch of unnecessary edits and potentially a number of disputes as editors unaware or disagreeing with this proposal revert the changes.--JohnBlackburnewordsdeeds15:39, 2 March 2017 (UTC)
No English has multiple different terms that mean essentially the same thing. Since the terms aren't confusing or misleading there's no real benefit to standardising on one, and trying to enforce a single term would only antagonise people. Hut 8.518:46, 2 March 2017 (UTC)
There is no proposal to "enforce" anything. Also see today's further discussion in the following section. ―Mandruss☎04:12, 3 March 2017 (UTC)
No Per WP:CREEP, we should always have a real problem that is solved by any changes, and I'm just not convinced there is a real problem here that would require a new rule to solve it. Beeblebrox (talk) 05:06, 3 March 2017 (UTC)
There is no proposal for a new rule. CREEP does not apply since the proposal is to replace two words, revision history or edit history, with a different two words, page history, in contexts referring to the tool described at Help:Page history. Also see today's further discussion in the following section. Per WP:BLUDGEON, this will be my last attempt to get participants to expend a bit of effort to understand the relatively simple question presented in this RfC, as well as the rationale for support. ―Mandruss☎05:10, 3 March 2017 (UTC)
No a waste of time RFC. The terms edit history and revision history are much more explanatory, esp. when it comes to external usage - by non-wikipedians. "Page history" is too vague. 103.6.159.75 (talk) 16:11, 16 March 2017 (UTC)
Discussion: Deprecate "edit history" and "revision history"
If I see significant support for a "choose the term or leave status quo" RfC, I will withdraw this and restart, pinging any prior participants. ―Mandruss☎23:56, 28 February 2017 (UTC)
My only concern would be if the use of edit history to refer to a users past edits accidentally get changed upon implementation, but that's unlikely to be a problem. -- IazygesConsermonorOpus meum01:43, 1 March 2017 (UTC)
Right, none of this would be automated and I think human intelligence and BRD would prevent such a problem. ―Mandruss☎01:46, 1 March 2017 (UTC)
I have generated a list of likely pages to look over for the term "revision history" - see here. The similar search for "edit history" has too many false positives to use this way. עוד מישהוOd Mishehu09:24, 1 March 2017 (UTC)
A lot of the opposition is that there is no confusion. I fully understand that there is no confusion to us, after we have learned that they refer to the same thing. In my opinion experienced editors should put ourselves in the position of the newbie; this is about entry after all. Does anyone dispute that it does take longer to learn three synonyms than a single term? It doesn't take a lot longer, but combined with the numerous other such situations the learning curve is significantly longer than necessary. Does anyone not find it intuitively obvious that many newbies, especially those not coming from technical backgrounds, must be overwhelmed by the complexity of this environment? The only way to address this is one nit at a time. The principle is that simpler is better, and the proper question is: What harm would be done by this small simplification? The effort required to implement is miniscule; except for the trivial software changes (you don't have to do elaborate regression testing of a change to a few words on a generated page), I would do most of it myself. ―Mandruss☎03:41, 3 March 2017 (UTC)
Counter-argument: Od Mishehu's comment above about "too many" false positives for a simple search on "edit history". In truth, it is not likely simple on a technical level, and certainly not simple on a behavioral level. Editors will continue to call and name these pages whatever they wish and banging them over the head with yet another stylistic preference is policy creep. Eggishorn(talk)(contrib)04:00, 3 March 2017 (UTC)
(edit conflict) The question also shouldn't be What harm would be done by this small simplification? but Why should we do this? I haven't heard a good case for why we should do it. TonyBallioni (talk) 04:03, 3 March 2017 (UTC)
Changing the words used by Wikipedia is hardly banging anybody over any heads. I'm not proposing a warning template here. Hyperbole is not helpful to the debate or one's own thinking. I think it's abundantly clear that editors would not be forced to use the "official" term any more than they are forced to use any other "official" terms. I merely assert that it makes sense to have one "official" term for each "thing". Some editors call the lead/lede the "intro", but does that mean we should rename Wikipedia:Manual of Style/Lead sectiontoWikipedia:Manual of Style/Lead or intro section? I think not. Does it mean we should call it lead/lede in some places and "intro" in others? I think not. Communication would be enhanced if everybody called it lead/lede, but we don't actively correct the editors who call it "intro". We simply hope that, at some point in their development as an editor, it will occur to them that Wikipedia calls it lead/lede and they will start calling it that instead. No head-banging. I've made the best case I know how, but if I fail to convince a majority, I certainly know how to lose. I do ask that participants refrain from misconstruing the proposal, as that undermines any decision-making process. I've seen little evidence that closers take the time necessary to discount such !votes. ―Mandruss☎04:09, 3 March 2017 (UTC)
Yes, yes. Disagree with your case, but wasn't trying to suggest you don't know how to lose. Sorry if the tone came off that way. Text being an imperfect means of communication :) TonyBallioni (talk) 04:12, 3 March 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As you can see from IJ (digraph), many Dutch words are written with "IJ", both capitalised, as their initial letters. This looks odd to English-reading eyes, and if you remember how such a world is spelled (e.g. IJlst), you may forget to capitalise the J.
With this in mind, creation of "Ij" redirects seems like a good idea. Would it be desirable to request that a bot create an "Ij" redirect for every "IL" article? Nyttend (talk) 02:45, 26 March 2017 (UTC)
Is there some idea of how many there are? If there are only a few dozen programming a bot might not be worth it. A few hundred? Then yeah, a bot might be useful. --Majora (talk) 02:47, 26 March 2017 (UTC)
Once we scrap acronyms and the like (e.g. IJA 145th Division and IJCAI Award for Research Excellence), we're left with 70 titles, out of which 38 are articles, 30 are redirects, and 2 are irrelevant, IJustWantToBeCool and IJustine. So I guess you're right about doing these some other way. By the way, is there some custom way to cause Special:Allpages to exclude redirects, or is there some other special page that does the same thing as Allpages except without the redirects? If we'd had hundreds of pages, it would have taken an excessive amount of time to count all of them. Nyttend (talk) 03:11, 26 March 2017 (UTC)
How did you come up with 70? I just did a search for prefix:ij and then did a normal ctrl + f search for the word "Dutch" and came up with 29 articles. I don't think there is a way to eliminate redirects in Special:Allpages and the manual on searching is coming up empty as well. --Majora (talk) 03:22, 26 March 2017 (UTC)
Even better, search for Dutch in the entire article. Search for "Dutch prefix:ij" returns 37 articles. --Majora (talk) 03:27, 26 March 2017 (UTC)
I searched for titles beginning with IJ at Special:Allpages, deleted the ones that were acronyms and the like, and I was left with 70 titles. Probably 1 of the 38 is unrelated to Dutch and I made a mistake by including it. Nyttend (talk) 03:34, 26 March 2017 (UTC)
Whether it is 37 or 38 it would probably just be easier to do these manually. That isn't really enough to warrant making a bot, getting it approved, and running it. --Majora (talk) 04:00, 26 March 2017 (UTC)
Good point. The problem is that I don't know how to search for such pages; you won't find them easily with Special:Allpages of course, and if it's possible to get Special:Search to be case-sensitive (i.e. counting "Hoge vuurtoren van IJmuiden" but ignoring "Hoge vuurtoren van ijmuiden" if it existed), I don't know how. Judging by Help:Searching, if I searched for intitle:IJ and intitle:IJ*, I suppose it would give me all pages with "IJ" as a separate word and all pages beginning with IJ, but those might still have to be sorted by capitalisation status. Nyttend (talk) 23:31, 26 March 2017 (UTC)
Make the title of each column follow the scrolling in tables
Hi, I like to read statistics and I often find that with a large table with many columns and rows, I get lost while scrolling down. I think the first row of a table should 'magnetize' to the top of your screen and follow along as you read entries of the table that are lower. Often, the tables are incomplete and so, it is hard to follow along, remembering which row is which. It can be especially hard when the subject is a new one for the reader. Of course, this idea should be implemented in beta first to see if it works.
I've been testing this lately in my personal CSS. It works quite well on sortable tables. For wiki tables, it's harder, since you need to guess where headers start and end, which is basically impossible (the JS of wiki tables has some pretty complicated logic to do that, which cannot be easily copied). It also only works on rather recent browsers. I'll turn it into a gadget. —TheDJ (talk • contribs) 11:18, 28 March 2017 (UTC)
Works on Safari. On Chrome it seems that it only works halfway (no sticky support for thead elements...) and on Firefox it should be working but apparently it doesn't work at all. —TheDJ (talk • contribs) 12:30, 28 March 2017 (UTC)
Done I've redirected and trivially "merged" the author's article into the book article. The book article is not well developed, but it definitely does warrant a page here. There are a large number of significant sources which discuss this book. Alsee (talk) 20:08, 29 March 2017 (UTC)
Rfc: Remove description taken from Wikidata from mobile view of en-WP
Withdrawn. The purpose of this RfC was to ask (or not ask) the WMF Reading team to turn this off, now. User:OVasileva (WMF)posted, saying that that the Reading Team is turning this off. Olga also requested feedback about "blockers", and that should be a new RfC focused on that question. I strongly urge the Reading Team to open that RfC and frame it in a way that is intelligible to editors who don't code, and to not turn this back on without the consent of the en-WP community. Jytdog (talk) 17:42, 30 March 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Do you support the following statement: "The description taken from Wikidata that is currently being loaded in mobile views of en-WP pages, must be immediately removed from mobile views of en-WP pages"
supportJytdog (talk) 00:32, 30 March 2017 (UTC) Adding rationales: 1) en-WP has a BLP policy and DS on BLP topics, because these are contentious issues and people get fierce about them, and there are legal ramifications. Wikidata has no BLP policy and in any case content changes there are not governed by anything in en-WP; content from there should not be the first thing people see when they go to read an en-WP article. 2) Same thing applies for non-BLP topics; V and NPOV and OR do not apply in Wikidata. 3) en-WP editors cannot see the Wikidata description. There are many possible ways they could but working that out is a huge issue itself. This practice should stop until things are worked out (if they ever can be) Jytdog (talk) 01:38, 30 March 2017 (UTC)
Oppose I'm not aware of any Wikidata policies which encourageallow descriptions that would be disallowed here (or prevents editors from removing them). The problem is just some poor editors and vandals at Wikidata – something we have far more of at Wikipedia. Anyone can fix bad Wikidata descriptions by clicking the "Wikidata item" link under "Tools" in the desktop version of the article (a link on the mobile version might be nice but the mobile designers like streamlining). Wikipedia accounts work at Wikidata and you remain logged in when you switch site. They also allow anonymous editing. A script to display Wikidata descriptions in the desktop version was posted to Wikipedia:Village pump (technical)#Wikidata description in mobile view on enwiki. We could consider making a gadget version or at least list it at Wikipedia:User scripts. By the way, many Wikipedia templates import data from Wikidata. See Category:Templates using data from Wikidata. PrimeHunter (talk) 00:41, 30 March 2017 (UTC)
The issue is that when vandalism occurs to a Wikidata definition that is viewed by millions, it often remains unfixed for months. On EN Wikipedia this simply does not happen for such popular pages. I have proposed a solution below to fix the issue. Doc James (talk · contribs · email) 00:44, 30 March 2017 (UTC)
Support - (edit conflict) I get the idea. For example, there are lots of other non-English Wikipedias that use templates to auto-generate infoboxes from Wikidata, but I think A) that in and of itself is a bad idea unless there's a way to incorporate the anti-vandalism team into it, which there currently doesn't seem to be, and B) we definitely shouldn't have someone making that decision for 5m articles without community consensus, which I don't think they would've gotten if they'd bothered to try. TimothyJosephWood00:45, 30 March 2017 (UTC)
support. As I wrote at YPT, the descriptions (I spent 5 mins in mobile mode browsing them) add nothing to articles. At best they just restate what is in the lead. At worst they are badly written or a poor summary. Mobile view should display the same content as desktop view, as far as is possible. Editors editing a lead to present the clearest definition of a topic do not expect it to be preceded by another definition, one they can’t even see if editing on the desktop. They are an obvious target for vandalism and disruptive editing; Wikidata’s terrible editing interface probably keeps some of them away, but it also deters anyone wanting to fix them. There is as far as I can see no way to edit them from the mobile view.--JohnBlackburnewordsdeeds01:03, 30 March 2017 (UTC)
Support Until (1) there is the ability to have changes from WD to JUST the definitions appear on my watchlist on WP. (2) there is the possibility to set the definition locally. When this has occurred I will support the use of definitions from Wikidata/WP again. Doc James (talk · contribs · email) 01:19, 30 March 2017 (UTC)
Oppose First, one important point: if wikidata use on enwiki is problematic for BLP reasons, please note Wikidata is displayed not only on mobile view, but also on desktop view at www.wikipedia.org when you type into the search bar. I have previously had the same problem of trying to change the wikidata text without knowing where it was from. Wikidata text in these contexts seems quite useful and rarely problematic, so the key is finding a way of displaying the source of wikidata text when it appears on enwiki so that editors know where to change it. NPalgan2 (talk) 01:41, 30 March 2017 (UTC)
Support per my comments in the AN/I thread mentioned immediately above by Euryalus. WMF needs to pay more attention to this find of feedback from the editors of en.wiki, its primary website. Beyond My Ken (talk) 03:29, 30 March 2017 (UTC)
Oppose, this seems to be kneejerk change aversion rather than an actual problem. The correct solution rather than taking a step backwards, is to make it easier to identify and correct the vandalism when it does occur. Lankiveil(speak to me)03:52, 30 March 2017 (UTC).
Support as emergency action until a technical solution is developed to address the issues raised here. This is the only prudent course of action to stop this highly visible vandalism. I do question its usefulness as a subtitle when viewing mobile pages, but I have found it to be very helpful in the search function, so there should be a long-range solution developed. Having this value locally stored in a template or magic word is the best idea. No matter the degree of watchlist and edit-button connectivity implemented between Wikipedia and Wikidata, there remains the fact that unless some pretty drastic permissions changes are made, administrators here will have no additional power to fight this vandalism than any other user. Given the prominent placement of these descriptions, it's better to take as few risks as possible. – Train2104 (t • c) 05:25, 30 March 2017 (UTC)
Conditional oppose – I use the mobile Wikipedia a lot and I find these descriptions very useful, especially for searching. However, it is undeniable that the amount of vandalism occurring is too high. I suggest that only autoconfirmed users can change labels on Wikidata (these "descriptions" are item labels). I believe the WD descriptions should be kept on two conditions: 1) that this is enabled in the desktop view, considering that most of our editors edit via desktop; and 2) that an "edit" link is included next to the description so editors know what to do if they spot vandalism. OVasileva (WMF)orJkatz (WMF), is this possible? Thanks, Laurdecltalk05:37, 30 March 2017 (UTC)
Support. The idea behind these descriptions (for mobile and for search) is good. But the implementation is poor. This is a language-based thing, not some common information, and should thus be stored and edited at the language version (enwiki), not at one of the common resources (Wikidata and Commons). Creating a template (a kind of hatnote) which goes above the infobox for mobile view and gives the description is easy (and initially a bot can probably copy the existing descriptions from Wikidata and import them here if people feel that that would be useful). Making that description turn up in the search results would probably require cooperation with WMF, and for that purpose it would be best if we could agree on some template form and name to be used across all wikilanguages (a bit like Persondata in the past). But the end result would be that the description is an integral part of the article here, subject to our policies, protection, ... and visible in watchlist, recent changes, history, ... Much simpler than trying to fix this on Wikidata, with e.g. an option to only show changes to this in our watchlist, and a direct link from here to there to edit it there, and so on. Keep it simple, keep it here. Fram (talk) 06:51, 30 March 2017 (UTC)
Support It's a knee jerk reaction, but that is how en.wp rolls :) I'd like to see some actual data. In my anecdotal experience, the vandalism rate on wikidata is significantly lower than on English Wikipedia, even though the 'online' time per incident might be a bit higher than we are used to here. I also think that this isn't significantly solving the problem, and that isolationism definitely isn't the solution. But we can create solutions later. —TheDJ (talk • contribs) 08:32, 30 March 2017 (UTC)
Conflicted. My immediate response is a knee-jerk reaction to the knee-jerk reactions, namely that I oppose disabling this because I feel like it would be an over-reaction and we would struggle to gain consensus to re-enable it in the future because 'WMF did a thing I didn't explicitly agree to and it's not perfect'. Equally, I totally agree that it's troubling there is content that is being displayed to enwiki readers that we can't easily monitor. As I said elsewhere, I think T161596 would be the best solution, adding the wikidata description to the desktop view for logged in users (perhaps optionally), to provide some extra oversight from this community. I'm sympathetic to disabling the feature until better checks are in place, I just worry that it would never be re-enabled. SamWalton (talk) 09:01, 30 March 2017 (UTC)
Support. Actual vandal rates may still be lower on Wikidata than here, but the level of vandal watching is also quite inadequate, and I've seen examples myself where vandalism on Wikidata remained uncorrected for unaaceptably long times. Plus, evidently, the system is not transparent enough for users of the mobile app to understand how and where to report and/or correct this kind of vandalism when they notice strange entries, and most regular Wikipedia talkpage watchers never notice these problems. Fut.Perf.☼09:03, 30 March 2017 (UTC)
Oppose. From my experience (1,936 pages on watchlist on enwiki 15,007 pagew on watchlist on wikidata) vandalism rate on wikidata is comparable to rate at enwiki, even a bit smaller. While wikidata are weaker with fast response to vandalism at popular themes, enwiki is weaker with vandalism at less popular themes (vandalism edits at less popular articles covered with some bot edit are mostly unnoticed). Meta:Resolution:Biographies of living people is fully binding for Wikidata and it is respected (see w:Wikidata:Wikidata:Autobiography). Jklamo (talk) 11:49, 30 March 2017 (UTC)
"Meta:Resolution:Biographies of living people is fully binding for Wikidata and it is respected (see w:Wikidata:Wikidata:Autobiography)" From that page: "You may raise such concerns on the Village Pump, on the Administrators' Noticeboard, or on the talk page of the editor concerned. If you are not satisfied with the response of editors and admins to a concern about biographical material about living people, you can contact the Wikimedia Foundation directly." The page was only created on 16 March 2017, and it is too bad that the links to the Village Pump and the Admin Noticeboard don't link to any Wikdata page and thus will never be seen by Wikidata editors. Just goes to show how serious this is taken by Wikidata... (plus, who will look for this at "autobiography"? That's only for pages you write about yourself, not for pages written by someone else where you have a complaint). Fram (talk) 13:12, 30 March 2017 (UTC)
Support I've been editing for almost nine years and had no idea mobile users see completely different text from what I see and edit. I feel either clueless, stupid, uninformed, or worse. First Light (talk) 14:22, 30 March 2017 (UTC)
Oppose wikidata is the backbone of Wikipedia so start using it and fix problems when you find it. Get good quality descriptions in WIkidata will add value to the user experience not just in the mobile phone but also on other platforms - Salgo60 (talk) 14:50, 30 March 2017 (UTC)
Support - Making it easily visible to all desktop editors is not a solution, as it would introduce a new battlegroundtime sink of highly visible content (titles, lead sentences, infoboxes) without enough added reader value to justify that battlegroundtime sink. In short, the cost exceeds the nonzero benefit. ―Mandruss☎15:31, 30 March 2017 (UTC)
Support. Content on en must be from en. We cannot trust wikidata to maintain our standards for BLPs or other such issues. And showing material on mobile that is not even visible to non-mobile users is especially problematic because if our editors not using mobile devices can't see it, how can they even notice it to fix it? The same content must be shown on all access methods. —David Eppstein (talk) 16:30, 30 March 2017 (UTC)
Support. I don't agree with statements such as "all content on en must be from en", but if any data is not coming from en then I think it's a minimum requirement that it's easy for en editors to see the change, e.g. in their watchlists. If that can be done we could revisit this. I would also prefer that editing data that affects en-wiki should happen on en-wiki, but that's more debatable. Mike Christie (talk - contribs - library) 17:19, 30 March 2017 (UTC)
Statements from WMF reading team
A comparison of mobile frontend with and without wikidata descriptions
Hi, we are open to switching this off while we identify next steps for fixing identified blockers. We do, however, want to make sure everyone understands the rationale behind the feature, which is designed to provide an at-a-glance article description for people who:
(a) have to scroll through many screens to get past the infobox before they can learn about the topic, and (b) for people who feel overwhelmed while scrolling through the often dense and opaque lead sentences.
We have currently identified these items as blockers:
Difficulty of editing wikidata descriptions in Wikipedia - for mobile, we are currently testing the mobile version of this solution on the Android app and have begun looking at ways to bring it to the mobile web (phabricator task https://phabricator.wikimedia.org/T141230). For desktop, we are in the process of brainstorming solutions along with the wikidata team
In terms of tracking the changes to these descriptions, we have some planned tasks for creating easier ties between Wikidata and Wikipedia. Currently:
2) Edits do not show up in recent changes and watchlist if the user is using the recent changes setting (Phabricator ticket: https://phabricator.wikimedia.org/T46874)
Please contribute your thoughts along with your vote, and lets continue to discuss productively how to help serve these diverse demographics. OVasileva (WMF) (talk) 00:52, 30 March 2017 (UTC)
Update: Hi all, based on the raised concerns, we have decided to turn the wikidata descriptions feature off for enwiki for the time being. However, we’d like to encourage the RfC to continue with a focus on identifying the blockers for turning the feature back on in the future - thank you for your comments on these issues so far. Posting current list of blockers in comments below - please review. As mentioned, users have found this feature useful as a means of providing an at-a-glance description of the article. I’d also like to note that releasing these types of features is a piece-wise process - we began with displaying the description to evaluate the feature and would like to continue with the next step - editing the description based on your feedback. Thus, this second iteration of the feature will take some time to complete, and would probably not be released until June 2017 at the earliest. Thanks! OVasileva (WMF) (talk) 17:21, 30 March 2017 (UTC)
Discussion
Note - please don't turn this into bigger issues, of which there are many. These descriptions from Wikidata are added to content generated by the en-WP community that is subject to en-WP policies, but comes from a source that is outside the control and oversight of the en-WP community, and can only be fixed off-enWP. We already have examples of BLP violations showing up in mobile views because of this feature. This should be a quick/yes no, and if it is "yes, remove it" we can have subsequent discussions about adding it back or setting up some safeguards, in other discussions. Not here please. Jytdog (talk) 00:07, 30 March 2017 (UTC)
Agree this is a serious issue as often the vandalism introduced is the first thing people see and En WP editors only hear about it when a reader posts on the talk page of the article in question (of which all are not that well watched).
Would like to hear proposed solutions and that the issue is being taken seriously before making up my mind. We should ping the app people to let them know of this discussion. I must sleep first though. Doc James (talk · contribs · email) 00:22, 30 March 2017 (UTC)
User:TNegrin (WMF) not sure who to direct this to. A few things that would help include:
1) These descriptions show on EN WP (so we can pick up issues)
2) If the description changes on Wikidata it shows within the watchlist for the EN article (I do not have the bandwidth to follow all changes on Wikidata but would be willing to watch this one section)
HiDoc James. Thanks for thinking through this with us. I totally agree that having them show in moderation queues and allowing editing are important. We've been thinking about these for awhile the issues we're facing might reflect us needing to change the order of operations bit. I'll quote what OVasileva (WMF) wrote on the Admin board [2] about this:
In terms of tracking the changes to these descriptions, the Wikidata team has been focusing on creating easier ties between Wikidata and :Wikipedia. Currently:
Currently the android team has built a way of editing wikidata descriptions from within the app - more information on the short descriptions page as well as the project page in phabricator We’re currently rolling it out as a pilot on three languages and our plan is to measure and evaluate the interest for this feature on the apps before approaching the solution for mobile web - we’re curious to know if there is any interest in pursuing a similar solution for the mobile website? Some of our initial mockups and ideas for the mobile website can be found in this phabricator task
I also believe there are some gadgets for showing it on desktop, but until we solve the editing and tracking issues, showing it to everyone might increase the impact of the issues rather than improving upon them. Jkatz (WMF) (talk) 01:12, 30 March 2017 (UTC)
User:Jkatz (WMF) The problem is I cannot watch all those wikidata entries as the number of changes are simply too great a load. If only changes to the "definition" could show up in my watchlist I would than turn that feature on. Doc James (talk · contribs · email) 01:17, 30 March 2017 (UTC)
Those are the complicated alternatives that in my view are too much to get into now. Endlessly debateable with many variations possible. Bottom line is that right now everybody reading en-WP on mobiles is seeing at the top of every article, content from Wikidata that is not subject to BLP or any other en-WP content policy for that matter. Jytdog (talk) 00:46, 30 March 2017 (UTC)
Not really. 1) It is an ad hoc solution based on en-WP editors turning on a feature, while the description is in every mobile view by default. It is apples and oranges. 2) Also, Wikidata has no BLP policy. You are in a Wild West when you make a change there and there is nothing stopping who ever did it in the first place from coming right back and re-adding it, over and over. We have a BLP policy and we have discretionary sanctions on BLP topics because of this kind of thing. Jytdog (talk) 01:26, 30 March 2017 (UTC)
As those definition show on EN WP by default, the changes to that part of WD should initially occur on the EN WP watchlists of all users by default (until a person turns it off).
If you can set a local definition that overrides WD that addresses your second concern of "re-adding". I like the overall functionality of these short definitions. They just need to be handled better. Doc James (talk · contribs · email) 01:31, 30 March 2017 (UTC)
You are not going to bed, mister! :) Three issues: (LIke I said all these "solutions" are endlessly complicated and we should not be discussing them here!! 1) It appears to me that the WMF reading team draws the field from Wikidata. I am not sure that an override in an infobox on en-WP solves the problem; 2) adding the 'definition" field in an infobox means displaying another field in an infobox and one of the things Olga says above is that infoboxes are already a problem in mobile view; and 3) we have our own battles about infoboxes in en-WP right? What about articles without infoboxes or where that field get suppressed? Not feasible. Jytdog (talk) 01:48, 30 March 2017 (UTC)
Not convinced on #3 at all. Seems like we are proposing that incorrect wikidata content be buried beneath possibly correct enwiki content, rather than the incorrect wikidata content be fixed. #2 is already a preference in the Watchlist - perhaps one way of going about this would be to change the preference so that all Wikidata description edits show on local watchlists irrespective of preference, while edits to the rest of a wikidata item can display or not on local watchlist according to the preference. Jo-Jo Eumerus (talk, contributions) 14:49, 30 March 2017 (UTC)
I was about to reformulate my post to say I'm not aware of any Wikidata policies which encourage descriptions which would be disallowed here, or prevent editors from removing them. PrimeHunter (talk) 00:53, 30 March 2017 (UTC)
:) Sorry to be too quick and thanks for replying. But what you write there, is entirely different from having a policy that forbids content like this, and that allows taking action against users who add such content. And what is worse, if I take the time to go fix an en-WP BLP violation in Wikidata and another editor there restores it, there is no Wikidata BLP policy to fall back on. This is not a feasible situation. Jytdog (talk) 01:01, 30 March 2017 (UTC)
Nothing to apologise for. I did save it and should have thought more about it first. I have limited Wikidata experience and don't know whether edit warriors readding crap is a serious problem. The Wikidata descriptions are also displayed in mobile searches. Bandwidth is limited or expensive for many mobile users so they may like a brief description before clicking a link. It may seem odd if the clicked link then doesn't contain what they clicked on. PrimeHunter (talk) 01:18, 30 March 2017 (UTC)
User:OVasileva (WMF) Does this mean that WMF Reading team has switched it off, or just that it is willing to, pending the outcome of this RfC? Please clarify. I have more to say but this is the essential point right now. Jytdog (talk) 01:10, 30 March 2017 (UTC)
Just posted a note on this above. We’re turning the feature off for now, but I would like to encourage the RfC to continue with a focus on identifying the main blockers so we can start working on the next iteration. OVasileva (WMF) (talk) 17:34, 30 March 2017 (UTC)
User:OVasileva (WMF) I will go ahead and add this before I forget. Above in (b) you wrote that the Reading team did this in part for people who feel overwhelmed while scrolling through the often dense and opaque lead sentences.. I am not sure you understand how explosive that is - WMF is overriding en-WP on a content issue. Yikes. Jytdog (talk) 01:20, 30 March 2017 (UTC)
Yes, if that's the way they want to play it, just do away with volunteer editors altogether and have the staff write the encyclopedia by themselves. Beyond My Ken (talk) 03:32, 30 March 2017 (UTC)
Hi - sorry if it came off that way. I was not trying to imply that the wikidata descriptions would in any way be overriding the lead (I think we can agree that’s a bit absurd). I wanted to highlight that these descriptions serve a very different purpose from the lead. The wikidata description provides an instant description/idea of the article, while the lead is a proper introduction to the remainder of the article. While the latter is undoubtedly more crucial, I think that both are useful. OVasileva (WMF) (talk) 17:34, 30 March 2017 (UTC)
History --I am playing catch up on all this but an IP posted these two threads from VPT about this happening - almost no one responded. No RfC.
I also looked and found this Phab from late 2015; These two comments there -- here and here -- were important and were blown off and are what we are talking about now. For pete's sake. Jytdog (talk) 03:59, 30 March 2017 (UTC)
WMF people (and others), is there a good reason why this needs to be on Wikidata and not in the enwiki (dewiki, frwiki, ...) article? I have described (in my "support" above) how I would see this working as a templated part of the article, not a Wikidata item. As it is something that needs to be typed out for every language and every article, it provides no profits to store it centrally (on Wikidata) as far as I can see. Otherwise why not store the whole article on Wikidata and get rid of all these language-based projects? I understand (and support) the reasons why these descriptions were added, but not the implementation of it through Wikidata (certainly not the current one, but not the philosophy behind it either). Fram (talk) 07:01, 30 March 2017 (UTC)
User:Laurdecl thanks for !voting above, but you are talking about a dramatic change to Wikidata with respect to who can edit what, and that is an extremely long and complex issue. There are other workarounds but they too will be long and complex discussions. This RfC is about stopping this now. Would you please respond to the RfC question? Thx Jytdog (talk) 07:25, 30 March 2017 (UTC)
{My suggestion is a way to stop this – now. If we restrict changing descriptions to autoconfirmed editors then we lose 99% of vandalism. Allowing new editors/IPs to change descriptions is similar to allowing them to move pages. "Now" is a relative term; this RfC will probably end up going on for three months, assuming the WMF even comply. Anyway, I have responded to the RfC question. Laurdecltalk07:32, 30 March 2017 (UTC)
{ping|Laurdecl}} - BLP issues are not just due to "vandalism" - people add BLP-violating content all the time for reasons they think are very good. This is why en-WP has BLP policy and discretionary sanctions. Framing this as just a vandalism thing misses a lot of the point. Two examples were brought up in the ANI - see this diff at Wikidata (did the person who added "boyfriend" think that was true? I don't know) and see here about ethnicity. Neither is vandalism-like. BLP issues are not simple. Jytdog (talk) 07:42, 30 March 2017 (UTC)
@Jytdog: I feel that it is too extreme to remove this from ~5,000,000 articles because someone found 2 BLP violations. I definitely agree with you that BLP violations should not be permitted, neither here nor Wikidata. Has anyone proposed the BLP policy over at Wikidata? Assume that this is removed, what would you then do? Laurdecltalk07:52, 30 March 2017 (UTC)
OK, you don't understand the problems here. Thanks for talking though. 07:56, 30 March 2017 (UTC) — Preceding unsigned comment added by Jytdog (talk • contribs)
Slightly rude, but I'll bite. Can you please dumb it down for me and make it more overly simplistic? Perhaps you could actually reply to what I said, namely introducing a BLP policy on Wikidata? Thanks. Laurdecltalk08:02, 30 March 2017 (UTC)
There are three different groups here, each of which have no control over the other. 1) en-WP; 2) WMF Reading team; 3) the Wikidata community. None of them can tell the other what to do. You seem to be suggesting that WMF Reading team "force" Wikidata to make dramatic changes in their policies. On top of that, it is hard to change policy. Wikidata is a big community that is very young, with almost no policy and no good way of making new policy, and people with their own set of very strong ideas and feelings. Doing something as radical as restricting editing fields or as huge as setting up a BLP policy there will take a very, very long time. And no one can make them do it, and they might never agree in any case. It is not any kind of real world solution.
The problem here is that on its own the WMF reading team decided to insert content from Wikidata that it doesn't control and that is uncontrolled by any en-WP policy and unmonitored by the en-WP community, into every single en-WP article viewed on a mobile, including BLPs. The WMF has no jurisdiction over en-WP content. What they have done here is an over-reach and one that puts en-WP and the WMF in legal danger every day. It was clueless. It should be stopped immediately. Jytdog (talk) 08:16, 30 March 2017 (UTC)
No, I'm not saying the WMF should force policy onto Wikidata (although it could because, as you say, BLP is a legal issue). How do you know Wikidata wouldn't accept a BLP policy; have you proposed it over there, on their Village Pump? I'll support it. Sidenote: Who cares if the WMF is sued, it's their responsibility. We can always fork Wikipedia. Laurdecltalk08:41, 30 March 2017 (UTC)
Yes they can, they can force anything they want, they own this place. Why do you not want to propose a BLP policy on Wikidata? If you can only consider one viewpoint and ignore any compromise or suggestions then I'm done as well. Laurdecltalk09:08, 30 March 2017 (UTC)
I would just care to say that the solution for BLP problems seems to be Pending Changes/Flagged Revisions/whatever. Getting rid of Wikidata is just admitting that 'the wikiway' doesn't scale towards BLP. Just because we have put a defensive mob in front of the en.wp wikiway, doesn't solve the larger problems of BLP on a movement scale. We are implementing the wrong solutions for the problem. —TheDJ (talk • contribs) 08:32, 30 March 2017 (UTC)
Any verify policy on Wikidata cannot help in this case, because the item description has no means of being associated with a reference to verify it. --RexxS (talk) 10:51, 30 March 2017 (UTC)
I've created a template to show what I think ought to be done. This template renders either the text of the first unnamed parameter or the item description from Wikidata if there is no parameter. It could be wrapped in a span to make it visible only in mobile view, but it provides a demonstration of a local override for the Wikidata description which is sorely needed. On the article Priyanka Chopra (Priyanka Chopra (Q158957)) it works like this:
{{DescriptionWD}} → Indian actress and singer (born 1982)
{{DescriptionWD |Indian actor and singer}} → Indian actor and singer
This is not a solution in itself, because the subheading in mobile view is not derived from wikitext. But it should be. --RexxS (talk) 10:51, 30 March 2017 (UTC)
While it is an improvement, it sidesteps the question of why we would ever take this language-dependent text from Wikidata in the first place. Fram (talk) 11:02, 30 March 2017 (UTC)
Indeed. I honestly do understand your antipathy to such procedures (although I don't share it generally), and in the case of item descriptions I am very sympathetic, because of the inability to associate them with sources. My intent was merely to illustrate how – given there exists a determination to make use of these descriptions in mobile view – we might restore control of what is displayed to the English Wikipedia. In many cases the Wikidata description is innocuous and serves to further disambiguate between articles like:
Newport, Rhode Island ("city in and county seat of Newport County, Rhode Island, United States");
Newport, Wales ("city in south east Wales, United Kingdom"); and
As far as I can tell this isn't mentioned in the discussion above; these descriptions are also used in the links dialog in VE. If you edit an article in VE, select "Newport", and hit Ctrl-K, you get a list of possible targets, with the description string attached. I'm sympathetic to this RfC and am leaning towards supporting it, but for completeness I should say that these descriptions are extremely useful in VE, and make adding links much more efficient. As written this RfC would not remove this function from VE. Mike Christie (talk - contribs - library) 13:18, 30 March 2017 (UTC)
Thanks. The idea behind the RfC is to disable the use of these Wikidata descriptions anywhere on enwiki, whether at the top of mobile articles, in search results, in the "related articles" (where they also seem to be used), ... And of course suggested future solutions should then also apply everywhere (if possible): whichever tool, code, toggle... populates these now, should fetch the text from e.g. a new template on enwiki instead of fetching it from Wikidata~, for every use of this text. The problem is the same in all cases, the RfC should apply to all cases, and the future solution as well (but the RfC is not strcitly dependent on any solution). Fram (talk) 13:29, 30 March 2017 (UTC)
I think I agree with you that if this RfC should succeed, the VE usage should disappear too, but I think it should be made explicit in the wording (and we might ping those who've !voted already so they can update their positions in the unlikely event they would change their views on that basis). Mike Christie (talk - contribs - library) 13:36, 30 March 2017 (UTC)
OVasileva (WMF) above says this feature "is designed to provide an at-a-glance article description... for people who feel overwhelmed while scrolling through the often dense and opaque lead sentences." It is not possible to "dumb down" every article to such a level, some topics actually need a little more explanation. Take an article I have been watching and editing for a long time, Christ myth theory. In the mobile view [3] the description imported from wikidata says "Opinion that biblical Jesus was purely fictional." Editors have spent years on the talk page and article space arguing about the definition of the theory and that description would not be accepted as accurate either by me or editors on the opposing "side" as me. I think it is outrageous that these simplistic descriptions are being added to every WP article on mobile view with no consultation or notice to the editors that write and edit the articles, yes it should be stopped, and reversed immediately.Smeat75 (talk) 15:22, 30 March 2017 (UTC)
In my view this problem was created by a combination of two local content issues: (1) infoboxes at the top of articles that, on mobile, mean you have to scroll down a long way to reach the lead sentence, and (2) cruft in the lead sentence (in overlong parenthetical remarks giving translations into other languages, birth and death dates, eponyms, or other extraneous information) that, again on mobile, mean you have to scroll down a long way to reach the meat of the sentence. These issues create pressure to show what the article is about earlier, and mediawiki responded to that pressure by grabbing a convenient source of information, the wikidata description. That was wrong, but we should still do something about the underlying issues. (1) could probably be fixed either technically, by moving the infobox down or minimizing it in mobile, or locally in a content-driven way, by changing our standards for infoboxes so that they start with a short description similar to the wikidata ones but locally sourced. (2) can only be fixed by changing our standards for leads to demand that the parenthetical junk be no more than a certain length. —David Eppstein (talk) 16:47, 30 March 2017 (UTC)
I agree that there's multiple ways to improve the experience - we've also been planning on displaying the lead before the infobox on mobile - we're currently testing this in beta mode on mobile if you want to take a look. OVasileva (WMF) (talk) 17:29, 30 March 2017 (UTC)
User:OVasileva (WMF) Thanks for posting above and communicating that the Reading Team is turning this off. I am closing this RfC, as its focus was a resolution asking the Reading Team to turn this off now. If you want to open an RfC to get feedback about "blockers", I suggest you open a new RfC here targeted to obtain that information. I suggest that you take your time and frame that request carefully. Many editors, including myself, don't understand exactly what you mean when you use terms like "blockers". I hope that your RfC also makes it clear that you will not turn this feature back on for en-WP without consent of the en-WP community. Thanks. Jytdog (talk) 17:42, 30 March 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal - non-requested automated messages on talk pages must be short
As more bots edit Wikipedia more often, I think we should be mindful of the ways that interacting with bots can take time away from human engagement in Wikipedia. As a general rule, messages from bots, especially if they are routine and posted 100,000+ times, should be short so as to minimize the amount of human time and attention that they capture. The time of Wikipedia editors is valuable and any small grab for time multiplied by 100,000 has a big impact. I wish to propose a general rule that could be expanded if there is community support.
Non-requested, mass-posted, automated messages on talk pages must be short.
Details can be sorted, but I mean that a message written by a bot and designed to capture the attention of thousands of users should be not more than about a sentence long.
I have just modified 2 external links on Gorham's Cave. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).
If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.
It is long and capturing too much volunteer attention. Research in eye tracking is raising awareness of how much time arbitrary decisions in online diversions take away from meaningful ways for people to spend their time. If someone reads or even sees this post that could take 15 seconds to a minute of time. Multiple visitors to a talk page might read the post, as it is persistent indefinitely and at current archiving rates probably has an average life of ~5 years.
The post asks for "source checking", where a human manually checks what the bot does. If a human does this task, that could take 2-3 minutes.
This is my own estimate, but my guess is that the average time consumed per talk page post is 1 minute. I think every talk page post will be viewed at least once for 15 seconds, many will be viewed multiple times by multiple users over a period of years, and in some cases some users will complete the sourcecheck task. Overall, I think guessing that each post consumes 1 minute is a fair place to start the conversation. Arguably the average time cost is higher.
This bot has made 700,000+ edits and is going to make millions more. If it edits 100,000 talk pages, then it consumes 100,000 minutes of time, or 1600 hours or 66 days. Also, the time it is consuming is time from the kind of person who would visit a Wikipedia article talk page, so this is the time of Wikipedia users who are among the 1% most engaged and whose time is most valuable.
100,000 minutes of time is too much time to give to this talk page post, when typically, the post needs no response at all. These posts represent one of the biggest content publishing pushes from a single project in Wikimedia history. Practically all Wikipedia editors who read talk pages are going to spend time reading these posts repeatedly for years, giving some amount of attention to them.
In 95% of cases there is no reason for anyone to interact with any of these posts. They do not contain information which is of interest to most talk page readers.
There is no plan in place to expire or remove these posts. Even if they are checked, they will continue to be read for years in the current plan design.
I am not aware of any discussion demonstrating mindfulness about how much editor time this bot is designed to consume.
To lessen the impact of the bot, I propose that its posts to talk pages be restricted. Perhaps restriction to one sentence is sufficient. Either it can say everything it needs to in one sentence, or otherwise, the one sentence can link to a more detailed log somewhere else for users to follow and read if they really want to spend their time engaging with this bot.
In the future, as a general rule, talk pages on Wikipedia should emphasize human to human interaction and work tasks posted to talk pages by bots should be minimally invasive.
I discussed this with Cyberpower678 at T161108 and they told me they wanted Wikipedia community consensus for change. I am asking now for support to reduce the bot's posting to one short sentence, like one of these -
I do not want to detract from the archiving project, which is important, but this is a big enough issue on a well-funded enough project that I think we can cut back to a sentence as an immediately measure then have longer discussions about whether more should be added back, if there is any dispute about exactly what should be cut and what is necessary.
Thoughts from others?
Operator comment: The settings for the talk page messages are controlled here, and it's documentation can be seen here. As a side note, the one sentence proposal of Bluerasberry is not feasible with current design considering that there are more than one links being fixed in most edits. This is in regards to sentence 1. In regards to proposed sentence 2, there is no archive log.
Also, talk page messages are only left when archives have been added or modified, and they're there for users to quickly be able to click on and verify their functionality.—CYBERPOWER(Chat)15:38, 23 March 2017 (UTC)
Cyberpower678 Can you comment on how feasible it seems to you that your current design process is likely to attract about 100,000 minutes of editor attention for every 100,000 talk page posts? Do you have a better guess for how much time your project is designed to consume? Blue Rasberry (talk)16:07, 23 March 2017 (UTC)
A user does not have to read the notifications if they do not want to. The notifications simply is there as a means to quickly verify the bot's edit if they choose to. The talk page messages provides tools for user to appropriately correct any errors found. Users would typically only read it once, and would be able to quickly identify any new message and act accordingly. So your estimate is likely smaller than that. The talk page messages can be shut off entirely too. It's all controllable on the config page I linked to.
There are a lot of organizations which post messages to twitter and Facebook to collect something called an Impression (online media). This is a contemporary advertising theory, and there is research describing how much thought people put into the messages to which they are exposed. I expect that posts on Wikipedia get read at least as much as something in a typical person's subscribed feeds elsewhere. If a message on a talk page lasts for ~3 years and gets read by 10 people for 6 seconds each over that 3 year period, then that adds up to one minute. Which of my numbers seem off to you? Does 6 seconds each by 10 users over 3 years per post seem excessive? What number would you tweak? Did your project do any calculation or put any thought into this yourselves, to present your own time cost estimate? Suppose that I am off by 50% - does a cost of 50,000 minutes per 100,000 posts seem reasonable to you? Blue Rasberry (talk)16:40, 23 March 2017 (UTC)
Comment - Better placed at WP:VPR unless you propose a change to some written Wikipedia policy. I didn't see such a proposal. Also seems of little value as a vague statement and should be framed as a proposal for change to the specific bot. ―Mandruss☎14:38, 23 March 2017 (UTC)
Oppose as a policy. However, address with any bot operators and during bot task requests as needed. Without defining "short" I see some regular talk messages that I don't consider "short" but don't think should be forbidden - examples: Suggest Bot suggestions, Tech News - and basically anything else that is opt-in. — xaosfluxTalk14:57, 23 March 2017 (UTC)
Weak Support Losing the many "walls of words" would be a relief, but I usually skip them anyway. That right there tells you the impact it has on me - I have trained myself to ignore these post whenevr possible. GenQuest"Talk to Me"15:24, 23 March 2017 (UTC)
Oppose as effectively unenforceable. How long is too long? are we going to set a hard byte limit on bot talkpage notices? There are other problems, as well. There is already a mechanism in place for bot best practices, the BAG. The idea that a new, permanent, policy is needed because of notices posted by one bot that the community and the WMF agree is doing necessary work is policy creep. Lastly, and most importantly, talkpage reading is not mandatory and easily ignored. If this is really considered a problem, then institute archiving on the page and let Cluebot or lowercase sigmabot take care of it. There's a certin elegance in letting a bot clean up after a bot, afer all. Eggishorn(talk)(contrib)16:59, 23 March 2017 (UTC)
Oppose - if some specific bot is giving messages which are too long, discuss it as you would any other issue related to a bot's behavior not being up to your standards. This would mean starting with a discussion with the operator, and if you can't agree, moving on to more public discussion. No need to make this an explicit rule. עוד מישהוOd Mishehu18:47, 23 March 2017 (UTC)
Oppose - A good suggestion, but a poor requirement. Sometimes longer messages may be due. Also, "short" is vague. — Godsy (TALKCONT)20:25, 23 March 2017 (UTC)
@Xaosflux, Eggishorn, Od Mishehu, and Godsy: Can you say more about why you oppose? Would any of you feel comfortable saying that you disagree with any or all of these premises?
If 100,000 long messages are posted to 100,000 articles, then over the life of the message, about 100,000 volunteer minutes will be consumed in the process. This is a significant amount of time and volunteer attention.
Volunteer attention, measured in time, is poorly spent engaging with automated messages of the sort presented by Internet Archive Bot as compared to other Wikipedia activities which the Wikipedia community encourages by placing into focus on this scale.
Assuming that the messages are consuming large amounts of time, and assuming that the time consumption is a problem to address, then shortening the messages is a viable way to address the issue.
Which of these, if any, do you doubt? If you doubt all of them, then it would be useful feedback for me to hear that you think that what the IABot is doing is practice that the Wikimedia community should permit or encourage. Blue Rasberry (talk)20:47, 23 March 2017 (UTC)
@Bluerasberry: My oppose was prior to the proposal being changed, I've stricken it for now - reason was that we should not restrict opt-in automated messages like in my exampled above to only be "small". — xaosfluxTalk22:28, 23 March 2017 (UTC)]
"Premise" #1 is a free-floating assertion with no evidence to back it up and supported by nothing more than assumed reading resources and back-of-the-envelope calculations. How are you deriving any of those numbers. Where is the data to believe that each message "consumes" volunteer minutes in anything like this amount? Premise #2 is a mere personal belief, again with no empirical data. Premise #3 is nothing more than a tautology. There is nothing in these premises to justify creating new rules. Here's a simpler solution: don't read the messages. Eggishorn(talk)(contrib)23:04, 23 March 2017 (UTC)
I don't insist that all premises be "proven"; I think reason and intuition are enough in many cases. But reason and intuition tell me that most editors actually read the whole message once, if that. After that they recognize it at a glance and they already know what it says and what its purpose is. ―Mandruss☎03:10, 24 March 2017 (UTC)
Personally, I usually don't either. If an editor tries to lay out their argument in terms of hypotheses and premises and suchlike, however, it is only natural for other editors to evaluate their arguments in similar terms. What I see in this set of premises is an editor raising their personal distaste to universal commonality, which is a really big leap in logic. Eggishorn(talk)(contrib)15:36, 24 March 2017 (UTC)
Eggishorn You are correct - I used poor word choices and I did not communicate effectively. I wish that I could step outside this conversation and ask you somehow if you understood my intent, because I feel like I presented arguments that you are parsing as equations when actually I was trying to raise concern about a recurring social issue. Do you do video or phone chat? I will email you and ask. If you really are interested in this conversation, one point that you raise which I can address is a better calculation. The most solid number that I have is that 100,000+ messages are posted to talk pages. I hope that I could get you to agree with an assumption that these messages are viewed on average for not less than 1 second each, which is less than the 60 seconds which I imagined people like you would take as conservative. If the number is 1, and not 60, then the time cost is still 100,000 seconds or 27 hours. I would argue that this is not time well spent, and that we should not permit or encourage processes which are designed to consume time in this way even if it is in small pieces from many people. User experience is not enhanced by subjecting them to messages which are designed to not be read, and if these messages are designed to be read and actually are being read, then they are consuming even more time and for no apparent reason. The novelty in this case is that whatever the effect, it is multiplied by 100,000 and planned for 1,000,000+ messages. Despite my inability to articulate the cause and effect as a matter of logic, does any part of this strike you as unusual and worth examining as a matter of policy? Blue Rasberry (talk)14:08, 28 March 2017 (UTC)
Oppose Saying this is a must is excessive. The postings shouild be as short as is clear, sets the right tone, and motivates people in a suitable way. I don't see that there is much time wasted, as on most pages I see them, the messages are ignored by others. Not only that, talk pages get only a few reads. Perhaps some talk messages could be hatted or closed once dealt with, so that others don't repeat any effort requested. Graeme Bartlett (talk) 10:19, 24 March 2017 (UTC)
SupportAsGenQuest stated above, i also tend to skip over these excessively large text walls; i've noticed many times the message given as the example at the beginning of this proposal, and as it's usually on pages i'm only visiting briefly, with no real interest in, i blur over the lines and move on; i'd be much happier to do that quickly ~ one or two lines-worth of quickly, rather than the dozen or more lines which are there. While the proposal as written does not define "short", i would think that any organisation such as the Internet Archive Wikipedia Link Archiving Project which is asking for help would see that a shorter, more definitive message would be better in terms of the help it generates. Speaking simply for myself, my definition of short would probably be no more than three lines and preferably less. Happy days, LindsayHello11:43, 29 March 2017 (UTC)
How about we require bot posts that start a section to begin the section header with "BOT:", except user warnings whose section headers are already "Month Year"? That would make for easier skipping. — Jeff G. ツ(talk)18:21, 1 April 2017 (UTC)
As well as doing some standardization and cleanup (doi 10.1234/whatever → doi:10.1234/whatever)
This is not, however, a proposal to convert bare citations to templated citations, e.g.
Smith, J. (2016), "Article", ''Journal of Foo'' '''23'''(3):1–23 doi:10.1234/whatever → {{cite journal |last=Smith |first=J. |year=2016 |title=Article |journal=Journal of Foo |volume=23 |issue=3 |pages=1–23 |doi=10.1234/whatever}}
only bare identifiers to templated identifiers, e.g.
Smith, J. (2016), "Article", ''Journal of Foo'' '''23'''(3):1–23 doi:10.1234/whatever → Smith, J. (2016), "Article", ''Journal of Foo'' '''23'''(3):1–23 {{doi|10.1234/whatever}}
I can't think of any reason why the unlinked/untemplated version would be preferred over the linked/templated versions, but I figured I'd at least advertise these BRFAS. Headbomb {talk / contribs / physics / books}14:09, 25 March 2017 (UTC)
There needs to be a way for editors to opt-out of this if a particular circumstance requires it. The easiest way would be to put the content in "nowiki" tags, which should be enough to tell the bot that it is not intended to be linked. Can the bot recognize and respect that? — Carl (CBM · talk) 18:40, 26 March 2017 (UTC)
AWB has the option to "Ignore external/interwiki links, images, nowiki, math, and <!-- -->". I can't see why that wouldn't be enabled during such a run. Headbomb {t · c · p · b}19:11, 26 March 2017 (UTC)
I do a lot of edit training mostly to or through the GLAM sector. My earlier edit training using the wikitext editor produced very few ongoing contributors. However, I now teach Visual Editor (VE) and this has been very popular (including the those previously taught the wikitext editor) and I am seeing the VE training producing more ongoing contributors (e.g. [4]) which is a good result for the VE. The stumbling block I am now enountering is these users increasingly want/need to contribute to pages in the Wikipedia name space, where the VE is not enabled. Here are some examples:
VE users cannot use the VE to report bugs or give feedback on the Visual Editor because it is located at Wikipedia:VisualEditor/Feedback, so who knows what bugs/feedback are not being reported because of this
the GLAM work is documented in the Wikipedia name space. So I have VE-trained libraries wanting to edit these pages about Wikipedia projects involving their library but can't. My only workaround is to redirect the page from the Wikipedia name space as a subpage of a User account (where the VE is enabled). See this example [5].
We need to reduce the barriers to VE users from being unable to contribute more fully. I note that Talk is not currently enabled for the VE due to the earlier plan to replace Talk with Flow (which appear to have been dropped). At this time, the VE is currently unable to produce indentation as the colon does in wikitext, so I am not proposing enabling the VE on Talk pages at this time. However, opening up the Wikipedia name space would facilitate greater engagement for our new VE cohort of contributors. Kerry (talk) 02:14, 30 March 2017 (UTC)
I think there are some problems with the sites you used for the copy (red links everywhere). But I copied this page into a the sandbox in my user space (i.e. still on the enWP site) and I didn't see any big issue with editing it in the VE. Kerry (talk) 03:23, 30 March 2017 (UTC)
The primary issue I found was that you can't properly indent comments in threaded discussions. Trying to add a comment here, for example, tried to add a paragraph one indent level back, and it wasn't obvious to me how to get it indented out again to the right place. VE also seems to add a lot of whitespace all over the place when editing, making the page very hard to read. SamWalton (talk) 10:00, 30 March 2017 (UTC)
If folks object to it being enabled everywhere, perhaps some method to enable it on a page-by-page basis where demand for such a thing exists? Lankiveil(speak to me)04:18, 30 March 2017 (UTC).
TheDj: Would it be possible to enable VE globally for a namespace, suppress the edit tab at the top of the page (so VE would work but you'd have to construct the URL), and then unsuppress on a page-by-page basis? Mike Christie (talk - contribs - library) 14:41, 30 March 2017 (UTC)
its software, with infinite resources almost everything is possible. But if it were easy to do, I'm pretty sure the VE team had done it by now, since it seems to align with their own desires —TheDJ (talk • contribs) 20:33, 30 March 2017 (UTC)
Oppose because it would cause VE to be enabled on some discussion pages where it doesn't and was never intended to work properly. Page-by-page enabling doesn't exist yet; also the proposer's suggested use cases involve discussion pages i.e. /Feedback and Teahouse. BethNaught (talk) 17:51, 30 March 2017 (UTC)
Oppose under the current rationale, because it is about talk pages (that happen to be on Wikipedia namespace rather than Wikipedia talk namespace) and VE can't deal with talk. No prejudice against relisting with a different use case. —David Eppstein (talk) 18:05, 30 March 2017 (UTC)
Oppose proposal as is - as far as training goes: train users that wikitext is a thing that they will need to learn if they want to do more then edit articles. — xaosfluxTalk02:30, 31 March 2017 (UTC)
"Fake news", a.k.a. any article that you disagree with, can be speedily deleted as a hoax, as long as you're experienced. You don't even need to be admin.
Of course, if someone else disagrees, they will try to delete it, but they're WRONG! anyway.
Last proposal: Repeal pending changes, and replace it with exclusively higher levels of protection. (It's to give more benefits to the experienced, even though I'm not explicitly saying that.) Anyone saying my proposal has under 20% approval has been looking at unreliable sources.
So, now that this proposal is done, read all the bold letters.
Consensus is that a file-autopatrol userright ought to be created that makes one's uploads automatically patrolled. There was also a suggestion that regular autopatrol should not patrol files but I am not certain there is consensus for that yet - a few users supported this proposal and others did not comment. Criteria for the file autopatrol to consider are understanding in file patrolling, copyright and fair use. Potential future projects that don't have consensus support yet (also per the following section) are to grant the file-autopatrol status by default to file movers. Jo-Jo Eumerus (talk, contributions) 10:11, 19 March 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
File patrolling was technically introduced almost a year ago (phab:T11501). The backlog of unpatrolled files, visible at Special:NewFiles, is very significant. Autopatrolled users have their files automatically patrolled, but there are many users who are trusted to upload files that do not meet the requirements for autopatrol (which is concerned with new articles, not files). Thus I suggest we request a new usergroup, "File autopatrolled", with a single userrright (to be created): autopatrol-upload that autopatrols upload of the user. This way, we'll cut down a lot on the new files to patrol. Cenarium (talk) 18:36, 10 February 2017 (UTC)
Support. Seems like a good idea. I don't think (article-)autopatrolled users should necessarily have their files autopatrolled either, since WP:PERM/A doesn't do anything to check that the editor is au fait with licensing policies etc. – Joe (talk) 15:52, 11 February 2017 (UTC)
Indeed these are very separate areas, in fact one would need separate userrights for patrolling uploads too, which should probably be bundled with the file mover usergroup. Cenarium (talk) 17:29, 11 February 2017 (UTC)
I can see the benefit of this in principle but there may be a difficulty in assessing a user's uploading experience. Files uploaded here may be transferred to Commons (sometimes wrongly leading to deletion there). Also, files uploaded here with a NFUR or with copyright outside the US are transferred to Commons when they fall out of copyright. Can an admin see the files I uploaded which were transferred to Commons on 14 January 2017? For example File:Boating in St Kilda, J Norman Heathcote, 1900.jpg. Thincat (talk) 18:17, 11 February 2017 (UTC)
Oh, well, in that case I am in favour, supposing the standard of approval is appropriate. (BTW I think the article autopatrolled criterion is too high I see the level has sensibly been reduced.). Thincat (talk) 18:32, 11 February 2017 (UTC)
Support - Nifty idea and potentially good in practice. Criteria to obtain this permission may be needed, nevertheless. I don't know what the standards should be, but the criteria would be related to copyright and fair use. I don't know how many people would meet the criteria; the number would be the same as that of template editors or as high as the number of PC reviewers. George Ho (talk) 06:24, 14 February 2017 (UTC)
Support - writing good articles and properly tagging uploaded images are two totally different skillsets and should not be bundled. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)
Support - Image copyright is a little trickier than print copyright (even allowing for some of the excesses and dubious interpretations of some extremist patrollers), but it should be simple enough to separate the sheep from the goats with respect to file uploading so that the goats can be more carefully minded. Carrite (talk) 21:13, 24 February 2017 (UTC)
Support splitting the current autopatrol right into autopatrol-upload and autopatrol-page (and having them separate permissions on enwiki). For other wikis which have just one autopatrolled group and want it to have the ability to do both, the two rights can just be added to it. If this comes up for a consensus check later I also support giving the autopatrol-upload right to file movers on the understanding that they are already experienced in this area. Callanecc (talk • contribs • logs) 06:02, 8 March 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Rename "File mover" usergroup to "File handler" and grant ability to patrol files (only)
Also to deal with the backlog of unpatrolled files. Patrolling files and patrolling new articles requires completely different abilities, editors with the file mover usergroup are knowledgeable about files and should be allowed to patrol files even if they aren't new page patrollers, and vice versa new page patrollers weren't vetted to patrol files. Hence I suggest to Nikkimariarename the file mover usergroup to file handler and grant them the ability to patrol files, while new pages patrollers would no longer be able to patrol files. Cenarium (talk) 21:18, 11 February 2017 (UTC)
I think this is getting too complicated - if someone just wants to patrol files, let them? The existing group can be used for that - if they are making bad patrols, it can be removed. — xaosfluxTalk13:05, 13 February 2017 (UTC)
I suppose this may make sense, but would users be given a newsletter and asked if they wish to get the new rights immediately, much like the grandfathering of the NPP rights? Because if not a massive backlog could ensue. -- IazygesConsermonorOpus meum13:10, 13 February 2017 (UTC)
Why not having two separate rights? Renaming a file is enough. Changing to "handler" would make things more complicated. Also, "file handler" is a little too new and needs to be practiced more. George Ho (talk) 21:07, 13 February 2017 (UTC)
We don't bundle page mover and new page patrol, so there's precedent for making them separate. But part of me says we're unbundling a bit too much. The suggested "file patrol" and the above "file autopatrolled" should be one right. Unlike article patrol where one can be good at identifying good articles/cleanup tagging but not that good at writing content from scratch, someone familiar with the file licensing polices should be easily able to apply them to their own uploads. — Train2104 (t • c) 06:08, 16 February 2017 (UTC)
Echoing Xaosflux: Users who wish to patrol pages and demonstrate and understanding of what constitutes an appropriate page should be granted the new page reviewer user right. The right can be removed if they demonstrate a pattern of marking inappropriate pages as patrolled. — Godsy (TALKCONT)05:56, 25 February 2017 (UTC)
Oppose rename, simply for the reason that this seems to be a Mediawiki thing, so the developers might have to do a bit of work just to do the renaming. I see no reason to disagree with the idea of allowing filemovers the ability to patrol files. Nyttend (talk) 00:20, 11 March 2017 (UTC)
Blockers to having short description on mobile
Overall I think having short descriptions on mobile is useful. This is now turned off per the above. What things do people feel are needed before they would be comfortable seeing it turn back on again? For me it is:
1) The ability to JUST have changes to the definitions on WD occur in my watchlists. And for this to be turned on by default (with the option for editors to turn it off).
2) The ability to have a local short definition override the one from WD. This should not be associated with infoboxes for all the obvious reasons but could be template based.
as far as I'm concerned there were no blockers before, so neither are there now. Just wanted that noted, for all the thousands of ppl who did not ask for this to be disabled. I do think it's a bad idea to build a shielding layer that overrides Wikidata (again, flagged revisions-like solutions seem more suitable for this problem and could also deal with Wikidata property usage in info boxes perhaps). Inline presentation and editing might be nice enhancements (just append below the title, and only for autoconfirmed users initially). —TheDJ (talk • contribs) 20:23, 30 March 2017 (UTC)
And I am sorry that you cannot see what a breach it was of the basic relationships among the projects under the WMF umbrella, for the Reading team to unilaterally decide to tack content from a different project onto en-WP content and at that, content that is not governed by the basic policies of en-WP, and that is not generated and changed by the processes that have made en-WP whatever it is among the various WMF projects. I don't want to exaggerate but there was a constitutional crisis ~kind~ of thing underlying this. Jytdog (talk) 20:54, 30 March 2017 (UTC)
Fellow editors, this section is for discussing what you see as blockers to restoring the short definitions in mobile. User:TheDJ sees no blockers. Jytdog I would be interested in hearing what you think would be required before you would be okay with seeing the short defs return. Doc James (talk · contribs · email) 21:22, 30 March 2017 (UTC)
I should point out that these definitions are still visible in VE, in the link dialog; they have not been disabled there. I would think the argument to disable the short definitions would apply in VE too. Mike Christie (talk - contribs - library) 21:24, 30 March 2017 (UTC)
Edit an article in VE, type in Newport and select that, and press Ctrl-K to bring up the link dialog. You'll see a list of possible link targets, each followed by the short definition. Mike Christie (talk - contribs - library) 21:29, 30 March 2017 (UTC)
there are people who want this field drawn from Wikidata, and to be good and useful (e.g. this comment from User:PrimeHunter) and having a local override is .. not elegant, breaks things etc.
these same people generally want to have the en-WP community monitoring these fields and editing and improving them. They see that as a win for everybody, as this label can be used in lots of places.
from that perspective, making the label visible in desktop en-WP and easily editable and not over-ridable is the way to go.
in my view, while i get that, i think these people fail to recognize that volunteer time is the lifeblood of this project and every WMF project, and that their line of reasoning is basically blackmail similar to the orangemoody scheme - it sounds like this: "I am going to stick some words from Wikidata onto this en-WP page. Fix it in Wikidata if it goes awry and if you don't, well too bad for en-WP". (I know that is not the intention, but as someone to whom Wikidata is peripheral and has no interest in it, that is what it sounds like to me.) It is siphoning off volunteer time and attention to en-WP to benefit Wikidata and whatever else people want to feed from that. My commitment is to en-WP. That is what I volunteer for.
What is more foundational are the basic "constitutional" issues here. Every project has its own consensus, own policies and guidelines, etc. Wikidata is a young project with few policies and will have its own trajectory in developing them. It isn't appropriate, and I have no desire to even try, to enforce en-WP policies in a project where en-WP policies have no consensus (the bedrock of all WMF projects) and do not apply - it is disrespectful to the Wikidata community and a clash of mission and values that makes sense for no one.
If there are aesthetic issues with presentation of en-WP articles in mobile, the right answer is for the Reading team to explain that and ask the en-WP community to add a new element to the Manual of Style - namely the "brief description" and that is something we can build with time. Or the like. Jytdog (talk) 22:40, 30 March 2017 (UTC)
If this is is done it should be done on-wiki. It just needs a simple template, something like {{lang}} which adds CSS that helps browsers decide how to display foreign language text. Then the CSS for desktop hides it, the CSS for mobile shows it. If editors want they can override this in their own CSS to either hide it in mobile or more usefully show it in desktop, to make it easier to spot and fix problems, easier to maintain a consistent style and approach which is badly lacking in these at the moment.
I thought the whole point of Wikidata was data. Data that could be usefully hosted off en-WP, so other language wikipedias could use it, and discussions about using Wikidata on en-WP have all been about such data. These comments are neither data nor useful for other languages. I can see why Wikidata might have its own descriptions but from just a short time browsing them they are unsuitable for use in articles, and absent the sort of editorial controls we have here they probably never will be suitable.--JohnBlackburnewordsdeeds23:14, 30 March 2017 (UTC)
Doc James, kind of yes, but your question is kind of... begging the question. There is nothing existent to "host" in my view. The label field in Wikidata is something that the WMF Reading team decided would be useful in many ways. One of those ways, was providing a mini-WP:LEAD for en-WP articles on mobile. (as I wrote above, in my view their decision to insert the Wikidata label into en-WP content on mobile breached fundamental norms about inter-project relations and governance. And as JohnBlackburne noted above, with these labels we are in a very different ballpark from data items like half-life of drugs.) It it not clear to me if the en-WP community will even want to have a mini-LEAD (it may well do, but this needs to be discussed), and if it does, the en-WP community is going to have to figure out how to create them, format them, etc. For sure, the Reading Team should explain why it would be good to have a mini-LEAD for en-WP articles, and what kind of formatting would be most useful for the Reading Team. When you get to all of that -- yes, the mini-LEAD would be native en-WP content hosted on en-WP, like all en-WP content is. Jytdog (talk) 05:36, 31 March 2017 (UTC)
". . . yes, the mini-LEAD would be native en-WP content hosted on en-WP, like all en-WP content is." I think that is the crux of this issue, and should be one of the main points of any RfC. Having en-WP edited outside of en-WP, without our even knowing about it or being able to see it here, is mind-boggling to say the least. First Light (talk) 06:08, 31 March 2017 (UTC)
I'll definitely support option 1, but I'm quite conflicted about 2. IMO the point of these descriptions is that they already exist on Wikidata and are very common. I would rather not have them than attempt to move them to enwiki, it would just add another thing that we're "supposed" to add to articles (i.e. infoboxes). I'd like to make two suggestions that should be implemented before the descriptions are returned:
Add an edit link next to the description so readers and editors know how to change it.
Enable this on desktop, since the majority of our editors (not readers) use desktop.
Some folks from the Wikidata community have responded and it is interesting to see how the WIkidata community views "BLP-like" issues. Laurdecl also found the policy proposal there (has existed since 2013) Wikidata:Living people. Jytdog (talk) 15:54, 31 March 2017 (UTC)
I think the original idea involves the fact that a mobile can quickly get the description from Wikidata without the overhead of downloading a big enwiki article. That allows (I think) the ability for a mobile user to find articles based on text in descriptions, and to choose whether to visit an article based on the description. Future developments are sure to want to automatically display more stuff from Wikidata in enwiki articles. A proper solution requires an option (default on) for an editor watching an article to also see only related Wikidata changes in the watchlist that affect text that could be displayed for a mobile user. For example, if someone changes the French description, people at frwiki would be alerted, while an English description change would appear in enwiki watchlists. Further, there must be a way that is clear and quick to temporarily suppress text from Wikidata being displayed while someone prepared to examine and fix the Wikidata is found. The "suppress" would prevent the offending text being shown on any platform (for example, it might be an egregious BLP problem or blatant vandalism). An alternative might be a system that is clear and quick to click a button at enwiki to temporarily wind back the last set of Wikidata changes. Johnuniq (talk) 02:14, 31 March 2017 (UTC)
1) Have discussion whether we even want such short descriptions, and what they should be used for (top of mobile, top of desktop, search results, related articles, ...?)
2) If 1) gives a "yes", design a method (probably a simple template) to incorporate this on enwiki. Collaborate with the WMF so that we produce something which they can use here and can use on other languages if they want it (not the other languages copying our descriptions, but the same template being used across different languages, to ease the technical implementation).
3) If wanted, do a one-time bot run to import the current Wikidata descriptions into that new template. The suggestion "2" by Doc James at the top is a worse version of this; why tell the WMF to write software that does "if template:description exists on enwiki, use template:description; else use wikidata:description" when you can much more easily say "if template:description exists on enwiki, use template:description" and don't bother with the second part? Like multiple people have argued, this is not the kind of data Wikidata was designed for, this is language-dependent data (or "text" as most people would call it) which can and should better be hosted at the language-specific page where it will be used anyway. Of course Wikidata is free to have descriptions if they believe this to be useful for them (we are not going to impose what Wikidata can have or not), but they shouldn't be used anywhere on enwiki.
Summary of my position: if it is decided we want this, we need to design a simple template for it on enwiki, and the WMF should use that and only that to populate the things until recently taken from the Wikidata descriptions. Fram (talk) 07:04, 31 March 2017 (UTC)
There is the consideration of "without the overhead of downloading a big enwiki article" I mentioned just above. Getting mobile correct is very important, and while obviously the situation where people can add damaging headlines to articles for mobile users while escaping enwiki scrutiny is untenable, importing all the data to here won't work. Johnuniq (talk) 08:00, 31 March 2017 (UTC)
I read your comment, but I don't think it is correct. If you read the article, with the description on top, you need to download the article anyway. And if you get the descriptions in search boxes, it is the software that fetches the description from either Wikidata or from the enwiki article, and only returns that description to the search results (or the related articles, or...). In what situation would you need to fetch the whole article but not display it and would thus fetching the Wikidata page instead (assuming that that is significantly smaller) make an important difference in overhead? The heav work would be done server-side, for the end-user this should make no difference (on the contrary, when you actually see the article, no link to Wikidata needs to be made for mobile views in my solution, while it needs to be done in the current situation). Fram (talk) 08:13, 31 March 2017 (UTC)
I see what you mean. I have only played with the mobile view and thought I saw a case where a mobile might get the wikidata directly. As usual, there does not appear to be a page outlining what it is all about, but I can see that a very fancy index (full text) would be needed for a server to efficiently find descriptions stored in enwiki articles for a search. Johnuniq (talk) 09:10, 31 March 2017 (UTC)
AFAIK, the search doesn't work on the descriptions, you search for article titles, but the search results include a short description to help you pick the right result. So no full text index is needed for this. And on the other hand, we presumably already have a full text index, since you can "search within pages" already! Fram (talk) 09:26, 31 March 2017 (UTC)
If you read the whole article then it has to be downloaded but that's not the case when the description is with search results. For providing fast search results it's very useful when there's a simply database lookup. ChristianKl (talk) 12:20, 31 March 2017 (UTC)
The idea behind it is worthwhile (for mobile viewers). It should in no way be dependant on Wikidata. Wikidata has no policies that would ensure the quality (and legality!) of the description in line with the various projects. Short of the active userbase of EN-WP going over to wikidata and forcibly installing all our policies, thats unlikely to happen (and would probably piss off the other languages too. There are almost no technical or policy-based reasons this cant be done here or at any of the other language versions of wikipedia through a template to be used by the mobile viewer. Its a fact Wikidata does not have a fraction of the ability to spot and fix vandalism OR NON POLICY-COMPLIANT CONTENT so anything like this needs to be somewhere where an active userbase is already curating the articles. Only in death does duty end (talk) 08:42, 31 March 2017 (UTC)
Pinging User:OVasileva (WMF), I mentioned above that wikidata shows up on desktop view in the search bar at www.wikipedia.org. That should be turned off too if consensus is not to allow wikidata to appear on enwiki. NPalgan2 (talk) 16:06, 31 March 2017 (UTC)
Howdy NPalgan2, I'm not sure I understand. Wikipedia.org is not English Wikipedia (more on Meta). Regardless, as others have mentioned in this discussion it appears that the Wikidata descriptions showing up in other parts of the interface (like the visual editor link inspector) are permissible. (I was wrong, see below) CKoerner (WMF) (talk) 14:56, 3 April 2017 (UTC)
Not really, no. The RfC was not perfectly worded, so we can't automatically assume that it applies to all instances of the Wikidata descriptions appearing on enwiki. However, there is no reason to believe that what is controversial in one instance would be suddenly unproblematic in another (say, in search results or as the descriptions on "related articles). It is much more likely that most people who wanted to get rid of the descriptions (temporarily, definitively, or as a Wikidata-driven item) wanted this to happen in all instances of these texts on enwiki (not on other sites, that's their prerogative). It would be best if for the time being, this was disabled on enwiki completely (i.e. the descriptions as given on Wikidata are not displayed anywhere on enwiki, whether in popups, text, search, ...). Fram (talk) 15:45, 3 April 2017 (UTC)
I mean, just look at recent examples; for 56 minutes today, Adam Sandler (BLP, viewed by 10,000 people every day) had the nice description " Doctor druing the death of the jews hail hitler". As long as this can't be controlled (corrected, protected, ...) at enwiki, this shouldn't appear anywhere on enwiki. Fram (talk) 16:07, 3 April 2017 (UTC)
I agree with Fram. I would be very sorry to see the VE link inspector usage disappear, as that's very useful, but I don't see how to justify exempting certain usages if the problem is not with the usage but the content. However, I think this RfC only applies to what it says it applies to. CKoerner, can you give a list of the different places this data is used on en-wiki? Perhaps some can be justified but it would help to know what the full list is. Mike Christie (talk - contribs - library) 16:57, 3 April 2017 (UTC)
Ah, sorry I misunderstood. I was trying to catch up after time away and assist Olga as she is out today. My apologies for not connecting the nuance in the discussion. As for the question on where else the Wikidata descriptions are used on English Wikipedia? The mobile web article descriptions (since removed), search results on the mobile web, and the visual editor link inspector (both mobile and desktop). The descriptions are also used in the wikipedia.org portal (pulling the appropriate language label depending on browser settings or changing the language in the search box). They are used in the mobile app for searching and in the articles as short descriptions. CKoerner (WMF) (talk) 19:26, 3 April 2017 (UTC)
User:CKoerner (WMF) thanks for that info. As I have noted, in my view the decision by WMF reading and search teams to take that text field from WD (which is not "data"), relying on the WD community (which is young, is not governed by any policies that I have been able to find, and has really undeveloped/poor community governance processes) and putting all this weight on it, in both search and reading, was unwise and something you all should back out of. That field is very unreliable, and hanging these important functions on it runs counter to the mission of WMF which is to provide the public with accepted knowledge. I understand the temptation to reach for it, but in my view this is a mission-level fundamental screwup. Jytdog (talk) 18:00, 5 April 2017 (UTC)
Using Wikidata at all has been messy and controversial. Remotely hosting language-specific content doesn't make sense at all. The WMF has suggested moving the lead above the infobox, which may help. Perhaps the beginning of the lead can be grabbed as a "short description" to use in other places. If we do want to have dedicated short-descriptions for each article, then we should have a template for it. That template would be hidden on desktop, and that content could be grabbed for short descriptions on search results and elsewhere. (If the template is missing, just grab the beginning of the lead.) If we make description-templates, we could import the existing Wikidata descriptions. However rather than a pure bot job I would really prefer if it were semi-automated, with someone skimming to ensure that the short-description was roughly compatible with our existing lead. That concern is not just about importing vandalism - in some cases the wikidata item may not precisely match the article's concept. The description may have been written without even looking at the article here. Alsee (talk) 00:36, 1 April 2017 (UTC)
RfC about marking the Featured portals process as "historical"
Bencherlite: Thanks for bringing this up. I agree with you that there's unanimous consensus to tag Featured Portals as historical, but to draw further administrative conclusions from it would be beyond the scope of ANRFC. Since the discussion has itself fallen onto an archive page I don't think formal closure would be necessary.
But since you asked, as a passerby admin I spotted these possible follow-up actions from this RfC:
Deprecation actions: Something should be done with existing featured portals, for example giving them a badge of recognition that isn't quite the same as a full featured articles star. This and other actions directly relevant to the deprecation of featured portals would be best done boldly because the project itself fizzled out due to inactivity, so discussion without prior opposition would be unnecessary.
Maybe discuss the possibility of merging Featured Portals into Featured Lists.
Some suggested a radical action of deprecating portals altogether. This will also require a separate discussion.
As far as ANRFC is concerned I'm tagging this as {{not done}}. Deryck C. 17:29, 25 April 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Portal:Featured portals and related pages have just been boldly tagged as {{historical}}, as there has been a lot of time without any activity in them. This was announced at Portal talk:Featured portals, but being such a big step, it should be discussed at a more visible location, like here. First of all: which would be the best venue to discuss this and find out which is the consensus? A thread here, a RFC, some other location?
Second: do everyone in here agree with this? Should we support the historical tag?
Support marking it as historical since the process was (a) pointless (the proportion of Wikipedia's readers who navigate via portals is miniscule—even Portal:War, the most active of the lot, only gets about 300 views per day) and (b) completely moribund, although if you want to do it by the book just pick a page (here is fine) and put a {{RFC}} tag on it. Following the precedent of the killing off of Wikipedia:Featured sounds, just remove it from those places where it's currently listed. ‑ Iridescent19:05, 30 March 2017 (UTC)
(edit conflict with Iridescent, which whom I agree) In fact I also announced it at Wikipedia talk:Portal#Portals are moribund, an active conversation about the whole system of portals. My bold move today followed on from:
Since December, nobody has chimed in and there has been absolutely no interest shown by anyone in the process - no activity on existing nominations to add or remove featured status, let alone new nominations (and when one removal nomination is nearly 2 years old, that tells its own story), and no activity at WP:Portal peer review either (which has been dead for years).
I used to be very interested and active in the featured portal process. I created Portal:Law of England and Wales and got that to featured status, and I used to comment regularly on nominations (even closing them from time to time, and carrying out various clerical tasks to keep the process running and properly documented). However, I lost interest as has everyone else... not even points for featured portals in the WikiCup has been enough to spark interest.
As for the questions raised by Cambalachero: (1) here is as good a place as any; (2) we don't need "everyone" to agree, of course, merely consensus that the FPo process has had its day; and there's no point in anyone saying that the featured portal process should remain unless they can put forward some ways in which the process can be made meaningful; (3) If FPo is "historicalized", yes we should remove it from Portal:Featured content in the same way that the featured sounds process was removed after that stopped in 2011, and we can remove the bronze stars; the categories, templates etc can be tweaked or deleted as appropriate unless the FPo process starts up again. If someone is looking for bold type, support ststorical. BencherliteTalk19:31, 30 March 2017 (UTC)
Endorse marking as historical. There's nothing wrong with portals, except that almost nobody uses them or even knows they exist. Frankly, I didn't know neil right now that we ever had a featured portal process. Beeblebrox (talk) 20:00, 30 March 2017 (UTC)
I don't think the criticality parameter most relevant is of mass of editors, but the growth rate of new articles, which correlated to the growth rate of new editors, which ceased to be exponential in 2006-2007. --SmokeyJoe (talk) 20:34, 30 March 2017 (UTC)
"recently" in this context being March 2016, in fact... and in fact deterioration tends to come from neglect rather than editing e.g. the summary of an article that's used as a blurb in a portal which hasn't been updated to reflect developments. For example, according to the featured portal Portal:Barack Obama, he's still the President of the United States, and in Portal:Supreme Court of the United States Antonin Scalia is still alive... BencherliteTalk20:41, 30 March 2017 (UTC)
What's the point of keeping a bronze star on a portal when there's no process left to remove it? It just devalues the bronze star everywhere else. The promotion will remain documented in the article history on the portal talk page; for featured sounds, there was no article history on a talk page, so the template had to stay but suitably reworded. BencherliteTalk20:41, 30 March 2017 (UTC)
Either archive things as is, or do a review process and then archive. I don't see any risk of devaluing bronze stars. There will be reasons for few people to review the old Portals, and it is an important part oft he historical record which were featured. I wouldn't object to altering the star to a star with a date range for the period of time it was considered featured. I do object to altering an archive if it is to hide the fact that it was featured. --SmokeyJoe (talk) 22:39, 30 March 2017 (UTC)
Support. Those portals that got stars should keep an indication, but they should be very visually distinct from the true stars (i.e. an outline, grayed out, etc.) – Train2104 (t • c) 20:55, 30 March 2017 (UTC)
Is there a list of portals, featured or not, that are updated every month with new content? Do they have any impact? --SmokeyJoe (talk) 22:43, 30 March 2017 (UTC)
Comment - I'm not so sure that we should get rid of the Featured Portal process. I continue to maintain two featured portals, Portal:Maryland Roads and Portal:U.S. Roads. Also, if we were to get rid of the process, I'm not so sure I like the idea of removing the stars from the portals that editors worked to get. That is pretty much undoing achievements of those editors simply due to the increased inactivity of Wikipedia, though some editors may be doing their part to keep Wikipedia and the featured portals updated. If we were to go through with shutting down Featured Portal, I would still keep the stars on those portals that were featured at the time of the shutdown. Dough487200:43, 31 March 2017 (UTC)
Not opposed I've added articles to portals myself, a few times, mostly Portal:Guatemala; and as I did so I noticed the remarkably low activity. The page is currently getting an average of 20 views per day, and this is a country-wide portal. Most of these probably come from the fact that it is linked at the bottom of most sizeable Guatemalan articles, of which there are quite a few. The more obscure and specific a portal gets, the fewer things there are linking to it, and its utility declines. Personally, I do not ever recall using a portal for navigation. I can see why folks may be attached to ones they have helped create; but surely we could at least mark the unused ones as historical? Vanamonde (talk) 04:30, 31 March 2017 (UTC)
Support: I forgot to clarify it when I started this thread (it was Bencherlite who tagged the pages, I merely reported it because it deserved some discussion), but I do support tagging the projects as historical. I also support the idea of removing the stars in the process: as he pointed, many featured portals have low quality (a consequence of the lack of oversight, improving and watching). But perhaps we can replace that with a "hall of honor" page, that lists the portals that once achieved featured status. Or a navbox at the bottom, listing all those former featured portals, while also making it clear that their featured process is deprecated. Cambalachero (talk) 17:59, 31 March 2017 (UTC)
It's a tough call. On one hand, if it was doing a lot of good, one would think that there would be more nominations. On the other hand, it's not doing any harm to the project either. One could argue that it forces people to work on more "critical" enterprises, but I'm not sure I subscribe to that viewpoint. I do think that keeping the stars, but putting a disclaimer on them is a good compromise. --Rschen775401:07, 1 April 2017 (UTC)
Support: as someone who's created many many many portals it's with a heavy heart I say I support. I also believe that the feature status should be removed. Was a big supporter of these when they first came out... that's why I created many but I see that they're not used and nor are they maintained properly....with vandalism unnoticed a lot.--Moxy (talk) 17:49, 3 April 2017 (UTC)
Support proposal. In fact, all portals should be tagged as historical. Other than amusing some of the editors these portals serve no encyclopedic purpose. 106.209.153.61 (talk) 06:14, 5 April 2017 (UTC)
Support marking featured portals as historical and portals in general. Maintenance costs are exceeding benefits to readers, and there are now many alternatives to portals to easily navigate between related articles (categories, navboxes, lists, what links here, etc). ~ Rob13Talk22:40, 5 April 2017 (UTC)
Support, seems reasonable as there isn't much activity around this anymore. Regarding the stars, either remove them or leave them. I don't like the idea of using grey or outlined stars. Kaldari (talk) 02:02, 6 April 2017 (UTC)
Comment – A bit indifferent about marking the Featured portals pages as historical, but the featured portal stars should not be removed from all portals that have achieved this status as a broad-sweeping default that lacks any oversight other than simply indiscriminately mass-removing the star graphic. The latter would serve to unnecessarily denigrate significant work some users have performed on portals and in the featured portal review process. It would be quite unfair to those users to automatically dismiss and disqualify their work in this manner. Rather, featured portals could be de-listed on a case-by-case basis, via the discussion process, which could occur on talk pages or elsewhere. North America100007:10, 8 April 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Relisted merger discussion on "Infobox single" and "Infobox song"
Is it allowed? What are some of your ideas about this? — Preceding unsigned comment added by Dndm49 (talk • contribs) 15:28, April 9, 2017 (UTC)
@Dndm49: It is not allowed for various reasons. One of the major one being copyright. Wikipedia is licensed under the CC BY-SA 3.0 and GFDL licenses. These are "free" copyright licenses. Those YouTube videos are under the Standard YouTube License which is "All Rights Reserved". They are copyrighted under a license we cannot use. Most everything you find on the Internet will be copyrighted under an All Rights Reserved type copyright and is not suitable for inclusion here. That is why all media that is embedded into articles has to be directly uploaded to a Wikimedia server somewhere (either here or on Commons). That way there is controls. Media can be checked and ensured to be licensed under a copyright license we can use. --Majora (talk) 16:49, 9 April 2017 (UTC)
Videos can be inserted, but using a format that normally results in low quality or large size. We should keep an eye on when patents expire so that unfree formats become free. It is a lot of work to make a video. There are also some useful animated gifs around. Graeme Bartlett (talk) 01:47, 10 April 2017 (UTC)
There are conversion tools if the only thing stopping you is file format. True, the free video file formats are subpar compared to other ones but if the copyright is there, a bad quality video is still better than nothing at all. --Majora (talk) 01:49, 10 April 2017 (UTC)
It would be useful if the main Wikipedia page about such a subject could be able to link to the specialized wiki about that subject, to let readers easily find the detailed in-world information about that subject, as within Wikipedia such information is liable to be deleted in a running edit war between inclusionists and exclusionists. For example, in the Pokémon field, some people think that in-world details about each Pokémon are specialized information but useful to some, and others think of it as『Pokécruft』and delete it. And mutatis mutandis for the other scenarios. If Wikipedia was allowed to link to those useful external wikis, that would give access to the full information for each scenario's fans without needing to clutter Wikipedia's server and without risk of it being deleted by exclusionists. But such links when put in, are often deleted. Please discuss this. Anthony Appleyard (talk) 23:26, 23 March 2017 (UTC)
Why would we link to any unreliable fan sites (which these wikis all are). The only wikis we may occasionally link to are tightly controlled, supervised ones, not truly open wikis. Links to wikia (and similar ones) should be removed from every article but the wikia one (and other very rare exceptions where the wikia is e.g. the source of a notable controversy). Fram (talk) 09:26, 24 March 2017 (UTC)
Your stance is not reflected in ELNO, so do not portray your stance as fact. We do routinely link to open wikis (some of which are at Wikia and others which are not) to provide additional information to the reader. (Or perhaps the word "open" to you means something other than "(most) anyone can edit"?) --Izno (talk) 14:05, 24 March 2017 (UTC)
To me, the Casualty Wiki and the Star Trek Wiki at least, seem to be of good quality. It depends on how well each wikia is supervised by its administrators. It looks that each wikia will have to be judged separately to see if it can be listed as reliable. Anthony Appleyard (talk) 09:33, 24 March 2017 (UTC)
(edit conflict) I'm with Anthony and particularly Izno on this. I do think that such links need to be carefully marked though, perhaps a template such as {{wikisource}} but with suitable guarded wording. You'll see that other respectable websites like BBC news: Kent have a section of external links, indeed so do we on some articles. We maintain WP:NOTCENSORED internally, so why should we prohibit external links, provided there is a suitable warning about (1) no connection to WP, and (2) content unverifiable by WP. Martin of Sheffield (talk) 09:42, 24 March 2017 (UTC)
I am not opposing linking to external links, which is standard practice. An external link is only acceptable if it would also be acceptable as a reference or a primary source, but simply isn't used as such. The Blake's 7 wikia has had 5 articles edited the past month, 4 by IPs. I see no reason to add a link to such wikis. Fram (talk) 11:15, 24 March 2017 (UTC)
I agree in the case of "Blake's" if those are the stats for activity. However, there are clearly wikis (Wowpedia, MemoryAlpha, MarvelDatabase, and Wookieepedia are perhaps the largest off-the-cuff) on the other end of the activity/stability spectrum which are clearly suitable for inclusion as external links here. --Izno (talk) 14:05, 24 March 2017 (UTC)
The amount of edits per day that a wiki gets, is not necessarily always related to how good the wiki is. If not much more new happens in that wiki's field of knowledge, i.e. if that field of knowledge becomes static, then the amount of edits per day (as distinct from people merely reading that wiki's pages) likely will tail off as the wiki's contents approach the best wording to describe that field of knowledge, perhaps with intermittent bursts of new editing when anything new happens in that field of knowledge. Anthony Appleyard (talk) 09:49, 6 April 2017 (UTC)
Support in external links on a case by case basis. THey would not have to fall into the same quality as references. The criteria should be that they are useful to the reader. Bias or speculation should not rule them out, but may need a warning next to the link. Graeme Bartlett (talk) 01:51, 10 April 2017 (UTC)
Remove the Citation needed template and make people use Citation needed span
In my opinion the {{Citation needed}} is unnecessary and hard to understand when it is used (In a paragraph containing a sentence that doesn't require a citation because it is obvious and a sentence that requires one, a person wouldn't know which part needs a citation). {{citation needed span}} is more understandable. For the 700,000 pages using {{Citation needed}} we can change them so that the whole paragraph is added to the span automatically by a bot. Uni3993 (talk) 04:57, 2 April 2017 (UTC)
Oppose both are useful, and I have no problem with allowing people to use either as they see fit. --Jayron3202:58, 3 April 2017 (UTC)
Comment How about a wiki markup tool which allows the editor to select the span and then apply the citation needed template by clicking the tool button, much in the way one would do for a subscript or reference? The tool could then automatically produce a dated markup. I would guess the majority of editors are not even aware that {{citation needed span}} option exists. If no span is selected it would default to the preceding paragraph. • • • Peter (Southwood)(talk): 06:26, 3 April 2017 (UTC)
Such a tool has been discussed for a number of years both among Wikipedians and developers. During this years MediaWiki Developer Summit it became much more tangible concept. This is on the radar of developers and is being taken into account in the long term vision of the software development. —TheDJ (talk • contribs) 08:00, 3 April 2017 (UTC)
If you haven't disabled the CharInsert gadget, you can get most of what you asked for easily enough, at least in the standard wikitext editor (not sure about VE or the 2017 VE-based wikitext editor). Stick this in your common.js:
Then look in the edit tools near the bottom of the edit form, in the "Wiki markup" section. If you highlight text it'll wrap it, but if you don't it'll just insert an empty template at the cursor instead of defaulting to the whole previous paragraph. When you save, Module:Unsubst will make it substitute into a dated instance of the tag. Anomie⚔23:33, 3 April 2017 (UTC)
Possibly mainly not used by people who don't know that it exists. I only recently found out by accident, though I have been using the basic template for years. It is the sort of template that one discovers by seeing it in use, then doing the same thing oneself, and that almost always means that one is exposed to the reasonless version, and then produces more of the same. It may be obvious after the fact that there should be a reason, but many things that should be are not. • • • Peter (Southwood)(talk): 21:05, 3 April 2017 (UTC)
It's not broken IMO. The great majority of the citation-needed tags I see are placed where it is clear what is meant. Nor is the "reason" field usually needed, since its clear what the reason is: there's no ref, and one is desired. Citation-needed-span is also good sometimes and should be popularized, I agree. The select-and-click markup idea sounds good too. However, the current Citation-needed-span makes the source text a little more complicated to read, if you're working in the basic editor, so that's a small negative. Herostratus (talk) 19:36, 3 April 2017 (UTC)
I'm not familiar with span, so I guess I shouldn't cast a "formal" "vote", but otherwise I agree with Hero's comments above. Besides, if one isn't sure what's being questioned, one can always ask the tagger or start a Talk page discussion. DonIago (talk) 20:27, 3 April 2017 (UTC)
I have found by experience that asking the tagger seldom gets a useful answer. If you don't get to ask them immediately they will probably have forgotten their reasoning at the time. Even tags I have made myself are often not clear when I come back later. • • • Peter (Southwood)(talk): 21:05, 3 April 2017 (UTC)
Oppose bot modification. In many cases applying a false span for the tag is clearly worse than not indicating a span at all. Alsee (talk) 16:15, 6 April 2017 (UTC)
Wikipedia is famous for "citation needed". Even non editors know it well, and have an idea when it could be used. Making it span only would put it beyond most editors skills. So please keep {{cn}} and {{citation needed}} Graeme Bartlett (talk) 01:56, 10 April 2017 (UTC)
Add quality criteria to WikiProject templates
WikiProject templates such as {{WikiProject Biography}} on article talk pages help project members by adding the articles to project categories and lists. However, many editors do not understand the quality criteria. They may just rate all short, boring articles as "Stub", all long, interesting ones as "C" and all others as "Start". The WikiProject templates include links to the quality scale, but most editors do not click on links like that, or give up when they see how long the instructions are.
This is to propose adding a [show] link to the project templates, as in the mock-up below, to open a standard definition of the chosen quality class:
This article has been rated as Start-Class on the project's quality scale.
Detailed criteria: The article has a usable amount of good content but is weak in many areas. Quality of the prose may be distinctly unencyclopedic, and MoS compliance non-existent. The article should satisfy fundamental content policies, such as BLP. Frequently, the referencing is inadequate, although enough sources are usually provided to establish verifiability. No Start-Class article should be in any danger of being speedily deleted.
Reader's experience: Provides some meaningful content, but most readers will need more.
Editing suggestions: Providing references to reliable sources should come first; the article also needs substantial improvement in content and organisation. Also improve the grammar, spelling, writing style and improve the jargon use.
This article has been rated as Low-importance on the project's importance scale.
Notes:
The [show] link will apply only to projects that have accepted the standard assessment scheme defined in {{Grading scheme}}, and will be implemented in {{WPBannerMeta}}. Projects with non-standard quality scales or criteria will not be affected
The [show] criteria will be in one place only, the {{WPBannerMeta}} template, not replicated in all the project templates.
The standard quality scale criteria defined in {{Grading scheme}} are extremely stable (i.e. cast in stone), but to ensure the criteria in the {{WPBannerMeta}} template are in sync with those in {{Grading scheme}}, we will make them both share the same text files.
Addition of the [show] criteria will cause an increase in page size for a talk page with just one project banner from about 30,000 characters to 30,500 characters on a desktop, and from about 21,000 to 21,500 characters on a mobile device. Since the main target is editors, and they will usually not use a mobile device to edit, we may suppress this feature on mobiles.
A lot of editors will still ignore the criteria, but more of them would check to see what their assessment really means. Assessment quality would improve. Aymatth2 (talk) 13:04, 8 April 2017 (UTC)
Comments
Neutral leaning support. I don't really have a problem with this. The only problem I can see going forward is that certain WikiProjects actually have slightly different criteria for each rating. The military history one seems to be the one most people go back to for an example of a well functioning project. Personally, I would rather see a uniformity towards the assessments but this is a step in the right direction. --Majora (talk) 17:10, 8 April 2017 (UTC)
{{WPBannerMeta}} takes a parameter "QUALITY_SCALE" that defaults to "standard", which is what most projects use. The proposal would only apply to projects that use the standard scale. I would prefer to keep it simple at this stage, maybe support non-standard scales later. Aymatth2 (talk) 17:38, 8 April 2017 (UTC)
Oppose I don't see the point of this. If people don't click on "Quality scale", that's because they're not interested in it, or remember what Stub/Start/C/etc mean from the last time they clicked on the link. There is little point in adding more clutter to banners. Headbomb {t · c · p · b}17:47, 8 April 2017 (UTC)
It does not add much clutter. A [show] link is more likely to get used because most editors know it will not take them off to another page, and perhaps because people like to check out hidden things. Of course, a lot of editors will just keep using their personal criteria anyway. Aymatth2 (talk) 18:11, 8 April 2017 (UTC)
Support provided that this is included as an option. Include a parameter "quality_info" or something which toggles in these descriptions if set to yes in the WikiProject template itself (i.e. not in each article, just in {{WikiProject National Football League}} etc). This lets projects with their own scales decide not to use these. ~ Rob13Talk18:00, 8 April 2017 (UTC)
We could add a "show_quality_info" parameter to {{WPBannerMeta}}, default "yes". Individual project templates like {{WikiProject Biography}} could choose "show_quality_info=no". But see above, this proposal would anyway only apply to projects that have chosen the standard scale. Aymatth2 (talk) 18:11, 8 April 2017 (UTC)
@Aymatth2: Yes, but many use the standard scale while applying different meanings to what the standard scale means. That's what I'm intending to address. Not to mention that individual projects may just not like the explanations being there. I would prefer default no, not default yes, to prevent unexpected changes. All active projects could be alerted of how to make the change (if they wish) via a talk page message. ~ Rob13Talk18:22, 8 April 2017 (UTC)
Some projects have their own definitions and override the {{WPBannerMeta}} default. But if a project template uses the default, the quality scale link will point to the standard definitions. This proposal only applies to project templates that link to the standard definitions. It gives quick access to the relevant definition. Aymatth2 (talk) 19:06, 8 April 2017 (UTC)
Unneeded given that quality scale is linked already. And I would oppose any bloat in the code sent out to the remove devices. Some of us have long and thin connections to the Wikipedia servers, so we can do without the extra delay. Graeme Bartlett (talk) 01:08, 10 April 2017 (UTC)
There is significant overhead in the data sent with a Wikipedia page. A talk page with nothing but one project banner, like Talk:Amapá mangroves, will be about 30,000 characters long for a fixed device. The definition would push that up to about 30,500 characters – an insignificant amount. The same talk page sent to a mobile device will be about 21,000 characters long, or 21,500 characters with the definition. Still, we could skip adding the definition for mobile devices. The feature is mostly aimed at editors, and most editors will be using a desktop. The fact that many assessments are incorrect shows that the link to the quality scale is not working. The hope is that a [show] link would work better. Aymatth2 (talk) 11:23, 10 April 2017 (UTC)
Oppose, for now – the information in the show section would have a tendency to content fork the page it was summarizing, for example, if it fell out of date. Also, if the criteria in the show section was edited directly by an editor, it could drift as a content fork from the actual criteria list. A link to the official criteria page, rather than a re-reporting of that criteria, is what is needed. I would support a proposal that I believed effectively synchronized the criteria on the WikiProject templates and on the criteria pages themselves. The Transhumanist12:16, 11 April 2017 (UTC)
@The Transhumanist: The [show] criteria will be in one place only, the {{WPBannerMeta}} template, not replicated in all the project templates. These criteria are extremely stable, but if there is a problem keeping the criteria in the {{WPBannerMeta}} template and those in {{Grading scheme}} in sync, we can have them both share the same text files. Would that address your concern? Aymatth2 (talk) 12:37, 11 April 2017 (UTC)
Aymatth2, you added it only conditionally. Synchronization isn't explicitly included in the proposal (to have the templates and criteria page share the same text files), and without synchronization to be implemented, my reason for withholding support has not been adequately addressed. With the existence of 2 versions, their content could drift apart -- what is needed is a single transcluded version. The Transhumanist13:38, 11 April 2017 (UTC)
Working with files in several Wikipedias, jumping from on wiki to another and trying to access file pages from articles, sometimes I've encountered a problem here clicking quickly on that logo to access the specific file page of the viewed file on Commons, but in result I just opened one more time the page File:Commons-logo.svg:( That's why personally I prefer to see that link pointing to the corespondent Commons file page of the viewed file, or at least to see it unlinked. XXN, 20:59, 4 April 2017 (UTC)
There is consensus to replace the magic links with corresponding templates, and to do this replacement via bot. The consensus for the bot extends only to the conversion of magic links, not any other ISBN/ISSN/etc tasks like linking things that currently aren't linked at all. ~ Rob13Talk18:14, 19 March 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In the RfC meeting for the Future of magic links RfC, it was agreed upon to disable magic links for the MW 1.28 release by default and begin the deprecation for Wikimedia sites. MW 1.28 was released 2016-11-28. I proposed a bot to replace the magic link to templates. See: Wikipedia:Bots/Requests for approval/Yobot 27 -- Magioladitis (talk) 09:10, 3 February 2017 (UTC)
I'm not seeing where the English Wikipedia had this "RfC meeting for the Future of magic links RfC" please provide a link to the RfC closure here, if there was not a community discussion here then spin one up. — xaosfluxTalk15:35, 3 February 2017 (UTC)
I understand that if the magic link gets disabled it will just revert these to plan text. I'm also in general support that having these be linkable text is a good thing, and that mass conversions would need to be handled by a bot. What I'm not see is community support for which mechanism should the new enwiki standard for presenting ISBN values. It could be a template, or a parser function to be, or a combination - a pseudonamespace, etc. It could be one of thees, supported by another one a is traditional for a module in a template. I don't have any strong preference for which one to use - just that it has widespread support. — xaosfluxTalk15:51, 3 February 2017 (UTC)
I'd agree with this. Replacement of the magic links in general with something else is probably not something we get to decide on, what the "something else" is on the other hand... Jo-Jo Eumerus (talk, contributions) 16:18, 3 February 2017 (UTC)
Discussion on how / if to replace magic links
My vote is using a template. It's consistent with how we treat other citations already and it allows page-level tracking of usage. We now have Template:ISBN and it's been working fine in live articles. Assuming that MediaWiki will no longer support magic links, does anyone object to using templates for their replacement? --MZMcBride (talk) 21:43, 4 February 2017 (UTC)
Support Seems like a sensible idea, as Jo-Jo says, it should be the same for each of those magic links. Regards SoWhy16:27, 5 February 2017 (UTC)
Support. We should also have a bot convert all future instances to {{}} format. I really wish this discussion had been better advertised, entering these things on mobile phone is going to be a big added nuisance. DaßWölf16:30, 5 February 2017 (UTC)
Coming back to this, I support the use of a template now that the deed has been done. However, I would be absolutely in favor of going back to using magic links if that's possible. DaßWölf02:25, 17 February 2017 (UTC)
Support conversion to {{ISBN}} and {{PMID}}, which provide error-checking that magic links do not currently provide. RFCs might need semi-automated conversion; I have read comments that some editors write something like "RFC 1048" but do not want that to actually link to https://tools.ietf.org/html/rfc1048. – Jonesey95 (talk) 22:37, 5 February 2017 (UTC)
Currently, if editors don't want magic linking of RFC links, I would expect they would use <nowiki> tags to suppress the links (e.g. RFC 1048). As long as the bots doing the replacements don't replace any text inside nowiki tags, I imagine this would work.Harryboyles04:35, 11 February 2017 (UTC)
Support the use of the template, but request widespread explanation of it. Some editors never use any formats for inline citations or bibliography lists now (e.g., Jane Austen article), and now they will need to learn a template. If a bot makes the change for existing reliance on the "magic link", perhaps it should be in existence for more than a one time use. --Prairieplant (talk) 20:46, 6 February 2017 (UTC)
Support use of {{ISBN}}, and a bot to go through and add the template to all existing ISBNs outside citation templates. PamD22:45, 6 February 2017 (UTC)
Support templates. It's simple and consistent with almost everything else. The others are range from gross to vile. Alsee (talk) 22:13, 8 February 2017 (UTC)
@Rich: This discussion is about how to replace magic links, not whether to replace magic links. Moreover, removing magic links at the MediaWiki level removes a headache in updating the wikitext parser(s), and therefore in updating VisualEditor and similar tools that ostensibly make it easier to edit Wikipedia. {{Nihiltres |talk |edits}}16:27, 2 March 2017 (UTC)
Maybe, but that begs the question of whether we should. This has been proposed on an obscure page on an obscure wiki, and supported by an atypical collection of editors, from a point of view of information purism, and being unable to code what looks like some trivial internationalisation extensions. Purism is inappropriate for Wikipedia. The attitude that "we cannot make this work for Arabic, so we refuse to allow it for English" - is also indefensible. The money that the Foundation has poured into supporting internationalisation should enable this fairly trivial function to work in LtoR, RtoL and boustrophedon. All the best: RichFarmbrough, 19:51, 2 March 2017 (UTC).
Support templates for all the disappearing magic links. It's most consistent with what editors will expect from other contexts, such as {{Imdb}}. Definitely a job for a bot. Cabayi (talk) 09:24, 23 February 2017 (UTC)
Support templates for everything currently handled by magic links, and by extension the creation of a bot to automatically wrap new instances of those non-magical links in an appropriate template. {{Nihiltres |talk |edits}}16:27, 2 March 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal to submit blockers on replacing our wikitext editor
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The Wikimeda Foundation is working on a new software project called New Wikitext Editor (also known as NWE, or 2017 Wikitext Editor). The "new editor" is being built as a new wikitext mode within the Visual Editor extension. This allows the WMF to consolidate on a single editor with both Visual and wikitext modes. The plan is for this to become the default wikitext editor in a few months. The current wikitext editor would be temporarily retained as an opt-in in preferences, but eventually the current wikitext editor would be removed completely. Please view mw:2017_wikitext_editor for a more thorough explanation of the project, as well as the WMF's reasons for it. The new editor is available for opt-in testing under the Beta features section of Preferences.
The WMF is still working on a number of issues with the new software, however over the last few months several editors have raised a pair of issues which (in my opinion) they have not constructively addressed. Both of these issues appear to be a direct consequence of designing the "new wikitext editor" as a mode within Visual editor. The issues are:
Slow load time, primarily on larger articles. Different people may experience different load times, but I will report my experience. With the current wikitext editor I am able to start editing the article United States within 3 seconds after clicking edit. (The toolbar at top took a moment longer to finish loading, but that does not obstruct editing.) The new editor took 30 seconds to load before I could begin editing. With the current wikitext editor it took 5 seconds until I could edit our largest article (List of named minor planets (numerical)). With the new editor my load time was 127 seconds.
Faulty previews. The new editor does not provide genuine article-view previews. Instead it uses the Visual Editor rendering engine for previews. This results in a large assortment of things that render incorrectly in preview, or fail to render at all. The WMF has been working to address these issues for years as part of the Visual Editor work, and they plan to continue hunting down and fixing many of these rendering problems. However the WMF has indicated that some of these rendering problems are CANTFIX or WONTFIX. They hope to address the common cases, and their goal is to eventually get 99+% correct previews.
The WMF has been developing a Technical Collaboration Guideline. According to the guideline, the community is invited to submit "actionable blockers" on any software project. These are issues that block deployment unless/until the issues are adequately resolved. This RFC is seeking consensus to formally submit the one or both issues as actionable blockers. You may support one issue as a proposed blocker while opposing the other.
EDIT FOR CLARIFICATION: The WMF has been developing a Technical Collaboration Guideline. It is currently a draft. At least one WMF staff member has been actively seeking to test the guideline in action (Qgil-WMF) and another WMF staff member subsequently requested removal of any mention of the guideline (Keegan (WMF)). Editors are reminded that it is merely a draft. This RFC could be interpreted by the WMF as a test of their draft best practices for collaboration with us, or it could be interpreted as some generic consensus on the New Editor's prospects for successful deployment if specific issues are or are not addressed, or it could be interpreted in some other manner. In any case, our goal is to work with each other as partners in a positive and constructive manner, seeking to serve our shared mission to the best of our ability. Added: Alsee (talk) 20:27, 19 January 2017 (UTC)
Proposals:
Actionable Blocker: Load time. Load time is a priority concern for both new editors and experienced editors. Possible resolutions:
We could happily retain our current wikitext editor; or
if possible, drastically reduce New Editor load times, particularly on large pages.
Actionable Blocker: Article previews. Previews are a critical part of the learning process for new editors, as well as a critical tool for experienced editors. Inaccurate previews will confuse, disrupt, and frustrate. Possible resolutions:
We could happily retain our current wikitext editor; or
previews must use the article-view rendering engine (this is called the PHP parser), as well as any other relevant parts of the article-view software stack. This fixes the assorted rendering errors all at once, and it ensures that previews remain synchronized with article views when any changes are made to the software.
Support both. The load time on large articles is gross, and using an entirely different rendering engine for previews was a bizarre design decision. Unless both of these issues are adequately resolved, our current wikitext editor is clearly superior to the proposed replacement. If it ain't broke, DON'T BREAK IT!Alsee (talk) 23:52, 16 January 2017 (UTC)
Support both Loading time is a problem with VisualEditor, I am guessing that it's a problem with Parsoid. And the preview engine should use the parser, not it's own software, otherwise it's just reinventing a wheel. A square one most likely. Jo-Jo Eumerus (talk, contributions) 00:08, 17 January 2017 (UTC)
Strongly oppose removal. To clarify, strongly support both (03:58, 17 January 2017 (UTC)). On some very large pages the text editor takes a bit to load, let alone the JavaScript-heavy visual editor. The visual editor has its uses and I support keeping/improving it, but making it the sole option would definitely make it harder for me to edit. DaßWölf01:34, 17 January 2017 (UTC)
It is a mischaracterization to say that the WMF is making the VE the sole option--it is that both the VE and the 2017 WTE use the same root software. --Izno (talk) 13:43, 17 January 2017 (UTC)
Thanks for your reply, I wasn't aware that VE and 2017 WTE were different things. Still, new WTE also has bad loading times. For example, the minor planets list referenced by Yodin below takes about 20 seconds to render in reading mode, 5 seconds in normal edit source (less than reading mode!), 114 seconds in new edit source and at least 5 minutes and 12 timeouts in VE (I gave up). This page takes around 2.5 seconds in both reading mode and old edit source and 21 seconds in the new edit source. In both cases loading the new edit source caused prolonged browser freezing and delayed keyboard and mouse response as long as the minor planets page was opened in a background tab. I'm going with "don't fix what ain't broke" here. DaßWölf01:10, 18 January 2017 (UTC)
Support both. I'd rephrase the first one as "loading times must be less than or equal to the current wikitext editor". Previewing using Parsoid is a mind-bogglingly stupid decision, especially when proper previewing is just an API call away. MER-C02:59, 17 January 2017 (UTC)
Support load time as a blocker. Do not support previews as a blocker. Previews are pretty gosh-darn close. --Izno (talk) 13:43, 17 January 2017 (UTC)
@NaBUru38: You can preview your edits in WTE2017, though the workflow is a little wonky: Click "Save Changes", and in the box that pops up is an option "Show preview". There's a task open to pull the "preview" button onto the main editing screen at phab:T153306. The original poster of this discussion is making the distinction that previews are not 100% equivalent to the PHP parser (which is a fact, but lacking the context that something like 99%+ renders using Parsoid are correct), not that they don't exist. --Izno (talk) 00:27, 24 January 2017 (UTC)
Support both as I will any other reasonable measures that may achieve allowing us to "happily retain our current wikitext editor". — Godsy (TALKCONT)13:46, 17 January 2017 (UTC)
Weak support 2, wary about 1. Load times are going to vary from computer to computer and browser to browser, and I think it's hard if not impossible to explicitly say that a specific measured load time applies to everyone. I support the idea of 1, that load times should be at worst comparable to the current editor, but I'm not sure that in practice this is something that could be a certain result. As for 2, I'm fine with the current previewer (I assume there's a good reason for using it), provided it reaches parity with the old one and is consistent with the saved contents of the page. For the record I very much support the new text editor, and apart from the unintuitive copy/paste behaviour (being debated elsewhere I believe), will be happy to use it. SamWalton (talk) 15:48, 17 January 2017 (UTC)
Support both noting that 2 is particularly egregious. Also comment that I do not want the current wikitext editor to be dropped for a very long time. BethNaught (talk) 15:51, 17 January 2017 (UTC)
Support both Having a resource heavy GUI as the only option would prevent a lot of contributions from editors who don't have the hardware or bandwidth to handle it, which defeats the object of wikimedia encouraging grassroots participation. Not everywhere is wikisilicon valley. In addition inaccurate rendering of previews can cause countless problems, direct and indirect.Cesdeva (talk) 22:41, 17 January 2017 (UTC)
Oppose I've been using the new source editor since the beta was announced and haven't run into anything like the load times you describe. I'm also not sure the "preview" issue is nearly as serious as you present it; many of the cases in which the preview is substantively inaccurate are pathological in the first place (i.e. you shouldn't be doing whatever it is that's causing the renderer to barf). There are definitely some irritating usability issues, but neither of the items on your list seems worth throwing a wrench in the works over. Opabinia regalis (talk) 23:25, 17 January 2017 (UTC)
Support both. I have a decent computer, but don't have broadband, and decided to try both of the examples given above. United States: in the current editor took 4 seconds before I could start typing, and 6 seconds before the full page loaded; in the new Visual Editor text mode, it took 35 seconds! Then List of named minor planets (numerical): in the current text mode it took me 8 seconds before I could start typing, and 14 seconds for the entire page to load; in the new editor, it took 90 seconds before timing out, then timed out again at 120 seconds, and took about 122 seconds in total to load. As pointed out above, these figures are just anecdotal, but now that the issue has been raised, please provide reliable stats on a range of modern and old devices, at various internet speeds and in various countries – we don't want to become "Wikipedia, the encyclopedia that anyone with a fast enough connection can edit"! I'm genuinely pleased for people who enjoy using the Visual Editor, and wouldn't want to take it away from them, but likewise please at least provide an option that will allow me and others in a similar position to keep editing. ‑‑YodinT00:29, 18 January 2017 (UTC)
Speed varies considerably per account, browser, device, and location. For example, it took me just six seconds in Safari 10 and nine seconds in Firefox 50 to open United States in the wikitext mode of VisualEditor – much less than the time it took your computer. In Safari, VisualEditor's wikitext mode is slightly faster than reading the page; in Firefox, loading the page in read mode is one second faster than opening it to edit. The team has a standardized system for testing this. In general, the results are that short pages take faster than long pages; that VisualEditor is faster in Europe and Africa than in North America; that any method of editing wikitext is faster than anything that shows a lot of images (e.g., reading a page); that newer computers are faster than older computers; and that IPs and new editors have faster load times than experienced editors (who tend to have a lot of performance-harming scripts in their accounts). For a reasonable sample of pages (i.e., not just the longest ones), when editing as an IP (e.g., with no scripts or gadgets), with nothing else running (e.g., no other scripts running or tabs refreshing in the background), in a highly standardized setting, the time-to-open speeds are approximately the same for VisualEditor's built-in wikitext mode vs the 2010 wikitext editor. And then you impose all of the real-world, non-standardized conditions that affect each of us, and the answer becomes: Who knows? Your experience is your real experience, and whether your experience is fast or slow, it's not safe to assume that the next editor will have the same experience. Whatamidoing (WMF) (talk) 19:33, 19 January 2017 (UTC)
Oppose (edit conflict) both procedurally and on the merits. Firstly, the technical guide is still a draft, it's not a guideline like the proposer states. I think it's far too premature to start implementing things from it. Secondly, the draft says that『Development teams participate in the discussion focusing on the proposed blockers (whether they are sensible, consistent with the project, actionable, realistic…)』so I am hesitant to make any decisions until the proposer shows they've discussed this with the devs or until the devs actually participate in this discussion. Thirdly, the purspose of "actionable blockers" is that they be actionable, they, in my mind, need to have clearly defined criteria for when they have successfully been actioned. Neither the proposal nor the draft technical guide adequately lay out how it is determined that an actionable blocker has been overcome. The draft says: "If the development team solves the blockers, the community will be asked for a new review. If no surprises are found, the deployment will proceed." What constitutes "surprises"? What is the threshhold for these proposed actionable blockers? Load times are highly variable, how will we determine an adequate level of load time? What if we just happen to have a discussion full of people contributing via Windows 95 who oppose the re-review? More likely, what if we just keep inflating our standards saying it's not fast enough or the preview isn't good enough in order to filibuster implementation? Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]01:37, 18 January 2017 (UTC)
Support both. Both have long been known as serious VE problems, to introduce these (and other VE problems) into normal editing would be a very bad idea. Fram (talk) 09:32, 18 January 2017 (UTC). To be sure these are still problems, I switched on the new Wikitext mode again, and edited Leuchtenberg Gallery. Not only does it take too long (15 seconds!) before I can start editing, the preview doesn't give ma good idea of how the page will look eventually (e.g. by eliminating the left sidebar, increasing the width of the page). On a second try, I first did "review changes" and from that window "preview", with the result "Error loading data from server: Failed to connect." This happened three times in a row. I could still edit the page and review my changes, so connection wasn't really lost... On preview, I don't get to see redlinks. This is one of the essential elements of preview for me, as it allows the correction of bad links before saving. Opening Exposition des primitifs flamands à Bruges first returns the standard editor for some reason, a second try gives me the new wikitext editor, but only after 50 seconds, which is way too long. I added an image, asked for a preview, and again got "Error loading data from server: Failed to connect.". In standard editing mode (I at this point switched back, quite relieved that that option still existed) opening the page took a few seconds, previewing went without any problem and showed the page as it would look after saving, including redlinks and the like. Fram (talk) 10:00, 18 January 2017 (UTC)
Oppose. I use primarily use the Visual Editor for content work and find the Parsoid preview adequate 99% of the time. In the few instances where it's troublesome (e.g. not seeing references), there's a very easy workaround: save the page. Excessive load times are a concern, but the proposed "blocker" is too vaguely worded to achieve anything. It seems to me that submitting a phabricator ticket asking for it to be profiled and reduced would suffice (if one doesn't already exist). – Joe (talk) 10:12, 18 January 2017 (UTC)
A. It seems a bit rude for someone not affected by this change (since you are a VE user) to oppose those who are affected by this change. B. "Saving" is no workaround for previewing, previewing is also meant for testing, but the mainspace is no place to test things. Of course, one can copy a page to a sandbox, comment out the categories, and then start testing, but this is no longer an "easy workaround" but a lot of haasle. C. Excessive load times of VE have been noted from the very start of VE, and numerous times since then[7], but have four (five, whatever) years later not been corrected. Yet another phabricator ticket won't solve this. (the "redlinks should be red" issue has been a ticket for more than a month now[8], no activity as far as I can see; other issues also are already phab tickets). Note that the new editor also seems to break some well-used gadgets and tools like Twinkle, apparently (I haven't tested this). Fram (talk) 11:00, 18 January 2017 (UTC)
Fram, the new editor is an entirely new system. Gadgets and scripts will need to be rebuilt from scratch. That adds a one-time cost to switching, but I think it's fair to primarily focus on long-term pros and cons. (Although I'm not really seeing a long-term pro to the new editor.) Alsee (talk) 22:32, 18 January 2017 (UTC)
@Fram: I said primarily; I also use the wikitext editor so I'm as "affected" as anyone else. After seeing this I opted into the NWE beta and haven't experienced any appreciable slowness, making me think that this, like the very few edge cases where Parsoid previews aren't sufficient, isn't a hugely critical issue. We can't keep obstructing the WMF's efforts at improving our antiquated interface because the new versions have a few bugs. All new software has bugs. – Joe (talk) 09:23, 19 January 2017 (UTC)
Support both, On point one, as a regular editor from developing countries the last thing I need is even slower download times. On point two, I'm mystified at the idea of a preview function that doesn't render the page as it would if you saved it. -- Euryalus (talk) 11:14, 18 January 2017 (UTC)
Support both. Slower loading times are an issue for developing countries and mobile users who don't like the mobile interface (I know I'm not the only one). But having a preview that doesn't render the page exactly like it appears when saved (even if it is just a missing sidebar) is daft. As Alsee said, if it ain't broke, don't break it. There's no reason to eliminate the plain text editor; far from simplifying things, the proposal to ultimately eliminate it is a switch to a more resource hungry process for no real benefit. oknazevad (talk) 23:00, 18 January 2017 (UTC)
Support both The optimism that allows programmers to ply their trade often leads them down strange paths, but none stranger than thinking these features should be imposed on everyone, with performance details on the todo list. Just save your edits for a true preview! That must be what was behind the fuss a couple of months back when someone dropped into WP:VPT to tell template/module writers they should not show extra error messages during preview. Johnuniq (talk) 23:04, 18 January 2017 (UTC)
Support both per every single support listed here. I tried the new editor and did not enjoy it. If they do go ahead and bring the new wikitext editor out of beta, they must keep the old editor. —Gestrid (talk) 05:46, 19 January 2017 (UTC)
Support both These sound like serious issues that need to be addressed. Change always makes me a bit uncomfortable, especially when there are problems. Also Support keeping old editor, as I think many editors would consider leaving if it was taken away, and we already have editor retention problems. Tamwin (talk) 05:50, 19 January 2017 (UTC)
Support both. Just tried it, clearly noticeable speed difference and the "preview" is unacceptable. Echoing BethNaught in that I do not want to see the current source editor (which is actually functional) to be removed. In what ways is the new source editor superior, other than "easy switching" (which is negated by the long load times of VE to start with) and the toolbar (whether that is even superior to the current setup is debatable)? This is a sham referendum, not that I expect any better from the WMF. feminist09:38, 31 January 2017 (UTC)
Support both. Offer it as an option, but don't try to impose it on everyone, especially not with increased load times and preview that doesn't preview. SarahSV(talk)15:58, 31 January 2017 (UTC)
I'm also not sure the "preview" issue is nearly as serious as you present it; many of the cases in which the preview is substantively inaccurate are pathological in the first place (i.e. you shouldn't be doing whatever it is that's causing the renderer to barf).
I don't know what you use previews for, O. regalis, but a large part of their value for me is spotting errors of execution as well as errors of intention. For example, last night on my mobile I added a rather complex "cite" ref, incorporating a template call as the last item. When I tapped Next for the preview, I got an "unclosed reference" error (or whatever the wording is). It turned out that in the steps of constructing the ref, which involves a good bit more moving around on a smartphone than on a computer, instead of inserting the double double curly closing braces at the end (}}}}) I'd lost track and only inserted one pair (}}), and as a result the "</ref>" and everything after it got swallowed up as part of the citation. This is not "doing something pathological that caused the renderer to barf" in the apparently snarky way you used it. This is called "checking your work", and we all should be doing it regularly.
Loading time. If you think it's slow on a computer, be glad you're not using a mobile. I get fairly frequent browser crashes, and I'm sure some of them are due to timeouts.
Support both. If WMF really does adopt the concept of project-by-project blockers, I would welcome that improvement. Here, I think both issues are meaningful, and I see no reason to implement anything that has significant problems. Most of us are here to edit an encyclopedia, not to beta-test software that does not even address the issues that we care about. --Tryptofish (talk) 00:03, 3 February 2017 (UTC)
Support load time as a blocker. I can live with the bad previews, but the slow load times will actually limit my editing activity. I frequently edit from countries where internet access is quite slow and having to wait more than a minute to edit a page isn't workable for me. I'm sure other people with slow internet access feel similarly. Kaldari (talk) 01:57, 12 February 2017 (UTC)
Strong oppose, we should keep ONE editing mode and ONE reading mode. On other Wikipedias have I noticed that it's possible to wright directly in to the text. This
causes confusion
the "direkt wrighting" will attract pure vandals
there is no obvious benefit, with a new way of editing Wikipedia
Note: Boeing720 explained[9] that they were attempting to oppose VisualEditor on EnWiki. Visual Editor is already here. This proposal is about a change to the wikicode editor. Boeing720, you may want to strike or revise your !vote here. Alsee (talk) 09:52, 21 February 2017 (UTC)
Alsee is 100% correct, like anyone who reads my explanation will understand. I made a huge mistake by turning the proposal. I Strongly support both. Sorry for the confusion I may have caused. Boeing720 (talk) 10:11, 21 February 2017 (UTC)
Strongest possible support on the load time. Long load times make editing a chore, so quick fixes of simple errors are likely to be left alone. Editing in general will be discouraged. Support on the rendering. VisEd still can't render links properly? After all this time, that is totally sad. SpinningSpark19:42, 18 February 2017 (UTC)
Support on load times. I have just come back from the Phillipines. It was nearly impossible to edit even with the faster load times of the wikitext editor. If the only option becomes an even longer load times less of the world is going to be able to contribute. Also there is no "color coding". The color coding of WikEd is essential. The cite tool still adds unneeded urls when the pmid is give (this too needs fixing) Doc James (talk · contribs · email) 16:12, 20 February 2017 (UTC)
Does anyone else think the current pasting behavior is weird, too? Whenever I copy a part of a page title and paste it, I want to get the text that I copied, not some empty bulleted lists and other wikitext cruft. Enterprisey (talk!) 03:03, 17 January 2017 (UTC)
Enterprisey, the WMF is aware of the copy-paste issue. They'll address it. The ability to paste something like a fully formatted table could be really nice in some rare cases, but plaintext is what we want in nearly 100% of cases. Right now they are leaning towards the idea that a single line copy would be plaintext paste, and a multi-line copy would be markup-code paste. (I think that's probably the wrong fix, but I didn't comment on that.) Another idea is that ctrl-V would always paste plaintext, and ctrl-shift-V would always paste markup-code. (That's probably the better fix, but it would be hard to discover that ctrl-shift-V even exists.) The WMF will happily give us whatever we want. Alsee (talk) 14:52, 17 January 2017 (UTC)
Once again, Alsee, you refer to a "large assortment" of rendering failures in the Parsoid previews, without providing a link or reference to help editors understand what you are talking about. With the exception of the fact that red links do not appear red (an obviously severe flaw that needs to be fixed), it seems to me that most of the issues that you are referring to are in fact obscure and rarely encountered. It would be helpful if you could link to or provide some examples of wikitext that does not preview as you expect. That way, editors can judge for themselves whether the problem is indeed as serious as you make it out to be. — This, that and the other (talk)14:02, 17 January 2017 (UTC)
This, that, I considered putting various examples in the RFC, but (1) I didn't want to bloat it up with a huge list, (2) the list that *I* happen to have compiled is an clearly an insignificant fraction of the issues that exist, and (3) I think the fundamental issue is broken previews, even if some of the cases are rare. I said in the RFC that the WMF is hoping to fix the common issues, and is aiming for 99+% accurate previews. If you think the exact list is important, then perhaps the WMF should compile a list. I'll happily contribute my pile of examples. Table of contents is missing. Redlinks, black links, external links, PDF links all show as plain blue links. Some links in the preview point to the wrong place... clicking them or opening-in-new-tab takes you to the wrong page. Markup on a link can completely break the link. Images can display in a completely wrong section (I haven't investigated why). Audio and video aren't included in the preview at all (they are replaced by a speaker-image). Oddly placed comments can break the preview. Some things that should be on one line are split onto multiple lines. Some elements - even entire paragraphs - can display in the wrong order. REFs can be missing from the reflist. I have multiple cases where it fails to render section-titles. Templating a template-name is is broken. Definition lists can render wrong. Some uses of elements like <code> <tt> and <s> can completely trash the preview. It can badly mangle table structure. Cases where stuff like <sub> doesn't get applied. Markup like #if can badly break if Parsiod doesn't like how it's arranged. And more. Some issues are related to Tidy, and the WMF is planning to remove Tidy, but so long as Tidy is part of the article view then Tidy must be part of the preview. And again, I'm sure the WMF can come up with far more examples than I have. And I'm sure that new examples will keep popping up. So let's consider the issue here as fix the endless render bugs that no one has listed yet, anywhere. In which case any particular list is irrelevant. Alsee (talk) 15:32, 17 January 2017 (UTC)
I would also add that I forgot to switch off the VE before editing the above section... and for some reason was given the entire html of the page instead of the wikitext of just the section, <!DOCTYPE html><html prefix="dc: http://purl.org/dc/terms/ and all. I didn't dare click preview... ‑‑YodinT00:34, 18 January 2017 (UTC)
It's a problem I've been experiencing since the last software deploy. I believe that Parsoid is showing us the internals of the page (incorrectly). I would guess there's a phabricator task for this problem at this time but I haven't gone looking (nor have I reported one). It is well you did not save; I find that bypassing your cache fixes the problem. --Izno (talk) 01:10, 18 January 2017 (UTC)
I tried the beta for this just now. I noticed the formatting issue when pasting text. That wasn't too bad but there was a major hiccup when I was using it to post an entry in a big RfC. There was an edit conflict and I chose the option to handle this manually. The resulting edit took an 86K bite out of the discussion. That was quite alarming so I reverted my edit immediately. I have stopped using the beta now as it's taking me too far out of my comfort zone when I want to get things done. Andrew D. (talk) 14:05, 18 January 2017 (UTC)
The Technical Collaboration Guideline is a document of guidance in communications that is in mid-draft and has nothing to do with this. It does not call for actionable blockers as framed here. Remove its mention, please. Keegan (WMF) (talk) 07:41, 19 January 2017 (UTC)
Specifically, the very first line says "This is a recommendation for software projects following the Technical Collaboration Guideline (TCG)". No project is following the TCG since the thing is still being written. More importantly, the guideline is not a guideline in the sense of the word that the English Wikipedia knows, a form of directive. It's help, that's all. To the point: you can't put something under rules it doesn't qualify for, and that aren't rules to begin with. Remove its mention in the proposal. Keegan (WMF) (talk) 07:49, 19 January 2017 (UTC)
Then consider this a Beta test of the TCG. A bit like we get from the WMF all kinds of software that is in mid-draft but which gets rolled out anyway... Fram (talk) 10:03, 19 January 2017 (UTC)
I think the entire mention could have been taken out and the intent of the request is clear - I still think that's the better way to go, but meh. What I do not want is to see this as any sort of test or use of the TCG aside from "as an example." If that is your intent, that's fine. I'm working on building collaborative frameworks for the future years, and great harm can come from using them before everyone agrees and we're all ready. I hope you can appreciate that perspective. Keegan (WMF) (talk) 21:02, 19 January 2017 (UTC)
This seems like a pretty pointless discussion, from a developer's perspective. Not sure what it is trying to accomplish. This feature is not being released yet, the feature is not bothering any of the people who are voting here, the previews will be aligned at some point in the next 1-2 years (mostly because maintaining 2 parsers is gonna be problematic), there is no plan to remove the current editor. If someone wants to be useful and constructive however, they could assist in some prototyping work, testing, design feedback etc etc. instead of nurturing your inner Statler and Waldorf. —TheDJ (talk • contribs) 01:49, 20 January 2017 (UTC)
"probably in mid-2017, we'll begin to provide it by default in place of the current wikitext editor"[10] If the WMF plans to roll out a new default editor in mid-2017, then early 2017 seems like the perfect time to discuss whether this really is fit to be the default editor, and which things surely need correcting before this can happen. The result of making this the default editor would be that new editors would encounter three editing environments instead of two (luckily we don't have Flow), as it has been shown here that there are circumstances where you always get the old wikitext editor, even if the new one would be the default. Sending out the message to the WMF that this is not acceptable is best done in time and not at the last minute (or even worse but rather typical, the WMF implements this, then a consensus emerges that we don't want it, the WMF refuses to roll it back because that would be too complicated or "confusing for new editors" or some similar excuse, and only after a long and bitter dispute does the WMF relent). This is a Beta, no one is arguing to end the availability as beta feature, but the stated plans by the WMF to roll out this out as the default in a few months time are simply premature. To dismiss this as "unconstructive" and "nurturing your inner grumpy old men" and adding the rather disingenious "this feature is not being released yet" (no, but it would be very stupid to wait with this discussion until it is released, wouldn't it?) is typical "shut up" behaviour of WMF supporters and not helpful, constructive, or open-minded at all. You could instead take the comments made in this very discussion as "testing and design feedback" and be happy that people care and voice their opinions. Fram (talk) 08:29, 20 January 2017 (UTC)
This is design feedback. An editor with broken previews and atrocious load times is clearly inferior to what we have, and should not be deployed unless the issues are resolved. Your suggestion that no issues should be addressed until deploy phase is silly. A primary reason the WMF has been developing the Collaboration guideline is to avoid having these sorts of issues (and RFCs) pop up at the last minute, during deploy. The best time to address issues is as early as possible, preferably during concept and design phase. Unfortunately there was no project page or information available until after it was built. Alsee (talk) 13:11, 30 January 2017 (UTC)
Comment - (sigh) I don't understand why there always seems to be so much effort going on in this project to create alternatives to things that already work fine. I hope this isn't where the money goes that is donated to Wikipedia, which I'm sure that the donators assume is used for maintaining servers and organizing the development of the encyclopedia. That said, load times of software under development are often high, because of bloat left in for testing purposes and emphasis on functionality over speed in early phases. We can only hope that sincere efforts at optimization take place before the deployment.—Anne Delong (talk) 12:40, 7 February 2017 (UTC)
Third blocker: undo no longer works?
Apparently from every page, if I am at "View History" (instead of "read") and then press "edit", I get the old editor instead of the new one. Apparently a page must be completely loaded in read mode before the new wikitext editor can be used. This would also mean that something like UNDO would no longer work when the new wikitext editor would be the only available editor. This seems to me to be a major blocker as well. Can others reproduce this and confirm this technically? Fram (talk) 11:18, 18 January 2017 (UTC)
You're mischaracterizing the WMF's plans re the new editor, so far as I'm aware. It is not that there will be no other way to do it, but that the wikitext editor which will be available when e.g. Javascript fails to load will be a simple and plain text field (rather than include the editor bar and other such items). That said, I have reproduced that error multiple times, though no discrete steps for it (I think it's just clicking the 'undo' button, but I could be wrong). --Izno (talk) 13:04, 18 January 2017 (UTC)
As long as the old wikitext editor remains, undo should keep on working, if they start it by default anytime the new editor fails (instead of e.g. only allowing it for people who have turned off the new editor explicitly). What their promises to keep the wikitext editor around are worth is anyone's guess of course. And obviously that "read - edit" gives a different result than "view history - edit" is perhaps not a technical blocker, but is it indicative of the total lack of adequate testing at the WMF, the thing that already sinked so many of their pet projects. The things that get discussed here are not exceptional occurrences or edge cases, these are basic functionality and actions. Fram (talk) 13:49, 18 January 2017 (UTC)
I agree that undo is a regression--and I think their intent to keep a basic text box form is pretty sound because we do need to provide some support for Javascript-less users. --Izno (talk) 15:08, 18 January 2017 (UTC)
Having activated and desactivated the new wikitext editor beta a few times, I now have all kinds of problems. At the moment, the beta (new editor) is activated: on most articles, I only get the old editor, and on some pages (e.g. Sumathi Murthy) I can,'t edit at all. This page has now opened in the new editor though (I thought it only worked in mainspace and user space?). Further testing confirms that I now can edit pages in the Wikipedia space with the new editor, but not in main namespace. I think I can safely conclude that this thing is far from ready to become a non-beta feature, never mind the default wikitext editor. Fram (talk) 14:28, 18 January 2017 (UTC)
Izno, Fram, I've also had issues where it seems random which editor starts up, and where turning the new editor on or off in preferences doesn't seem to take effect, among other problems. Bypassing local cache with shift-reload does not fix the issue. If it's a cache issue, it seems to be the server cache. I've also had cases preview fail to work at all, returning server errors. I suspect it's related to Parsoid, as I was trying to preview an article which the WMF had listed as generating a Parsoid roundtrip semantic error in their automated testing. Alsee (talk) 23:21, 18 January 2017 (UTC) On second thought, it might have been an article that generated Parsoid timeout in the automated testing. Alsee (talk) 23:45, 18 January 2017 (UTC)
@Alsee: Yes, there's a handful of tasks documenting issues related to the 'wrong editor' in Phabricator. With Fram however "activating and deactivating a few times", that's not going to go well, I should think, and I'm pretty sure I've seen advice regarding other "Beta"-tab projects to the effect of "try to avoid turning things off and on multiple times". --Izno (talk) 23:54, 18 January 2017 (UTC)
My biggest failure mode with VE is undo failing. If there is any cut & paste in my undo buffer, trying to undo that step often fails in an odd way, and I have to reconstruct my edits piecemeal. If that's what Fram is talking about, and it would apply to NWE editing, that seems like a major issue to me as well. Not as big a blocker as performance, but significant for complex edits. – SJ +22:28, 19 March 2017 (UTC)
There is no plan to remove the old wikitext editor
I have seen comments now on multiple pages that say something like, "eventually the current wikitext editor would be removed completely" – with the implication that this is definitely planned and will happen soon.
If we use a typical definition of "plan" like a "list of steps with timing and resources, used to achieve an objective" (to quote the article), then there is no plan to remove any of the wikitext editors from any WMF site. It would be far more accurate to say that the Editing department (and anyone who's been around computing for more than a few years) has a reasonable expectation that none of the current software will be used a hundred years from now, or even a few decades from now. So, sure, it's technically true that "eventually the current wikitext editor would be removed completely": someday, it presumably will be. However, it's also technically true that "eventually" I'm going to die (as will all of us) – and AFAICT it's still an open question as to which of those events will happen first.
On the other hand, I believe that we are all going to outlive the old parsing system, which is what the second proposed blocker concerns. They are planning to remove the old (HTML4-based) parser and to use (HTML5-based) Parsoid for saving all pages, no matter which of the many editing tools you're using. This epic project will certainly not be finished during 2017, but when it is finally completed, the odd differences between the two parsers will simply disappear. (One example: should [<!-- Invisible -->[Text]] produce a normal wikilink or should it display all the characters on the page or should it display the brackets but not the invisible HTML comment?)
If you are interested in this project, then I recommend that you join WP:WikiProject Check Wikipedia. The first major step in replacing the old parsing system is described at mw:Parsing/Replacing Tidy; basically, some typos in HTML codes (e.g., someone typing </br> rather than the correct <br>) will no longer be silently fixed. (NB: This initial set of disruptive changes would have to happen even if Parsoid didn't exist; the library is unmaintained and outdated.) Whatamidoing (WMF) (talk) 07:25, 19 January 2017 (UTC)
@Whatamidoing (WMF): When you say that Parsoid will be used to save all pages, do you mean that pages will be saved in Wikitext but rendered with Parsoid, or saved in Parsoid HTML and round-tripped to Wikitext for source editing? I hope the former, as the latter will inevitably cause dirty diffs, and if made retroactive will change historical Wikitext revisions. BethNaught (talk) 09:00, 19 January 2017 (UTC)
I mean that what we've called "the parser" for years (Parser.php and a string of other supporting pieces in that system) will be completely removed – gone, not used, completely unavailable, deleted from the servers, given a death certificate that lists bitrot as the primary cause of death, etc. If you use (for example) the oldest, Javascript-free wikitext editor to save a change today, the resulting wikitext revision is currently turned into HTML by the old parser so that a reader can read it. When (2018? 2020?) the switch to Parsoid-based rendering is completed, even if you use exactly the same editor, the resulting revision will be turned into HTML by Parsoid instead. This change should have no practical effect on most Wikipedians, although I suppose that people may someday wonder why "obvious typos" like </br> were overlooked in articles for years. The change will be retroactive in the specific sense that it will no longer be possible to use the old parsing system to render any pages, so if you go look at a revision from 2003, then you will see how Parsoid turns it into HTML5, rather than how the old parser turned it into HTML4. (This is not very different from what we have now, since "the old parser" has changed quite a lot during its existence, and there's currently no way for you to see the 2003 revision with the 2003 parser, either.)
Whether revisions should be saved in wikitext alone or simultaneously saved in both wikitext and HTML+RDFa was an open question the last time I heard anyone mention it, but not one that affects the editing experience. (The idea seemed to be that dual-format saving would increase disk use but might be faster to read.) A few years ago, the devs discussed someday saving pages in HTML+RDFa alone and then turning them back into wikitext whenever someone wanted to edit, but interest in that option was limited. Maybe it's something they should consider again in future decades, but I don't expect it to happen in the foreseeable future. Whatamidoing (WMF) (talk) 17:13, 19 January 2017 (UTC)
@Whatamidoing (WMF): If we switch both editors to use Parsoid, issue #2 will be moot (as you explained above), but it isn't clear to me that that is actually going to happen. Can you provide any clarification on that issue? i.e. is the Editing Team planning on switching the old Wikitext editor to use Parsoid? Personally, I haven't heard of any such plans. On issue #1, my understanding is that there is little possibility of further improving the load time of the new WikiText editor due to its architecture (since it has to load most of the VisualEditor code in order to function). Is that also your understanding? Has the Editing Team considered re-architecting it to address the load time concerns or is that not a realistic option? Kaldari (talk) 02:23, 12 February 2017 (UTC)
Hi, Kaldari: Replacing the old parser with a modern one (i.e., some modern one/not necessarily Parsoid) has been expected for some time (software is not eternal, bitrot is real, etc.), but I believe that the decision to replace it with Parsoid (i.e., a modern replacement that happens to be Parsoid) was officially taken last quarter. (That decision belongs to ArchCom and Parsing, not to the VisualEditor team.) There is some information on the plans at on mediawiki.org; IMO the more interesting and informative page is the one about the two-systems problem itself.
The VisualEditor team is not currently working on performance issues. It's being considered for the coming year, but I don't know what they'll decide yet. There are some resource constraints that make it a difficult choice (e.g., inability to instantly clone certain members of Ops. ;-) Whatamidoing (WMF) (talk) 18:40, 20 February 2017 (UTC)
Even if maintaining our "old" editor, have I experienced troubles at other Wikis, which uses more than one. All developments are not necessary good ones Boeing720 (talk) 00:52, 24 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Factual Accuracy indicator in the Revisions
Wikipedia articles undergo a lot of revisions everyday, and a casual reader going through an article has to re-check to be doubly sure about the veracity of everything he is reading. I propose the introduction of an indicator (ideally a symbol) beside the last revision which has been checked for factual accuracy, in the View History section.
Initially we can begin with Good/Featured Articles (which are subject to factual accuracy checks while nomination), and place a symbol besides the revision that granted the GA/FA status indicating that the article has been checked for factual accuracy till that point.
Subsequent edits can also be checked for factual accuracy by other trusted users (we may give the privilege to extended confirmed users to check the diffs since the GA/FA and ensure that the factual accuracy is still maintained). These users can then move the symbol to the newer revision that they are authorising.
In case the proposal turns out to be successful, we can extend the accuracy indicator to all the articles.
This can help improve the readability and trustworthiness of the encyclopedia. Here is an example - List of Delhi Daredevils cricketers is an outdated Featured List. The list is erroneous, incomplete and outdated and has not been actively edited post its successful nomination in 2012. It would therefore be ideal that a symbol be added besides [11] (the FL nomination revision) indicating that the article is factually correct as of this revision. Subsequent editors can continue editing the article, and trusted editors can move the symbol to a subsequent revision, post a fact check of the diff between the revision on which the symbol is currently placed to the current unchecked revision.JupitusSmart02:58, 13 April 2017 (UTC)
Well...one of our main disclaimers is in regards to the validity of the articles (we don't guarantee they are valid in any way). A GA and FA review already checks for validity. That is one of the main purposes of the reviews and no article should pass either of those (especially FA) if it hasn't been checked. The {{article history}} template also has a space for the revision that met GA/FA standards.
Second, who qualifies as a "trusted" user? This sounds a lot like expert review which was a failed proposal. Also, I don't speak for anyone else, but the articles I have brought up to GAs I watch like a hawk already. I would expect anyone who puts in the time to tidy an article up to a presentable standard to do the same.
If you do find featured content to no longer meet the GA or FA standards please bring it to WP:GARorWP:FAR respectively for review and possible demotion. Things get demoted all the time. Finally, our readers don't generally understand the inner workings of Wikipedia and few of them actually know that the article history exists. I'm assuming this icon would be for the readers? So sticking it in the history would be a little pointless. --Majora (talk) 03:25, 13 April 2017 (UTC)
A disclaimer that the data is invalid is okay and will continue to exist in my proposal as well. All I propose is adding a symbol besides the GA status granting revision, at which point the data is guaranteed to be correct. After that a 'trusted user' by which I mean any user who has extended confirmed status should be allowed to move the symbol to a newer revision after ensuring that the data added in between is also correct. As for readers, Wikipedia has 30,690,549 users of whom 137,379 are active. Assuming that a great majority of the 30,690,549 users had multiple accounts, it would still be a huge number. If we assume that at least these users know how to check the history, and if they do so while researching on some data, and find the convenience of having a verified revision, I believe then that the idea of checking the history to read the last verified revision will spread to other casual users as well. This will probably lead to lending Wikipedia more acceptability as an even more trusted source than at present.JupitusSmart05:25, 13 April 2017 (UTC)
Editors != readers by any standard. 99.9% of our readers do not have accounts period and only come here to read the articles. They have no understanding of article histories or the inner workings of Wikipedia nor do they care to learn. As for extended confirmed, 30/500 does not infer some sort of magic ability to tell what is correct and what isn't. There are plenty of extended confirmed editors who have zero clue. That level is an arbitrary level chosen by ArbCom for article protection purposes. It shouldn't be used for anything else. This really doesn't seem like a workable solution and I can assure you, Wikipedia's acceptability as a trusted source will always be as it is now. --Majora (talk) 20:40, 13 April 2017 (UTC)
This proposal is well intentioned, but not likely to go anywhere. Sure we could put some sort of indicator on versions when they do happen to get reviewed as GoodArticles/FeaturedArticles, but it would really be minimal value. Those versions will typically be years and years out of date. Effectively no one is going to be accessing them. It would take a vast amount of work to try and establish verified versions for any significant portion of articles, and it would be extremely costly to repeatedly re-review them up to a newer version. The only way old verified versions will get significant readership if the reviewed version is considered the default version. That's a non-starter because it would kill our process of continuing development of articles. Alsee (talk) 07:04, 15 April 2017 (UTC)
Hello, I would like to propose including the option "upright" in the menu "embedded file" of the editing surface for all Wikis, since I think one does need this formatting function quite often when illustrating articles. What do you think? As I'm not at all familiar with Phabricator, I would be very pleased if somebody could forward this accordingly. Best regards--Hubon (talk) 15:19, 12 April 2017 (UTC)
Can you give more context? I'm afraid I don't know what you're talking about. What would this option do, exactly? --Trovatore (talk) 22:40, 13 April 2017 (UTC)
@Trovatore: Sure, thanks for asking! When you want to add an image by clicking on "embedded file" (the image symbol on the editing surface), you already have a number of default functions you can select from. However, the upright option is still missing although used quite frequently. And that's what it's all about. ;-) Best--Hubon (talk) 15:48, 14 April 2017 (UTC)
The WMF has had this issue listed for at least three years. I added links above for two most relevant Phabicator tasks. Visual Editor is build on top of something called Parsoid, and Parsoid doesn't have support for it. I didn't try to fully sort out what's going on, but it looks like that don't want to directly fix it. Instead it appears they want to change or scrap "upright" itself. There is a three year old Mediawiki:Requests for comment/Square bounding boxes discussing various options for changing how thumbnails work. I wouldn't anticipate any imminent resolution. Alsee (talk) 21:12, 14 April 2017 (UTC)
@Alsee: Thanks a lot for your inquiry. Though I do wonder why it seems so difficult to implement this that they even consider discarding "upright"...--Hubon (talk) 15:45, 15 April 2017 (UTC)
(Talk) 19:16, 13 January 2017 (UTC)
Done. Thanks for your input, everyone! I've gone ahead and implemented the change. Mz7 (talk) 14:49, 21 March 2017 (UTC)
Not done--The proposal failed to gain consensus.Many editors have expressed a lack of any meaningful benefit/purpose ariving out of the change.Winged Blades Godric 06:42, 24 March 2017 (UTC)
ansh666 06:09, 1 April 2017 (UTC)
Moved from Wikipedia:Village pump (technical)
